10 ms·

Payment Request API

365 points by praveenscience 7y ago

wk0 7y ago
Fairly related: https://interledger.org/ https://interledger.org/ Pretty sure a lot of blockchain projects are banking on this spec becoming official.
- matdehaast 7y ago
  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 I am contributor to Interledger
- whatsmyusername 7y ago
  Blockchain = instant no
  - noxer 7y ago
    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.
    - whatsmyusername 7y ago
      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.
  - dang 7y ago
    Please don't post unsubstantive comments here, regardless of how you feel about blockchain. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- matdehaast 7y ago
  Wanted to add as I can't edit. 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. Matt
felixfbecker 7y ago
I wish all payment processes online would use this.
Etheryte 7y ago
> 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.
- ancarda 7y ago
  Why not switch to a different browser then, such as Firefox? Worth saying today Chrome already supports storing credit card details for auto-fill.
  - Jaruzel 7y ago
    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.
    - ancarda 7y ago
      Nobody is forcing you to do that. Your browser is very likely going to have a "Don't remember" option. You're free to keep your credit card details in your password manager or type it out every time.
    - testuser66 7y ago
      You do realise that storing them (be it Google, LastPass, or any other hopefully trusty manager) is safer than carrying them around on you, right?
      - polyglotnetwork 7y ago
        The parent is concerned about privacy, not security.
  - djsumdog 7y ago
    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...
leeoniya 7y ago
sorry to hijack im sad that the Contact Intent API proposal is dead. https://www.w3.org/TR/contacts-api/ 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.
- ceejayoz 7y ago
  That seems unlikely. Google has an API for contacts. https://developers.google.com/people/v1/write-people https://developers.google.com/people/v1/write-people
  - leeoniya 7y ago
    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.
    - djsumdog 7y ago
      I store contacts/calendars on my own server as well using Radicale + DavDroid on my phone and Thunderbird w/ Cardbook on my desktop.
- abraham 7y ago
  Chrome just shipped a Contact Picker API. https://web.dev/contact-picker/ https://web.dev/contact-picker/
  - leeoniya 7y ago
    looks good! is this on any standards track?
mixedbit 7y ago
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).
- WilliamEdward 7y ago
  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.
- ancarda 7y ago
  >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?"
  - derefr 7y ago
    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.
- ceejayoz 7y ago
pjc50 7y ago
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.
- WilliamEdward 7y ago
  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.
- buboard 7y ago
  no economic incentive, while nowadays google and apple are both in the finance business.
- jefftk 7y ago
  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)." -- https://news.ycombinator.com/item?id=22465032 https://news.ycombinator.com/item?id=22465032
- divbzero 7y ago
  It has indeed been 20 years since 402 Payment Required was “reserved for future use” as an HTTP/1.1 status code. [1]: https://tools.ietf.org/html/rfc2616#section-10.4.3 https://tools.ietf.org/html/rfc2616#section-10.4.3
namanaggarwal 7y ago
"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.
beebs93 7y ago
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.
- pbreit 7y ago
  Those payment methods and countries with silly regulations will get left behind.
  - why-oh-why 7y ago
    “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.
  - beebs93 7y ago
    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.
- koonsolo 7y ago
  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.
  - bdcravens 7y ago
    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.
ahopebailie 7y ago
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.
zackmorris 7y ago
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.
- NoInputSignal 7y ago
  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.
- ahopebailie 7y ago
  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
purephase 7y ago
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.
- cj 7y ago
  > Stripe is using this Can someone expand on how Stripe is using this, how it affects integration and the end user experience?
  - rhodysurf 7y ago
    Here it is: https://stripe.com/docs/stripe-js/elements/payment-request-button 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.
  - hkai 7y ago
    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 https://github.com/stripe/stripe-payments-demo
- ben174 7y ago
  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.
  - robecommerce 7y ago
    Yes Braintree does support this: https://developers.braintreepayments.com/guides/payment-request/setup-and-integration/javascript/v3 https://developers.braintreepayments.com/guides/payment-requ...
apolymath 7y ago
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.
- vinniejames 7y ago
  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
ruffrey 7y ago
I expected to see at least one editor from a financial institution on the Editors list.
Karunamon 7y ago
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? I.e. items = [...] currency = "USD" value = 5.00 #vs amount = {"currency": "USD", "value": 5.00}
- PeterisP 7y ago
  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.
ent101 7y ago
This seems to have been out since 2016 (https://medium.com/samsung-internet-dev/how-to-take-payments-on-the-web-with-the-payment-request-api-a523f6fc7c1f https://medium.com/samsung-internet-dev/how-to-take-payments...). Yet, I haven't seen even one website use it in production. Was this a failure or am I missing something? p.s. I hope it catches on.
- MBCook 7y ago
  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.
  - ent101 7y ago
    Do you know of a website that's using the API? I genuinely want to see how it's used in the wild.
divbzero 7y ago
This is great. With a Chrome and Safari it’s already supported for almost 90% of users globally. [1] [1]: https://caniuse.com/#feat=payment-request https://caniuse.com/#feat=payment-request
- rene_kapusta 7y ago
  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).
zhoujianfu 7y ago
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..
- AdieuToLogic 7y ago
  Supporting crypto-payments would not eliminate chargebacks in the general case. Chargebacks are part of the business process and not a technical one.

wk0 7y ago

Fairly related: https://interledger.org/ https://interledger.org/ Pretty sure a lot of blockchain projects are banking on this spec becoming official.

matdehaast 7y ago
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 I am contributor to Interledger
whatsmyusername 7y ago
Blockchain = instant no
- noxer 7y ago
  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.
  - whatsmyusername 7y ago
    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.
- dang 7y ago
  Please don't post unsubstantive comments here, regardless of how you feel about blockchain. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
matdehaast 7y ago
Wanted to add as I can't edit. 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. Matt

felixfbecker 7y ago

I wish all payment processes online would use this.

Etheryte 7y ago

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

ancarda 7y ago
Why not switch to a different browser then, such as Firefox? Worth saying today Chrome already supports storing credit card details for auto-fill.
- Jaruzel 7y ago
  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.
  - ancarda 7y ago
    Nobody is forcing you to do that. Your browser is very likely going to have a "Don't remember" option. You're free to keep your credit card details in your password manager or type it out every time.
  - testuser66 7y ago
    You do realise that storing them (be it Google, LastPass, or any other hopefully trusty manager) is safer than carrying them around on you, right?
    - polyglotnetwork 7y ago
      The parent is concerned about privacy, not security.
- djsumdog 7y ago
  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...

leeoniya 7y ago

sorry to hijack im sad that the Contact Intent API proposal is dead. https://www.w3.org/TR/contacts-api/ 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.

ceejayoz 7y ago
That seems unlikely. Google has an API for contacts. https://developers.google.com/people/v1/write-people https://developers.google.com/people/v1/write-people
- leeoniya 7y ago
  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.
  - djsumdog 7y ago
    I store contacts/calendars on my own server as well using Radicale + DavDroid on my phone and Thunderbird w/ Cardbook on my desktop.
abraham 7y ago
Chrome just shipped a Contact Picker API. https://web.dev/contact-picker/ https://web.dev/contact-picker/
- leeoniya 7y ago
  looks good! is this on any standards track?

mixedbit 7y ago

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

WilliamEdward 7y ago
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.
ancarda 7y ago
>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?"
- derefr 7y ago
  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.
ceejayoz 7y ago

pjc50 7y ago

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.

WilliamEdward 7y ago
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.
buboard 7y ago
no economic incentive, while nowadays google and apple are both in the finance business.
jefftk 7y ago
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)." -- https://news.ycombinator.com/item?id=22465032 https://news.ycombinator.com/item?id=22465032
divbzero 7y ago
It has indeed been 20 years since 402 Payment Required was “reserved for future use” as an HTTP/1.1 status code. [1]: https://tools.ietf.org/html/rfc2616#section-10.4.3 https://tools.ietf.org/html/rfc2616#section-10.4.3

namanaggarwal 7y ago

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

beebs93 7y ago

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.

pbreit 7y ago
Those payment methods and countries with silly regulations will get left behind.
- why-oh-why 7y ago
  “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.
- beebs93 7y ago
  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.
koonsolo 7y ago
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.
- bdcravens 7y ago
  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.

ahopebailie 7y ago

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.

zackmorris 7y ago

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.

NoInputSignal 7y ago
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.
ahopebailie 7y ago
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

purephase 7y ago

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.

cj 7y ago
> Stripe is using this Can someone expand on how Stripe is using this, how it affects integration and the end user experience?
- rhodysurf 7y ago
  Here it is: https://stripe.com/docs/stripe-js/elements/payment-request-button 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.
- hkai 7y ago
  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 https://github.com/stripe/stripe-payments-demo
ben174 7y ago
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.
- robecommerce 7y ago
  Yes Braintree does support this: https://developers.braintreepayments.com/guides/payment-request/setup-and-integration/javascript/v3 https://developers.braintreepayments.com/guides/payment-requ...

apolymath 7y ago

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.

vinniejames 7y ago
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

ruffrey 7y ago

I expected to see at least one editor from a financial institution on the Editors list.

Karunamon 7y ago

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? I.e. items = [...] currency = "USD" value = 5.00 #vs amount = {"currency": "USD", "value": 5.00}

PeterisP 7y ago
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.

ent101 7y ago

This seems to have been out since 2016 (https://medium.com/samsung-internet-dev/how-to-take-payments-on-the-web-with-the-payment-request-api-a523f6fc7c1f https://medium.com/samsung-internet-dev/how-to-take-payments...). Yet, I haven't seen even one website use it in production. Was this a failure or am I missing something? p.s. I hope it catches on.

MBCook 7y ago
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.
- ent101 7y ago
  Do you know of a website that's using the API? I genuinely want to see how it's used in the wild.

divbzero 7y ago

This is great. With a Chrome and Safari it’s already supported for almost 90% of users globally. [1] [1]: https://caniuse.com/#feat=payment-request https://caniuse.com/#feat=payment-request

rene_kapusta 7y ago
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).

zhoujianfu 7y ago

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

AdieuToLogic 7y ago
Supporting crypto-payments would not eliminate chargebacks in the general case. Chargebacks are part of the business process and not a technical one.