Hacker News Reader

Comment by ffsm8 | Hacker News Reader

Honestly apples approach is pure security theater, as they're not an acquirer that process the transaction at the end.

Instead the real acquirer now reverses apples masking.

The merchants themselves aren't allowed to store the credit card information anyway, otherwise they'd lose their PCI certificate, losing the ability to process credit cards. And if they use a payment processor, then they didn't ever get in contact with the credit card information either.

No clue how/if Google does anything. I was just involved in implementing apple pay at a payment processor that was also an acquirer a few years ago. Ultimately, we've had the same information on the consumer, wherever they used Apple pay or just a regular credit card

View on HN

I am not an expert in this so I can't explain it in any truly deep detail, and you might be right in terms of "Masking" the identity of the card number if you think this is a privacy feature, but there is much more to it than security theater of a per-device DAN.

Both when using EMV Contactless and when using Apple Pay on the web, some kind of dynamic and/or encrypted data is signed by the secure element of the device. EMV Contactless definitely signs the whole transaction, with Apple Pay on the web in at least some cases it will use either a dynamic CVV code and/or "cryptogram" containing the transaction data similar to the contactless protocol that verifies that specific payment request was signed by the secure device/card.

The payment processors can use this to know the transaction is freshly authorised and is not a replay of a skimmed credit card number/CVV (whether skimmed from another apple pay transaction, or skimmed from entering the static physical card details).

On the merchant/processor side, I believe in some cases you may get a better rate or different fraud protection for such transactions (especially at a large scale), or, it will also factor into the fraud control and the bank/payment network/etc are less likely to reject such a payment as fraud where as it may be more likely to reject the static physical card details as fraud, etc.

If someone knows better or different then please do share.

Some references: https://support.apple.com/en-au/HT203027 https://developer.apple.com/documentation/passkit_apple_pay_... https://support.apple.com/en-au/guide/security/secc1f57e189/...

> EMV Contactless definitely signs the whole transaction, with Apple Pay on the web in at least some cases it will use either a dynamic CVV code and/or "cryptogram" containing the transaction data similar to the contactless protocol that verifies that specific payment request was signed by the secure device/card.

The same is true for chip card payments.

What makes Apple Pay significantly more secure in practice is that issuers can limit the device-specific card number to be only usable with a chip cryptogram, and not e.g. by manually typing it in on a website.

For POS and online payments, the idea was the same (eventually depreciate cryptogram-less use entirely and use 3DS online and chip/EMV at the POS), but alas, it never quite happened that way.

> On the merchant/processor side, I believe in some cases you may get a better rate or different fraud protection for such transactions (especially at a large scale)

Apple Pay usually shifts the liability for fraud to the issuer, yes. This is a huge advantage for merchants that would otherwise usually be on the hook for most types of fraud.

Do the chip / paywave payments with the physical card also use a DPAN generated for that card, or do they use the FPAN that's embossed on the plastic?

A physical card usually uses the number embossed on the plastic on all other channels (i.e. magnetic stripe, chip, contactless) as well.

That's not a hard rule – some cards have no number embossed/printed at all (e.g. the Apple Card), and it's technically possible to use different numbers. But I haven't really seen it done since it could cause quite some confusion, as e.g. some airlines use the card number to look up your online booking at self-check-in machines, which wouldn't work if the two differ.

There are also some special cases of things that are technically regular old smartcards but that do (I believe) use tokenization/DPANs, like wearable form factor contactless payment devices by Swatch or Fidesmo.

Ahh, that makes sense - in fact I just used a credit card to pick up linked online Shinkansen bookings from the JR-West ticket machines.

(Those systems all seem to use either magstripe or chip though, so maybe the wireless transaction could still use a different one, in theory).

Apple Pay is also somewhat different from contactless/chip payments on a card because it's authenticated, whereas (US at least) cards are not authenticated since we don't use PINs.

IIRC in some countries this means it's accepted more or has higher payment limits.

> For POS and online payments, the idea was the same (eventually depreciate cryptogram-less use entirely and use 3DS online and chip/EMV at the POS), but alas, it never quite happened that way.

where I live it happened exactly this way since a few years. Online is 3DS only and in person is chip/EMV only

Can you not use your card in US online stores? These mostly don’t support 3DS, so there is still a large fraud vector for compromised cards that work internationally.

I'm not sure, because I haven't been to the US in more than ten years. Last year in Canada everything worked flawlessly

> What makes Apple Pay significantly more secure in practice is that issuers can limit the device-specific card number to be only usable with a chip cryptogram, and not e.g. by manually typing it in on a website.

That's sort of true for non 3DS enabled cards. For 3DS enabled cards, you need a second factor for most transactions on the internet.

For 3DS enabled cards, 3DS is optional. Unless you mean 3DS-mandatory cards.

Reply on news.ycombinator.com