CashtoCode vs Apple Pay: Not the Same Contest

Comparison pages love a head-to-head. This one has to start by admitting that these two are barely in the same contest.

Apple Pay is a way of presenting a card. CashtoCode is a way of paying without one. If you hold a card the checkout accepts and you are happy to use it, Apple Pay is almost certainly the more convenient option, and no amount of feature-table arrangement changes that.

The interesting question is what happens when one of those two conditions fails.

CashtoCode vs Apple Pay: what each one actually is

Apple Pay stores a card you already own and presents it at checkout in tokenised form. The merchant receives a device-specific number rather than your card number, and authentication happens on your device. Underneath, it remains an ordinary card transaction: your bank authorises it, your statement records it, and the card scheme’s rules apply — including chargeback rights.

The CashtoCode eVoucher is a prepaid 20-digit PIN bought from an authorised reseller and typed into a merchant’s checkout. No card is presented because none is involved. There is no account with us, no login and no stored history, and the merchant receives a code and an amount.

One requires a card and a bank. The other requires neither. That is the whole difference, and everything else is downstream of it.

Where Apple Pay is genuinely better

It deserves a fair hearing, because the tokenisation is not marketing.

Handing a merchant a token instead of a card number meaningfully limits the blast radius of a merchant data breach — the stolen token is tied to a device and is not your card. That is a real improvement over typing sixteen digits into a form, and it applies at every merchant that supports it.

It is also faster than anything else at a checkout, it works across an enormous merchant network including ordinary retail, and it carries the card scheme’s dispute rights with it. If a purchase goes wrong, you have a route back that a prepaid code does not offer.

None of that is in dispute here.

Where the comparison turns

Two situations, and they are more common than the 92 percent card-ownership figure suggests.

You do not hold a suitable card. Around 8 percent of euro-area consumers hold no payment card at all, and card ownership has edged down rather than up. Beyond that, holding a card is not the same as holding one a given checkout accepts — a domestic debit card is often refused by international merchants. Apple Pay cannot solve either case, because it has nothing to present.

You hold one but would rather it stayed out of this. A card payment produces a statement line naming the merchant. Tokenisation does not touch that, because the token protects you from the merchant, not from your own bank. For anyone whose reason for looking at alternatives is the statement rather than the merchant, Apple Pay solves the wrong half of the problem.

That second point is where most fair comparisons of these two end up, and it is worth stating without exaggeration: this is about which party sees what, not about being invisible.

What each party sees

	Apple Pay	CashtoCode eVoucher
Card number reaching the merchant	No — device token instead	No card exists
Merchant name on your statement	Yes	No, when the code was bought with cash
Requires a card	Yes	No
Requires a bank account	Yes, behind the card	No
Chargeback rights	Yes, via the card scheme	No
Works at ordinary online retail	Yes, broadly	No, by design
Deposits and payouts	Both	Deposit only

The two rows that decide most real cases are the last three. Apple Pay is the general-purpose instrument with recourse attached. Ours is a narrow instrument for a specific set of merchants — casinos, sportsbooks, crypto exchanges, VPN and hosting providers, gaming marketplaces and dating platforms — with no recourse and no way back out.

Our page on paying online without a credit card sets out the wider field, including options that sit between these two.

The trade you are actually making

Give up chargeback rights, gain the absence of a card in the transaction.

That is a good trade for a modest deposit at a merchant you have chosen deliberately. It is a poor trade for an expensive purchase from a seller you have never dealt with, where the card scheme’s dispute process is exactly the protection you want.

Anyone telling you a prepaid code is simply better than a card is not describing a payment method, they are selling one. The honest version is that the two protect you against different failures, and only you know which failure is likelier in your case.

What we would actually recommend

Hold a card the checkout accepts, and want convenience and recourse? Use it, ideally through a wallet, because tokenisation is a free improvement over typing the number.

Hold no such card, or want the transaction to stay off your statement, and are depositing an amount you would be comfortable handing over in cash? That is what our eVoucher is for, and it does that job cleanly.

Those are different situations, not competing products.

Using both, which is the common case

There is a combination worth knowing about, because it confuses people the first time they meet it: some reseller checkouts accept Apple Pay as a way of buying a prepaid code.

That is not a contradiction. It gives you the wallet’s convenience for the purchase and the code’s properties at the merchant, which still receives only a code and an amount. What it does not do is remove the card transaction. Buying a code with a card leaves a line on your statement for that purchase, though never one naming the merchant where you later redeem it.

So if the statement is the thing you are managing, the cash purchase is the step that matters, not which wallet you tap at the reseller. Our page on eVoucher fees sets out what each purchase route costs, and the MiFinity comparison covers the case where the alternative is an account rather than a card.

The general principle is worth carrying into any comparison of this kind: convenience layers sit on top of funding sources, and only the funding source determines what your bank sees. A wallet changes the experience of paying. It does not change who is paying, or from what.