The first thing we built into the Nox Æterna checkout, before the form fields and the order numbers and the receipt PDFs, was an Apple Pay button. Google Pay sits beside it. The plain card form is there too, because we are not in the business of turning customers away, but the device-token buttons come first on purpose.
It is a small piece of front-end. It is also the most honest line in the entire checkout.
What Apple Pay actually does
When you tap Apple Pay, your real card number, the sixteen digits embossed on the plastic, never reaches us. It does not reach Stripe either. It does not pass through any log file, any analytics tag, any database column we own.
What we receive is a Device Account Number. It is a token bound to a specific device, generated when you first added your card to Wallet. It is signed for each individual transaction with a one-time cryptogram. If someone steals the token, they cannot use it on their phone, their browser, or their card-cloning kit. It is married to your hardware and useless without it.
Google Pay does the same trick with slightly different plumbing. The principle is identical: the merchant gets a stand-in, not the original.
What this means if we get breached
The honest way to think about any merchant is: assume the database leaks. Not as a prediction, as a planning exercise. Every team that has ever said "we take security seriously" was sincere right up until the morning of the incident.
So we plan for it. We hold the minimum data we need to file a removal on your behalf, we delete it on a schedule, and on the payments side we hold no card numbers at all. If our customer database were exfiltrated tomorrow, the attacker would find names, addresses, a few opt-out reference codes, and, where Apple Pay or Google Pay was used, a token that cannot be replayed against another merchant.
There is no card number to steal because we never had one in the first place.
That is not a feature we engineered. It is a consequence of routing the right way through Stripe and putting the device-token buttons at the top of the form.
Why most merchants quietly prefer the raw card
If tokenisation is so obviously better, why is the plain card form still the default across most of the internet? Because most merchants want the card on file.
They want it for the upsell, the cart-abandonment recovery email with a one-click button, the inevitable subscription renewal, the "we have updated your plan" charge that lands six months later. A Device Account Number is awkward for those games. It is bound to a device you may not be holding, and your bank can revoke it from Wallet without ever cancelling the underlying card. The merchant loses control of the relationship.
The raw PAN gives them that control back. It also gives them a thirteen-to-nineteen-digit number they now have to protect, on your behalf, forever. The risk is yours. The convenience is theirs.
The Stripe specifics, briefly
Our checkout uses Stripe's Payment Element. Apple Pay and Google Pay route through Stripe's tokenised network end to end. The card number, when one is involved at all, is captured inside a Stripe-hosted iframe that our JavaScript cannot read. We never see it, we never store it, and we are out of PCI-DSS scope for the parts of the standard that govern cardholder data at rest.
That last point matters less for marketing reasons and more because it shrinks the surface area an attacker can aim at. Code we do not write cannot be exploited. Data we do not hold cannot be exfiltrated.
A small architectural dig
The subscription-privacy companies, the ones charging fifteen pounds a month forever, structurally cannot do this cleanly. They need a card on file because the whole business model is the automatic renewal. Apple Pay tokens can be made to work for recurring charges, but the path of least resistance for a subscription product is to store the PAN and bill it monthly until you remember to cancel.
We take one payment. Then we are done. That is a pricing decision and a payment-method decision and an architectural decision, and they all point the same direction: hold less, store less, owe you less.
If you can pay with a tap
None of this is novel cryptography. Apple Pay launched in 2014. Google Pay tokenisation has been live for almost as long. The technology is mature, the network rails support it, and the friction at checkout is, on a modern phone, a single biometric tap.
The reason it is not the default everywhere is not technical. It is commercial. Knowing that should change how you read a checkout page. If a merchant offers Apple Pay or Google Pay, take it. If a merchant only offers raw card entry and you cannot tell why, that is a small signal worth noting.
If you would rather not hand over a card to buy a deletion service, you do not have to. Nox Æterna takes one £89 payment via Apple Pay, Google Pay, or card, then closes the door behind you.