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.
> In theory, after the protocol was widely adopted, Mozilla could shut down the centralized service. In practice, nobody adopted the protocol
Sounds a lot like the Matrix chat protocol. Who’s using a private Matrix server?
I feel like a lot of these companies think they’ll handle the bootstrapping stage with economies-of-scale from having one central node; but in practice, having that one central node enables extra network effects (e.g. super-low-latency interactions with people on the same node) that make people resistant to eventually becoming more distributed.
I think WordPress.com represents a better model: it’s a first-party hosting provider, but everyone that signs up is signing up for their very own instance. (Maybe some things are shared under the covers—that’d certainly be good engineering—but everyone gets full control of their WordPress “engine”, with their own plugins, scheduled tasks, etc.) This way, people are used to the concept of these blogs being a loosely-federated network with pingbacks et al from the start, rather than everything being one server with one dashboard. Very easy from there to “lift” your instance out into a separate enterprise deployment; very easy for other cloud providers to spring up and offer you an import tool, to move “your server” from service X to service Y.
>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?"
You can even compare it to OpenID, where it languished mostly-unused—but still actively-maintained!—for 5-10 years before OpenID Connect (a hybrid of the ideas of OpenID and OAuth) became the basis for all the major Single Sign-On services in use today. I doubt OpenID Connect would have inherited any OpenID-like functionality (e.g. profile discovery) if OpenID had been deprecated a year after its drafting. They probably would have instead (badly) reinvented it with no knowledge of the prior art, because there wasn’t an existing (if small) install-base to prove out the practicality of the various features.
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.
That's my opinion of Auth0 and similar services, no offense to Auth0, but people still use them.
As for federated auth... Twitter, Facebook, Google and Github authorizations seem to work okay-ish. Integration is rarely good. Login, User and Account are three different things, and people tend to conflate them poorly, this causes issues down the road in most projects.
Webauthn was weirdly impractical when I looked at it.
For example, the private key gets stored in hardware protection thus cannot be exported. So the UX is a non-starter if the user wants to log in from more than one device.
People will say that's a feature. But it's also why it's never going to replace passwords.
In a typical WebAuthn scenario the Private Key is actually being stored by the Relying Party, they just don't know that because it's encrypted with a symmetric key. That symmetric key is baked inside the hardware token.
Yes I'll say not being able to get that symmetric key out of the hardware token is a feature, because it is. Without that feature you'll have to educate users about how to care for their symmetric key and every time you inevitably fail they get exploited.
You can register multiple hardware tokens for a service (if the site supports that).
Regarding export of private keys -- some crypto hardware wallets also support the FIDO[2] specs. -- so there you have the option to use the 12 words to setup a new hardware with the same private keys ...
this really isn't the best thread to ask, but I've been quite curious if there are any other, less secure, key stores under consideration (i.e a filesystem or remote sso service) under CTAP?
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?
I'm suspicious of specs that require long term browser vendors support. Payments are definitely a problem that people want to solve, but my estimate is that it would require 5-10 years of continuous commitment from browser vendors to solve this problem, which I doubt will happen.
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.
The problem with any sort of alt-currency whether it's Flattr points or some cryptocoin is that it's always going to have the insurmountable barrier of indirection that ensures it's never going to have more than the fraction of hard-core users that are willing to buy into it. Signing up with Flattr or Coinbase to even access these alt-currencies is such a showstopper when we need a solution that can go mainstream.
I think the only solution that has a shot is enabling and improving the UX of spending plain ol' USD with the same motion we thoughtlessly buy groceries.
For example, a specific low overhead micropayment channel. It's kind of silly to pay the full cost of things like refund ability and fraud protection on a $0.005 purchase.
Without this, I don't see how micropayments will ever be a thing.
People often bring up the mental overhead of a la carte pricing for things like individual Netflix shows vs $12/mo. But I think they're also looking at it through the lens of the current world where you can't even price something below $1 if you're going to accept anything other than cash.
Cryptocurrencies do not address what @beebs93 accurately describes as:
> ... complex instruments/workflows that are no small feat to handle and handle well.
Cryptocurrencies are, by definition, currencies. Just like other ones, they do not address what commerce workflows exist to satisfy.
And as to "0 fees and instant transactions" argument...
That's all fine and dandy until a purchase is contested. At that point, the lack of a third-party which arbitrates between the merchant and customer, with legally binding consumer advocation mandated, will become painfully obvious.
“Left behind” i.e. this API will work for USA only. Don’t be silly. The point of browser APIs is that they work for all/most, if it’s only Apple Pay and Google Pay they solve nothing.
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.
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.
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?
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.
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.
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.
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
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)
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.
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)?
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.
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.
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..
Just to clarify, Interledger is a minimal payments clearing protocol, not a blockchain project. It was developed to mimic many of the characteristics of the Internet Protocol stack in order to “internetwork” clearing participants. The effect of using this model is a highly scalable and simple global clearing network on which rapid innovation is possible. Especially for low-value payments that are currently difficult to serve using traditional payment rails
Thanks for sharing Interledger! My post may have come off aggressive but that was not my intention. It was to ensure people don't conflate blockchain with Interledger.
But your comment suggest that you didn't understand what a blockchain is. Blockchain is just a specific type of merkle tree. A git repository is also a merkle tree and also a chain of blocks. It just isn't revered to as blockchain because the term didn't exist back when git was created. In short blockchain is not "cryptocurrency scam, slow database" and all the other negative descriptions people use these days. It's just a technology that was/is used for that. Instead of blockchain it should be refereed to as DLT because it doesn't mater if there is a chain of blocks the key part is that is that it is distributed ledger which requires some sort of consensus mechanism and that is what makes this tech "new" compared to git or any merkle tree-like thing that we had before blockchains where a thing.
DLT also makes it obvious that it is absolutely useless to use in a centralized way.
Plenty of tech terms has got negative associations over time because of how the tech was used and not because the tech is actually bad.
P2P for example. People connect this with illegal file sharing, slow and buggy connections, non-private because your IP is visible etc. etc. While technically non of these properties are related to P2P at all it's actually quite the opposite.
That's a lot of word to defend a term that's going to instantly turn off the CEO if I were to bring it up with him (which I'm not going to do because it also instantly turns ME off).
Blockchain proponents have done a really good job of turning their terminology into dirty words. It's vaporware at best and actively malicious at worst. Just no.
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.
Browsers are restricting third party identity for privacy reasons, which means they now need to offer a specific API instead of letting developers build something out of third-party iframes:
"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)."
The internet has only been around for around 30 years as we know it and things have been standardising very fast, this came just in time if you ask me.
Safari only supports "Apple Pay" + "basic card" -- it's blocking / not supporting other payment methods / instruments -- W3C Payment Method ID / Payment Handler API is not implemented right.
Like the successful lawsuit against Apple regarding the closed NFC API for payments in Germany, I suppose the same would apply for "Apple Pay on the web" (non-discrimination of other payment methods).
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?
It's general good practice in financial software to not have "naked" values without the associated currency. Even if right now all your transactions have a single currency, it's still useful to follow that practice because it might not be that way in some edge case, it might not stay that way in the future, to reduce the risk of accidental aggregation (adding multiple values without concern that they might be in different currencies), etc.
Two arbitrary edge cases with multiple currencies mixed in single purchase that come in mind; i'm not saying that they apply here, but they are relevant in some cases:
1) card txns with currency exchange - txn currency differs from card currency, the merchant asks for and receives some amount in currency A, the customer gets shown, confirms and pays amount in currency B.
2) tax-included payments (e.g. VAT where applicable) for txns in foreign currency; you might have a payment for 1000 USD but you'd need to calculate/indicate/store the VAT in the local currency.
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.
Really? I remember over a decade ago credit card information was being stored in inputbox history in Firefox and they added patches to prevent from storing cc info. Of course that was a side-effect/bug of the autocomplete fields and I'm sure in Chrome it was a planned addition, but still...
That’s more a failure of the form creator as password fields were never persisted to the history. If you don’t tell the browser that the input is for sensitive data it won’t protect it of course.
Chrome can already manage CC data. If it recognizes a CC form, then it will prompt a dialog where you enter your CVV code and it will fill the form for you.
No? It won't obliterate other forms of payment processing in the medium term. And I'd be very surprised if a "gpay is now mandatory for online shopping" monopoly was left to develop.
"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.
i want the ability to have contacts stored only locally on my phone (synced via carddav to my own server). then have a web api to attach one or multiple vcards (or specific fields from vcards).
seems like a very sinple thing to spec out and implement. just press a button, pop up an address book, just like a file selector.
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.
