7 ms·

It’s randomised in a similar way to how iOS creates privacy MAC addresses for each WiFi SSID. The merchant receives the same ‘random’ card number for transacti

It’s randomised in a similar way to how iOS creates privacy MAC addresses for each WiFi SSID. The merchant receives the same ‘random’ card number for transactions from the same device.

ffsm8 2y ago
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
- lathiat 2y ago
  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://support.apple.com/en-au/HT203027 https://developer.apple.com/documentation/passkit_apple_pay_and_wallet/apple_pay/payment_token_format_reference https://developer.apple.com/documentation/passkit_apple_pay_... https://support.apple.com/en-au/guide/security/secc1f57e189/web https://support.apple.com/en-au/guide/security/secc1f57e189/...
  - lxgr 2y ago
    > 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.
    - caf 2y ago
      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?
      - lxgr 2y ago
        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.
        caf 2y ago
lxgr 2y ago
The device card number (DPAN) is static after adding a card to a given device. It doesn’t change between transactions or merchants.

It’s randomised in a similar way to how iOS creates privacy MAC addresses for each WiFi SSID. The merchant receives the same ‘random’ card number for transactions from the same device.

ffsm8 2y ago

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

lathiat 2y ago
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://support.apple.com/en-au/HT203027 https://developer.apple.com/documentation/passkit_apple_pay_and_wallet/apple_pay/payment_token_format_reference https://developer.apple.com/documentation/passkit_apple_pay_... https://support.apple.com/en-au/guide/security/secc1f57e189/web https://support.apple.com/en-au/guide/security/secc1f57e189/...
- lxgr 2y ago
  > 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.
  - caf 2y ago
    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?
    - lxgr 2y ago
      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.
      - caf 2y ago

lxgr 2y ago

The device card number (DPAN) is static after adding a card to a given device. It doesn’t change between transactions or merchants.