Payment Request API

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

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.

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.

Persona was also implemented, the problem is to keep it supported and iterate on the solution for long enough to reach wide adoption.

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.

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.

What problem is it solving? What's so bad about entering my credit card details?

Yes Braintree does support this: https://developers.braintreepayments.com/guides/payment-requ...

Does the payment processor need to explicitly support it or can it be implemented independently of processor?

Sounds like an interesting problem.

Here it is: https://stripe.com/docs/stripe-js/elements/payment-request-b... . I am using it right now for a client and it makes integration mind numbingly easy. Got it working with Apple Pay in production in like 30 minutes.

There's a single button that you install in your site and it works in Chrome and Safari, both mobile and desktop.

If you have a saved credit card in your browser or apple/Google pay on your phone, it will work.

Demo describes it better:

https://github.com/stripe/stripe-payments-demo

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.

Pretty sure you'll get downvoted whether it's BTC, BCH, BSV, ETH, etc. HN isn't cryptocurrency-friendly.

None of these are viable outside of crypto-advocates.

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

Heh, when I started working in the payments space, I had fleeting moments early on where I caught myself thinking something similar.

I soon realized, however, head-in-the-sanding the other current use cases and their complexities would be an amateur mistake.

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.

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.

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.

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)

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.

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

It's mostly a card thing.

Please don't post unsubstantive comments here, regardless of how you feel about blockchain.

https://news.ycombinator.com/newsguidelines.html

Its is not a blockchain at all its a protocol.

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.

Do you know of a website that's using the API? I genuinely want to see how it's used in the wild.

There is absolutely no way I would let Google (or any other browser provider for that matter) have a copy of my Credit Card Details.

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

It’s opt-in though. This would effectively make it mandatory no?

> Who is out there hand-rolling credit card auth?

It's extremely common, and few of them get PCI compliance right. In my experience they usually just feed a website form directly into email.

This is your mom and pops, local bed and breakfast, small specialty store type websites. They hire someone to just make it work.

They're deprecating the "User Agent String", but they are still considered "User Agents".

looks good!

is this on any standards track?

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.