Web Payments: 2 Slow 2 Tedious
Your legacy checkout system is costing you customers, money, and brand loyalty. Here’s a solution.
Check our Kainos’ newest blog on web technologies, focusing on Web Bluetooth by Witomir Badowski here!
If you’re anything like me, you prefer to do all of the shopping you can online, because let’s be honest, machines are just much more efficient than boring old human interaction. But, it could still be better. Through all the online shopping I do, I’ve racked up a countless number of accounts, each of which has my payment details — granted many of them are probably out of date now.
In the Applied Innovation department here in Kainos, we’ve been looking into future web technologies that we think are going to be the most beneficial to web users in the next few years. With online shopping being an industry that raked in $2200 billion last year alone, it’s very important that the process from browsing to purchase is as smooth and as quick as possible.
Every single site I add my details to increases my risk of my information being breached and nobody wants that, right? So this is where the new Google Payment Request system comes in. If you think of a password manager that many of us use, it behaves very similarly. You add a card to your Google account, and then when you go to checkout on a website, it fills in all those tedious forms for you, leaving you just to hit pay. Boom, just like that, I can go to a new online store I’ve never visited before, and place an order within 3 clicks.
You might be thinking, well I use PayPal, what’s the difference in this new Google system? Well even with PayPal, you have to be re-directed by your browser to authenticate the purchase. With the Google system, everything is done in the same window. This Google system is also a W3C candidate to replace checkouts, so it’s very likely we’ll start seeing this crop up very frequently in the near future.
I experimented with this new system and was very surprised not only at how easy it was to implement, but at how well it worked in general. The interface is compact, and doesn’t over burden the user with many options. It allows the user to have multiple payment methods and shipping addresses, one of each being the “default” the browser will select when the payment pop-up opens. The only thing you actually have to enter is your CVC.
Why Bother?
You might be thinking, “Eh, my payment system now is fine, it gets the job done”, and you might be right, but the truth is — gets the job done — just isn’t good enough these days. People want to spend as little of their free time as possible waiting for web pages to load/process their transaction, and so even a single bad interaction with a checkout system can drive users away from your site forever. I know there are some sites I refuse to buy from because of convoluted, over-complicated systems.
Cart abandonment is a huge issue for online retailers, and thanks to some recent surveys, we can now get a feel for the reason behind why customers decide they’d rather buy nothing at all than deal with whatever system that site is offering.
Aside from cost related issues such as shipping and tax, the biggest offender relating to time issues seems to be “account creation” coming in at 37% of abandonment cases. With the new Payment Request system, accounts are unnecessary — your details are autofilled including address and email.
Second, at 28%, and the main problem that this API solves, is “too long/complicated checkout process”. The average checkout flow contains 23 form elements (Doesn’t that seem a bit much to you?). Streamlining your websites payment system to the new Payment Request API takes all the work out of creating your own system. This is very much something that we’ll all start to see much more of a benefit as more and more websites/apps implement it.
As for “trust issues”, your payment info is never stored by the retailer, only by the browser. The question of whether you trust your browser or not is one for another day, but I know for certain that I’m more comfortable with my payment info being stored with one company instead of all the websites I shop on.
Im sold. What next?
If you’re a small business owner, or are thinking about setting up your own online marketplace, away from the giant umbrellas of eBay and Amazon, there is no easier and more effective payment solution available right now.
Implementation of this payment system takes no longer than 10 minutes, a change that will prove useful for years to come. If you’re interested in how to implement this system in a project, I’ll now talk you through how I got on and things to watch out for.
The official Google documentation can be found here, although if you don’t really care about the how and why, and just want to know what you have to change in your site, then here it is.
Yep. The barebones of the payment request API is only 6-ish lines of code. Of course this doesn’t actually do anything at this stage. We have to provide it with a few things before it can actually prompt the user for a payment. Price of the item, for example. So lets add that now…
We’re now up 20 or so lines (depending on how you as a retailer make use of discounts/special rates etc.) and we’re almost done. All thats left to do is close the window after the user is done with the payment.
All done. This will get you support on Chrome, Firefox, Edge, and Opera, with the lines of code following line 25 allowing for graceful degradation in the form of your legacy checkout method. Of course, these days, it would be foolish to neglect the l̶a̶r̶g̶e̶s̶t̶ loudest demographic : iPhone users. Unfortunately, the above code does not accommodate iPhone users and as can be expected, Apple aren’t as lenient with who they will let make use of their Apple Pay platform. They require certificates and have their own JavaScript API that they want you to use. Luckily, there is a solution that will allow you to use both the Google API, and Apple Pay symbiotically.
After you’ve collected the customers information, you then have to charge them. You can do this however you like, through any payment processor, but I found Stripe to be the easiest to work with. Stripe provide an API called elements, that combines the code needed to complete a Google Payment Request payment, and also an Apple Pay payment. It will even change the style of the button on the fly based on what browser the customer is using.
So what does the code for this Stripe API look like? Well, fairly similar to the above code snippet, meaning you don’t have to essentially duplicate the code just to accommodate Apple’s slight differences in notation.
I have purposefully left out the actual “charging” the customer section of the code, because how you use the customers details will vary from retailer to retailer, but if you would like to read more on how Stripe handles charges, you can see their documentation on the matter here. If you aren’t a fan of Stripe, there are similar companies offering their processing services, Braintree for example.
What does this actually look like?
It’s all well and good me throwing code snippets at you, but at the end of the day if you don’t like how the system looks, then you aren’t going to use it. So here are 2 different examples of how the PaymentRequest system will look to your users — on iPhone and Android (Desktop version can be seen here)
On iPhone the system appears just how any other Apple Pay payment would, a modal appears, prompts the user for fingerprint confirmation, and then the transaction is completed.
This is the Payment Request API running on my Pixel XL. As you can see in this GIF it’s possible to swap between several payment methods effortlessly.
It should be noted that the Google PaymentRequest API is still in development, and so, the above code snippets may become out of date (Highly unlikely, unless there are major functionality changes). PaymentRequest is currently supported in Chrome, Edge, Firefox, with Safari support coming in the form of Apple Pay.
At the minute, there is no faster, more streamlined payment solution for small businesses. Large businesses can make use of this system too without having to depend on Stripe, so long as you have a way to process the transactions yourself. And the more vendors that start using the Payment Request system, the more the user is going to see the advantage of it. For such a small implementation time, it seems there’s absolutely no downside to this, so why not?
