Let's see how the new payment ecosystem works with W3C Payment APIs.
The anatomy of W3C Payment APIs
W3C Payment APIs comprises multiple web standards.
- Payment Request API: The Payment Request API enables fast and easy checkouts through a native browser UI. It provides a consistent checkout flow while reducing the need for users to enter their shipping and payment information on every checkout. Learn how it works at high level at How payment request api works or in detail at Deep Dive into the Payment Request API.
- Payment Handler API: The Payment Handler API opens up the ecosystem to payment providers by allowing their web-based payment applications to act as payment methods on merchant websites through the standard Payment Request API.
- Payment Method Identifiers: The Payment Method
Identifiers defines how strings
https://google.com/pay, etc.) can be used to identify a payment method. Along with standardized payment method identifiers, it allows anyone to define their own payment method with URL-based payment method identifiers. Learn more at Payment method basics.
- Payment Method Manifest: The Payment Method Manifest defines the machine-readable manifest file, known as a payment method manifest, describing how a payment method participates in the payment ecosystem, and how such files are to be used.
How the Payment Request Process Works
There are typically four participants in an online transaction.
|Customers||Users who go through a checkout flow to purchase item(s) online.||N/A|
|Merchants||Businesses selling products on their website.||Payment Request API|
|Payment Service Providers (PSPs)||Third-party companies that actually process payments, which involves charging customers and crediting merchants. Alternatively called payment gateways or payment processors.||Payment Request API|
|Payment Handlers||Third-party companies which provide applications that typically store customers' payment credentials and on their authorization provide them to merchants to process a transaction.||Payment Handler API|
The typical sequence of events in processing a credit card payment on the web looks like this:
- The Customer visits a merchant's website, adds items to a shopping cart, and starts the checkout flow.
- The Merchant needs the customer's payment credentials to process the transaction. They present a payment request UI to the customer using the Payment Request API. The UI lists various methods of payment specified by the Payment Method Identifiers. The payment methods can include credit card numbers saved to the browser, or third party payment apps like Google Pay, Samsung Pay, etc. The Merchant can optionally request the customer's shipping address and contact information.
- If the customer chooses a payment method like Google Pay, Chrome launches either a platform-native payment app or a web-based payment app using the Payment Handler API. This step is completely up to the payment handler's implementation, based on the Payment Method Manifest. After the customer authorizes the payment, the payment app returns a token (payment credential) to the Payment Request API, which relays it to the merchant site.
- The merchant site sends the payment credential to a PSP to process the payment and initiate funds transfer. Usually, verifying the payment on the server side is also required.
- The PSP processes the payment, securely requesting a funds transfer from the customer's bank or credit card issuer to the merchant, and then returns a success or failure result to the merchant website.
- The merchant website notifies the customer of the success or failure of the transaction and displays the next step, e.g., shipping the purchased item.
Caveat: PSP Reliance
If you are a merchant and want to accept credit card payments, PSPs are an important link in the payment processing chain. Implementing the Payment Request API does not obviate the need for a PSP.
Merchants usually rely on a third-party PSP to perform payment processing for convenience and expense reasons. This is primarily because most PSPs maintain compliance with PCI DSS, an information security standard that regulates the safety of cardholder data.
Because achieving and maintaining strict PCI DSS compliance is expensive and difficult, most merchants find that relying on a compliant PSP avoids going through the certification process themselves. Some large and financially robust companies, however, obtain their own PCI DSS certification specifically to avoid such third-party reliance.
It's especially important when you are using
basic-card payment method which
returns a non-tokenized credit card number as a payment credential. Handling one
PCI SAQ A-EP
Thus, delegating payment processing to a PCI DSS-compliant PSP both simplifies the merchant site's requirements and ensures payment information integrity for the customer.
If you want to use the Payment Request API but don't have bandwidth to be compliant with PCI SAQ A-EP, some PSPs provide an SDK that uses the Payment Request API.
List of supporting payment gateways
Learn about the Payment Request API's fields and methods in How the Payment Request API Works.
Was this page helpful?