Hacker News Reader

Comment by nextstep | Hacker News Reader

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)

View on HN

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.

Thanks. Makes sense.

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

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

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

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?

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

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.

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?

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

It goes from one click to one depression. it is the mobile equivalent and steps right around amazon's 'patent'

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?

Care to back that up with sources or a reference?

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.

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

Interesting. Does this mean that transaction data (what I bought, when I bought) is visible to Google, unlike Apple Pay (claimed)?

Yes, it is.

http://www.google.com/wallet/faq.html#tab=faq-security

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.

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

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.

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

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?

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.

Reply on news.ycombinator.com