I co-chair the working group doing this work. Happy to answer (almost) any questions? PR API is part of a set of specifications designed to improve payments on

I co-chair the working group doing this work. Happy to answer (almost) any questions? PR API is part of a set of specifications designed to improve payments on the Web. Most importantly, it is the invocation side of a cross-origin payment service ecosystem we're trying to seed. The other half is Payment Handler API which is less mature but has been rolled out in Chrome and Edge: https://www.w3.org/TR/payment-handler/ https://www.w3.org/TR/payment-handler/ Think of PR API as the payment service discovery/invocation side and PH API as the service provider side with the possibility of the service provider being a native app if the platforms supports it (e.g. Android lets apps register as payment apps and Safari + ApplePay works like this already). The website invokes the PR API (I want to get paid and these are the payment methods I support) and the browser matches the supported methods the website supports to payment apps the user has installed that support the same methods then prompts the user to pick the app they want to use. (Payment apps register/install themselves via the PH API) If you invoke Google Pay on Chrome today both of these APIs are already in use. Google Pay is deployed as a fully web-based Payment Handler with no special privileges in Chrome. It's important to note that many of the tricks (like hidden iframes from PSPs) that are used to make payments frictionless today are going to become useless as browsers roll out more changes to protect user's privacy (e.g. killing 3rd party cookies and storage). The privacy improvements are good but they have significant side-effects on UX. PR API and PH API offer a way for websites to invoke a payment app from another origin (eg. shop.com invokes paypal.com) without losing context (the payment app is rendered in a modal window not via a redirect) and without needing to know up front what payment methods the user supports (good for privacy). I agree with @mixedbit that there is a risk this doesn't gain sufficient adoption to stick around but I believe the combination of a decreasing number of alternatives and increasing support and interest from browsers suggest it has a very good chance. We are also working closely with the card networks to support Secure Remote Commerce (SRC) via these APIs providing a significantly better card payments experience than most websites offer today. Finally, the movement toward payer-initated payment methods whereby the payer or a third-party payment initiation service (think PISPs under PSD2) is handling the payment (as opposed to a PSP on behalf of the merchant capturing the user's card details) suggests the API will gain traction if we can get the design right to support these new payment methods (e.g. SEPA instant credit etc). If you have strong opinions about factors that will contribute to the success of the API (especially wrt adoption) please provide your feedback on our Github repo linked from the spec. There is a lot in the wikis that covers our current thinking, the whole process is done in the open.