14 ms·

Payment Request API

273 points by petethomas 9y ago

aerovistae 9y ago
Wonder how this impacts Stripe
- AdieuToLogic 9y ago
  I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.
  - jrochkind1 9y ago
    Like browser auto-fill for CC fields, which is already supported by most browsers?
    - AdieuToLogic 9y ago
      I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example). Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those who do incur chargebacks. Also, some processors will give a better discount rate for merchants who require customers to enter billing information manually (or as manual as the merchant system can reasonably enforce). So the fact that browsers support auto-fill is immaterial to the processors. What is important is that data provided by a customer in a card-not-present transaction is verified against the System of Truth, in addition to other verifications of course.
      - jrochkind1 9y ago
        Pretty sure Chrome autofill will store CVV. I think for most people using Chrome autofill for CCs, Chrome is already the System of Truth for CC, to quite the same extent it would be under this new system. No banks or retailers seem to be complaining about it at present. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one?
        AdieuToLogic 9y ago
        ... Chrome is already the System of Truth for CC ... Chrome, or any program running on a client device, is not a System of Truth due to the definition of same. A System of Truth is a trusted, authoritative, source of information in which services can rely on the information provided as being correct. In this context, a System of Truth is one which has exclusively its data from channels either controlled by the processor or secure feeds from partners. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one? From the perspective of the browser, no, there is none. From the perspective of a transaction processor, they will see the client request the same and treat it as being untrusted until verified against their System(s) of Truth as well as satisfying ancillary verifications. As such, a client device can never qualify as being authoritative due to its assumed compromised state (from the perspective of a processor).
- Gaelan 9y ago
  I'm pretty sure it doesn't. It would just let Stripe add a "use credit card data from your browser" button that avoided making users type it in every time.
  - pfg 9y ago
    Not only that, but they can also register as a payment provider in the user's browser, allowing for a convenient checkout flow on any site that uses Stripe.
- tehlike 9y ago
  "At a high level, the API affects the front end (checkout), not back end. Therefore, merchant's should not have to make changes to backend processing of various payment methods."
- lern_too_spel 9y ago
  It's marginally bad for Amazon. If a shoe is a dollar cheaper from the Nike store, but Nike doesn't have a card on file, you'd probably just get it from Amazon. With this system, you're more likely to order from Nike.
- madeofpalk 9y ago
  Not at all. This API is on-par with Apple Pay (in fact, it's API is very similar to it) and Stripe has supported Apple Pay since it launched.
angersock 9y ago
Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options. EDIT: Also, we see stuff like so: > The PaymentRequest API does not directly support encryption of data fields. Individual payment methods may choose to include support for encrypted data but it is not mandatory that all payment methods support this. What problem is this solving again? How does this make developers' lives easier than existing solutions? I'm kinda thinking it doesn't.
- rictic 9y ago
  The problem it solves is reducing friction on checkout. For a super quick gist, watch 15 seconds of this video starting at this time: https://youtu.be/NDZw7vtoYnU?t=514 https://youtu.be/NDZw7vtoYnU?t=514
  - AdieuToLogic 9y ago
    The problem it solves is reducing friction on checkout. One of the problems it creates is increasing the attack vector on an account holder by storing sensitive transaction information locally.
    - marksomnian 9y ago
      Not necessarily, depending on the method. For example, Apple/Android Pay is stored securely. Raw credit card data may be stored encrypted by the browser and decrypted at runtime or with the OS keychain, although I'm not sure if this is done now or not.
      - AdieuToLogic 9y ago
        For example, Apple/Android Pay is stored securely. See this comment[0] for a more detailed description of Apple Pay (and I'm pretty sure Android Pay). In short, account holder information is not stored on client devices. Instead, a server-generated encrypted token usually is. 0 - https://news.ycombinator.com/item?id=15276574 https://news.ycombinator.com/item?id=15276574
baybal2 9y ago
Why do we need to put a payment api into a browser?
- always_good 9y ago
  To make impulse buys easier.
- askvictor 9y ago
  To enable micropayments for content such as news.
  - canremember 9y ago
    True micropayments integrated in browser would be amazing. Imagine instead of ads or subscriptions, you could pay a few pennies for an article. It would revolutionize online content, in a good way. Nobody would be willing to pay for clickbait type stuff, but I think people would be willing to pay for quality content and journalism.
    - sadlyNess 9y ago
      There's been a debate for a while now about this. Clay Shirky, Walter Isaacson, Jakob Nielsen, Norman Hardy, Kevin Kelley and others have expressed arguments for and against(mostly for) micropayments. But there's yet to be a success story, most early implementations failed(BitPass, Ezcash, Peppercoin) but that was before cryptocurrencies. Now there's a new crop(Steemit, 21.co?, etc) that are trying again. Interesting to see how this will all pan out.
    - alwillis 9y ago
      True micropayments integrated in browser would be amazing. You might want to check out Brave, a Chromium-based browser with micropayments built-in: https://brave.com/publishers/ https://brave.com/publishers/.
    - amelius 9y ago
      I want to pay a fixed amount per month, and distribute that money over the websites I visited, weighted by the time I spent there.
litzer 9y ago
For anyone else like me who was overwhelmed by all the information and just looking for summaries: "In one sentence, how does it work? Payment Request API enables a user to complete a transaction more easily by reusing information stored in the browser or third party payment apps." https://github.com/w3c/payment-request-info/wiki/FAQ https://github.com/w3c/payment-request-info/wiki/FAQ
- stablemap 9y ago
  Maybe this helps too: https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/ https://developers.google.com/web/fundamentals/discovery-and...
- z1mm32m4n 9y ago
  This also opens up the door to more secure payments. The "basic card" handler is one where the browser might just store your raw card number. But you can imagine that your bank might implement a payment handler that requires you to enter a 2fa code before using your card. When it comes down to it, a credit card number is kind of serving double as a username and password for online payments right now. This new API has the potential to significantly improve upon the security of raw PANs.
  - jimktrains2 9y ago
    Just a clarification, a credit card number is an iin, pan, and checksum. http://jimkeener.com/posts/everyday-numbers-1 http://jimkeener.com/posts/everyday-numbers-1
    - lsaferite 9y ago
      Interesting that the post says the term BIN (vs. IIN) isn't commonly used anymore, but it's practically the only thing I've heard them called in the last 10+ years of ecomm dev.
      - jimktrains2 9y ago
cptskippy 9y ago
Android Pay for the Web uses a version of the Payment Request API, I surprised by how similar it is to the Apple Pay for Web implementation. We implemented both for sending payment requests from our App, I found the Payment Request API to be much better documented and easier to implement than Apple Pay for Web and significantly easier to test.
- objclxt 9y ago
  I won't bore you with the history of the Payment Request API, but a sizable chunk of it was inspired by the native Objective-C / Swift Apple Pay API, which is why it's so similar. With regards to Android Pay being easier to test - that's primarily because Apple Pay implements a much stricter security standard that requires a challenge/response to take place before starting the transaction. It's actually pretty easy to shim the Apple Pay API to Payment Request. If you didn't know about this already you might kick yourself, but there's even a Google supplied shim that allows you to just write the code once using Payment Request: https://github.com/GoogleChrome/appr-wrapper https://github.com/GoogleChrome/appr-wrapper
StavrosK 9y ago
So there's now a protocol for the browser to transparently share payment data with websites but we still can't get something to let the browser transparently log us in to websites?
- swiley 9y ago
  The w3c seems to be run by people who make money on the web, not people who use the web.
  - throwaway284534 9y ago
    The W3C is run by the same peers who frequent this and other tech forums. You can help by contributing to the organization, or you could hope for some internet points with snarky remarks. Which do you want to be remembered for?
    - ben_jones 9y ago
      While he could've worded it better he did provide valid criticism. I'm sure he is not the only person here who has profiteering concerns for the various bodies who govern the internet.
    - swiley 9y ago
      Alright "run" wasn't the right word, "heavily influenced by" is probably better. They just seem to continuously standardize things that are very user hostile and only serve content distributors.
      - RandomInteger4 9y ago
        If people want to make money of the content they produce and other people are happy to pay them, then what's the problem?
      - detaro 9y ago
        > continuously standardize things that are very user hostile and only serve content distributors. Example Nr 1 you are going to quote is the DRM stuff (understandably, it's the most controversial for good reasons, both inside and outside W3C). What other very user hostile examples are there?
gobengo 9y ago
It's exciting and all that this API could make us not have to type in our credit cards so often. But the same API should also be able to let us choose which wallet to pay cryptocurrencies from.
- octalmage 9y ago
  Cryptocurrency support is something they're very interested in.
deleted 9y ago
[deleted]
ChrisMorrisOrg 9y ago
Not sure if this is still the case, but Marcos from Mozilla did a talk on this at CampJS earlier this year. Apparently Chrome will send data about the items purchased to Google, even if you’re using a payment provider completely unrelated to Google. Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla. Edit: https://twitter.com/chrismorrisorg/status/896352427426799618 https://twitter.com/chrismorrisorg/status/896352427426799618
- microcolonel 9y ago
  Is there a source for this? That seems like a pretty outrageous thing for a browser to do.
  - kyrra 9y ago
    Agreed. I'd also like to see the source for this, as I can't find it mentioned anywhere on the Chrome sites about PaymentRequest or any of the top sites talking about Chrome Payment Request.
  - 482794793792894 9y ago
    Don't think there's recordings of CampJS for this year, but on the schedule [1] there's a talk about it listed by Marcos Caceres. You could probably ask the guy on Twitter (@marcosc). [1] http://viii.campjs.com/sessions/#payments http://viii.campjs.com/sessions/#payments
  - ChrisMorrisOrg 9y ago
    Not sure if the talk has been uploaded, but: https://twitter.com/chrismorrisorg/status/896352427426799618 https://twitter.com/chrismorrisorg/status/896352427426799618
    - microcolonel 9y ago
      Ahh, that completely changes the meaning. It's basically just like credit card processing in that case, but just for Android Pay (and probably Apple pay if/when they adopt the API). The transaction description/line item thing makes a lot of sense from a user perspective (granted, I am not, and do not intend on becoming, an Android Pay or Apple Pay user).
marichards 9y ago
Can we suggest this is renamed to something like: point of sale API? It appears to do a lot more than just the financial amount for payment as a request.
rayshan 9y ago
Here's an in-depth discussion with Molly Dalton and Zach Koch, contributors to the Payment Request API spec: https://modernweb.podbean.com/e/2017-04-mw-payments/ https://modernweb.podbean.com/e/2017-04-mw-payments/ (Disclosure: I'm the host of the podcast)
kylehotchkiss 9y ago
After Stripe switched to iframes for payment forms, I am very happy to see this. Trying to wrestle a iframe credit card field to have same fonts and error handling as other fields in a form is a really annoying workaround considering how nice the plaintext tokenizers in the past were... Knowing that credit card fields might not be in our forms at all feels very cool
- dbbk 9y ago
  Stripe offers a UI widget but you can still just design and code the form inputs yourself.
lgeorget 9y ago
We might finally see HTTP error code 402 in action, then. https://tools.ietf.org/html/rfc2616#section-10.4.3 https://tools.ietf.org/html/rfc2616#section-10.4.3
avaliente 9y ago
Will this use the 402 Payment Required HTTP status code?
danhardman 9y ago
So currently, users are often redirected to the 3rd party payment service or interact with an embedded form offered by the 3rd party service and the user either has to register/login. Does this mean, in the case of PayPal, users will have to install the PayPal Payment API App on their browsers?
- deleted 9y ago
  [deleted]
Dowwie 9y ago
Are Stripe and its competitors planning to adopt these standards?
osrec 9y ago
This is great! I've implemented the PaymentRequest API on a couple of my apps, and customers have really liked the user experience on mobile chrome. This is another positive step towards PWAs becoming more ubiquitous (I strongly believe PWAs will play a bigger part in the app ecosystem in the near future). I can imagine Apple will feel a bit more comfortable with web apps if they could conduit payments via apple pay more seamlessly - I hope things like this help remove some of the dev inertia on their side and make safari more suited to web apps.

Payment Request API

273 points by petethomas 9y ago

aerovistae 9y ago

Wonder how this impacts Stripe

AdieuToLogic 9y ago
I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.
- jrochkind1 9y ago
  Like browser auto-fill for CC fields, which is already supported by most browsers?
  - AdieuToLogic 9y ago
    I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example). Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those who do incur chargebacks. Also, some processors will give a better discount rate for merchants who require customers to enter billing information manually (or as manual as the merchant system can reasonably enforce). So the fact that browsers support auto-fill is immaterial to the processors. What is important is that data provided by a customer in a card-not-present transaction is verified against the System of Truth, in addition to other verifications of course.
    - jrochkind1 9y ago
      Pretty sure Chrome autofill will store CVV. I think for most people using Chrome autofill for CCs, Chrome is already the System of Truth for CC, to quite the same extent it would be under this new system. No banks or retailers seem to be complaining about it at present. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one?
      - AdieuToLogic 9y ago
        ... Chrome is already the System of Truth for CC ... Chrome, or any program running on a client device, is not a System of Truth due to the definition of same. A System of Truth is a trusted, authoritative, source of information in which services can rely on the information provided as being correct. In this context, a System of Truth is one which has exclusively its data from channels either controlled by the processor or secure feeds from partners. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one? From the perspective of the browser, no, there is none. From the perspective of a transaction processor, they will see the client request the same and treat it as being untrusted until verified against their System(s) of Truth as well as satisfying ancillary verifications. As such, a client device can never qualify as being authoritative due to its assumed compromised state (from the perspective of a processor).
Gaelan 9y ago
I'm pretty sure it doesn't. It would just let Stripe add a "use credit card data from your browser" button that avoided making users type it in every time.
- pfg 9y ago
  Not only that, but they can also register as a payment provider in the user's browser, allowing for a convenient checkout flow on any site that uses Stripe.
tehlike 9y ago
"At a high level, the API affects the front end (checkout), not back end. Therefore, merchant's should not have to make changes to backend processing of various payment methods."
lern_too_spel 9y ago
It's marginally bad for Amazon. If a shoe is a dollar cheaper from the Nike store, but Nike doesn't have a card on file, you'd probably just get it from Amazon. With this system, you're more likely to order from Nike.
madeofpalk 9y ago
Not at all. This API is on-par with Apple Pay (in fact, it's API is very similar to it) and Stripe has supported Apple Pay since it launched.

angersock 9y ago

Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options. EDIT: Also, we see stuff like so: > The PaymentRequest API does not directly support encryption of data fields. Individual payment methods may choose to include support for encrypted data but it is not mandatory that all payment methods support this. What problem is this solving again? How does this make developers' lives easier than existing solutions? I'm kinda thinking it doesn't.

rictic 9y ago
The problem it solves is reducing friction on checkout. For a super quick gist, watch 15 seconds of this video starting at this time: https://youtu.be/NDZw7vtoYnU?t=514 https://youtu.be/NDZw7vtoYnU?t=514
- AdieuToLogic 9y ago
  The problem it solves is reducing friction on checkout. One of the problems it creates is increasing the attack vector on an account holder by storing sensitive transaction information locally.
  - marksomnian 9y ago
    Not necessarily, depending on the method. For example, Apple/Android Pay is stored securely. Raw credit card data may be stored encrypted by the browser and decrypted at runtime or with the OS keychain, although I'm not sure if this is done now or not.
    - AdieuToLogic 9y ago
      For example, Apple/Android Pay is stored securely. See this comment[0] for a more detailed description of Apple Pay (and I'm pretty sure Android Pay). In short, account holder information is not stored on client devices. Instead, a server-generated encrypted token usually is. 0 - https://news.ycombinator.com/item?id=15276574 https://news.ycombinator.com/item?id=15276574

baybal2 9y ago

Why do we need to put a payment api into a browser?

always_good 9y ago
To make impulse buys easier.
askvictor 9y ago
To enable micropayments for content such as news.
- canremember 9y ago
  True micropayments integrated in browser would be amazing. Imagine instead of ads or subscriptions, you could pay a few pennies for an article. It would revolutionize online content, in a good way. Nobody would be willing to pay for clickbait type stuff, but I think people would be willing to pay for quality content and journalism.
  - sadlyNess 9y ago
    There's been a debate for a while now about this. Clay Shirky, Walter Isaacson, Jakob Nielsen, Norman Hardy, Kevin Kelley and others have expressed arguments for and against(mostly for) micropayments. But there's yet to be a success story, most early implementations failed(BitPass, Ezcash, Peppercoin) but that was before cryptocurrencies. Now there's a new crop(Steemit, 21.co?, etc) that are trying again. Interesting to see how this will all pan out.
  - alwillis 9y ago
    True micropayments integrated in browser would be amazing. You might want to check out Brave, a Chromium-based browser with micropayments built-in: https://brave.com/publishers/ https://brave.com/publishers/.
  - amelius 9y ago
    I want to pay a fixed amount per month, and distribute that money over the websites I visited, weighted by the time I spent there.

litzer 9y ago

For anyone else like me who was overwhelmed by all the information and just looking for summaries: "In one sentence, how does it work? Payment Request API enables a user to complete a transaction more easily by reusing information stored in the browser or third party payment apps." https://github.com/w3c/payment-request-info/wiki/FAQ https://github.com/w3c/payment-request-info/wiki/FAQ

stablemap 9y ago
Maybe this helps too: https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/ https://developers.google.com/web/fundamentals/discovery-and...
z1mm32m4n 9y ago
This also opens up the door to more secure payments. The "basic card" handler is one where the browser might just store your raw card number. But you can imagine that your bank might implement a payment handler that requires you to enter a 2fa code before using your card. When it comes down to it, a credit card number is kind of serving double as a username and password for online payments right now. This new API has the potential to significantly improve upon the security of raw PANs.
- jimktrains2 9y ago
  Just a clarification, a credit card number is an iin, pan, and checksum. http://jimkeener.com/posts/everyday-numbers-1 http://jimkeener.com/posts/everyday-numbers-1
  - lsaferite 9y ago
    Interesting that the post says the term BIN (vs. IIN) isn't commonly used anymore, but it's practically the only thing I've heard them called in the last 10+ years of ecomm dev.
    - jimktrains2 9y ago

cptskippy 9y ago

Android Pay for the Web uses a version of the Payment Request API, I surprised by how similar it is to the Apple Pay for Web implementation. We implemented both for sending payment requests from our App, I found the Payment Request API to be much better documented and easier to implement than Apple Pay for Web and significantly easier to test.

objclxt 9y ago
I won't bore you with the history of the Payment Request API, but a sizable chunk of it was inspired by the native Objective-C / Swift Apple Pay API, which is why it's so similar. With regards to Android Pay being easier to test - that's primarily because Apple Pay implements a much stricter security standard that requires a challenge/response to take place before starting the transaction. It's actually pretty easy to shim the Apple Pay API to Payment Request. If you didn't know about this already you might kick yourself, but there's even a Google supplied shim that allows you to just write the code once using Payment Request: https://github.com/GoogleChrome/appr-wrapper https://github.com/GoogleChrome/appr-wrapper

StavrosK 9y ago

So there's now a protocol for the browser to transparently share payment data with websites but we still can't get something to let the browser transparently log us in to websites?

swiley 9y ago
The w3c seems to be run by people who make money on the web, not people who use the web.
- throwaway284534 9y ago
  The W3C is run by the same peers who frequent this and other tech forums. You can help by contributing to the organization, or you could hope for some internet points with snarky remarks. Which do you want to be remembered for?
  - ben_jones 9y ago
    While he could've worded it better he did provide valid criticism. I'm sure he is not the only person here who has profiteering concerns for the various bodies who govern the internet.
  - swiley 9y ago
    Alright "run" wasn't the right word, "heavily influenced by" is probably better. They just seem to continuously standardize things that are very user hostile and only serve content distributors.
    - RandomInteger4 9y ago
      If people want to make money of the content they produce and other people are happy to pay them, then what's the problem?
    - detaro 9y ago
      > continuously standardize things that are very user hostile and only serve content distributors. Example Nr 1 you are going to quote is the DRM stuff (understandably, it's the most controversial for good reasons, both inside and outside W3C). What other very user hostile examples are there?

gobengo 9y ago

It's exciting and all that this API could make us not have to type in our credit cards so often. But the same API should also be able to let us choose which wallet to pay cryptocurrencies from.

octalmage 9y ago
Cryptocurrency support is something they're very interested in.

deleted 9y ago

[deleted]

ChrisMorrisOrg 9y ago

Not sure if this is still the case, but Marcos from Mozilla did a talk on this at CampJS earlier this year. Apparently Chrome will send data about the items purchased to Google, even if you’re using a payment provider completely unrelated to Google. Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla. Edit: https://twitter.com/chrismorrisorg/status/896352427426799618 https://twitter.com/chrismorrisorg/status/896352427426799618

microcolonel 9y ago
Is there a source for this? That seems like a pretty outrageous thing for a browser to do.
- kyrra 9y ago
  Agreed. I'd also like to see the source for this, as I can't find it mentioned anywhere on the Chrome sites about PaymentRequest or any of the top sites talking about Chrome Payment Request.
- 482794793792894 9y ago
  Don't think there's recordings of CampJS for this year, but on the schedule [1] there's a talk about it listed by Marcos Caceres. You could probably ask the guy on Twitter (@marcosc). [1] http://viii.campjs.com/sessions/#payments http://viii.campjs.com/sessions/#payments
- ChrisMorrisOrg 9y ago
  Not sure if the talk has been uploaded, but: https://twitter.com/chrismorrisorg/status/896352427426799618 https://twitter.com/chrismorrisorg/status/896352427426799618
  - microcolonel 9y ago
    Ahh, that completely changes the meaning. It's basically just like credit card processing in that case, but just for Android Pay (and probably Apple pay if/when they adopt the API). The transaction description/line item thing makes a lot of sense from a user perspective (granted, I am not, and do not intend on becoming, an Android Pay or Apple Pay user).

marichards 9y ago

Can we suggest this is renamed to something like: point of sale API? It appears to do a lot more than just the financial amount for payment as a request.

rayshan 9y ago

Here's an in-depth discussion with Molly Dalton and Zach Koch, contributors to the Payment Request API spec: https://modernweb.podbean.com/e/2017-04-mw-payments/ https://modernweb.podbean.com/e/2017-04-mw-payments/ (Disclosure: I'm the host of the podcast)

kylehotchkiss 9y ago

After Stripe switched to iframes for payment forms, I am very happy to see this. Trying to wrestle a iframe credit card field to have same fonts and error handling as other fields in a form is a really annoying workaround considering how nice the plaintext tokenizers in the past were... Knowing that credit card fields might not be in our forms at all feels very cool

dbbk 9y ago
Stripe offers a UI widget but you can still just design and code the form inputs yourself.

lgeorget 9y ago

We might finally see HTTP error code 402 in action, then. https://tools.ietf.org/html/rfc2616#section-10.4.3 https://tools.ietf.org/html/rfc2616#section-10.4.3

avaliente 9y ago

Will this use the 402 Payment Required HTTP status code?

danhardman 9y ago

So currently, users are often redirected to the 3rd party payment service or interact with an embedded form offered by the 3rd party service and the user either has to register/login. Does this mean, in the case of PayPal, users will have to install the PayPal Payment API App on their browsers?

deleted 9y ago
[deleted]

Dowwie 9y ago

Are Stripe and its competitors planning to adopt these standards?

osrec 9y ago

This is great! I've implemented the PaymentRequest API on a couple of my apps, and customers have really liked the user experience on mobile chrome. This is another positive step towards PWAs becoming more ubiquitous (I strongly believe PWAs will play a bigger part in the app ecosystem in the near future). I can imagine Apple will feel a bit more comfortable with web apps if they could conduit payments via apple pay more seamlessly - I hope things like this help remove some of the dev inertia on their side and make safari more suited to web apps.