project_path: /web/fundamentals/_project.yaml book_path: /web/fundamentals/_book.yaml description: Learn who are involved in the Web Payments ecosystem, how they interact each other and how you can get involved.
{# wf_published_on: 2018-09-10 #} {# wf_updated_on: 2019-02-22 #} {# wf_blink_components: Blink>Payments #}
{% include "web/_shared/contributors/agektmr.html" %} {% include "web/_shared/contributors/dgash.html" %}
Let's see how the new payment ecosystem works with Web Payments.
Web Payments 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 a 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
(
basic-card,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.
There are typically four participants in an online transaction.
| 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. | Payment Handler API |
- 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 payment handlers 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. 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 handler returns a response to the Payment Request API, which relays it to the merchant site. (If the payment is push type such as bank transfers, cryptocurrencies, the payment is already processed when the merchant receives the response.)
- The merchant site sends a 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.
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 can be 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 primary account number (PAN) as a payment credential, that is the
number embossed on the card. Handling one with JavaScript requires PCI SAQ
A-EP
compliance.
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.
Note: Send pull requests to us if your payment gateway provides an SDK that involves the Payment Request API but is not listed here.
Learn about the Payment Request API's fields and methods in How the Payment Request API Works.
{% include "web/_shared/helpful.html" %}