Payment Request API
By Bastian Brodbeck, Front-End Software Engineer
Introduction to the Problem
At GetYourGuide we are interested in providing a great experience for our customers – we want them to find fantastic activities on our website, be able to book these activities hassle-free and of course enjoy the activities when they take place.
Looking at the website, especially on smartphones, we see that there is one area that can be a real struggle for our customers: the checkout process. But is this a struggle we created or is checkout inherently complex in nature?
We know long forms perform badly on mobile, but having an easy-to-use checkout can be especially tricky to achieve in the travel business. It should not have too much or too little information, not ask for too much detail from the customer and yet be sure to ask for the things we really need.
A Little History
Let’s back up a bit, around 20 years I’d say, to the dawn of the World Wide Web. This was the ‘big bang’ for e-commerce, during what was a peak time for mail order companies.
With the World Wide Web, buying stuff suddenly got a lot easier. You would browse through the online catalog like you were used to (just in digital form), add your desired products to the basket (again as you would in a store, just digitally) and once you had everything you would press the order button.
With that, you would be prompted with a set of questions: your personal details, billing address, shipping address and payment details (be it credit card or invoice). Again this resembled the information needed from mail order companies, and I would say it was an exact copy of that process. Rightly so: it was familiar for the customer!
What has Changed Today?
Fast forward to today and little has changed. Sure, now there are thousands of great shops on the web, but this makes things even worse: it increases the number of checkouts where a customer has to fill in their information. You can create an account that will save your data, but shops do not share these accounts.
That means for every new shop you make a purchase from you have to go through the same steps to provide the data, just like 20 years ago: personal details, billing address, shipping address and payment details. And again looking at smartphones, with their increasing share of conversion, this can be a struggle.
PayPal and others offer a solution: have a special payment type which holds all the necessary information that can be requested (by every shop) to complete the purchase. The downside is that the customer still has to log in and sometimes provide a lot of information. This information is either missing or already exists on PayPal’s side – it is just not requested by the shop.
While there has been some progress in retail, and with native apps allowing us to easily pay with our smartphones with a mere press of the thumb, this is currently not the case on websites.
What is GetYourGuide’s Solution?
But what if we could store all the necessary customer information on the device that is used to make the purchase? What if we even already have that data, but just do not use it for that purpose? After 20 years of little to no progress, we might finally see a checkout revolution.
The World Wide Web Consortium (W3C for short), working with different browser vendors, came up with Web Payments and a draft of the new Payment Request API – allowing websites to request all the basic information needed for a purchase.
A couple of weeks ago, Google offered GetYourGuide an opportunity to participate in a Hackathon. They wanted to show us how they – together with the W3C – imagine the future of the checkout.
GetYourGuide was happy to send three of our front-end engineers to the Google office in Berlin. We were excited to see their vision for checkout and how to add that into our already existing flow.
Simplified, Web Payments works like this: the browser saves your personal information, billing address, shipping address and payment information in a safe way, and when a shop requests the data the user gets prompted to allow transfer of data.
This is done on the client side, meaning there is no communication to third-party providers needed and the data – once approved by the user – is just passed from the browser to the site.
A website using Web Payments can request that stored data, provide a list of accepted payment methods, process that data and send it to its server – skipping the checkout altogether.
After the introduction to Web Payments, we started to look at our code. Google promised that it would be fairly easy to integrate and, as a developer working in e-commerce for all of my career, I totally agree: I was able to wrap my head around it in less than 5 minutes! Our only challenge was adjusting our back-end to it, but here at GYG we have an expert 3-man team and we managed to add the API within 20 Minutes and adjust the flow within another 2 hours – faster than expected. If you are a developer, you will find an example later on in this article.
But we did not stop here! A proof-of-concept is simply not enough for us, so we decided to get all the kinks out over the next few days and make it usable for all our customers.
As mentioned, the Payment Request API is currently a draft, but of course Google did not invite us to participate if we could not use it. Starting with Chrome 53, the API was shipped on Android devices: so if you are running it on your phone visit www.getyourguide.com and book an awesome tour in your city! You may or may not book a tour that supports the new way of payment, because right now we do have to live with a few limitations.
A challenge we encountered with Web Payments, which is intended for the basic payment information, was handling both additional information and the overall flow. If an e-commerce platform needs more data (which we sometimes do) it still needs to acquire it as before: through the means of a form.
This is where you need to get the flow right. How do you apply Web Payments to your page if you need more than basic information during checkout? Do you add a custom layover? Do you add a step after the payment or before? There are no best practices yet with Web Payments and we will do it the wrong way first – we always do. But we will learn and will find the right flow over time.
Even if the API provides all the data, you still need a back-end endpoint that handles it all at once. This endpoint does not necessarily exist if your e-commerce platform offers multiple steps during checkout. Usually you split up your checkout forms and preset the customer information form first. The back-end then validates the input and, if everything is fine, sends the customer to the next step (usually payment).
If you get all that data with a single response from the Payment Request API then your back-end has to apply all of its logic in one step as well. Depending on what webshop platform you are running this might already be supported, or you may need to write it from scratch.
In our case, we had already experimented with a single endpoint and we were able to apply our knowledge and write it with little effort.
Then there was the big issue of validating the data passed from the API. While it makes sure you get all requested data, who’s to say it comes as you would expect it? You need a step in your flow that accommodates for errors and gives the right feedback to the customer.
Some webshops give the customer a summary of information provided in the checkout as a last step before finalizing the purchase. This summary page could be adjusted to give the user said feedback, for example if the payment failed due to insufficient funds or a malformed name.
It is these adjustment to your codebase, if they do not already exist, that take the longest when implementing Web Payments, not the actual requesting of data.
Is the Customer Happy?
We solved or technical issues easily but there was another challenge not related to the implementation side: the engagement. This is new technology, so how do you get a customer to engage with it? Will the customer accept this new way of checking out? Will the customer trust or understand the prompt shown by the browser? Is the overall flow understandable to the customer? This is a topic for UX.
To try and answer these questions we also need to ask some of ourselves. Do we add a second call-to-action button on the product page to allow for a simple ‘one click’ experience, knowing that multiple call-to-actions can be confusing? Or do we only apply it to the checkout? And we have to learn if we can force the customer into this new experience or if we need to give them a choice.
These are the things we need to learn – and again over time we will learn – and are important topics not just here at GYG, but for all browser vendors implementing Web Payments.
The possible benefits, on the other hand, are what should drive every e-commerce platform to implement Web Payments. It drastically decreases the steps from “adding to the basket” to the confirmation of the purchase. In the best case the user only has to grant access to the data. In the worst case the user has no stored data and it needs to be entered once – the first time they encounter the feature – and then never again
In my opinion, this is more than just an evolution of buying online. It is a revolution of the whole checkout process: reducing it to merely a few clicks.
On a smartphone, it is a delight to use. And although it is currently only available on Android Chrome, it won’t be limited to it for long. This being an open standard, it will be added to to all platforms and devices in the future. As Apple recently showed, Apple Pay has arrived on desktop and so will Web Payments.
Web Payments on the Android version of Chrome offers Android Pay, allowing websites to use the new payment method for the first time and not limiting it to Apps anymore.
This is the advantage of it being just a store of data: all the payment processing is still done by the website, no matter how it was done in the past. There is no need to have a special payment provider by the company.
So Let’s Get to Work
The developers among you might now be wondering: how do I actually use this Payment Request API?
As mentioned before, the Payment Request API holds all the necessary data and asks the user to pass it to the website. The layover that will be shown by the browser contains the total amount of the shopping basket, the items in the basket, as well as a selection of the payment method and the (optional) shipping address – optional for digital purchases like music or eBooks.
To trigger the layover you create a new PaymentRequest object, passing in the payment configuration array, a shopping basket object and an options object like this:
Calling the show function on our requests opens the layover and returns a thenable object. In case the customer cancels the request it will be rejected, in case the customer presses pay it will be resolved.
So your code could look like this:
And that is actually all the magic to it. If you have basic understanding of Promises you are good to go. In the case of fulfillment you get all the requested data passed as an object. You can try the example on your Android using the latest Chrome.
Of course, as mentioned earlier, this is not the tricky part. But now you have all the relevant data and you can transform it, validate it and pass it to the server the way you want it.
It should be reiterated again that the Payment Request API does not process the payment, it just holds the payment data saved by the browser, like the address and credit card number. Your back-end has to do the heavy lifting of the payment processing.
It is all about making your website a positive experience. With Web Payments, you can now ease the pain of checkout forms, making the booking a delight. Be one of the first to implement it with us and make your customers happy.