Payment request API with React
As a front end developer passionate about e-commerce platforms I had the chance to work on the development of a mobile booking flow and I soon realised that it’s very difficult to create a low friction experience with high engagement and easy to use workflow.
Reducing friction and making our user’s life easier when it’s time to make a purchase is fundamental. The checkout process is probably the most stressful step for our users.
The problem
People usually don’t enjoy the process of buying something on the web using their mobile devices.
They do not remember all 16 digits, cvv, expiration of their credit/debit card. Then the users need to add their contact details, billing/shipping address.
They do not trust the website: it does not matter if the website has the green locker on the navigation bar; the user experience and the user interface is always different because every website implements a different solution to resolve the same problem.
On top of this, users need to add the same information using different keyboards, dealing with fat fingers, moving through multi page forms. It’s a large set of information, always the same, tedious and repetitive.
Statistics
If we try to compare the desktop web site and the mobile website of a product I’ve worked on, we find a very interesting situation. Despite the mobile traffic is continuously increasing, the conversion on mobile web devices is pretty low. Now, I’m not saying that the mobile web product is badly engineered. I’m also not saying that we should compare the users base. People probably use the two products in two different ways and they expect something different.
I can probably give you the following rough statistic about a product I have worked on in the past. The mobile web traffic is 30% more of the desktop web traffic. The mobile web conversion is 60% less of the desktop web conversion.
If we now try to compare the native apps (ios and android) with mobile web, we can see something very interesting. On mobile web, the step conversion between the result page and the checkout page is the same as a native app, i.e. ~30%. Despite this, the step conversion between checkout page and payment confirmation is half, i.e. 30% on native app versus 15% on mobile web.
Other requirements
On top of all this, as developers we unfortunately have to deal with some business requirements that are not always simple to meet:
- guess the card type as soon as you start type the number
- validating the number
- guess when the number is complete so to jump the focus of the user on the next field
- add spaces between digits to change the syntax depending on the type of the number
These require always being up to date with new cards that banks are continuously releasing. Imagine also providing OCR functionality with the device’s camera.
Save the world from tedious checkout forms with Payment Request API! 💳
Payment Request API is not
Payment Request API does not integrate with a payment processor; it’s not going to replace Braintree. It’s not a new payment method, you will still deal with cards payment, Paypal, Android/Samsung pay, AliPay. It’s not a finalised standard: at this moment in time we have a working draft already implemented by 30% of the browser in the market. It’s not supported by Safari because the vendor (Apple) has implemented their own specific standard and payment method, i.e. ApplePay.
Payment Request API is
It’s an open standard already available in Chrome, Chrome for Android, Microsoft Edge and Opera. This standard allows users to pay in the way they want to pay and do it quickly and efficiently.
The browser plays a middleware role to help facilitate checkout at the highest friction point. It helps exchange sensitive information between the merchant, the user and the payment provider in a secure and sandboxed way.
It’s a native user experience. It will look and feel as any other native application. Despite being a native widget controlled by the browser, the merchant’s name, icon and url are visible, signifying safety through brand recognition.
A React high order component for it
React is great, I love the community and the good amount of library you can find out there. Despite this, sometimes it’s difficult to find a great solution for a problem you are facing. That’s the reason why I have decided to write a high order component [HOC] around this API. With a HOC you can encapsulate a powerful behaviour providing a cleaner interface and a easier way to consume a composable API.
On Github:
On NPM:
react-payment-request-api
React high order component that expose the payment request api
www.npmjs.com
Let’s get started
You can write your dumb UI component like this:
And consume it as follow:
As you can see, the HOC consume the config prop to enhance the interface and the behaviour of the dumb component. The HOC inject into the UI component three props: isSupported, show, abort. All the other properties provided by the parent component are spread down into the UI component, e.g. style.
isSupported is a boolean property that allow you to drive a different UI if the browser does not support the API.
show is the handler you have to attach to user action when you want to initialise and show the browser widget
abort is the handler you have to execute if you want to abort the process and close the widget prematurely.
Configuration
The config property is an object that describe which data should be driven in the browser native widget and the handlers that allow us to control some behaviours.
Before diving into the configuration I really suggest you to look into the native API documentation written by Matt Gaunt and Eiji Kitamura.
Now that you have an overview on how the API works, I suggest you to look into the documentation of the config property.
Conclusion
In this article you have learnt why you should decrease the friction of the user providing a simple to use experience and leverage the browser when it’s possible to behave like a native app. Given the fact that the checkout of a booking flow is one of the worst experiences a user could face on mobile web, we all should start implementing Payment Request in our applications.
You have also learnt how to consume a React high order component to implement the Payment Request API with few simple steps.
I really suggest you to have a look in the W3C documentation; despite the API is already stable in about 30% of the browsers, the standard is still a work in progress draft:
Now you are ready to decrease the friction of your customers improving the user experience and increasing conversion. So enjoy, consume high order components and make the money fly 💸.
