How to take payments on the web with the Payment Request API

A simple demo and how to get real

Paying for things online can be a pain, can’t it? You keep having to type out the same card details and contact details. It’s especially a pain on mobile — when was the last time you gave up filling out a form on your phone? (For me it was last night!)

It’s also a pain for us web developers, having to keep re-implementing complex checkout forms.

Thankfully, it should be about to get easier...

In our latest Samsung Internet release, we introduced support for the Payment Request API. It provides an easy-to-use, native UI that you can use to collect your users’ payment — their card details, shipping options, even their address and contact details.

A simple Payment Request demo

Our users can now have a more consistent, faster checkout experience. They can save their payment details securely in their browser, ready to use again on any supporting web app.

And as developers, no longer will we need to spend such time and money developing and maintaining a whole checkout process ourselves.

How does it work?

The core of the API is the new PaymentRequest method. First we should check if it's supported in this browser:

if (window.PaymentRequest) {
// We're good to go...
} else {
// Alas! Use your legacy checkout form...
}

Then when the user taps your pay/donate button…

// A couple of example payment networks (others exist too!)
var methodData = [{supportedMethods: ['visa', 'mastercard']}];
var details = {total: {label: 'Something that costs money', amount: {currency: 'GBP', value: '9.99'}}};
// Show a native Payment Request UI and handle the result
new PaymentRequest(methodData, details)
.show()
.then(function(uiResult) {
processPayment(uiResult);
})
.catch(function(error) {
handlePaymentError(error);
});

Update: You may see other examples which use basic-card for the supported method and include a separate supportedNetworks field. This is a newer format, currently supported in Samsung Internet Beta v5.4. The old format is still supported. For details, see: https://groups.google.com/a/chromium.org/d/msg/blink-dev/IYRjdUKxCoM/8B-jp4g9AgAJ

For now, we are just going to simulate the actual payment processing with a 2 second delay. With just a quick sprinkling of HTML and CSS, we now have a demo that looks like this:

Easy, eh? You can try this demo out for yourself here. The source code is here on Github.

Of course there’s a little bit more to it if you want to configure things like shipping costs, contact details etc. If you’re looking for further examples, the Chrome team have some here. There’s also a nice guide by Ruadhán O’Donoghue here.

This should be enough to get started developing your own payment UI — oh except, please remember that (for good reason) the API is only available in secure contexts!

Getting real

“A demo is all well and good”, you may be thinking, “but how do we take real payments?” Good question…

Most of us won’t be working at organisations where we handle payments ourselves. Processing real payment data is not something to undertake lightly; there are a lot of checks and balances to put in place to ensure the data remains secure. Card providers have a required standard for this called PCI.

Thankfully, many companies provide this as a service. They’re called payment gateways because they’re the interface between those of us doing the selling (the “merchant”) and the banks.

Payment gateways are starting to introduce easier facilitation for Payment Requests. Some may provide iframe or redirect solutions, so you do not need to handle the sensitive data yourself. If you need more control, some may provide custom checkout services where you make the PaymentRequest call and are responsible for passing on the data to them securely. The payment gateway should be able to give you more specific information – and if you’re unsure, please seek further advice!

Pay today

With support for the Payment Request API in Samsung Internet, Chrome for Android and coming soon to Edge, it’s possible to start using it now. For real applications (as per usual), just be sure to progressively enhance and ensure you have another method in place for browsers without support yet.

Payment Requests are part of a wider effort to improve payments on the web. Did you know 66% of mobile purchases are made through the web, rather than native apps? Yet we know there’s more work to do. There’s more to come!

Let us know what you think. Ha-pay holidays!