Browse 554 attributed reviews, viewable separately for our classroom and online training
Our experience of switching to Stripe payments
Part two of a five-part series of blogs

This is the blog which I wish I could have read before starting to integrate Stripe payments on our website! It explains why I'm ultimately glad we went for Stripe, but also some of the things which are harder than they need to be.

  1. Our experience of switching to Stripe payments
  2. Background and reason for change (this blog)
  3. Enabling payments using Stripe
  4. Customising payments forms
  5. Conclusion - would I choose Stripe again?

Posted by Andy Brown on 01 June 2021

You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.

Background and reason for change

I thought it would be useful to start by showing how our payments used to work, and why we wanted to change.

Our old system

Our payment system for courses booked online (as opposed to donations) still uses WorldPay and/or PayPal.  I'm going to show the WorldPay option, since it's the one with which I'm most painfully familiar. 

Making a booking

After choosing to pay by WorldPay, you see this message on our site, showing that you are about to be redirected to another page.

Clicking on the button above to make the payment takes a user to the WorldPay site, but styled (at least to a degree) in Wise Owl colours:

WorldPay payment page

The WorldPay payment page for Wise Owl bookings.

If a user successfully makes a payment, they will be redirected to a success page on our site, and WorldPay will pass to us a transaction id.  If a user fails to pay they are redirected to a failure page and we have to reverse the entire transaction.

The problems with our old system

We've found three problems with the above.  Firstly, WorldPay is so hard to understand!  To give a flavour, here's part of the customisation page for our account:

Customisation page

All of the forms look as if they were designed in the era of mainframe computer systems, and have been reluctantly ported to Windows.  And don't get me started on what's it like trying to reconcile payments received!

Now seemed a good time to use software developed recently by one of the trendy new fintech companies, to make our development life easier. 

A particular driver was a coming requirement to take recurring payments for our skills assessment tests - I couldn't bear the thought of re-entering the WorldPay labyrinth!

The second problem was that I wanted more ability to customise the look of payment pages:

Customising look and feel

Even simple customisation like this took me ages, because the WorldPay payment pages are held on a different site (ie theirs).

Which brings me to the third, and biggest reason for changing: I wanted to be able to process payments on the same page. 

Staying on the same page

In the new system I want users to be stay on the same page when they click on buttons like this one.

There are huge pros - and cons - to staying on the same page.  On the downside you end up with reams and reams of messy JavaScript controlling what appears when, and where, but the big upside is that you don't have to pass choices made on an order form onto a separate payment page.

Keeping an order and its payment on the same page has one other big advantage: you can wait to log an order internally until you're sure that it has been paid for.

Choosing a new supplier

So that was the background to our decision to change payments provider. In browsing the Internet for a new supplier, some obvious names came up:

Supplier Notes
WorldPay FIS WorldPay are a respected name in the business, but as explained above we found their software to be old-fashioned and difficult to integrate.
PayPal PayPal are another huge supplier, and perhaps I should have investigated them further.
SagePay I was put off by SagePay by the fact that they are linked to Sage (the accounts software people), which will inevitably constrain the way the software is written and the mindset of its authors.
Square Square seemed a good choice, but seemed to be aimed at out-of-the-box solutions, whereas ...
Stripe ... eveyone seemed to think that Stripe was a more suitable choice for integrating into a website (more development needed, but more customisation possible).

I also liked the fact that Stripe are already a huge company (with market capitalisation of about $100 billion), despite having been founded in 2009.  So I signed up for an account, and was so taken aback by how easy the process was that I was hooked (little knowing that the pain that lay a bit further down the line).

Please note that this is just one UK web developer's humble interpretation of what seemed to be available as of May 2021!

This blog has 0 threads Add post