This page has 0 threads | Add post

Blogs

Finding our blogs useful? Please consider helping us to share more!

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. Our experience of switching to Stripe payments Background and reason for change (this blog) Enabling payments using Stripe Customising payments forms Conclusion - would I choose Stripe again?

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.

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

Posted by Andy Brown on 01 June 2021

In this blog

Our old system
The problems with our old system
Choosing a new supplier

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.

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:

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:

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:

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.

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!

Parts of this blog
Our experience of switching to Stripe payments Background and reason for change (this blog) Enabling payments using Stripe Customising payments forms Conclusion - would I choose Stripe again?

This blog has 0 threads

Add a new post

BLOGS BY TOPIC

BLOGS BY AUTHOR

Background and reason for change

Our old system

The problems with our old system

Choosing a new supplier

Head office

London

Manchester