You have money on the card. You can see it. The merchant is trying to charge you nothing at all, zero, and the payment fails anyway.
This is the single most confusing failure in prepaid cards, and the reason it is confusing is that everyone describes it wrong. It is not a bug, it is not MPay, and your card is not broken. The merchant asked your card a question, and an empty card cannot answer questions.
A pre-authorisation is a question, not a payment
Before charging you, most merchants send a separate request through the card network that means, roughly: does this card exist, is it active, and will it cover something later? The card answers yes or no. That is a pre-authorisation, and it happens before any money moves.
Sometimes the question comes attached to an amount, and the issuer puts a temporary hold on it. The hold is not a charge. It reduces what you can spend while the merchant decides whether to collect, and if they never collect, it falls off and the money comes back. Annoying, not lost.
Sometimes the question comes attached to nothing. A zero dollar authorisation. Pure "is this card real".
And here is where the intuition breaks. A card with exactly nothing on it can fail a request for exactly nothing, because the card is not being asked to produce zero dollars. It is being asked to approve a transaction, and a balance of zero is not in a position to approve anything. The amount being zero is irrelevant to the machinery.
Why subscriptions do this and one-off purchases mostly don't
If you buy a single thing and leave, the merchant has one job: take the money once. There is little reason to verify you separately.
A subscription is a different relationship. The merchant is storing your card to charge it again next month, without you present. They want to know now whether that card is worth storing, because discovering it is dead on renewal day means an involuntary churn event and a support ticket. So they check upfront.
MPay names ChatGPT, Claude, Spotify, Netflix and Amazon as merchants that do this. Read that list as representative rather than complete: if something bills monthly, assume it verifies first, and you will be right more often than not.
The fix, which is almost insultingly simple
Leave headroom on the balance beyond what you are actually paying.
That is it. That is the whole fix. A card holding a little more than the charge passes the check, the check releases, the real payment goes through, and you never learn any of the above.
How much headroom? Nobody has published a rule, and I am not going to invent one, because the honest answer is that it depends on the merchant and you cannot see what they are doing. What I can tell you is the shape of it: a subscription needs enough spare that a price rise does not tip you under, and a one-off order needs enough that the store's verification does not eat into the purchase total. Topping up to a round number above what you owe solves it without any arithmetic.
If you are funding a specific thing, the per-use guides have the practical version for AI subscriptions and for streaming services, both of which are unusually prone to this.
This is Visa behaviour, not a crypto card quirk
Worth saying plainly, because it gets used as a criticism of stablecoin cards specifically and that is not fair.
Pre-authorisation is how the card networks have worked for decades. Every prepaid card behaves this way. Every gift card behaves this way. A debit card on a current account behaves this way too; you just never notice, because the account has a few hundred pounds sitting in it and the check passes silently every single time.
What is genuinely different about a card you fund deliberately is that you are much more likely to run it at or near zero. That is the actual risk factor. Not the technology, the funding pattern. People load exactly the subscription price, feel clever about it, and then get declined by a check for nothing.
When it is not pre-authorisation
Do not reach for this explanation every time something fails, because it will send you topping up a card that had plenty on it.
If the balance clearly covered the charge plus a sensible buffer, look elsewhere. Details typed from memory rather than copied from the reveal screen are a common one, and the expiry in particular is easy to get wrong. Some merchants require a billing address that matches something on file. And a small number of services refuse prepaid cards outright as policy, which no amount of balance will fix and which no card product can route around, whatever its marketing says.
There is a full diagnostic order of operations for working through it, and the FAQ covers the common ones if you would rather skim.
Reading your own balance correctly
One habit worth building. The number to compare against a charge is not the balance, it is the available balance, and those differ whenever a hold is sitting on the card.
Pay for something, have the merchant place a hold, and your spendable amount drops before the charge settles. Do that across two or three subscriptions in the same week and you can be looking at a balance that says one thing while the card behaves as though it says less. Nothing has gone wrong. The holds just have not cleared yet.
Tap the card in the app and hit CHECK when you need the number, expiry and security code. They stay hidden the rest of the time, which is the right default, and it also means the figure you are reading is the current one rather than something you memorised last month.
If you take one thing away: stop loading the exact amount. Round up. The failure mode you are avoiding costs you nothing to avoid and a genuinely irritating afternoon to diagnose.
