6 ms·

Can anyone ELI5 how Apple & Google Pay work in detail? I used to think they simply pass on my CC details to the merchant or the merchant's chosen payment gatewa

Can anyone ELI5 how Apple & Google Pay work in detail? I used to think they simply pass on my CC details to the merchant or the merchant's chosen payment gateway in one way or another (obfuscated or not), and the OP suggests the same. Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard. However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves. After all, they collect all my transaction data, and it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps. Interestingly, this comment[0] is saying the opposite, namely that at least Apple Pay is very much rooted in standards. But what is Apple and Google's special proprietary sauce then? Why are these apps so hard/impossible to replace by open-source alternatives? Is it because only Apple/Google get full access to the NFC chips on iOS/Android? [0]: https://news.ycombinator.com/item?id=39845805 https://news.ycombinator.com/item?id=39845805

tekno45 3y ago
Good info here https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handle-card https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
refulgentis 3y ago
Correct. Though it's not the same on Android, you can be not-Google and do payments just fine, provided you have the same business relationships with the CC companies as a big merchant processor (good luck) Not a huge fan of Android, but Android's pretty damn open, the open advocacy orgs unfortunately tend to conflate "you have to say "yes" to a dialog about untrusted apps in Android! intentionally difficult!" with the debacle the years-long Apple stuff has turned into. I suspect we'll see less of that equivocation now that the petulance is nakedly visible, and gratefully, there's no longer billions spent on things like the "Privacy™" ad campaign, rushed after 100s of celebs had their nudes leaked from iCloud due to bad customer support.
mundays 3y ago
The biggest difference is that no internet connection is required for the authentication because the bank trusts the user's device. CC number is randomized per transaction so that the merchant does not receive the real CC number. 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.
- 1ncorrect 3y ago
  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 3y 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 3y 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/...
mainde 3y ago
>Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard. In my experience this is normally due to either how the card machine provider has set up the device or due to the lack of certification of the mobile wallet functionality on the "acquirer" backend ("host") that speaks to the card schemes. It's annoyingly tricky to get the end-to-end transaction working properly across all schemes, all payment methods and devices. Different card schemes support different "payment kernel" parameters and have different certification requirements. It could also be an attempt to save money on transaction fees, amex is generally significantly more expensive for merchants.
- Nursie 3y ago
  Historically, Amex always required a separate retailer relationship and to act as its own acquirer. I don't know how true that is any more. They've just always been the awkward one, with higher fees and special relationships. Also they used to use ANSI standards on some stuff where everyone else used ISO... but that's going back 20 years!
  - inkyoto 3y ago
    Yes, that is still true – AmEx own their own payment processing network, and they do not allow outsiders into it, even banks they have the brand sharing agreements with, hence a separate retailer relationship.
- devmor 3y ago
  >Different card schemes support different "payment kernel" parameters and have different certification requirements. Those certification requirements are one of the biggest hurdles because they can change quite often, and unless you are a high-volume gateway, there may be no leniency for you, making simply refusing the transactions cheaper than processing them and being fined. The digital cryptogram requirements for visa caused some major engineering expenditures for a few payment processors I'm aware of.
- EricE 3y ago
  When I briefly had my own store I blocked amex because of their ridiculous fees. And they are pretty merchant hostile re: chargebacks too. The overhead and headache wasn't worth dealing with them. That was a while ago so maybe they have improved, but I still occasionally run into places that don't take them so I guess not.
Nursie 3y ago
They work using contactless EMV, which is the same way contactless credit cards work, and is the standard behind Visa/MC's Paywave and Paypass products. This is why wireless terminals in general just work with apple and google pay and actually didn't need much in thw way of special support. From what I recall one of the few things that did change was raising of payment limits for these devices over contactless cards, because they are deemed more secure (can't be used by just anyone that happens to have stolen it). > Why are these apps so hard/impossible to replace by open-source alternatives? EMV implementations are non-trivial and need a lot of testing and validation using specialised equipment. There need to be secure enclaves on the device to hold private keys in a way that can't easily be compromised. The app needs to interact with the phone in such a way as it can tell that biometric or PIN-based unlocks have been used so that it can vouch for user security. And the app needs to interface with card-issuing banks on the back end during setup, to get the keys and details it needs issued. An open source implementation would need to jump through a lot of hoops and set up agreements with the banks and pay for all sorts of lab verification (probably through UL).
- lxgr 3y ago
  > From what I recall one of the few things that did change was raising of payment limits for these devices over contactless cards, because they are deemed more secure (can't be used by just anyone that happens to have stolen it). The limits are the same, but what these wallets added is on-device cardholder verification. In a nutshell, it lets Apple Pay tell the terminal "the cardholder already did Face ID/Touch ID/entered their passcode; it's fine", which can then skip PIN entry or signature collection. Other wallets do it differently and only prompt for that on-device authentication if the amount exceeds that where a PIN or signature would normally be required; yet others don't support it at all and just make you enter the PIN on the terminal (if there is any).
  - karlshea 3y ago
    A couple of times that lack of signature verification tripped up a cashier, they’re obviously used to always needing it with however their terminal was configured, but with Apple Pay the receipt got printed with no signature line and after looking at it funny they’re like, “oh, well here’s you’re receipt I guess you don’t need to sign!”
lxgr 3y ago
> But what is Apple and Google's special proprietary sauce then? There isn't any. Many banks across the world offer their own HCE wallets, but these only run on Android (Apple simply doesn't offer the necessary APIs, although that's now changing in the EU). What does matter a lot are defaults: You can only have one default Visa, Mastercard etc. wallet per device (that you don't need to specifically need to open before tapping your phone), so Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet. > However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves. They don't. They're involved in mediating the initial setup of a new card on a given device, but aren't part of the actual transaction flow at all (at the POS, in any case). > Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard. The underlying card brand still needs to be accepted by the merchant. Unlike e.g. early Google Pay (or what it was called back then; I lost track) and some other solutions, modern-day Google Pay and Apple Pay aren't "proxy cards" (which can sometimes change the card brand, e.g. from Visa to Mastercard; an example of that would be Curve). > it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps. They don't. Unless a given POS terminal is buggy, it'll work anywhere that otherwise accepts the underlying card scheme. The physical and logical protocols are exactly the same as for actual plastic cards and mostly indistinguishable to the terminal; actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side. On the web it's a different story; explicit support by both the store website and payment service provider is needed there.
- codethief 3y ago
  > Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet. Ah, so it's the integration with issuer banks in the background that requires a lot of effort. That makes sense! Thanks so much for enlightening me! :)
  - p_l 3y ago
    Android essentially provided bunch of interfaces over time to either load a complete payment infrastructure through hw means (usually it involved telco cooperating with banks to provide EMV secure element on the SIM card, and the NFC chip has hardware connection to the SIM card), and later and more popular there's both complete Host Card Emulation capability (so you can run EMV protocol in your app) plus Google Pay integration making it easier on issuer because now they don't have to implement EMV themselves on HCE, and also provide more convenience to users vs forcing you to open specific app when you have more than one card connected.
numpad0 3y ago
I suspect there are more than just one combination of frontend and backend for Apple/Google Pay depending on how you're paying, masked behind that act of you presenting the device and store presenting the reader. So I think there can be cases where "payments" (or promises thereof) can be made, while money withdrawn from banks notwithstanding, e.g. queued in an intermediary entity and manually resolved on request, in which cases the payment gateway might want to pattern detect and shut down such cases.
Nursie 3y ago
> Can anyone ELI5 how Apple & Google Pay work in detail? Oh, in case this was not really answered in other responses ... When you add a card to an Apple or Google wallet, the wallet softwares goes off to your card issuer and asks for permission to include it in the wallet. Your card issuer may then ask you directly if it's OK and please confirm. When you have confirmed, they provide some details to your phone including some private keys (likely derived from a master) and other bits and pieces like the PAN to use, supported transaction types etc. OK, now it's set up in your phone. What happens when you tap? The terminal first goes through a sort of rapid handshake - hey, I'm a terminal, please select your default card application, let's go! Then it asks for a bunch of data - can I have your PAN, expiry, velocity data, hard and soft limits etc, please? Then it sends a bunch of data to your card - transaction type (payment, cash, refund(?)), amount, date and time, terminal type, some other bits. Your phone or card will then check these fit in with its internal rules (do I allow cash? etc), add some information (user unlocked biometrically/with PIN) arrange the data in a canonical order, hash and sign it and send back the resulting signature as a cryptogram. Part of this cryptogram will tell the terminal Yes/No to proceed and whether it needs to ask for a PIN or go online to the acquiring bank for approval. The terminal applies its own rules to the transaction as well, and can optionally downgrade the transaction from approved to online or denied, or from online to denied. If it needs to go online, it will transmit the transaction details to the acquiring (merchant's) bank, which may approve the transaction immediately or itself refer the transaction to the issuing (your) bank. It's at this point, for Apple Pay, that Apple steps into the picture - as the PAN is not the 'real' PAN, the acquiring bank refers to apple, and they then refer to the issuer. Then the approved message pops up :) Apart from the issuer-proxying, the process is basically identical if you use a phone or your physical card. I've probably glossed over quite a lot and got a couple of details wrong, but hey, that's the nature of ELI5.
- codethief 3y ago
  Thanks so much!
sitharus 3y ago
The only “secret sauce” is the liability shift. Traditional online and contactless payments are classed as “cardholder not present” transactions which place more liability for fraud on the merchant. Apple and Google Pay (and other bank-provided payment apps) use biometrics to confirm cardholder authorisation, switching a subset of payment types to cardholder present. This means some chargeback types are instantly declined, and others have a lower requirement for merchant proof. This is all part of the card network standards, which are freely available if you’re interested from https://www.emvco.com/ https://www.emvco.com/ The reason there’s no open source option is the requirement to certify the implementation’s security, so you need a commercial entity to work with the banks. Oh, and every bank has to integrate separately - that’s a lot of banks to talk to.
- Nursie 3y ago
  Contactless card transactions are not “Cardholder not present” transactions! They are usually “No Cardholder Verification Method” transactions, though they can do ask for PIN entry in some circumstances. And no, the liability is not with the merchant for contactless, or they never would have accepted it! It’s firmly with the banks, which is why the limits were initially so low - to limit potential fraud. When it transpired that fraud was more than acceptably low, they raised the limits a bit. The liability is only with the merchant if the merchant chooses to accept a magnetic swipe transaction, or keyed card details. Not contactless EMV.
  - anticensor 3y ago
    > They are usually “No Cardholder Verification Method” transactions, though they can do ask for PIN entry in some circumstances. In Turkey, contactless transactions are "Special Cardholder Verification Required, no PIN" or "Cardholder Present, PIN required" depending on the amount. And they are legally required to be performed online with immediate confirmation.
criddell 3y ago
This is not an ELI5, but it is all the details: https://www.emvco.com/emv-technologies/payment-tokenisation/ https://www.emvco.com/emv-technologies/payment-tokenisation/ EMVCo is American Express, Discover, JCB, Mastercard, UnionPay and Visa. It’s basically a credit card standardization group.
Reason077 3y ago
> "But what is Apple and Google's special proprietary sauce then? Why are these apps so hard/impossible to replace by open-source alternatives?" Google Pay and Apple Pay aren't unique. There's Garmin Pay and Samsung Pay, too, for example. The EMV standards are maintained by EMVCo (www.emvco.com), and the specification documents seem to be out there and googleable. I'm sure anyone sufficiently qualified in NFC tech could have a go at implementing them on their own device. The only tricky part is that you have to interface with each card issuer (bank) to generate DPANs?

tekno45 3y ago

Good info here https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handle-card https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...

refulgentis 3y ago

Correct. Though it's not the same on Android, you can be not-Google and do payments just fine, provided you have the same business relationships with the CC companies as a big merchant processor (good luck) Not a huge fan of Android, but Android's pretty damn open, the open advocacy orgs unfortunately tend to conflate "you have to say "yes" to a dialog about untrusted apps in Android! intentionally difficult!" with the debacle the years-long Apple stuff has turned into. I suspect we'll see less of that equivocation now that the petulance is nakedly visible, and gratefully, there's no longer billions spent on things like the "Privacy™" ad campaign, rushed after 100s of celebs had their nudes leaked from iCloud due to bad customer support.

mundays 3y ago

The biggest difference is that no internet connection is required for the authentication because the bank trusts the user's device. CC number is randomized per transaction so that the merchant does not receive the real CC number. 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.

1ncorrect 3y ago
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 3y 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 3y 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/...

mainde 3y ago

>Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard. In my experience this is normally due to either how the card machine provider has set up the device or due to the lack of certification of the mobile wallet functionality on the "acquirer" backend ("host") that speaks to the card schemes. It's annoyingly tricky to get the end-to-end transaction working properly across all schemes, all payment methods and devices. Different card schemes support different "payment kernel" parameters and have different certification requirements. It could also be an attempt to save money on transaction fees, amex is generally significantly more expensive for merchants.

Nursie 3y ago
Historically, Amex always required a separate retailer relationship and to act as its own acquirer. I don't know how true that is any more. They've just always been the awkward one, with higher fees and special relationships. Also they used to use ANSI standards on some stuff where everyone else used ISO... but that's going back 20 years!
- inkyoto 3y ago
  Yes, that is still true – AmEx own their own payment processing network, and they do not allow outsiders into it, even banks they have the brand sharing agreements with, hence a separate retailer relationship.
devmor 3y ago
>Different card schemes support different "payment kernel" parameters and have different certification requirements. Those certification requirements are one of the biggest hurdles because they can change quite often, and unless you are a high-volume gateway, there may be no leniency for you, making simply refusing the transactions cheaper than processing them and being fined. The digital cryptogram requirements for visa caused some major engineering expenditures for a few payment processors I'm aware of.
EricE 3y ago
When I briefly had my own store I blocked amex because of their ridiculous fees. And they are pretty merchant hostile re: chargebacks too. The overhead and headache wasn't worth dealing with them. That was a while ago so maybe they have improved, but I still occasionally run into places that don't take them so I guess not.

Nursie 3y ago

They work using contactless EMV, which is the same way contactless credit cards work, and is the standard behind Visa/MC's Paywave and Paypass products. This is why wireless terminals in general just work with apple and google pay and actually didn't need much in thw way of special support. From what I recall one of the few things that did change was raising of payment limits for these devices over contactless cards, because they are deemed more secure (can't be used by just anyone that happens to have stolen it). > Why are these apps so hard/impossible to replace by open-source alternatives? EMV implementations are non-trivial and need a lot of testing and validation using specialised equipment. There need to be secure enclaves on the device to hold private keys in a way that can't easily be compromised. The app needs to interact with the phone in such a way as it can tell that biometric or PIN-based unlocks have been used so that it can vouch for user security. And the app needs to interface with card-issuing banks on the back end during setup, to get the keys and details it needs issued. An open source implementation would need to jump through a lot of hoops and set up agreements with the banks and pay for all sorts of lab verification (probably through UL).

lxgr 3y ago
> From what I recall one of the few things that did change was raising of payment limits for these devices over contactless cards, because they are deemed more secure (can't be used by just anyone that happens to have stolen it). The limits are the same, but what these wallets added is on-device cardholder verification. In a nutshell, it lets Apple Pay tell the terminal "the cardholder already did Face ID/Touch ID/entered their passcode; it's fine", which can then skip PIN entry or signature collection. Other wallets do it differently and only prompt for that on-device authentication if the amount exceeds that where a PIN or signature would normally be required; yet others don't support it at all and just make you enter the PIN on the terminal (if there is any).
- karlshea 3y ago
  A couple of times that lack of signature verification tripped up a cashier, they’re obviously used to always needing it with however their terminal was configured, but with Apple Pay the receipt got printed with no signature line and after looking at it funny they’re like, “oh, well here’s you’re receipt I guess you don’t need to sign!”

lxgr 3y ago

> But what is Apple and Google's special proprietary sauce then? There isn't any. Many banks across the world offer their own HCE wallets, but these only run on Android (Apple simply doesn't offer the necessary APIs, although that's now changing in the EU). What does matter a lot are defaults: You can only have one default Visa, Mastercard etc. wallet per device (that you don't need to specifically need to open before tapping your phone), so Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet. > However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves. They don't. They're involved in mediating the initial setup of a new card on a given device, but aren't part of the actual transaction flow at all (at the POS, in any case). > Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard. The underlying card brand still needs to be accepted by the merchant. Unlike e.g. early Google Pay (or what it was called back then; I lost track) and some other solutions, modern-day Google Pay and Apple Pay aren't "proxy cards" (which can sometimes change the card brand, e.g. from Visa to Mastercard; an example of that would be Curve). > it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps. They don't. Unless a given POS terminal is buggy, it'll work anywhere that otherwise accepts the underlying card scheme. The physical and logical protocols are exactly the same as for actual plastic cards and mostly indistinguishable to the terminal; actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side. On the web it's a different story; explicit support by both the store website and payment service provider is needed there.

codethief 3y ago
> Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet. Ah, so it's the integration with issuer banks in the background that requires a lot of effort. That makes sense! Thanks so much for enlightening me! :)
- p_l 3y ago
  Android essentially provided bunch of interfaces over time to either load a complete payment infrastructure through hw means (usually it involved telco cooperating with banks to provide EMV secure element on the SIM card, and the NFC chip has hardware connection to the SIM card), and later and more popular there's both complete Host Card Emulation capability (so you can run EMV protocol in your app) plus Google Pay integration making it easier on issuer because now they don't have to implement EMV themselves on HCE, and also provide more convenience to users vs forcing you to open specific app when you have more than one card connected.

numpad0 3y ago

I suspect there are more than just one combination of frontend and backend for Apple/Google Pay depending on how you're paying, masked behind that act of you presenting the device and store presenting the reader. So I think there can be cases where "payments" (or promises thereof) can be made, while money withdrawn from banks notwithstanding, e.g. queued in an intermediary entity and manually resolved on request, in which cases the payment gateway might want to pattern detect and shut down such cases.

Nursie 3y ago

> Can anyone ELI5 how Apple & Google Pay work in detail? Oh, in case this was not really answered in other responses ... When you add a card to an Apple or Google wallet, the wallet softwares goes off to your card issuer and asks for permission to include it in the wallet. Your card issuer may then ask you directly if it's OK and please confirm. When you have confirmed, they provide some details to your phone including some private keys (likely derived from a master) and other bits and pieces like the PAN to use, supported transaction types etc. OK, now it's set up in your phone. What happens when you tap? The terminal first goes through a sort of rapid handshake - hey, I'm a terminal, please select your default card application, let's go! Then it asks for a bunch of data - can I have your PAN, expiry, velocity data, hard and soft limits etc, please? Then it sends a bunch of data to your card - transaction type (payment, cash, refund(?)), amount, date and time, terminal type, some other bits. Your phone or card will then check these fit in with its internal rules (do I allow cash? etc), add some information (user unlocked biometrically/with PIN) arrange the data in a canonical order, hash and sign it and send back the resulting signature as a cryptogram. Part of this cryptogram will tell the terminal Yes/No to proceed and whether it needs to ask for a PIN or go online to the acquiring bank for approval. The terminal applies its own rules to the transaction as well, and can optionally downgrade the transaction from approved to online or denied, or from online to denied. If it needs to go online, it will transmit the transaction details to the acquiring (merchant's) bank, which may approve the transaction immediately or itself refer the transaction to the issuing (your) bank. It's at this point, for Apple Pay, that Apple steps into the picture - as the PAN is not the 'real' PAN, the acquiring bank refers to apple, and they then refer to the issuer. Then the approved message pops up :) Apart from the issuer-proxying, the process is basically identical if you use a phone or your physical card. I've probably glossed over quite a lot and got a couple of details wrong, but hey, that's the nature of ELI5.

codethief 3y ago
Thanks so much!

sitharus 3y ago

The only “secret sauce” is the liability shift. Traditional online and contactless payments are classed as “cardholder not present” transactions which place more liability for fraud on the merchant. Apple and Google Pay (and other bank-provided payment apps) use biometrics to confirm cardholder authorisation, switching a subset of payment types to cardholder present. This means some chargeback types are instantly declined, and others have a lower requirement for merchant proof. This is all part of the card network standards, which are freely available if you’re interested from https://www.emvco.com/ https://www.emvco.com/ The reason there’s no open source option is the requirement to certify the implementation’s security, so you need a commercial entity to work with the banks. Oh, and every bank has to integrate separately - that’s a lot of banks to talk to.

Nursie 3y ago
Contactless card transactions are not “Cardholder not present” transactions! They are usually “No Cardholder Verification Method” transactions, though they can do ask for PIN entry in some circumstances. And no, the liability is not with the merchant for contactless, or they never would have accepted it! It’s firmly with the banks, which is why the limits were initially so low - to limit potential fraud. When it transpired that fraud was more than acceptably low, they raised the limits a bit. The liability is only with the merchant if the merchant chooses to accept a magnetic swipe transaction, or keyed card details. Not contactless EMV.
- anticensor 3y ago
  > They are usually “No Cardholder Verification Method” transactions, though they can do ask for PIN entry in some circumstances. In Turkey, contactless transactions are "Special Cardholder Verification Required, no PIN" or "Cardholder Present, PIN required" depending on the amount. And they are legally required to be performed online with immediate confirmation.

criddell 3y ago

This is not an ELI5, but it is all the details: https://www.emvco.com/emv-technologies/payment-tokenisation/ https://www.emvco.com/emv-technologies/payment-tokenisation/ EMVCo is American Express, Discover, JCB, Mastercard, UnionPay and Visa. It’s basically a credit card standardization group.

Reason077 3y ago

> "But what is Apple and Google's special proprietary sauce then? Why are these apps so hard/impossible to replace by open-source alternatives?" Google Pay and Apple Pay aren't unique. There's Garmin Pay and Samsung Pay, too, for example. The EMV standards are maintained by EMVCo (www.emvco.com), and the specification documents seem to be out there and googleable. I'm sure anyone sufficiently qualified in NFC tech could have a go at implementing them on their own device. The only tricky part is that you have to interface with each card issuer (bank) to generate DPANs?