
Payment Request API for Apple Pay - stablemap
https://webkit.org/blog/8182/introducing-the-payment-request-api-for-apple-pay/
======
jaredcwhite
The importance of this cannot be overstated. ~25 years after the web was first
popularized, we have an open payments layer API that is supported by the most
popular mobile wallet.

I know Apple Pay's killer app when it was first announced was the ability to
pay easily in-store, but I feel like this is actually a bigger deal. I never
had much annoyance with whipping out a card at a grocery store, but paying for
things online in a way that's ridiculously fast as well as secure has always
been a dicey proposition. This is a huge leap forward.

~~~
fizwhiz
"most popular mobile wallet"

Citation? PayPal/Venmo seem far, far ahead.

~~~
abalone
Venmo is not a mobile wallet. It's for bank transfers (i.e. ACH), not
credit/debit card payments.

PayPal is widely supported online but I doubt they are far, far ahead in the
real world, which I think is what people mean by "mobile" wallet.

~~~
fizwhiz
Your statement regarding the "real world" being equated to "mobile payments"
is confusing. FWIW, PayPal cleared $155B in pure mobile payments volume in
2017. Apple Pay on the other hand hasn't published any numbers (apart from a
450% "growth" which every analyst knows is a cop out because the raw numbers
themselves are likely not impressive.)

------
saagarjha
Nice! I just tried out the demo and it seemed to work (hopefully I don't have
a charge on my credit card tomorrow, though!). One thing that I saw was that
it took a while to do processing, though; something like 30 seconds. I'm not
sure if this could be improved.

~~~
MBCook
I’ve used Apple Pay on the web before and it’s quite fast. My guess is that
some sort of side effect of the sandbox that I assume that little demo is
running in.

------
ucaetano
Does Safari only supports Apple Pay, unlike the Chrome implementation and the
actual W3 Payment Request API specifications?

[https://developers.google.com/web/fundamentals/payments/](https://developers.google.com/web/fundamentals/payments/)

[https://www.w3.org/TR/payment-request/](https://www.w3.org/TR/payment-
request/)

~~~
aestes
The Payment Request spec is agnostic to payment methods. It doesn’t require
implementors to support any particular method(s).

WebKit implements Payment Request, and Safari supports Apple Pay as a payment
method. Other browsers that implement Payment Request might support other
methods.

Edit: spelling

~~~
ucaetano
> WebKit implements Payment Request, and Safari supports Apple Pay as a
> payment method. Other browsers that implement Payment Request might support
> other methods.

So Safari ONLY supports Apple Pay?

~~~
aestes
Yes.

~~~
bni
What about the reverse, will apple Pay work in Chrome? Assuming ofcourse you
have set it up on a apple device first.

~~~
ucaetano
Chrome does support other payment apps, not sure if Apple Pay blocks Chrome.

Also, Chrome on iOS has to use the Safari rendering engine, since Apple blocks
third party rendering engines, so not sure if that would actually work.

Essentially, that's Apple making sure that if you have an iPhone, you can use
any payment method, as long as it is Apple Pay.

------
kitsunesoba
Very nice. The web shops that’ve implemented Apple Pay already are much nicer
to use than your average shop between elimination of the need to fill (or even
auto fill!) addresses and the security of single use tokens.

Once web payments is implemented widely I’ll likely start avoiding shops that
don’t implement them.

------
jtbayly
I know they don't take 30%, but I can't figure out what the cost is. According
to Apple, it's free, but does the seller generally have to pay more in CC fees
to get Apple Pay support?

~~~
abalone
That's up to the processor you (the merchant) sign up with, just like anything
else. Apple takes 0.15% and that comes out of the card issuing bank's end.[1]

Quick 101 on how card fees work generally:

Card issuer banks (Citibank, Chase, Bank of America, etc.) contract with a
card network (VISA, MC, etc.) and earn a standard fee schedule called
Interchange (it's public, you can look it up, typically 1.x-2.x% depending on
the card type). This is the bulk of where the card fees go, and often funds
card rewards and benefits.

Meanwhile merchants contract with processors (e.g. Chase Paymentech,
Heartland, First Data, Square, etc. etc.) who interface with all the card
networks, marking up those interchange fees with their own margins. The
processors may set up merchants with equipment, or maybe a third party POS
vendor does that. But most fundamentally processors are responsible for any
merchant-related fraud on the network.

That is why processor markups and merchant vetting procedures can vary -- and
why Apple would never take the place of the processor. It's merchant-specific
work and involves financially vouching for them. The less vetting the
processor does (Square, Stripe), the higher the markup. The more vetting, the
close to interchange the fee is going to be.

[1] [https://www.digitaltransactions.net/apple-pay-no-charge-
for-...](https://www.digitaltransactions.net/apple-pay-no-charge-for-
merchants-but-transaction-security-fees-for-issuers/)

------
MBCook
This is great to see. I knew they were working on it (since they’re
transparent about what features they’re working on) but I figured they would
end up in iOS 12 and Safari 12 in MacOS Tuscaloosa.

Great job guys!

------
discussedbefore
Does Apple take 30% on the web?

~~~
zaksoup
To add some context to the other reply: Apple doesn't take ANY cut of Apple
Pay payments, even on native mobile apps. Apple does, however, require that
app store apps ONLY allow the purchase of physical or similar goods with Apple
Pay. For instance, they'll reject an app that uses Apple Pay to allow the
purchase of eBooks, instead of the in-app-purchase API (which does take a 30%
cut). This is why Kindle forces you to the web to buy eBooks, but allows you
to buy physical amazon goods in the native app.

Similarly how you can use Apple Pay to call an Uber/Lyft in-app.

That said, Apple Pay is just a layer between you and the user's credit card -
there's no functional difference at the transaction layer between accepting
Apple Pay and having a credit card form in your App. This is why Stripe/Paypal
et al. all 'support' Apple Pay. You still need a payment processor who can
take the Apple Pay token and turn it into a transaction that puts money into
your account.

The in-app-purchase API, however, directly charge's the user's credit card on
file with Apple and is credited to your developer account as a payment.

TL;DR Apple Pay is a layer between customer and payment processor, IAPs are a
layer between customer and merchant. Apple takes 30% of IAP. Payment
processors of Apple Pay take a cut before passing payment on to merchant
(Stripe is 2.9% + 30c/transaction, for instance).

~~~
chatmasta
You sure about those TOS requirements? Last I checked all you needed was a
separate website providing equivalent service. If you charged for a
subscription on the website, and you have an app too, then the user should be
able to use your app since they've already paid the subscription.

~~~
zaksoup
Sorry, I may have been unclear. If you've _already paid_ outside of the native
app Apple won't prevent users from accessing the content (Netflix is an
example of this). The rule only applies to purchasing within the app itself.
Apple requires that if your app allows a user to purchase digital goods it
must be via an IAP. There's no restriction on users accessing content they've
already payed for elsewhere.

Somewhat related: It doesn't seem to be the case anymore but I have the
distinct recollection of paying for Hulu through the iPad app as an IAP at a
subscription price of $13.99/month only to discover Hulu was charging
$11.99/month if purchased through their site. I think Apple cracked down on
folks with different IAP pricing vs. direct subscription pricing, but for a
while it was a very frustrating effect of the 30% cut that you're forced to
give to Apple if you want to allow any in-app subscription on an Apple device.

Edit: I was right, they just recently dropped it when they rolled out their
redesign

[https://www.macrumors.com/2017/12/21/hulu-apple-itunes-
billi...](https://www.macrumors.com/2017/12/21/hulu-apple-itunes-billing-
price-drop/)

