Who’s who in Web Payments

Web Payments is not a single standard but a collection of them. At the core are four pieces:

  • Payment Request API: Gives merchants a native browser UI for checkout, so customers don’t have to re-enter shipping and card details on every purchase.
  • Web-based Payment Handler API: Lets payment providers build web-based payment apps that can be invoked as payment methods through the Payment Request API.
  • Payment Method Identifiers: Defines how strings like https://google.com/pay identify a payment method. Anyone can define their own URL-based identifier.
  • Payment Method Manifest: A machine-readable file that describes how a payment method participates in the ecosystem and how it should be used.

The transaction flow

An online transaction typically has four participants. The steps below map how they interact.

Players Description API usage
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. Web-based Payment Handler API
The typical sequence of events in processing a credit card payment on the web
The typical sequence of events in processing a credit card payment on the web
  1. The customer shops on the merchant’s site and starts checkout.
  2. To collect payment credentials, the merchant triggers the Payment Request API. The UI lists payment methods — from browser-saved cards to handlers like Google Pay or Samsung Pay — based on Payment Method Identifiers. The merchant may also request shipping address and contact details.
  3. If the customer picks a method like Google Pay, Chrome spawns either a platform-native or web-based payment app. That choice depends on the Payment Method Manifest. After authorization, the handler returns a response to the Payment Request API, which passes it to the merchant. For push-type payments, like bank transfers or crypto, the payment is already complete when the response arrives.
  4. The merchant forwards the payment credential to a payment service provider (PSP) for processing. Server-side verification of the payment is usually required.
  5. The PSP handles the funds transfer from the customer’s bank or card issuer to the merchant and reports success or failure.
  6. The merchant site tells the customer the outcome and what happens next, such as shipping the item.

Why PSP compliance matters

Implementing the Payment Request API doesn’t remove the need for a PSP. Merchants typically lean on third-party processors because those providers maintain PCI DSS compliance — an information security standard governing cardholder data. Reaching and keeping that certification is costly, so most merchants let a compliant PSP handle it rather than going through certification themselves. Some large, financially strong companies do certify on their own to drop that third-party dependency.

If you ever handle a primary account number (PAN) — the number embossed on the card — directly, doing so with JavaScript requires PCI SAQ A-EP compliance. For most merchants, delegating to a PCI DSS-compliant PSP both simplifies their own obligations and protects customer payment data.