Get to know MDN better
This feature is not Baseline because it does not work in some of the most widely-used browsers.
Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.
Experimental: This is an experimental technology
Check the Browser compatibility table carefully before using this in production.
Note: This feature is available in Web Workers.
The Web-based Payment Handler API provides a standardized set of functionality for web applications to directly handle payments, rather than having to be redirected to a separate site for payment handling.
When a merchant website initiates payment via the Payment Request API, the Web-based Payment Handler API handles discovery of applicable payment apps, presenting them as choices to the user, opening a payment handler window once a choice has been made to allow the user to enter their payment details, and handling the payment transaction with the payment app.
Communication with payment apps (authorization, passing of payment credentials) is handled via Service Workers.
On a merchant website, a payment request is initiated by the construction of a new PaymentRequest object:
The supportedMethods property specifies a URL representing the payment method supported by the merchant. To use more than one payment method, you would specify them in an array of objects, like this:
In supporting browsers, the process starts by requesting a payment method manifest file from each URL. A payment method manifest is typically called something like payment-manifest.json (the exact name can be whatever you like), and should be structured like this:
Given a payment method identifier like https://bobbucks.dev/pay, the browser:
These members have the following purposes:
From the payment method manifest, the browser gets the URL of the default payment apps' web app manifest files, which can be called whatever you like, and look something like this:
When the PaymentRequest.show() method is invoked by the merchant app in response to a user gesture, the browser uses the name and icons information found in each manifest to present the payment apps to the user in the browser-provided Payment Request UI.
Note: If prefer_related_applications is set to true in the payment app manifest, the browser will launch the platform-specific payment app specified in related_applications to handle the payment (if it is available) instead of the web payment app.
See Serve a web app manifest for more details.
The Payment Request API's PaymentRequest.canMakePayment() method returns true if a payment app is available on the customer's device, meaning that a payment app that supports the payment method is discovered, and that the platform-specific payment app is installed, or the web-based payment app is ready to be registered.
The Web-based Payment Handler API adds an additional mechanism to prepare for handling a payment. The canmakepayment event is fired on a payment app's service worker to check whether it is ready to handle a payment. Specifically, it is fired when the merchant website calls the PaymentRequest() constructor. The service worker can then use the CanMakePaymentEvent.respondWith() method to respond appropriately:
The promise returned by respondWith() resolves with a boolean to signal that it is ready to handle a payment request (true), or not (false).
After the PaymentRequest.show() method is invoked, a paymentrequest event is fired on the service worker of the payment app. This event is listened for inside the payment app's service worker to begin the next stage of the payment process.
When a paymentrequest event is received, the payment app can open a payment handler window by calling PaymentRequestEvent.openWindow(). The payment handler window will present the customers with a payment app interface where they can authenticate, choose shipping address and options, and authorize the payment.
When the payment has been handled, PaymentRequestEvent.respondWith() is used to pass the payment result back to the merchant website.
See Receive a payment request event from the merchant for more details of this stage.
Once a payment app service worker is registered, you can use the service worker's PaymentManager instance (accessed via ServiceWorkerRegistration.paymentManager) to manage various aspects of the payment app's functionality.
For example:
The event object for the canmakepayment event, fired on a payment app's service worker when it has been successfully registered to signal that it is ready to handle payments.
PaymentManagerUsed to manage various aspects of payment app functionality. Accessed via the ServiceWorkerRegistration.paymentManager property.
PaymentRequestEventThe event object for the paymentrequest event, fired on a payment app's service worker when a payment flow has been initiated on the merchant website via the PaymentRequest.show() method.
Fired on a payment app's ServiceWorkerGlobalScope when it has been successfully registered, to signal that it is ready to handle payments.
paymentrequest eventFired on a payment app's ServiceWorkerGlobalScope when a payment flow has been initiated on the merchant website via the PaymentRequest.show() method.
ServiceWorkerRegistration.paymentManagerReturns a payment app's PaymentManager instance, which is used to manage various payment app functionality.
| Web-based Payment Handler API # the-paymentrequestevent |
Enable JavaScript to view this browser compatibility table.
This page was last modified on Mar 8, 2026 by MDN contributors.
Your blueprint for a better internet.
Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998–2026 by individual mozilla.org contributors. Content available under a Creative Commons license.