Today W3C published the First Public Working Draft of Payment Handler API. This diagram shows the relationship between Payment Request API and Payment Handler:
In a typical scenario, a merchant calls Payment Request API so that the browser (or other user agent) displays UI for the user to choose a way to pay via a “payment app.” Payment apps include browsers (which plan to offer the service of storing card credentials), native mobile apps and Web sites. Browsers will communicate with native mobile apps using operating-system specific mechanisms. But what about Web sites?
Payment Handler API is designed to enable Web apps to handle payment requests. The specification explains how Web apps register supported payment methods with the browser and provide information that the browser will display to the user to make a selection. The specification also defines what happens after user selection of such a Web app, including how the app is launched, what data it receives about the transaction, and what data it returns to the browser after the user has completed interaction with the payment app. That data is packaged and returned to the merchant Web site through Payment Request API.
Although we have had some early implementation experience at both ends of the API (browser and payment app), I expect that to accelerate now that we have reached this milestone.
For more information, see the Payment Request FAQ.