I'm skeptical. Browser vendors have too short attention span to work on difficult problems like this until the solution becomes good enough and widely adopted. One of the recent examples of this was Persona - an attempt to standardize login flow across browsers, also difficult problem, but easier than payments. Persona was killed, not because the solution was not working or couldn't be further improved, but because it wasn't widely adopted after relatively short time (somewhere between 1-2 years if I recall correctly).
I was an early adopter of Persona (my website was one of the canonical examples). I share your sentiment and dismay that Persona was shut down, although ultimately I think the way it was implemented was fundamentally flawed.
Background: Persona was a centralized, Mozilla-run auth service designed to bootstrap a decentralized protocol. In theory, after the protocol was widely adopted, Mozilla could shut down the centralized service. In practice, nobody adopted the protocol and the whole thing collapsed when Mozilla shut down the service.
I think the whole endeavor would have been more successful as self-hosted software. The downside is that each website would require separate email verification (until the protocol got adopted), but it would have been far less confusing to everyone and it most importantly it still would be running today. On the other hand building shrink-wrap cross-platform software is a lot harder than running a service and publishing some javascript, so I understand why they did what they did... but here we are dead in the water.
I would love to see Persona revived as a self-hosted auth library someday, and actually think it could still be successful in that role. It encapsulates the whole verify-your-email step; it leverages several existing federated login solutions to skip the roundtrip; it could still revive the decentralized protocol.
I haven't looked at this Payment Request API and I'm as skeptical as anyone, but if it doesn't rely on any kind of centralized service, it at least has a chance.
>it wasn't widely adopted after relatively short time
Why is that a problem, by the way? Wouldn't we expect something like Persona to be implemented in new software projects first, then gradually get adopted in existing software?
Nobody is going to gut their auth system to implement something shiny unless many are asking for it - i.e. by saying "oh it's so easy to sign into $rival_website because they use Persona, why can't we get that here?"
Similar timeline for browsers working on an implementation.
You've got to hate these short attention spans.
Seriously: Anything that's browser standards work moves on the time scale of multiple years. Yes, that goes for Persona too - launched in 2011, finally canned in 2016.
Just because your pet project doesn't launch doesn't mean there's "short attention span for difficult problems".
I'm optimistic. Already supported by Chrome, Safari, Firefox & Edge on both mobile and desktop including support for both Apple & Google Pay where possible.
My understanding is that the Payment Request API is just the standardisation of Apple's Apple Pay API for web, which has reasonable adoption. The browser vendors - Apple and Google - have a vested interest in making sure this works because it supports their other businesses/platforms.
Persona was a Mozilla project first and foremost. Nobody is going to just hand over one of the most critical parts of web-apps to their competitor, especially not a minor one.
Any standard can get adopted in two ways: either imposed by a dominant player, who can effectively force others to follow; or pushed by a wholly-independent 3rd-party that is completely neutral. Persona could not follow any of those strategies, and it withered, predictably.
I don't know the specifics of persona so i cannot make a comparison, but payment processes are way harder to set up, and money is on the line, so more people should adopt this.
Logins are often provided as part of whatever framework you're using.
Just because one spec failed you are suspicious of all specs? If it solves a problem people will use it. If it doesn't they won't. Are you saying you don't think that payments are a problem that people want to solve?
Stripe is using this, and it's great. There's a few gaps in terms of messaging and flexibility (notably, which type of payment request is being sent -- apple pay, google pay etc.) but it makes it much, much more developer friendly.
Does Braintree support this? I’m currently in a situation where I need to ping pong between stripe and Braintree and this would be the perfect solution.
I'm doubtful browser vendors could ever properly encapsulate the various international payment use cases behind their abstraction, but I would love to be proven wrong.
Bank accounts (ACH/SEPA), EU's relatively recent push for MFA for credit card transactions, India's mandate overall for MFA, China's gov't regulations around customer payment data not leaving the GCF, validation of China Union Pay cards in North America, etc., are all complex instruments/workflows that are no small feat to handle and handle well.
I don't want to be "that guy", but this is an ideal use case for a certain cryptocurrency that has 0 fees and instant transactions (not gonna say which because of the downvotes).
Instead of facing a paywall for a yearly subscription, you pay around $0.005 to read an article. But with a currenncy that anyone can own and can really handle micropayments.
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.
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.
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 ...)
>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?
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.
I wish somebody would make a crypto wallet/gateway combo that worked with this.
That combined with a auto “spend and replace” would actually make using crypto as simple and easy as say, Apple Pay.
And merchants could accept it without a payment processor, and pay no fees, have no risk of chargebacks, maybe pass some savings back to the customer, etc..
c.f. the "Epistemic standards for “Why did it take so long to invent X?”" thread, I kind of wonder why this took so long to arrive. It could, in theory, have been done at almost any time over the past 20 years.
I suppose it required IE to die and Google to produce a browser with an integrated payment solution. And also it's only recently that end-user devices have become secure enough to tolerate storing credit card info on them, at least on Android and iOS devices.
One thing that jumped out at me on this is that currency is being associated with every instance of a value. It is a common use case for multiple different currencies to be used as a part of a single transaction, instead of being set at the per-transaction level?
Have you ever seen Apple Pay in the web? If so there is a good chance you’ve seen this as it’s Apple’s recommended way of doing things instead of their older custom JS.
> User agents (e.g., browsers) facilitate the payment flow between merchant and user.
I'm very torn on how to feel about this. On one hand, it would be better than the current bonanza where every online shop has their own home-rolled thing for credit cards, on the other, I don't like the idea of having my CC info stacked on top of the already massive trove of data Google is gathering about me.
"The working group maintains a list of all bug reports that the group has not yet addressed."
As always major browser vendors already have this implemented and I don't know whether to blame them or not. Specification finalization is a slow process and can be made better in my humble opinion.
This is pointless to integrate. Payment systems are complicated and should be designed independently outside of the browser. This API looks very similar to a simple AJAX call anyway. It's pointless to create this API, and it can be confusing because now, as a developer, I have to read about the API, learn how to use it properly, find work-arounds for all the caveats, and find myself frustrated at how stupid the API is for existing.
I think you missed the point. This standardizes the process across all browsers and devices, for all applications. Additionally, it allows users to enter payment details only once for use in any application using this API
I looked over it briefly and saw some things about merchant validation and other events. I haven't done much with payment handling other than use APIs like PayPal. My gut feeling is that the asynchronous nature of this is going to make it difficult for users to implement properly.
Is there a synchronous abstraction for payments? So basically the user would submit a JSON object with the payment information and get a single atomic approve/deny response that is final?
If so, then I'd like to see a wrapper for this that encapsulates all of the async minutia into a sync protocol.
If not, then I think that reveals the underlying complexity of payment handling which is due to its asynchronous nature. There are so many reasons for payments to be rejected, returned or fail outright that perhaps nobody gets it all right. In the end, somebody has to moderate it and make it a manual process at some level.
So that's the part that that I'd like to see someone solve, regardless of the interface. Maybe Stripe or Square already have? Sorry if I'm using the wrong terminology here, I haven't done much merchant stuff, but have a nose for the fundamentals that make these types of things complex.
My expectation is that the PSPs will help to hide the complexity from merchants that don't have the resources to use the (admittedly complex) API directly.
e.g. Stripe already have support for PR API in their SDK
I think you are on the right track, but I would say that any payment that requires banks or card providers (or both) to act as agents of the exchange will ultimately have these qualities. It doesn't matter if you wrap it in a pretty bow and call it a clever name.
I think this is where crypto currency shines, as it doesn't require a deep stack of agents to facilitate a payments. It requires two parties (maybe a third for escrow), and money can move with less friction.
[+] [-] mixedbit|6 years ago|reply
[+] [-] stickfigure|6 years ago|reply
Background: Persona was a centralized, Mozilla-run auth service designed to bootstrap a decentralized protocol. In theory, after the protocol was widely adopted, Mozilla could shut down the centralized service. In practice, nobody adopted the protocol and the whole thing collapsed when Mozilla shut down the service.
I think the whole endeavor would have been more successful as self-hosted software. The downside is that each website would require separate email verification (until the protocol got adopted), but it would have been far less confusing to everyone and it most importantly it still would be running today. On the other hand building shrink-wrap cross-platform software is a lot harder than running a service and publishing some javascript, so I understand why they did what they did... but here we are dead in the water.
I would love to see Persona revived as a self-hosted auth library someday, and actually think it could still be successful in that role. It encapsulates the whole verify-your-email step; it leverages several existing federated login solutions to skip the roundtrip; it could still revive the decentralized protocol.
I haven't looked at this Payment Request API and I'm as skeptical as anyone, but if it doesn't rely on any kind of centralized service, it at least has a chance.
[+] [-] ancarda|6 years ago|reply
Why is that a problem, by the way? Wouldn't we expect something like Persona to be implemented in new software projects first, then gradually get adopted in existing software?
Nobody is going to gut their auth system to implement something shiny unless many are asking for it - i.e. by saying "oh it's so easy to sign into $rival_website because they use Persona, why can't we get that here?"
[+] [-] groby_b|6 years ago|reply
Similar timeline for browsers working on an implementation.
You've got to hate these short attention spans.
Seriously: Anything that's browser standards work moves on the time scale of multiple years. Yes, that goes for Persona too - launched in 2011, finally canned in 2016.
Just because your pet project doesn't launch doesn't mean there's "short attention span for difficult problems".
[+] [-] Rafert|6 years ago|reply
[+] [-] pbreit|6 years ago|reply
[+] [-] madeofpalk|6 years ago|reply
[+] [-] toyg|6 years ago|reply
Any standard can get adopted in two ways: either imposed by a dominant player, who can effectively force others to follow; or pushed by a wholly-independent 3rd-party that is completely neutral. Persona could not follow any of those strategies, and it withered, predictably.
[+] [-] djsumdog|6 years ago|reply
https://battlepenguin.com/tech/the-decline-of-openid/
(Super confusing name since it was also the name of a type of Firefox theme engine)
[+] [-] ceejayoz|6 years ago|reply
https://stripe.com/docs/stripe-js/elements/payment-request-b...
[+] [-] 101404|6 years ago|reply
[+] [-] WilliamEdward|6 years ago|reply
Logins are often provided as part of whatever framework you're using.
[+] [-] buboard|6 years ago|reply
[+] [-] spankalee|6 years ago|reply
[+] [-] arkanciscan|6 years ago|reply
[+] [-] purephase|6 years ago|reply
[+] [-] ben174|6 years ago|reply
[+] [-] cj|6 years ago|reply
Can someone expand on how Stripe is using this, how it affects integration and the end user experience?
[+] [-] beebs93|6 years ago|reply
Bank accounts (ACH/SEPA), EU's relatively recent push for MFA for credit card transactions, India's mandate overall for MFA, China's gov't regulations around customer payment data not leaving the GCF, validation of China Union Pay cards in North America, etc., are all complex instruments/workflows that are no small feat to handle and handle well.
[+] [-] koonsolo|6 years ago|reply
Instead of facing a paywall for a yearly subscription, you pay around $0.005 to read an article. But with a currenncy that anyone can own and can really handle micropayments.
[+] [-] pbreit|6 years ago|reply
[+] [-] ahopebailie|6 years ago|reply
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|6 years ago|reply
[+] [-] rene_kapusta|6 years ago|reply
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|6 years ago|reply
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?
[+] [-] strictnein|6 years ago|reply
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.
[+] [-] olau|6 years ago|reply
[+] [-] pbreit|6 years ago|reply
[+] [-] sam_lowry_|6 years ago|reply
[+] [-] yeaaaaaaaaaaah|6 years ago|reply
[deleted]
[+] [-] apolymath|6 years ago|reply
[deleted]
[+] [-] zhoujianfu|6 years ago|reply
That combined with a auto “spend and replace” would actually make using crypto as simple and easy as say, Apple Pay.
And merchants could accept it without a payment processor, and pay no fees, have no risk of chargebacks, maybe pass some savings back to the customer, etc..
[+] [-] wk0|6 years ago|reply
Pretty sure a lot of blockchain projects are banking on this spec becoming official.
[+] [-] pjc50|6 years ago|reply
I suppose it required IE to die and Google to produce a browser with an integrated payment solution. And also it's only recently that end-user devices have become secure enough to tolerate storing credit card info on them, at least on Android and iOS devices.
[+] [-] ruffrey|6 years ago|reply
[+] [-] divbzero|6 years ago|reply
[1]: https://caniuse.com/#feat=payment-request
[+] [-] Karunamon|6 years ago|reply
I.e.
[+] [-] ent101|6 years ago|reply
p.s. I hope it catches on.
[+] [-] MBCook|6 years ago|reply
[+] [-] Etheryte|6 years ago|reply
I'm very torn on how to feel about this. On one hand, it would be better than the current bonanza where every online shop has their own home-rolled thing for credit cards, on the other, I don't like the idea of having my CC info stacked on top of the already massive trove of data Google is gathering about me.
[+] [-] ancarda|6 years ago|reply
Worth saying today Chrome already supports storing credit card details for auto-fill.
[+] [-] felixfbecker|6 years ago|reply
[+] [-] namanaggarwal|6 years ago|reply
As always major browser vendors already have this implemented and I don't know whether to blame them or not. Specification finalization is a slow process and can be made better in my humble opinion.
[+] [-] leeoniya|6 years ago|reply
im sad that the Contact Intent API proposal is dead.
https://www.w3.org/TR/contacts-api/
this means you cannot create a web app that competes with native apps in UX for anything involving communication.
i suspect it died because neither google nor apple want you to move/keep your contacts easily out of their sync'd address books.
[+] [-] apolymath|6 years ago|reply
[+] [-] vinniejames|6 years ago|reply
[+] [-] zackmorris|6 years ago|reply
Is there a synchronous abstraction for payments? So basically the user would submit a JSON object with the payment information and get a single atomic approve/deny response that is final?
If so, then I'd like to see a wrapper for this that encapsulates all of the async minutia into a sync protocol.
If not, then I think that reveals the underlying complexity of payment handling which is due to its asynchronous nature. There are so many reasons for payments to be rejected, returned or fail outright that perhaps nobody gets it all right. In the end, somebody has to moderate it and make it a manual process at some level.
So that's the part that that I'd like to see someone solve, regardless of the interface. Maybe Stripe or Square already have? Sorry if I'm using the wrong terminology here, I haven't done much merchant stuff, but have a nose for the fundamentals that make these types of things complex.
[+] [-] ahopebailie|6 years ago|reply
e.g. Stripe already have support for PR API in their SDK
[+] [-] NoInputSignal|6 years ago|reply
I think this is where crypto currency shines, as it doesn't require a deep stack of agents to facilitate a payments. It requires two parties (maybe a third for escrow), and money can move with less friction.