Apple Pay as a Digital Check
Adopting modern encryption to credit card payments
You shouldn’t use credit cards.
They’re not secure—maybe not as insecure as checks, but not by much. Not because the data is written on the plastic, and can be lost (although, that too).
No. My issue with credit cards is that the whole protocol is a mess, designed in an era where being online was science fiction.
When trust, not scale, was the bottleneck.
There are two features that make the credit card protocol insecure. One is that the details written in your card are reusable. When you fill a checkout form, you always key in the same information every time. The other is that to prove that you are who you claim to be, you need to share precisely the information that should be kept secret.
This creates a challenge: despite the combined efforts of everyone working in payments, if someone wants to steal your card data, they just have to ask you in a way that seems convincing. Trained by habit, we often fall for it.
It’s 2024, and credit card fraud it’s still a thing.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. It is frustrating to see diagrams on LinkedIn about payment systems that are simplistic, or even wrong. The ugly truth is that there’s not much out there that teaches you how to build money software for real users and real money.
The reason I know this is because I’ve built and maintained payment systems for almost ten years. I’ve been able to see all types of interesting conversations about what works and what doesn't behind closed doors.
And I thought, “you know what? It’s time we have these conversations in public”.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extract tactics from it. Today’s article goes deep on encryption, privacy, and the next generation of payment protocols.
Let’s dive in.
Credit cards belong to an era when payments were made face to face.
This is critical: physical presence made fraud unthinkable—the risk of getting caught “in the act” was enough of a deterrent. But e-commerce vaporized this risk. Fraud, as a result, is at an all time high, both in amount and frequency.
The physical world is local, and so it's grounded on community and trust.
The online world is global, and it’s conceived on secrets and verification.
Offline, this is how we let others know that we know a secret: by sharing it. We have no choice but to trust. That’s why community is so important offline: it’s the familiar face that secures the system.
Online, we had to be smarter. That’s why we rely on a mathematical trick: we prove that we know a secret by sharing the result of calculations that we could have only produced if we knew the secret.
This is called public-key cryptography. Much of the online world relies on it. Credit card payments would benefit a lot from it.
From faces to hardware
The core assumption in the online world: being you and knowing your secrets is the same thing. That’s exactly why what used to work offline is disastrous online: we’re forced to trust in an untrustworthy place.
Public-key cryptography relies on mathematical problems that are intractable. These are problems that, to our best knowledge, there is no alternative to brute force to solve them.
This is a useful property if we don’t want others to decode our secrets. However, that’s not enough: we want the recipient to be able to decode what others can’t.
This paradox gets resolved because there’s a subset of intractable problems, called one-way functions, which are intractable to solve, but whose solution is easy to verify.
If you’re somewhat familiar with crypto, you know that figuring out the two factors of a large semiprime is one of those problems. You wouldn’t even know where to start figuring out what are the factors of 359,999, but you’re a few keystrokes away from checking that dividing that number by 599 gives you 6011.
One-way functions form the basis of public-key cryptography: they make verification easy and fast, and are robust to the most powerful computers.
Their downside is: they’re a pain in the ass.
Keeping track of a long string of numbers and letters is unmanageable for humans. We barely keep up with a few phone numbers. That’s why they have to be stored safely, which introduces a problem: who can I trust with my most important secrets?
The best person to trust is probably not a person, but a cryptographic key. That’s a device that stores the secret for you, so that you don’t even have to remember it or write it down somewhere.
This is where Apple and Google come in.
A DNS of Credit Card data
If cryptographic keys are a great way to store your secrets online, it would be amazing if your smartphone were one. And it is! Over the last decades, smartphones had slowly integrated a certified environment (that is, a separate operating system running on an isolated chip) called Secure Element.
It’s been a slow burn, especially in the US, but it’s becoming a popular way to pay, both online and offline.
And it works like DNS records:
When you type “birchtree.me” into your browser, your browser is able to determine what IP address this domain is related to and directs you there. I can keep my website physically in the same place on the same IP address, but I can change the domain to birchtree.com or wigglewobble.org and browsers will know what to do without the user needing to know what IP address is involved.
— Digital wallets and the “only Apple Pay does this” mythology
The guys at ByteByteGo have an article on Apple Pay and Google Pay that’s unfortunately wrong, so let’s get the record straight.
Unlike store credits, which we’ve already covered, Apple Pay and Google Pay are pass-through, open-loop wallets.
This means that when you add your credit card to your smartphone, the payment network sends a number called DPAN, or Device Primary Account Number, and a private key. Both are stored in the Secure Element.
When you authenticate the payment (the “double click to pay” on your iPhone), the Secure Element emits the DPAN and a transaction-specific token. This token can be sent to the PSP to process the payment as if it were a normal, credit card token.
Then, the network will use the DPAN and the token to decrypt your actual credit card details, and will pass them to the issuer.
Do you need to authenticate the transaction with 3DS? The short answer is “it depends”. Based on the payment network and your smartphone’s operating system, you may not need to. The long answer is “ask your PSP”.
Privacy, and the MPAN
Consumers don’t really care about secure payments.
Sure, they do in the abstract. But the regulators have removed all liability from them when fraud happens. And so, they don’t really care, because, in the end, they get their money back.
What consumers demand is privacy.
This puts them at odds with merchants, where the consensus is that the more data collected about their prospects, the easier it is to convert them into customers. One of the key selling points of digital wallets is that the DPAN hides the credit card details from the merchant.
That, however, doesn’t mean they can’t track you.
The DPAN is specific to the device you’re using. Losing your phone means getting a new DPAN, and using the same card on your iPhone and your Mac creates two of them.
Plus, data brokers might buy this data from merchants, because they can use it.
The DPAN also presents another important challenge, and that is subscriptions. There’s no way for merchants to update credentials—even when you’ve removed the card from your device. Your subscription to Netflix will eventually fail.
To fix this, Apple introduced MPANs, or Merchant PANs.
While DPANs were device specific, MPANs are unique to the merchant. This provides enough granularity to keep subscriptions active even when the device is lost. MPANs are also useless for data brokers.
However, it doesn’t prevent a single merchant from seeing your transaction history within their ecosystem.
Checks, then Cards, and then (digital) checks again
Using a transaction-specific token for authentication is not unlike cashing a check at the teller.
Thankfully, we’ve come a long way, and this digital check doesn’t expose sensitive information the way checks do.
This should give you pause. Have you ever heard how Bitcoin consumes as much electricity as the Netherlands? This comparison has always rubbed me the wrong way, mostly because the Netherlands isn’t a payments system.
It’s not apples to apples: comparing them is meaningless.
A more useful comparison would be to calculate how much human labor, compute power and time is spent authenticating credit card transactions.
Which highlights what Bitcoin's real problem is: not that the energy footprint is high (which it is), but that it is measurable.
Bitcoin is based on “proof of work”. But credit cards use “proof of trust”, and it’s probably as impactful as bitcoin’s.
Moving credit card authentication from the way it’s currently prevalent that leverages modern mechanisms like public-key encryption is an effective way to reduce the payments’ energy footprint.
So, if a more private and secure payment protocol doesn’t convince you to switch, perhaps this will.
This has been The Payments Engineer Playbook, I’ll see you next week.
PS: Do you have 2 minutes?
Years ago, when I became interested in finance for the first time, a newsletter like this didn’t exist. I sure wish it had. I had been a paying subscriber for Stratechery right after I read it for the first time. I read all of Michael Lewis’s books voraciously. Especially Flash Boys.
But none of that helped me build better money software. I learned a lot, yes. But I couldn’t apply any of it.
With The Payments Engineer Playbook, I set out to write what I needed back then. What would’ve made me a better payments engineer. What would’ve led me to avoid lots of costly mistakes along the way.
There are a few newsletters that many of us in the payments industry know about. But they are focused on one of two things: system design job interviews, and soft skills.
And look, I get it! These are probably the only topics that are broadly applicable for software engineers. System design interviews are mostly the same, regardless if you’re interviewing for one company or another, and soft skills are valuable everywhere.
But what’s going to put you ahead is doing your damned job right.
If you build software that moves money around, being a paid subscriber of The Playbook pays for itself.
You may know that this newsletter is going to become a paid publication in 2025. Before then, you can pledge a subscription for a lower price, because as soon as the year starts, the price will increase.
If you know somebody who can benefit from this newsletter, can I ask you to forward this email to them?
Even if they can’t afford it themselves, most companies have a training budget for their employees (ask your manager). These things move slowly though, so if you need approval from your company, better hurry up before the window closes.
And if someone you respect shared this article with you, do me a favor and subscribe. Every week I feel I’m getting better at this. That means that my best articles on how to build payment systems are probably yet to be written.
You can only find out if you subscribe to The Payments Engineer Playbook. I’ll see you around.
Prime numbers like 599 and 601, whose difference is exactly 2, are called twin primes. There’s a famous conjecture that says that there are an infinite number of these pairs, but we don’t know for sure