
Payment Request API - petethomas
https://www.w3.org/blog/wpwg/2017/09/14/payment-request-api-now-being-implemented-in-all-major-browsers-advances-on-the-recommendation-track/
======
litzer
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)

~~~
z1mm32m4n
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
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
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
I've seen both. When I wrote the post all the docs from the gateways I had
access to called then iin with a historical note on bin. I done have access to
those docs anymore though.

~~~
lsaferite
I don't doubt you, but as an example, the recent notification of BIN/IIN
prefix additions for Mastercard uses BIN 19 times and IIN 2 times.

[https://www.mastercard.us/en-us/issuers/get-
support/2-series...](https://www.mastercard.us/en-us/issuers/get-
support/2-series-bin-expansion.html)

~~~
jimktrains2
Interesting, maybe I should update that page then.

------
StavrosK
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?

~~~
noway421
This became a thing lately:
[https://developers.google.com/web/updates/2016/04/credential...](https://developers.google.com/web/updates/2016/04/credential-
management-api)

~~~
homakov
Built in pw manager with JS api. Nothing special. Doesn't fix anything.

~~~
dbbk
It's more than that, it syncs user login credentials across devices, and can
auto-sign in users without them having to go through a login form.

Example scenario: user signs up for a site on Chrome desktop. When they visit
the site from their phone, they're automatically signed in, they don't even
see a login screen.

~~~
homakov
Does it by default generate a password or there is STILL a way for user to set
their own? If the latter, then it won't change anything. We must hide pw field
entirely from the user.

~~~
dbbk
I believe they autogenerate the password, but the long-term strategy is to
make OAuth as seamless as possible so users are encouraged to login to
everything with their Google/Facebook etc account.

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

~~~
objclxt
> Unlike Chrome, Firefox will apparently not send data about what you purchase
> back to Mozilla.

It sounds like something has been lost in translation. If not, Marcos is
conflating two very different things.

If you use Payment Request in Chrome __with Google Wallet or Android Pay
__then yes, Google is going to have a description of what you bought and where
you bought it. But you used their payment service. This is no different to
what PayPal or a dozen other payment services are doing.

If you use Payment Request in Chrome __as a replacement for auto-fill __\-
that is, you 're just using it with regular card numbers, or with another non-
Google payment instrument then nothing is being sent back to Google. Go check
the source code, it's all implemented in Chromium (indeed, other Chrome based
browsers that integrated Payment Request like Samsung's own mobile browser or
AliPay are using Google's implementation).

The reason that the standard asks for a description of what you bought is that
it's useful to display to the user in a standardized way as part of the
payment process so you can reconfirm exactly what it is you're paying for.

I sat on the Payment Request Working Group until about three months ago and I
didn't hear any of these concerns from Mozilla then. I don't really know what
Marcos has been saying, and since the talk itself isn't online I'm going to
assume he's been mis-quoted.

~~~
ChrisMorrisOrg
I must have misunderstood. Sorry!

[https://twitter.com/marcosc/status/909645024282869760](https://twitter.com/marcosc/status/909645024282869760)

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

------
gobengo
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
Cryptocurrency support is something they're very interested in.

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

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

~~~
AdieuToLogic

      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 can say all but Braintree, which may as well, process through one of the
Paymentech platforms (owned by Chase) and have the ability to store customer
billing information securely on PCI compliant servers provided by same.

Furthermore, the fraud exposure presented by this API will be difficult to be
accepted by processors.

EDIT: Stripe is an ISO with FDMS, owned by Wells Fargo. They got the
transactional system from Paymentech in "the divorce."

~~~
objclxt
> Furthermore, the fraud exposure presented by this API will be difficult to
> be accepted by processors.

I'm confused by what you mean. The API doesn't have any additional fraud
exposure. It uses existing payment instruments and methods. Also, all major
card networks - Visa, MasterCard, AmEx - and many payment processors - Stripe,
Worldpay, etc - all actively participate.

~~~
AdieuToLogic

      The API doesn't have any additional fraud exposure.
    

The fraud exposure is due to identifying information, or access therein, being
stored on and/or directly provided by the client in this model. Existing
payment methods do not store billing information on the client devices as they
are assumed to be untrusted.

    
    
      Also, all major card networks - Visa,
      MasterCard, AmEx - and many payment processors
      - Stripe, Worldpay, etc - all actively
      participate.
    

Card networks are not banks. Stripe is not a bank. Worldpay may be (I've never
heard of them), but for the sake of discussion, I'll assume they are not a
bank.

Banks are the CC account issuers and the processors "on the rails" of payment
networks (Visa, MasterCard, Amex). Whether or not an ISO/VAR/merchant (Stripe,
PayPal, eBay, Apple, Google, Amazon, etc.) wants this type of API is
immaterial. If the banks aren't comfortable with it, someone is going to eat
their discount rate hike (yes, ultimately this is the customer, but I'm
talking about entities directly impacted by the hike).

~~~
gsnedders
> Existing payment methods do not store billing information on the client
> devices as they are assumed to be untrusted.

Except this is exactly how Android Pay and Apple Pay work: they store the
billing information on the client side. A large part of the impetus behind
Payment Requests is to open up Android Pay and Apple Pay to the web. And
all(?) major browsers support autofilling card details already, which means
storing the billing information on the client side and exposing the web to
that fraud risk.

And, heck, a conforming Payment Requests payment handler doesn't need to store
_anything_ locally: one based on payment cards could require you to enter the
card details on every transaction.

~~~
AdieuToLogic

      Except this is exactly how Android Pay and
      Apple Pay work: they store the billing
      information on the client side.
    

No, Apple Pay does not. And I'm pretty sure neither does Android Pay. What
Apple Pay does is produce encrypted tokens based on the account holder's
information and the device(s) authorized to use it. It is only this encrypted
token which is stored on a client device and it is verified on each
transaction as well as periodically replaced by the servers.

The PAN and related data is stored securely on Apple's servers (or, more
likely, PCI compliant servers provided by Paymentech). This is why merchants
have to accept these payment methods specifically and not treat them as
"regular" card-not-present transactions.

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

------
kylehotchkiss
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
Stripe offers a UI widget but you can still just design and code the form
inputs yourself.

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

------
avaliente
Will this use the 402 Payment Required HTTP status code?

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

------
danhardman
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?

------
aerovistae
Wonder how this impacts Stripe

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

------
Dowwie
Are Stripe and its competitors planning to adopt these standards?

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

~~~
askvictor
To enable micropayments for content such as news.

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

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

~~~
askvictor
A micropayment system tied in to browsing history might make this possible.
Otherwise it would require essentially a syndicated subscription system, which
is server side, but would need enough content producers on board to make
feasible, and they probably wouldn't be able to agree.

