[ahopebailie]

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/

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.

[lgregg]

How do you become a co-chair of a working group like this?

[ahopebailie]

I was originally a member of the web payments community group which existed before payments was on any standards track at W3C.

The high level of interest and activity in the community led W3C to form an interest group to explore if payments was a WG-worthy topic and I also participated in that.

When we finally chartered the WG I was approached to chair and agreed. We've re-chartered twice since and I continue to chair.

The job is made a lot easier by the fact that we have a great W3C staff contact who does all the heavy lifting.

[rene_kapusta]

SEPA Instant Credit Transfer (SCTInst) + PSD2 Strong Customer Authentication (SCA) is working fine with PR API + Payment Handler + Payment Method ID + Payment Method Manifest specs.

Here is a not-so-uptodate PoC showing SCTInst with a live Raiffeisen Bank account (Austria) via S€PA.digital in Microsoft Edge: https://sepa.digital/pay.mp4

As Webkit / Safari only implemented the Payment Method ID for usage with Apple Pay (on the web), there it is only possible to redirect the user to a web page (a Progressive Web App which is else rendered in the PR modal). ... but in combination with the QR code format recommended by the European Payments Council* you'll get an other nice UX like "iOS Scan & Pay": https://www.linkedin.com/posts/renekapusta_apple-ios-scan-pa... // vimeo.com/391365723

QR codes suck you think? Card schemes & payment apps too.

So, I think "Request to Pay" in combination with eIDAS will be the future of frictionless SEPA / EUR real time payments (in combination with PR API to exchange the checkout data): https://www.linkedin.com/posts/renekapusta_instant-account2a... // vimeo.com/391881139

btw.: Persona was quite nice -- WebAuthn seems promising too (but it is/was only supporting hardware tokens and not the finger print reader on osx at my first trials ...)

) https://www.europeanpaymentscouncil.eu/document-library/guid... *) https://en.wikipedia.org/wiki/EIDAS

[jacobra2]

>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).

Could you point me to resources to learn more about this? I work on integrations like this. Is it that iframed PSP integrations won't work at all, or they won't appear as seamless?

[ahopebailie]

Here's a decent write up.

In short, 3rd-party cookies and storage are being blocked (or phased out). This means you can insert an iframe into a page but the cookies/storage it has access to will be partitioned based on the origin of the top-level context.

E.g. If PayPal embeds an iframe in walmart.com's site and the user logs in to PayPal to pay then goes to target.com's site where there is also an iframe embedded the user will have no active session and will need to login again.

[ahopebailie]

Sorry, link: https://www.theverge.com/2020/1/14/21064698/google-third-par...

[strictnein]

Yeah, this really needs to be fleshed out more. Stripe, Braintree, Paypal, etc all have rolled out this type of thing and it helps improve the security posture of everyone involved.

Just saying those "tricks" are going to die sometime in the name of "privacy" definitely needs a little more unpacking. There are likely tens or hundreds of thousands of sites with those implementations live today.

[strictnein]

What is the support like for storing payment information with a site? Ex: example.com wants to store my payment information to help expedite future purchases.

I ask this as someone who works at a large online retailer whose CISO has specifically asked to keep them informed of things that could improve our security posture around payments. Inability for a site to store payment information would discourage large sites from supporting this, or at best slow the implementation and support of it.

Apologies if this is somewhere in one of the two documents. I tried to skim through the ~150 pages to find related items.

[ahopebailie]

The APIs aren't really designed to solve for this.

If the site knows you and has payment credentials stored they won't need to use Payment Request API (although they still can).

Storing payment credentials differs by payment method. If you're talking about card payments then you have to deal with things like PCI-DSS and/or tokenization but there are other ways to pay which may support this use case more explicitly, for example by capturing explicit permission from the user to allow the merchant to make future purchases seamlessly.

This is something we're trying to find a standard protocol for with https://openpayments.dev so that the ecosystem is less fragmented. But, this is not linked to the W3C work explicitly

[rictic]

Worth questioning why you want to store payment info. One common reason is for a faster subsequent checkout experience.

If this API gives a fast checkout experience without storing data, then you've potentially got the benefit of storing payment info without the exposure of storing sensitive data.

(disclosure: I work at google on the web, but not on anything payments related)

[strictnein]

Imagine the multiple ways a customer interacts with a large retailer. It won't always be through a specific browser tied to a Google/etc account. They'll likely order things through their work computer, home computer, phone browser, retail app, etc. The common account between those all will likely be the retail store's account, not a Google/etc account.

At a certain scale, any reduction of friction results in $xx million in increased sales.

[rene_kapusta]

Regarding storing sensitive data at the client -- how good / bad / secure is it to store data in the IndexedDB store (as this is the only option for web apps used in the PR modal)?

[olau]

Have you designed it to support subscription payments, e.g. I sign up for a cloud solution and need to pay a bill monthly from now on?

[ahopebailie]

Not explicitly but it does come up regularly. The challenge with standards is that they are very slow to solidify so we have to keep ensuring we are tackling a manageable (small) scope.

In my personal opinion recurring payments are quite specific to the payment method. For example, how would one do a recurring Bitcoin payment?

At Coil we are trying to come up with some open standards to address this problem space that we hope will complement the W3C browser APIs. We base our standard around the concept of a "mandate" which the user authorizes a payee to create in against their account and which allows that payee to "push" funds from the account to themselves at specific intervals and for predefined amounts. We prefer mandates to the card-based model because the user is in control and can cancel the mandate at any time.

You can read a bit more about that work here: https://openpayments.dev

Excuse the state of the website it's under a small redesign but the content is mostly there, albeit a little rough right now.

[pbreit]

Would be great to see more HowTo's and sample code on implementation. Thanks for your efforts. I'm bullish on the topic.

[ahopebailie]

Google have some great ones which are applicable across the board (it's a standard!), but they are busy being updated: https://developers.google.com/web/ilt/pwa/introduction-to-th...

also: https://developers.google.com/web/fundamentals/payments

There is also some good content on MDN: https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...

[sam_lowry_]

How come neither SWIFT nor ECB are involved?

[pbreit]

It's mostly a card thing.

[ahopebailie]

Not true at all.

The ISO20022 RA (Swift) has been involved since the beginning as have numerous banks from Europe and LOTS of non-card payment methods are represented through their associations or scheme participants.

Part of the challenge is that the standard needs implementors to participate and contribute use cases and designs and users and merchants that use these systems to implement and test them.

The PSD2 ecosystem is also still quite nascent so even though we've had Open Banking UK, STET, Berlin group etc engaged they are still figuring out how their systems will work. These APIs are simply a channel by which their systems will ultimately be used.

I've seen some very good Open Banking demos using the PR API and PH API but they aren't in the market yet.

I'll also confess it is a bit of a chicken and egg situation. They won't prioritize support for these APIs until they see adoption by browsers and up to now Edge and Firefox have been slow to adopt. Edge is now Chromium based and has inherited all of the work already done to implement so that has changed overnight and I believe Firefox are keen to progress but just need to get this work on into their pipeline.