News · New this week
Tap to pay design with Apple Pay and Google Pay
A walkthrough of the tap to pay interview design, from the phone's token to the issuer bank, and how retries avoid a double charge.
The shop never sees your real card number when you tap. That is the answer to the interview question "design an app like Apple Pay", and the reel walks through it in under a minute. Here is the same design with a bit more room.
The answer that gets rejected
The obvious design has the phone send the real card number to the card machine, which passes it on to the bank. The flow is Phone, Card number, Machine, Bank.
It fails fast. If the shop gets hacked, every card that was tapped there leaks. So the interviewer rejects it.
A good design has to meet three conditions at the scale of millions of taps a day. The number stays safe, the tap is fast, and nobody gets charged twice.
Token and one-time code
When you add a card, Visa or Mastercard creates a token. It's a stand-in number for this one phone. It isn't the real number.
So what if the phone is stolen? Not much happens. Every tap also carries a one-time code, called a cryptogram, and it's different each time. An old one can't be replayed.
The machine sends the token to the acquirer, which is the shop's bank. That's where the money lands.
Where the real number lives
After the acquirer, the request goes to the card network. The network holds the token vault, which stores the pairing of each token and its real card number. The shop doesn't have that pairing. Only the network does.
The network then forwards the request to the issuer bank, the bank that issued your card. The issuer checks your limit and approves.
The full path is Phone, Card machine, Acquirer, Card network, Issuer bank. The real number only travels from the network to the issuer.
Stopping the double charge
At peak times the issuer can be slow. Taps pile up as pending, and you tap again.
The fix is to reuse the same transaction ID on the retry. The bank sees an ID it already knows and doesn't charge again. Without that, a slow issuer turns into duplicate charges.
The reel ends by pointing out that this is the standard interview design. It isn't Apple's own internal design.
A real-world note
Apple Pay in India is live only with Axis Bank credit cards, on Visa and Mastercard. RuPay, debit cards and UPI aren't supported yet.
What to try
Next time you practice a payments design question, draw the five hops and mark who holds what. Phone has the token, the network has the vault, and the retry carries the same transaction ID. If you can say that cleanly, you have the answer.
