9 ms·

Payment Request API for Apple Pay

114 points by stablemap 9y ago

MBCook 9y ago
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!
jaredcwhite 9y ago
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.
- analogmemory 9y ago
  Agreed, it's fun to use my phone to pay in the store, but not needing to input my address and cc details feels like magic.
- Boulth 9y ago
  Last time I checked the Payment API it was pretty low level, for example you'd get CC numbers. Processing that would then require PCI-DSS compliance so you'd likely still need a payment processor like Stripe. Payment API just provided a nicer UI for your cards and maybe virtual numbers in case of Google Wallet.
  - aestes 9y ago
    OP here. You’d only get a card number when using the “basic-card” payment method, which Safari does not support. Apple Pay provides a payment token instead, which does not reveal your physical card number.
    - abalone 9y ago
      Second that.. That's a huge improvement and massively under-appreciated aspect of real-world Apple Pay as well. Basically you don't have to worry anymore about merchants getting hacked and getting card numbers stolen, because the tokens they use in place of card numbers are tied to iPhone-based authentication (device possession + PIN/biometrics). Seems like all the marketing around Apple Pay is about convenience, but security is a big part of the story.
      - thefounder 9y ago
        Let me guess...as a merchant you are pretty much doomed if Apple doesn't like you. I find the blockchain payments way better for both merchant and buyer. No more 3 digits secret codes.
        abalone 9y ago
        You guessed wrong! Apple's deal is with the card issuers, so the only people doomed by Apple's disfavor are customers with cards from banks that haven't adopted Apple Pay. Apple has no say over which merchant can use it. Also I think you missed the part where Apple Pay doesn't involve 3 digit CVVs.
        MBCook 9y ago
        The merchant and/or processor also have to be registered, although I don’t think that’s too much of a hassle.
        IAmEveryone 9y ago
        I added basic bitcoin functionality to our store a few years back. About 1% of customers chose it, and nobody really paid attention to it. Then, payments would just stop getting through unless customers were willing to spend $40 (on a $60 purchase). That ended our little experiment. I couldn't care less about credit card companies' unwillingness to deal in child porn and Nazi propaganda. For us, they simply work. The decentralised nature of Bitcoin has also been proven to be mythological anyway. You can't use it (or any other cryptocurrency) without access to centralised services for exchange and other services. And those companies will adopt the same policies as CC companies and banks as they grow larger, professionalize, and draw scrutiny. The only positive was the small fortune that had accrued in the meantime. The earliest orders had exchange rates of around $100:1BC. We didn't care about it December or so, and got lucky again in that the problems with transaction costs both coincided with BC's peak and were the reason for us to cash out.
- fizwhiz 9y ago
  "most popular mobile wallet" Citation? PayPal/Venmo seem far, far ahead.
  - abalone 9y ago
    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 9y ago
      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.)
  - daniel-grigg 9y ago
    WeChat and Alipay both dwarf all of the above. Pity they don’t strive to be more accepted in the West.
    - gruez 9y ago
      Because there's no market. For physical transactioms EMV does everything they do, and in a more convenient package. For online transactions, they're not more convenient than the incumbents.
  - chatmasta 9y ago
    Just guessing based on my experience, but it seems like Apple Pay has broader worldwide adoption than Venmo, which is tied to the US banking system.
  - jaredcwhite 9y ago
    This is the most recent useful data I could find on short notice: https://www.cnet.com/news/apple-pay-users-nearly-double-in-2017/ https://www.cnet.com/news/apple-pay-users-nearly-double-in-2... Between Apple Pay, Samsung Pay, and Android Pay (which I believe recently got rebranded as just Google Pay), Apple Pay is ahead in userbase numbers by a considerable margin — perhaps not as much now as a year ago, but I doubt it was overtaken.
- ucaetano 9y ago
  > open payments layer API that is supported by the most popular mobile wallet Does it only support Apple Pay? Kinda of a downgrade from Chrome and the W3 specification: 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/ Oh, and WeChat Pay has 600 million active users, far more than Apple Pay: https://www.statista.com/statistics/744944/mobile-payment-platforms-users/ https://www.statista.com/statistics/744944/mobile-payment-pl...
  - aeontech 9y ago
    It’s the same W3C API, where do you see that this is Apple-only API?
    - ucaetano 9y ago
      “We’re pleased to announce that Safari 11.1 on macOS and Safari on iOS 11.3 now support the W3C Payment Request API for conducting Apple Pay transactions on the web.”
      - MBCook 9y ago
        What did you think they would do, support basic-card? How would they present that and make it clear to users that that’s far less secure than Apple Pay? Why would they do that? Wasn’t this API basically invented to provide a standard complaint way of doing something like Apple Pay? Here you go.
        ucaetano 9y ago
        > Wasn’t this API basically invented to provide a standard complaint way of doing something like Apple Pay? Here you go. No, the API invented so that the browser could act as an intermediary between many payment-requesting services and payment services, such as PayPal, PayTM, Apple Pay, etc. They chose to limit support exclusively to Apple Pay, so that users won't have a choice.
discussedbefore 9y ago
Does Apple take 30% on the web?
- mikestew 9y ago
  No. You think Whole Foods is handing over 30% of my grocery bill when I use Apple Pay?
- zaksoup 9y ago
  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 9y ago
    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.
    - 9y ago
jtbayly 9y ago
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?
- shivaas 9y ago
  The merchant pays anywhere from 1.6% to 3% of the transaction amount in fees to the payment processors/gateways. Part of this goes to Visa/MC and the issuing banks. Apple gets a cut from them and that's how they make money/break even. The Seller pays their card issuer directly or indirectly. You're not interacting with Apple pay support as Apple pay is not the one processing your payment - its simply storing your card securely and generating a payment token for the merchant when invoked.
- abalone 9y ago
  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-merchants-but-transaction-security-fees-for-issuers/ https://www.digitaltransactions.net/apple-pay-no-charge-for-...
deleted 9y ago
[deleted]
saagarjha 9y ago
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 9y ago
  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 9y ago
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/
- aeontech 9y ago
  The very first line of the article states: “We’re pleased to announce that Safari 11.1 on macOS and Safari on iOS 11.3 now support the W3C Payment Request API for conducting Apple Pay transactions on the web.”
  - ucaetano 9y ago
    Yes, I read that part: "W3C Payment Request API for conducting Apple Pay transactions" My question is: is this only for Apple Pay? Safari won't support any other payment method/service?
    - aeontech 9y ago
      I’m not sure I understand the question - what other payment service are you thinking of? With this change developers can use the same code to initiate a payment no matter which browser they are in, instead of having to write custom code for triggering Apple Pay, that’s the win here. This doesn’t change how Apple Pay for the web works. You can use Stripe or any other merchant processor to process your Apple Pay payments, iirc.
      - ucaetano 9y ago
        The original specification and the Chrome implementation aren't restricted to a single payments app, such as Apple Pay: > The browser then presents the payments UI to the user, who selects a payment method and authorizes the transaction. A payment method can be as straightforward as a credit card that is already stored by the browser, or as esoteric as third-party application written specifically to deliver payments to the site. So if you have the PayPal app installed, you should be able to choose it as the payment method and so on. My question is if the Apple implementation on Safari restricts the payment methods only to Apple Pay, bocking any other payment services or apps.
deleted 9y ago
[deleted]
kitsunesoba 9y ago
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.

114 points by stablemap 9y ago

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!

jaredcwhite 9y ago

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.

analogmemory 9y ago
Agreed, it's fun to use my phone to pay in the store, but not needing to input my address and cc details feels like magic.
Boulth 9y ago
Last time I checked the Payment API it was pretty low level, for example you'd get CC numbers. Processing that would then require PCI-DSS compliance so you'd likely still need a payment processor like Stripe. Payment API just provided a nicer UI for your cards and maybe virtual numbers in case of Google Wallet.
- aestes 9y ago
  OP here. You’d only get a card number when using the “basic-card” payment method, which Safari does not support. Apple Pay provides a payment token instead, which does not reveal your physical card number.
  - abalone 9y ago
    Second that.. That's a huge improvement and massively under-appreciated aspect of real-world Apple Pay as well. Basically you don't have to worry anymore about merchants getting hacked and getting card numbers stolen, because the tokens they use in place of card numbers are tied to iPhone-based authentication (device possession + PIN/biometrics). Seems like all the marketing around Apple Pay is about convenience, but security is a big part of the story.
    - thefounder 9y ago
      Let me guess...as a merchant you are pretty much doomed if Apple doesn't like you. I find the blockchain payments way better for both merchant and buyer. No more 3 digits secret codes.
      - abalone 9y ago
        You guessed wrong! Apple's deal is with the card issuers, so the only people doomed by Apple's disfavor are customers with cards from banks that haven't adopted Apple Pay. Apple has no say over which merchant can use it. Also I think you missed the part where Apple Pay doesn't involve 3 digit CVVs.
        MBCook 9y ago
        The merchant and/or processor also have to be registered, although I don’t think that’s too much of a hassle.
      - IAmEveryone 9y ago
        I added basic bitcoin functionality to our store a few years back. About 1% of customers chose it, and nobody really paid attention to it. Then, payments would just stop getting through unless customers were willing to spend $40 (on a $60 purchase). That ended our little experiment. I couldn't care less about credit card companies' unwillingness to deal in child porn and Nazi propaganda. For us, they simply work. The decentralised nature of Bitcoin has also been proven to be mythological anyway. You can't use it (or any other cryptocurrency) without access to centralised services for exchange and other services. And those companies will adopt the same policies as CC companies and banks as they grow larger, professionalize, and draw scrutiny. The only positive was the small fortune that had accrued in the meantime. The earliest orders had exchange rates of around $100:1BC. We didn't care about it December or so, and got lucky again in that the problems with transaction costs both coincided with BC's peak and were the reason for us to cash out.
fizwhiz 9y ago
"most popular mobile wallet" Citation? PayPal/Venmo seem far, far ahead.
- abalone 9y ago
  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 9y ago
    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.)
- daniel-grigg 9y ago
  WeChat and Alipay both dwarf all of the above. Pity they don’t strive to be more accepted in the West.
  - gruez 9y ago
    Because there's no market. For physical transactioms EMV does everything they do, and in a more convenient package. For online transactions, they're not more convenient than the incumbents.
- chatmasta 9y ago
  Just guessing based on my experience, but it seems like Apple Pay has broader worldwide adoption than Venmo, which is tied to the US banking system.
- jaredcwhite 9y ago
  This is the most recent useful data I could find on short notice: https://www.cnet.com/news/apple-pay-users-nearly-double-in-2017/ https://www.cnet.com/news/apple-pay-users-nearly-double-in-2... Between Apple Pay, Samsung Pay, and Android Pay (which I believe recently got rebranded as just Google Pay), Apple Pay is ahead in userbase numbers by a considerable margin — perhaps not as much now as a year ago, but I doubt it was overtaken.
ucaetano 9y ago
> open payments layer API that is supported by the most popular mobile wallet Does it only support Apple Pay? Kinda of a downgrade from Chrome and the W3 specification: 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/ Oh, and WeChat Pay has 600 million active users, far more than Apple Pay: https://www.statista.com/statistics/744944/mobile-payment-platforms-users/ https://www.statista.com/statistics/744944/mobile-payment-pl...
- aeontech 9y ago
  It’s the same W3C API, where do you see that this is Apple-only API?
  - ucaetano 9y ago
    “We’re pleased to announce that Safari 11.1 on macOS and Safari on iOS 11.3 now support the W3C Payment Request API for conducting Apple Pay transactions on the web.”
    - MBCook 9y ago
      What did you think they would do, support basic-card? How would they present that and make it clear to users that that’s far less secure than Apple Pay? Why would they do that? Wasn’t this API basically invented to provide a standard complaint way of doing something like Apple Pay? Here you go.
      - ucaetano 9y ago
        > Wasn’t this API basically invented to provide a standard complaint way of doing something like Apple Pay? Here you go. No, the API invented so that the browser could act as an intermediary between many payment-requesting services and payment services, such as PayPal, PayTM, Apple Pay, etc. They chose to limit support exclusively to Apple Pay, so that users won't have a choice.

discussedbefore 9y ago

Does Apple take 30% on the web?

mikestew 9y ago
No. You think Whole Foods is handing over 30% of my grocery bill when I use Apple Pay?
zaksoup 9y ago
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 9y ago
  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.
  - 9y ago

jtbayly 9y ago

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?

shivaas 9y ago
The merchant pays anywhere from 1.6% to 3% of the transaction amount in fees to the payment processors/gateways. Part of this goes to Visa/MC and the issuing banks. Apple gets a cut from them and that's how they make money/break even. The Seller pays their card issuer directly or indirectly. You're not interacting with Apple pay support as Apple pay is not the one processing your payment - its simply storing your card securely and generating a payment token for the merchant when invoked.
abalone 9y ago
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-merchants-but-transaction-security-fees-for-issuers/ https://www.digitaltransactions.net/apple-pay-no-charge-for-...

deleted 9y ago

[deleted]

saagarjha 9y ago

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

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/

aeontech 9y ago
The very first line of the article states: “We’re pleased to announce that Safari 11.1 on macOS and Safari on iOS 11.3 now support the W3C Payment Request API for conducting Apple Pay transactions on the web.”
- ucaetano 9y ago
  Yes, I read that part: "W3C Payment Request API for conducting Apple Pay transactions" My question is: is this only for Apple Pay? Safari won't support any other payment method/service?
  - aeontech 9y ago
    I’m not sure I understand the question - what other payment service are you thinking of? With this change developers can use the same code to initiate a payment no matter which browser they are in, instead of having to write custom code for triggering Apple Pay, that’s the win here. This doesn’t change how Apple Pay for the web works. You can use Stripe or any other merchant processor to process your Apple Pay payments, iirc.
    - ucaetano 9y ago
      The original specification and the Chrome implementation aren't restricted to a single payments app, such as Apple Pay: > The browser then presents the payments UI to the user, who selects a payment method and authorizes the transaction. A payment method can be as straightforward as a credit card that is already stored by the browser, or as esoteric as third-party application written specifically to deliver payments to the site. So if you have the PayPal app installed, you should be able to choose it as the payment method and so on. My question is if the Apple implementation on Safari restricts the payment methods only to Apple Pay, bocking any other payment services or apps.

deleted 9y ago

[deleted]

kitsunesoba 9y ago

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.