
Payment Request API - praveenscience
https://www.w3.org/TR/payment-request/
======
mixedbit
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).

~~~
arkanciscan
Just because one spec failed you are suspicious of all specs? If it solves a
problem people will use it. If it doesn't they won't. Are you saying you don't
think that payments are a problem that people want to solve?

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

~~~
apolymath
It isn't solving any problems. This payments API looks like a simple AJAX
call. This API shouldn't even exist in my opinion.

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

~~~
ben174
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
Yes Braintree does support this:
[https://developers.braintreepayments.com/guides/payment-
requ...](https://developers.braintreepayments.com/guides/payment-
request/setup-and-integration/javascript/v3)

~~~
purephase
I wish this was true around 4 months ago. But, good news on the Braintree side
now!

~~~
jtdowney
Looks like it has been available since September 2017:
[https://github.com/braintree/braintree-
web/commit/b79008a51c...](https://github.com/braintree/braintree-
web/commit/b79008a51ccf3a002a20fb20a0df8976c39435d6#diff-a0f63037a788a310a12175cdfd0101f2)

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

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

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

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

~~~
jacobra2
>It's important to note that many of the tricks (like hidden iframes from
PSPs) that are used to make payments frictionless today are going to become
useless as browsers roll out more changes to protect user's privacy (e.g.
killing 3rd party cookies and storage).

Could you point me to resources to learn more about this? I work on
integrations like this. Is it that iframed PSP integrations won't work at all,
or they won't appear as seamless?

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

~~~
ahopebailie
Sorry, link: [https://www.theverge.com/2020/1/14/21064698/google-third-
par...](https://www.theverge.com/2020/1/14/21064698/google-third-party-
cookies-chrome-two-years-privacy-safari-firefox)

------
zhoujianfu
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
Supporting crypto-payments would not eliminate chargebacks in the general
case. Chargebacks are part of the business process and not a technical one.

------
wk0
Fairly related: [https://interledger.org/](https://interledger.org/)

Pretty sure a lot of blockchain projects are banking on this spec becoming
official.

~~~
whatsmyusername
Blockchain = instant no

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

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

~~~
jefftk
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)

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

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

------
Karunamon
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
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
This seems to have been out since 2016 ([https://medium.com/samsung-internet-
dev/how-to-take-payments...](https://medium.com/samsung-internet-dev/how-to-
take-payments-on-the-web-with-the-payment-request-api-a523f6fc7c1f)). 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
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
Do you know of a website that's using the API? I genuinely want to see how
it's used in the wild.

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

~~~
testuser66
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
The parent is concerned about privacy, not security.

------
felixfbecker
I wish all payment processes online would use this.

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

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

~~~
abraham
Chrome just shipped a Contact Picker API. [https://web.dev/contact-
picker/](https://web.dev/contact-picker/)

~~~
leeoniya
looks good!

is this on any standards track?

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

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

~~~
ahopebailie
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

