Stripe and Apple Pay(stripe.com)
stripe.com
Stripe and Apple Pay
https://stripe.com/applepay
99 comments
I'm not sure I understand Stripe's value proposition here. What is the benefit of using Stripe's library over using ApplePay (PassKit) directly? (Honest question)
You can't use Apple Pay directly: you have to use it with a supported payment platform. (List is at https://developer.apple.com/apple-pay/.)
Three of the payment platforms either don't load or show a 'Coming Soon' page. Ouch.
So is Apple Pay in essence another way to get a credit card processed against stripe? If you have an app that customers can store credit cards on, it's not clear to me what the additional benefit of apple pay is? Is it simply a better/faster way of getting the card information to stripe by way of thumb press as opposed to key entered?
With Apple Pay, your physical credit card number is NOT stored on the iPhone 6's secure element; instead, a token is (the token is effectively an alias to your credit card number; it looks like one too - is 16 digits, etc, so will work nicely w/existing payment infrastructure). So there's additional security there. If your iPhone 6 is stolen, you can report it stolen, and the issuing Bank of your credit card will simply invalidate your token. You won't have to worry about replacing your physical credit card. In contrast, if the merchant --- whose app you have your physical credit card number stored within --- is hacked, you'd have to get your credit cards replaced, which is of course more onerous than the former.
Just curious...does Google Wallet also do the same thing?
No, Google Wallet doesn't. When performing a tap & pay at a merchant NFC terminal using Google Wallet with your Android phone (running 4.4+), your Google Wallet Mastercard card is the card-account actually being used vis-a-vis transaction authorization. Then, later, Google will charge your card that you've configured to be your default-payment card. I do not know if Google is fully implementing Mastercard PayExpress spec, but they are implementing some of it at least. Thing is, because Google Wallet is HCE-based, and thus there's no secure element, they cannot permanently be storing the encryption keys needed to generate the cryptogram(s) and such that are part of a standard EMV transaction (Mastercard and/or the issuing banking of your Google Wallet Mastercard - Bancorp[1] would never allow permanently storing the encryption key w/out a secure element).
[1] https://support.google.com/wallet/answer/2676665?hl=en
[1] https://support.google.com/wallet/answer/2676665?hl=en
Interesting. Does this mean that transaction data (what I bought, when I bought) is visible to Google, unlike Apple Pay (claimed)?
I don't know, but I do know that Google Wallet has some kind of 'ghost' credit card number - that's the one that gets sent to the terminal, then presumably Google charges my actual card in the background somewhere.
I suppose the idea would be that you want to lower the barriers to payment and a thumb press is pretty low.
In Europe, we can already pay for things with contactless bank cards, without even tapping (up to about $30). If you want to do it like NFC or iPay, you can always stick your payment card to the back of your phone....
UKCards Association says "44.6 million contactless cards in circulation in the UK, used to make 22.1 million contactless transactions in May 2014". http://www.theukcardsassociation.org.uk/contactless_consumer...
UKCards Association says "44.6 million contactless cards in circulation in the UK, used to make 22.1 million contactless transactions in May 2014". http://www.theukcardsassociation.org.uk/contactless_consumer...
You joke about sticking your card to your phone but that's what my bank did https://www.commbank.com.au/blog/tap-pay-new-commbank-app-io...
We have NFC sim cards in Turkey that enables regular phones (even dumb ones) to make purchases. (http://www.garanti.com.tr/en/personal_banking/credit_cards/b...)
There are also NFC enabled stickers, watches and key fobs.
There are also NFC enabled stickers, watches and key fobs.
Wasn't joking ;-)
Even BofA in the USA issued tags that could be attached to the back of a phone (or anywhere else).
That's what I don't understand...why does a NFC transaction have to involve smartphones? What is it that needs the processing power of a smartphone? Is it so that Goog Wallet/Apple Pay can access your transaction data?
That's what I don't understand...why does a NFC transaction have to involve smartphones? What is it that needs the processing power of a smartphone? Is it so that Goog Wallet/Apple Pay can access your transaction data?
In Google's case, yes - access to transaction data is absolutely part of the plan. Apple explicitly set their system up so they don't get that data though.
NFC payments don't have to involve smartphones, but look at what Apple Pay gets you:
- Biometric auth - one-time numbers generated for each transaction - multiple cards in one place - hides your info from the vendor (and apple for that matter)
Those are pretty nice things to get from something that lets me ditch my wallet...
NFC payments don't have to involve smartphones, but look at what Apple Pay gets you:
- Biometric auth - one-time numbers generated for each transaction - multiple cards in one place - hides your info from the vendor (and apple for that matter)
Those are pretty nice things to get from something that lets me ditch my wallet...
It goes from one click to one depression. it is the mobile equivalent and steps right around amazon's 'patent'
You actually can:
"The alternative is to provide your own server-side solution to receive payments from your app, decrypt payment tokens and interface with the payment provider. Handling credit and debit card payments can be complicated and unless you already have the expertise and systems in place, an SDK from a payment provider is the quickest and most reliable way to support Apple Pay in your app."
From: https://developer.apple.com/apple-pay/Getting-Started-with-A...
"The alternative is to provide your own server-side solution to receive payments from your app, decrypt payment tokens and interface with the payment provider. Handling credit and debit card payments can be complicated and unless you already have the expertise and systems in place, an SDK from a payment provider is the quickest and most reliable way to support Apple Pay in your app."
From: https://developer.apple.com/apple-pay/Getting-Started-with-A...
... That's not directly. The "interface with the payment provider" is what Stripe is and this lets you interface with Stripe.
What is the barrier in building your own interface with the payment provider? Is it red tape, or technical challenges?
Both. You have to build a pretty significant architecture which meets PCI compliance (so e.g. hardware firewalls, hosted in a data centre with sufficient physical security, etc. etc), which makes it hugely expensive, and technologically demanding. Then you have to sign a contract with a bank or banks in order to get the process going, which is the red tape part. Then you get to handle all the systems responsible for handling fraud, chargebacks, extra customer service, and so on. And then you pay higher rates because you're doing worthless volumes, even assuming that the banks will deal with you at those volumes.
Once you're done that, you've built a small-scale, inefficient, featureless, and altogether shitty version of what Stripe will offer up to anyone with an e-mail address, and it's taken you six to eight months to build. Oh and your app is out of date and all your competitors have taken your customers.
Once you're done that, you've built a small-scale, inefficient, featureless, and altogether shitty version of what Stripe will offer up to anyone with an e-mail address, and it's taken you six to eight months to build. Oh and your app is out of date and all your competitors have taken your customers.
What I meant to ask was, "what did people do before Stripe came into existence"?
There are dozens of payment gateways. Braintree and Authorized.net are two large ones. If you accept credit card payments you will need a payment processor. You don't want to do this yourself.
N.B. The comment you're responding to was made by Stripe cofounder Patrick Collison (pc).
Thanks. Makes sense.
Here's how I think about it: Apple is the user's broker and Stripe is the merchant's broker. Every time there's a transaction between the user and the merchant, they are setting up a deal between their respective brokers.
As fgblanch points out, a merchant using Stripe only needs a single account with them to handle credit cards, Apple Pay, and whatever else comes along tomorrow.
As Igglybook and zaidf point out, Apple wants to provide the hardware and software for the user, but they don't actually want to be a financial services company like Stripe.
As fgblanch points out, a merchant using Stripe only needs a single account with them to handle credit cards, Apple Pay, and whatever else comes along tomorrow.
As Igglybook and zaidf point out, Apple wants to provide the hardware and software for the user, but they don't actually want to be a financial services company like Stripe.
In other words, Apply Pay is a digital credit card. You still need the remaining infrastructure to process credit cards, as well as be compatible with a physical credit card.
Apple does not provide the merchant account. Apple Pay serves as the middle party between the merchant account provider(Stripe) and the user with Pay's role being to maintain cards on file and relay it securely to the merchant account providers.
If you're using Stripe as your payment processor and using Apple Pay through Stripe (just like choosing a different credit card), then you're still only using one payment processor. All your transfers, transaction data, accounting, etc. is just done through Stripe. You don't care that the customer actually used Apple Pay.
Apple Pay doesn't actually deal with banks or credit card processors. It's just the frontend for the actual physical payment(card swipe or nfc).
Then why does Apple Pay have to be "compatible" with visa/MC/Amex? I don't think it just stores a digital version of the credit card...
Apple charges the banks and credit card issuers a fee every time Apple Pay is used, rather than charging the company receiving the money.
How do you know that Apple receives a fee for the transaction? I'd be curious to see a source.
Yup exactly. What is the incentive here for the banks to allow Apple to tokenize CC numbers, AND pay Apple for it? Some kind of risk/liability reduction?
The card issuers need to sign off on it for the liability purposes.
Apple needs the networks and/or the banks to tokenize the CC numbers at the time the card is imported into the wallet.
When the payment is processed, that same network/bank takes the token provided, translates it back to a card number and passes the card number to the issuing bank.
I think it's actually quite a feat that Apple managed to tokenize all 800 million existing card numbers, because of this requirement.
When the payment is processed, that same network/bank takes the token provided, translates it back to a card number and passes the card number to the issuing bank.
I think it's actually quite a feat that Apple managed to tokenize all 800 million existing card numbers, because of this requirement.
And, apparently, at "card present" transaction rates, which I imagine took some degree of negotiation on Apple's part.
http://bankinnovation.net/2014/09/apple-said-to-negotiate-de...
http://bankinnovation.net/2014/09/apple-said-to-negotiate-de...
Apple still needs payment processors and gateways to pass the cryptogram to the relevant networks and issuers. Now that's not to say in the future Apple can't go build their own processor down the line :)
I guess the Stripe's value proposition for developers is that they don't have to maintain or support several payment platforms. Just one, Stripe and there they integrate all of them ( Credit Cards, Apple Pay, etc.)
Apply Pay is essentially a digitized copy of your physical credit cards. You still need the remaining infrastructure to process credit cards, as well as be compatible with a physical credit card.
Patrick,
Curious, was the majority of the work required to support ApplePay related to the format of the PKPayment? I assume in other cases, you just pass the raw PAN + pin, etc, where as now you need to pass the encrypted single use token + cryptographic data + more. Was more work required to support ApplePay?
And if so, did Visa/MC/Amex and the processing networks recently start supporting this payload, or has it been in place for some time?
Finally, what does Apple use the Merchant ID for?
Curious, was the majority of the work required to support ApplePay related to the format of the PKPayment? I assume in other cases, you just pass the raw PAN + pin, etc, where as now you need to pass the encrypted single use token + cryptographic data + more. Was more work required to support ApplePay?
And if so, did Visa/MC/Amex and the processing networks recently start supporting this payload, or has it been in place for some time?
Finally, what does Apple use the Merchant ID for?
I think this all that extra stuff is a standard 3D Secure transaction (Verified by Visa/Mastercard SecureCard). Apple has replaced the complicated multi-step authentication process with TouchID
I presume from what I've read/seen, ApplePay will be app-only (i.e. iOS) for launch. But I've got to imagine they (as in, Apple and Stripe) will integrate with web-based payment forms as step 2.
Or, should I say, "I hope"...
Or, should I say, "I hope"...
I doubt it. For one thing they'd lose the ability to ensure you're who you say you are with TouchID, etc.
Presumably, if they wanted to do a web version, they could introduce Safari-only JavaScript APIs for verifying TouchID.
They could use Continuity-type stuff to have you verify the payment from your phone, that's happening in your desktop browser.
Which sort of makes sense with today's announcements, they said they had the ability to now detect between taps and presses with the Apple Watch, that technology seems like it could be easily integrated under a trackpad as-well...
Apple trackpads can already distinguish between a finger touching them and being physically depressed, though I don't know what it has to do with payments.
Thats a very different mechanism.
Of course, but it accomplishes something similar. Also, trackpads already have the two finger tap for additional actions (i.e. right click menu), and I still don't know what this has to do with the topic. :)
That's what I thought, but Apple Watch supports Apple Pay and that doesn't support Touch ID.
There are ways you could integrate this with a web site. You could use an authentication code sent on the backend to the phone for confirmation. It would basically be the same as any two-factor authentication. I'm just not sure which way it would have to go.
Or instead of NFC, maybe the phone is linked to Safari through a bluetooth connection and works with a specific Javascript API.
All of this, is of course implementation dependent. And at the moment, I won't think that we have enough information to rule it out.
Or instead of NFC, maybe the phone is linked to Safari through a bluetooth connection and works with a specific Javascript API.
All of this, is of course implementation dependent. And at the moment, I won't think that we have enough information to rule it out.
It's great to see Stripe endorsing Apple Pay. But from a dev standpoint, how difficult is it to integrate?
Stripe? A breeze. At least in comparison to other payment providers (I've worked with stripe, auth.net, and paypal.)
If it's anything like how Stripe does stuff, easy as 1, 2, 3.
Looking at the documentation I think it's fairly easy.
No API for web?
Apple pay is a combination of hardware for authentication and security, with a unified payment interface on the backend. It makes sense as a mobile payment solution.
Using your device to authenticate web purchases is a more complicated and difficult (and potentially insecure) prospect, and thus, will take longer before it's viable.
Apple's normal mode of operation is to start with the smallest essential thing that adds value, and then extend it over time. In a way, what we saw today is Apple's idea of an MVP.
If the web isn't an area where Apple can add value, they won't do it. Or put another way, if other people do a better job on the web (e.g.: stripe) then Apple's not going to try and compete with them.
Using your device to authenticate web purchases is a more complicated and difficult (and potentially insecure) prospect, and thus, will take longer before it's viable.
Apple's normal mode of operation is to start with the smallest essential thing that adds value, and then extend it over time. In a way, what we saw today is Apple's idea of an MVP.
If the web isn't an area where Apple can add value, they won't do it. Or put another way, if other people do a better job on the web (e.g.: stripe) then Apple's not going to try and compete with them.
Web is the enemy of Apple. iOs devices need unique features to sell, not Web stuff that is easy to duplicate by the competition.
Can we now use Stripe + Apple Pay to circumvent 30% revenue cut?
The %30 cut is for digital goods sold via Apple's stores, such as the AppStore, iTunes, iBookstore and in-app purchase. Physical goods have never had any kind of a restriction or revenue split.
Today you can go to the amazon or target app and buy physical goods using a credit card and Apple's cut of the sale is %0.
This just makes it easier and more secure for apps to take credit card payments. I think Apple may be getting a cut of the credit card fees when this happens, but that's between Apple and the card companies.
Today you can go to the amazon or target app and buy physical goods using a credit card and Apple's cut of the sale is %0.
This just makes it easier and more secure for apps to take credit card payments. I think Apple may be getting a cut of the credit card fees when this happens, but that's between Apple and the card companies.
Your Stripe pricing is the same if you use Apple Pay -- there are no additional fees. (And no 30%.)
(We should update the page to say this...)
(We should update the page to say this...)
It looks like Applepay generates one-time cards by default resulting in a single-use Stripe token. Does that mean the use case this supports is only one-time payments versus "sign up with Apple pay+Stripe"? Any advice on how best to integrate Apple pay for recurring pay scenarios like Sumon?
Edit: Some more context on how this all works from the other ApplePay thread on HN: http://clover-developers.blogspot.com/2014/09/apple-pay.html
Edit: Some more context on how this all works from the other ApplePay thread on HN: http://clover-developers.blogspot.com/2014/09/apple-pay.html
This supports recurring payments too -- you can associate an Apple Pay-originated Stripe token with a Stripe customer object as normal, and then create charges for that that customer. (This means that the Lyft use-case also works largely unchanged.)
Apple only takes 30% for digital goods, I doubt they'll remove that limitation.
For non-digital goods, Stripe is offering a library for iOS for a few years now which isn't affected by the 30% cut.
For non-digital goods, Stripe is offering a library for iOS for a few years now which isn't affected by the 30% cut.
https://support.stripe.com/questions/apple-and-stripe-tos-an...
I assume this would apply to Apple Pay, too.
I assume this would apply to Apple Pay, too.
No; this is now out-of-date. (I work at Stripe.)
"I work at Stripe"
Understatement :)
Understatement :)
Understatement I would expect given the design of https://stripe.com/about
They're for completely different things. The 30% is for in-app only, but there is administrative costs with providing those resources (plus, Apple is a for-profit). This is for physical good.
The app store is still the app store.
[deleted]
In which countries will Apple Pay launch in October?
The USA. The other countries Apple has not been specific about.
I believe this will follow the pattern that Apple normally follows for complex regulatory-involved industries (e.g.: the cellular carriers to support the iPhone). They're probably already working on BRIC and the G8 countries, will focus on them initially and then start rolling it out to wider and wider countries (with deeper and deeper integration in those initial countries.)
I think this is going to be a multi-year process, assuming it's a success, and it will be something that future keynotes include an update on (like "I'm pleased to announce that Apple Pay is now in 80,000 retailers in 8 countries")
I believe this will follow the pattern that Apple normally follows for complex regulatory-involved industries (e.g.: the cellular carriers to support the iPhone). They're probably already working on BRIC and the G8 countries, will focus on them initially and then start rolling it out to wider and wider countries (with deeper and deeper integration in those initial countries.)
I think this is going to be a multi-year process, assuming it's a success, and it will be something that future keynotes include an update on (like "I'm pleased to announce that Apple Pay is now in 80,000 retailers in 8 countries")
I'd be surprised if Australia wasn't one of the first countries to get it; we've for a long time had very technologically advanced banks that are often years ahead of the US. Last I heard cheques were still used by most people to transfer money in the states, is that still the case? I've grown so used to being able to instantly transfer money to anyone for free from my phone that I can't imagine how tedious having to use cheques would be.
No, nobody really uses checks anymore. Most payroll is direct deposit, person to person is Paypal, Venmo or your bank's version of them.
Edit: bills and rent are possibly the last hold out, but usually you set up bill payments through your bank.
Edit: bills and rent are possibly the last hold out, but usually you set up bill payments through your bank.
I remember reading tweets from an Australian that moved to the US (to work for Apple as it happens) commenting on the banking system maybe 2 or 3 years ago:
Basically his experience was:
- Cheques were still reasonably common, to the point that some bank(s) had mobile apps to scan a cheque to deposit it!
- "Bill payments" through a bank usually involved bank staff literally preparing a cheque on your behalf, and mailing it to the biller
As for your comment about "person to person is Paypal" - ok and what if I actually care about what happens to the money, rather than it randomly being held by some non-bank? Do US banks really not have a standard way to transfer money to another individual electronically?
In Australia all that's needed are BSB number (Bank-State-Branch, a unique identifier for each individual branch through the country) and Account number. Transfers could take up to a day or two, the last time I tracked it
In Thailand, there is a similar system where money can be transferred directly to an account belonging to someone else (or your own account at another bank). So far it has always been instant transfer.
Both of these systems are available via internet banking, mobile apps and in Australia, phone banking (not sure about Thailand, promo material isn't always in English)
I remember a few years ago a client in the US apologising for an incorrect wire transfer to me, as he'd given the teller the wrong amount (swapped a 5 and a 2 or something). I was stunned to think that the founder of a tech startup would not be using internet banking to make wire transfers to contractors, but after reading about the cheque situation it occurred to me that maybe he didn't have the choice.. can anyone confirm deny this is available?
Basically his experience was:
- Cheques were still reasonably common, to the point that some bank(s) had mobile apps to scan a cheque to deposit it!
- "Bill payments" through a bank usually involved bank staff literally preparing a cheque on your behalf, and mailing it to the biller
As for your comment about "person to person is Paypal" - ok and what if I actually care about what happens to the money, rather than it randomly being held by some non-bank? Do US banks really not have a standard way to transfer money to another individual electronically?
In Australia all that's needed are BSB number (Bank-State-Branch, a unique identifier for each individual branch through the country) and Account number. Transfers could take up to a day or two, the last time I tracked it
In Thailand, there is a similar system where money can be transferred directly to an account belonging to someone else (or your own account at another bank). So far it has always been instant transfer.
Both of these systems are available via internet banking, mobile apps and in Australia, phone banking (not sure about Thailand, promo material isn't always in English)
I remember a few years ago a client in the US apologising for an incorrect wire transfer to me, as he'd given the teller the wrong amount (swapped a 5 and a 2 or something). I was stunned to think that the founder of a tech startup would not be using internet banking to make wire transfers to contractors, but after reading about the cheque situation it occurred to me that maybe he didn't have the choice.. can anyone confirm deny this is available?
Wire transfers are not common (other than Direct Deposit). Yes, banking apps can scan and deposit checks. Most banks offer a paypal like feature to send money to people. People prefer paypal to using those services though.
I sometimes still get paid by clients using checks, but most have switched over to direct deposit or paying with credit cards.
International wire transfers are another beast due to the IRS and all the regulation around it. You need their bank account, ABA routing number, name, branch address, etc. I wire funds to Vietnam all the time, but there is a limit to the frequency and amount that I can do. It also will raise flags with the IRS, which is something to avoid.
Paper checks are suspected to go the way of the dinosaur in the US by 2028.
The UK is also a big check writing country too, fwiw.
And, honestly, checks aren't a pain in the ass. It's probably the same amount of time/effort as logging into a website and sending money, except for the time it takes to mail it or deliver it by hand.
I sometimes still get paid by clients using checks, but most have switched over to direct deposit or paying with credit cards.
International wire transfers are another beast due to the IRS and all the regulation around it. You need their bank account, ABA routing number, name, branch address, etc. I wire funds to Vietnam all the time, but there is a limit to the frequency and amount that I can do. It also will raise flags with the IRS, which is something to avoid.
Paper checks are suspected to go the way of the dinosaur in the US by 2028.
The UK is also a big check writing country too, fwiw.
And, honestly, checks aren't a pain in the ass. It's probably the same amount of time/effort as logging into a website and sending money, except for the time it takes to mail it or deliver it by hand.
And then wait for it to clear, hope it doesn't get lost, order a new cheque book, etc.
Edit: did you notice what I said about transfers in Thailand: instant. I can, within about 90 seconds, send money to a person or business at any other bank in the country. A cheque is only "basically the same time" if your scale for comparison is years.
Cheques are absolutely a pain in the ass, and you're kidding yourself if you think the us isn't woefully behind the times in terms of banking.
I thought thailand was bad when I tried to setup a foreign currency account, but it's like Star Trek era banking compared to amercia
Edit: did you notice what I said about transfers in Thailand: instant. I can, within about 90 seconds, send money to a person or business at any other bank in the country. A cheque is only "basically the same time" if your scale for comparison is years.
Cheques are absolutely a pain in the ass, and you're kidding yourself if you think the us isn't woefully behind the times in terms of banking.
I thought thailand was bad when I tried to setup a foreign currency account, but it's like Star Trek era banking compared to amercia
If you asked for an opinion but already had your mind made up, why did you even ask?
Checks are cleared almost instantly now. When you take a photo of it, it's run through ACH just like a wire transfer is. At most, it takes a day depending on when you deposit it.
I never said the US was ahead or behind either, that's something you erroneously inferred. Checks are no longer common, as I said a few replies up. Other than dealing with come clients that still pay by check, I haven't seen one or dealt with them for years.
Also, I live part-time in Vietnam, so I know all about wire transfers thank you very much. I also know what dicks Aussie ex-pats are too, thanks for confirmation.
Checks are cleared almost instantly now. When you take a photo of it, it's run through ACH just like a wire transfer is. At most, it takes a day depending on when you deposit it.
I never said the US was ahead or behind either, that's something you erroneously inferred. Checks are no longer common, as I said a few replies up. Other than dealing with come clients that still pay by check, I haven't seen one or dealt with them for years.
Also, I live part-time in Vietnam, so I know all about wire transfers thank you very much. I also know what dicks Aussie ex-pats are too, thanks for confirmation.
Well that escalated quickly.
If you look again you'll see I didn't ask for an opinion, like "are cheques a good way to transfer funds" I asked for confirmation/updates about a previously documented fact - the use of cheques in us banking.
If you look again you'll see I didn't ask for an opinion, like "are cheques a good way to transfer funds" I asked for confirmation/updates about a previously documented fact - the use of cheques in us banking.
I'm an Aussie who's been I'm the Bay Area for about a year now, I'll confirm what you say, American banks are absolutely prehistoric compared to Australia. Cheques are still very common for rent, govt etc(I haven't filled out a bloody cheque since my Dolomites account when I was 12). Paying other people for shared expenses (dinner, weekend away etc) is a mess of 3rd party services, some of which charge fees, none of which are ubiquitous. I still end up dealing in cash for a lot of things(!).
I never thought I'd say it, but I miss the aus banks so much, it's just so inconvienient here.
Can Apple Pay be bypassed?
What scares me is that Stripe knew my email address and prefilled the box.
Hi! We only prefill your email address if you're logged into your Stripe account while looking at that page. Hope that clarifies things.
And here I thought he was making a joke about his address being [email protected].
Doh!
Doh!
they're so on it!
Obvious question - when can I store my stellar or bitcoin in my apple pay "wallet"? Or have I misunderstood?
From what I've seen, you need to have a card with an existing payment provider before you can use it on Apple Pay. If you have a bitcoin debit card or a way to integrate a bitcoin wallet into a payment service, you can use it. If not, Apple Pay isn't what you're looking for. It's not a wallet in the same way a bitcoin wallet is.
Ok downvotes, that wasn't sarcasm, it was genuinely a recognition that Stripe's view on Stellar and the cryptocurrency ecosystem is coming closer - with Apple offering what is to all intents and purposes a iPhone controlled wallet with fingerprint security and locked down OS there is not a lot of steps to go to reach a means of storing electronic currency which has a security and convenience that is hard to imagine beating
Stripe is receiving payments from Applepay not making them to Applepay so the other payment methods they accept have no impact on Applepay.