I've seen cases contactless payment is not supported only for a particular brand and I believe it's because of missing software update on the payment terminal.
The merchant receives the same ‘random’ card number for transactions from the same device.
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
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/...
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.
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.
(Those systems all seem to use either magstripe or chip though, so maybe the wireless transaction could still use a different one, in theory).
IIRC in some countries this means it's accepted more or has higher payment limits.
where I live it happened exactly this way since a few years. Online is 3DS only and in person is chip/EMV only
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.