Nobody chooses a device to pay on. Whatever is in your hand when you decide to buy something is the device that takes the payment. It is a decision made by accident, roughly a billion times a day.
It is worth about ninety seconds of thought, because the screen you use changes three things: whether the payment clears first time, how much of your card detail the seller ever receives, and whether you end up with a record you can find later. The phone is better at two of those and worse at the third.
What actually changes with the device
Almost nothing changes because the screen is small. What changes is that a phone usually has a wallet configured and a laptop usually does not, so the comparison people call "mobile versus desktop" is nearly always wallet versus typed card wearing a different name.
That distinction matters, because a phone with no wallet set up offers none of the advantages below — it is a typed card on a smaller keyboard, which is marginally worse than a laptop. And a desktop with a wallet available in the browser gets most of the benefit without the phone being involved at all.
Browser autofill sits awkwardly between the two and is worth understanding correctly, because it feels like a wallet and is not one. Autofill types the real card number into the form on your behalf. It removes the typing error and nothing else: the seller still receives the full number, and no authentication has taken place that the bank can see. It is a convenience feature wearing a security feature's clothes, and treating it as equivalent to a wallet is the most common misreading of this whole comparison.
| Factor | Wallet on a phone | Typed card on a desktop |
|---|---|---|
| What the seller receives | A device-specific token | The card number itself |
| Authentication | Fingerprint or face, on the device | A code, often by text |
| Risk of a typing error | None — nothing is typed | The most common failure |
| Likelihood of a refusal | Lower | Higher on a foreign purchase |
| Reading the terms properly | Poor | Good |
| Saving the confirmation | Awkward | Straightforward |
The token, and why the seller sees less
This is the part with genuine substance behind it, as opposed to convenience.
When a card is added to a wallet, the device stores an encrypted stand-in rather than the number. At payment, that stand-in travels to the seller together with a one-time cryptogram. The seller ends up holding something that can charge that specific card, through that specific wallet, on that specific device — and is worthless anywhere else.
Compare that with a typed card. The seller receives the actual number, which works anywhere the card works, for as long as the card is valid. However carefully it is handled, the difference in what has been handed over is not close. This is also why the wallet route reduces the consequences of a seller being careless with their own systems, which is a risk you cannot inspect from outside. The comparison in full is in paying by card versus paying by wallet.
The wallet does not make a bad seller safe. It makes a specific failure — your card number being stored somewhere it should not be — largely impossible, and it does nothing about any of the others. It is a narrow protection, applied perfectly.
Why wallet payments clear more often
A refusal on a foreign digital purchase is usually a fraud model deciding it has too little certainty about who is paying. Several inputs feed that decision, and a wallet payment improves most of them at once.
The fingerprint or face check is not a convenience feature — it is strong authentication performed on a device the bank associates with you, and it is reported as such. From the model's side, a payment that has already been authenticated on a known device is a substantially easier call than the same payment arriving as a bare card number from a browser it has never seen.
The billing address helps too. It comes from a stored profile rather than being retyped, so the address verification check either matches or does not for real reasons instead of failing on a formatting difference. On a cross-border payment this is a common and completely invisible cause of refusal. Everything the model is reacting to is broken down in bank declines on a foreign digital purchase, and a wallet quietly improves four of the five inputs described there.
The two failures the phone removes
The mistyped number. Sixteen digits, an expiry and a three-digit code, entered by hand, several times a year. The error rate is not zero and never has been. A wallet payment types nothing, so this failure mode does not exist rather than being reduced.
The stranded one-time code. This one is specific to the desktop and more annoying than it sounds. You start a payment on a laptop, the bank sends a verification code by text to your phone, and the phone is in another room or on charge. By the time you have it, the page has timed out. You retry, and now there are two authorisations in flight — which is one of the routes to the situation described in the cost of paying twice.
Paying on the phone collapses that whole sequence. The verification happens on the same device, in the same few seconds, with nothing to fetch.
The phone introduces one problem of its own, though, and it is worth naming because it undercuts the advice in the article this one links to most. Links opened from inside a messaging app frequently load in that app's own embedded browser rather than your real one, and those embedded browsers routinely hide or truncate the address bar. That removes the single most reliable check available to you at the moment you most need it. The fix is trivial: use the "open in browser" option before paying, or copy the link into your actual browser, so that the domain check described in signs a payment page is not the seller's own is still possible.
Where the desktop is still better
Two things, and they are not small.
Reading before you commit. Terms, refund position and renewal behaviour are genuinely hard to read on a phone. Long documents on small screens get scrolled rather than read, and the six clauses that decide what a yearly payment actually buys — set out in reading a subscription's terms before the money moves — are exactly the sort of thing a thumb skips past. Doing that part on a proper screen is worth more than the payment convenience it costs.
Keeping the record. A confirmation on a phone tends to stay on the phone. Saving a page as a PDF, filing it in a folder, checking the transaction reference in a banking app's detail view — all of it is faster and likelier to actually happen on a desktop. And a payment record that exists only in a messaging app on a device you will replace within three years is not really a record, which is the argument made at length in the paperwork worth keeping after you pay for a yearly service.
What does not change: your rights
Worth stating plainly because the marketing around wallets encourages the opposite impression. The device does not change what you can recover.
A wallet is a presentation layer over a payment method, not a payment method in itself. A wallet payment funded by a card is a card payment for every purpose that matters afterwards — same dispute route, same deadlines, same grounds. What those actually cover is in chargebacks explained.
Where a wallet operates its own protection scheme, that is an additional layer rather than a replacement, with its own separate clock — the detail of which is in what a PayPal dispute actually covers for digital goods. And cryptocurrency is final on every device ever made; the phone offers exactly one improvement there, which is scanning an address instead of pasting one. Everything else about that route is unchanged, as described in crypto payments: fast, cheap, and completely final.
Public wifi, mobile data and the security question
The instinct that public wifi is dangerous for payments is about a decade out of date, but the conclusion it points to is still reasonable.
A payment page is encrypted end to end, so somebody sitting on the same café network cannot read the card details in transit. That was the original fear and it has been addressed thoroughly. Mobile data is nonetheless slightly better, for the simple reason that the network belongs to your own account and there is one fewer party involved.
The real network risk sits earlier in the sequence, not at the payment. It is being directed to a page that is not the seller's in the first place, at which point encryption is working perfectly to protect a conversation with the wrong party. That problem is unchanged by device and is covered in signs a payment page is not the seller's own.
The arrangement that works best
Split the job across both devices along the line where each is actually better.
Read the terms, check the price and look at what you are buying on the largest screen available. Our figures sit permanently on the pricing page — $69, $97 and $137 a year for one, two and three simultaneous screens — so that comparison can be done properly before anything is paid.
Then make the payment on the device that holds your wallet, which for most people is the phone. Then, once it has cleared, go back to the desktop and file the confirmation and the reference number where you will still be able to find them in thirteen months.
Which methods we accept, and what each one gives you afterwards, is set out on the payment methods page. If a payment is refused and you are not sure whether to retry, ask the desk before trying again — a second attempt made in the wrong minute is the most reliable way to turn one problem into two.
