Why your virtual card gets declined

A card declines and the instinct is to try again. Then to try a different browser, then a different card, then to conclude that crypto-funded cards do not work. Almost none of that is diagnosis. An authorisation is a short, structured conversation between five parties — you, the merchant, their payment processor, the card network and the issuer — and when it ends in a no, one of those parties said it, for one recorded reason.

This guide sorts the causes by who said no, because that determines whether you can fix it in thirty seconds, fix it by issuing a different card, or not fix it at all. It is deliberately candid about the third category: there are merchants no prepaid virtual card will ever satisfy, and pretending otherwise wastes your time. If you want the mechanics underneath all of this first, how crypto cards work covers the settlement path end to end.

A decline is a message, not a malfunction

Four parties can refuse an authorisation, and they refuse for completely different reasons. Identifying which one spoke is the whole diagnosis — everything after that is mechanical.

The tell is timing. An issuer decline is instantaneous and always carries a reason code you can read. A merchant-side refusal is usually vaguer, often phrased as advice to call your bank, and the issuer never sees an authorisation attempt at all — which is why support can look at the auth log and truthfully say nothing arrived.

Sixty-second triage: the order to check things in

Run these five checks in order. They are sequenced by how often each one is the answer, so most declines resolve before step three.

1. Is the card balance above the full authorisation amount? Not the price on the screen — the price plus 1.5% if the merchant charges in anything other than USD, plus any hold the merchant adds on top.
2. Did a 3-D Secure challenge appear, and did you finish it? An abandoned or timed-out challenge reads as a decline and looks identical to a balance problem from the outside.
3. Is the card frozen, or is a rule blocking this merchant? Check the freeze state, the spend ceiling, the MCC allow-list and any geo-lock on that card. Rules you set weeks ago are the most-forgotten cause on this list.
4. Is the BIN right for the merchant? Ad platforms, SaaS billing and mobile wallets each have a BIN tuned for them. The wrong one is declined by merchants that would approve the right one instantly.
5. Does the transaction exist at all in your history? If not, the merchant refused it before the network saw it. Nothing on your side will change that outcome.

If all five pass and the merchant still refuses, you are almost certainly in the prepaid-policy category covered further down — and the honest answer there is to stop retrying.

Money problems: the balance, the load, and the fees you forgot

This is the largest bucket by a wide margin, and it is the one people are most confident is not the problem, because the card visibly has money on it.

The authorisation is larger than the price

A card authorises the full amount up front, and a prepaid card has no overdraft, no credit line and no bank behind it to cover a shortfall. Three things routinely make the authorisation bigger than the number you were quoted:

• The foreign-currency margin. Any authorisation in a currency other than USD carries a 1.5% conversion margin. A €48 charge is not €48 on a USD-denominated card — it is the converted amount plus 1.5%, and a card funded to the exact quoted figure declines every time.
• Merchant-added holds. Fuel pumps, hotels and car hire commonly authorise more than the eventual bill. The excess is released later, but it must be available now.
• Renewal timing. A subscription renewing on a card that is a cent short fails outright. There is no partial authorisation and no retry with a lower amount.

The load never landed, or fell outside the load window

Funding a Cryptocardium card is two distinct steps, and each has its own boundaries. A top-up moves crypto into your account balance; a load moves account balance onto a specific card. Confusing the two produces a card that shows $0 while the account clearly has funds.

Two numbers here cause most load failures. The $5,000 per-load ceiling means a $12,000 card has to be built from three loads, not one. And the 2% rail fee sits on top of the load: a $5,000 load requires $5,100 of account balance to complete, so an account holding exactly $5,000 cannot make a $5,000 load. If the top-up itself has not credited yet, the balance simply is not there — top-ups are free but they are not instant, and finality takes one to three confirmations depending on the chain. The whole funding path is walked through in funding a Visa card with USDT, and the complete fee sheet is on the pricing page.

Authentication problems: 3-D Secure and the BIN you chose

The second-largest bucket, and the one where the fix is almost always to issue a different card rather than to change anything about the one you have.

The 3-D Secure step was never completed

On a growing share of checkouts — mandatory across Europe under strong customer authentication, and standard on ad platforms and high-ticket purchases everywhere — the merchant hands you off to an authentication step before the authorisation is attempted. If that step is abandoned, blocked by a pop-up blocker, or simply times out while you look for the code, the payment fails. From the outside it is indistinguishable from a balance decline.

Two Cryptocardium BINs authenticate natively rather than relying on the merchant waving the step through: Visa Business 416842, the advertising card, and Visa Gold 448585, the BIN on every physical card. That is precisely why the Business BIN has the highest approval rate on Meta, Google and TikTok Ads, where the authentication step is not optional. The other virtual BINs — 557213, 489517 and 472305 — clear the challenge frictionlessly when the merchant's risk engine allows it, and are refused at the challenge when it does not.

The wrong BIN for the merchant

Merchant risk engines make decisions on the first six digits of the card number before anything else is known about you. A BIN tuned for mobile wallets, presented to an ad platform, is a different risk profile than the same balance on a business BIN — and it is declined for that reason alone. Five programmes exist so you can match the card to the spend:

The economics favour experimenting. A virtual card costs $2 to issue and goes live in under a minute, so issuing a second card on the correct BIN is usually cheaper in time than diagnosing why the first one is being refused. If your spend is advertising, best virtual card for Google Ads and paying for Google and Facebook ads with crypto go deeper on why the business BIN is not interchangeable with the others. For recurring billing, a virtual card for anonymous subscriptions covers the SaaS side. The full catalogue is on the cards page.

A per-transaction or monthly ceiling

Each programme carries its own ceilings, shown in the table above. A $4,200 purchase on a Visa Platinum card declines at $3,500 regardless of balance, and a card that cleared happily all month can start declining in the last week because the monthly aggregate is exhausted. Neither shows up as a balance problem, which is what makes them confusing — the money is visibly there.

The fix is to move the spend to a higher-ceiling programme rather than to retry. And note that the ceiling applies to the authorisation, so a hold that inflates a $3,400 booking to $3,600 breaches a $3,500 limit even though the final bill would not have.

Merchant problems: prepaid blocks, AVS and pre-authorisation holds

This bucket is where honesty matters more than optimism. Some of these have fixes; two of them do not, and recognising which is which is the point.

The merchant refuses prepaid BINs outright

A prepaid card cannot be charged once its balance is gone. For most merchants that is irrelevant, because they charge you at the till and the transaction is finished. For a minority it is fundamental, because their whole model depends on being able to bill you afterwards — and those merchants filter prepaid BIN ranges before an authorisation is ever attempted:

• Car hire deposits and excess. The counter needs a card it can charge for damage after you have driven away. Prepaid is refused as policy, everywhere, without exception.
• Hotel incidentals at check-in. Paying the room online is usually fine; the incidentals hold at the desk frequently is not.
• Utilities and telecoms billed in arrears. Anything that meters usage and invoices later has the same structural objection.
• Some financial services and identity checks. A handful of platforms use a card as an identity signal and specifically require a non-prepaid, name-matched card.

There is no card, BIN or workaround that changes this, and any guide claiming otherwise is selling you something. The realistic approach is to use the virtual card for everything it is good at — online checkout, subscriptions, advertising, marketplaces, mobile wallets, travel bookings paid in advance — and to keep another method for the handful of counters that need a chargeable-later card. Best anonymous debit card is candid about the same boundary from the privacy angle.

AVS and the billing address you do not have

Some merchants, overwhelmingly US ones, run an Address Verification Service check that compares the billing address you type against what the issuer holds. On a no-KYC card there is no address on file, because no address was ever collected — so a strict AVS check has nothing to match and returns no result, which a cautious risk engine may treat as a failure.

In practice most international merchants either do not run AVS or do not decline on an unmatched result. When one does, it is usually visible as a decline that happens the instant you submit the billing form rather than at the authorisation. The workaround is to prefer merchants that accept international cards, or to use a merchant's guest checkout, which is frequently less AVS-strict than an account checkout. This trade-off is inherent to a no-identity product and is covered in no-KYC crypto cards explained.

Pre-authorisation holds are bigger than the bill

Fuel pumps authorise a fixed amount before knowing how much you will pump — commonly far above a typical fill. Hotels authorise the stay plus a margin. Car hire desks authorise the excess. Restaurants sometimes authorise the bill plus a notional tip. In every case the card must have the inflated amount available at the moment of authorisation, and the difference is released only days later.

On a physical Visa Gold card at a fuel pump, the practical answer is to pay at the kiosk rather than at the pump, where the authorisation is the actual amount. Everywhere else, fund for the hold rather than for the bill.

$0 and $1 verification authorisations on free trials

Signing up for a trial usually triggers a tiny verification authorisation — zero dollars, one dollar, or a small local-currency equivalent — which is immediately reversed. A card with a zero balance fails that check even though nothing was ever going to be charged, and the signup reads as a declined card. Load something onto the card before starting a trial, even if the trial itself is free.

Self-inflicted declines: your own controls

The most frustrating category, because everything looks correct. Programmable per-card rules are enforced server-side at authorisation time, which means a rule you set and forgot is indistinguishable from an issuer fault until you look at the card configuration.

• The card is frozen. Freezing is instant and every subsequent authorisation is declined at network level. Unfreezing is symmetric and equally instant.
• An MCC allow-list is too narrow. A card restricted to advertising merchant categories declines a hosting invoice. The rule is doing exactly what you asked.
• A geo-lock is active. A card locked to one region declines a merchant that acquires in another — and the acquiring country is often not the country you think the shop is in.
• A spend ceiling below the purchase. Per-card daily and monthly ceilings sit underneath the programme ceilings, and the lower of the two applies.
• The card was cancelled, not frozen. Cancellation is permanent; a cancelled card cannot be revived, only replaced.

All five are visible in the panel, and readable over the API in one call if you manage cards programmatically. Reissuing is free for virtual cards, so a card with rules you no longer remember setting is cheap to replace.

Retry velocity, and why the sixth attempt fails hardest

Repeated identical attempts in quick succession look exactly like a card-testing attack, because that is what card-testing attacks look like. Velocity rules exist on both sides — the issuer's anti-fraud layer and the merchant's risk engine — and rapid retries can convert a soft, fixable decline into a harder block that persists for a while after you fix the actual cause.

It was Apple Pay or Google Pay, not the card

A wallet failure and a card decline surface identically on a phone. If a card works in a browser checkout but fails at a contactless terminal, the problem is provisioning rather than authorisation — the token in the wallet, not the card behind it. Removing and re-adding the card usually fixes it. Visa Platinum 489517 is the BIN tuned for wallet provisioning, with the lowest friction of the five; adding a crypto card to Apple Pay and Google Pay walks through the whole flow and best crypto card with Apple Pay compares the field.

Reading the decline through the API

Every authorisation passes through six independent checks, and any single failure declines the transaction. Every decline carries a structured reason code — never a silent failure — so if you run cards programmatically you never have to guess. Fetch the transaction and read why:

curl https://api.cryptocardium.com/v1/transactions/txn_3b91fe \
  -H "Authorization: Bearer ck_live_…"

{
  "id": "txn_3b91fe",
  "card_id": "card_8f2a1c",
  "merchant": "Cloud API Inc",
  "mcc": "5818",
  "amount_usd": 74.20,
  "status": "declined",
  "decline_reason": "insufficient_funds"
}

When the reason code alone is not enough — a merchant-side refusal, an authentication failure, an unexpected MCC — the raw authorisation record tells you what the network actually saw:

curl https://api.cryptocardium.com/v1/transactions/txn_3b91fe/auth \
  -H "Authorization: Bearer ck_live_…"
# → raw ISO 8583 authorisation fields for that attempt

If you would rather be told than have to ask, subscribe a webhook to transaction.declined; the event carries the same reason code at the moment the decline happens, HMAC-signed, with at-least-once delivery. Agents that issue and spend autonomously should branch on that event rather than polling — the pattern is worked through in the virtual card API for AI agents and, for MCP clients, in the crypto card MCP server. Endpoint-level detail is in the documentation.

The merchant categories that are genuinely hard

Every honest guide to declines needs this section, because the alternative is sending you into a retry loop against a wall. Sorted by whether the wall moves:

The pattern is consistent: anything charged at the moment of purchase works, and anything that depends on charging you later does not. That is not a defect specific to crypto-funded cards — it is what prepaid means, on every prepaid card ever issued.

How to stop declines before they happen

1. One card per merchant, funded for that merchant. At $2 a card, a dedicated card per subscription or platform isolates failures and makes the cause obvious the moment one declines.
2. Fund 5% over expected spend, 20% for anything with a hold. This absorbs the foreign-currency margin and merchant-added authorisations without thinking about them.
3. Pick the BIN before you issue, not after the decline. 416842 ads, 472305 subscriptions, 489517 wallets, 557213 cross-border, 448585 physical and in-person.
4. Top up ahead of known renewal dates. Top-ups need one to three confirmations, so a same-day top-up on renewal morning is a race you can lose.
5. Write down the rules you set. MCC allow-lists and geo-locks are excellent controls and terrible surprises. If you set them programmatically, log them.
6. Keep the card unloaded between uses if you prefer. Unloading back to account balance is free, so a dormant card need not hold funds — just remember to reload before the next charge.

Followed together, these remove essentially every decline that is not a merchant policy. The remaining ones are, by definition, the ones no configuration fixes.

When it is genuinely the issuer

Occasionally the reason code points at something that is not your configuration and not the merchant's policy — an authorisation that should have cleared and did not. In that case the auth log is definitive, and it is worth raising rather than retrying: the raw ISO 8583 fields for the attempt show exactly which check refused it. Open a ticket from the panel with the transaction ID and the merchant name, and the auth record is read directly rather than reconstructed from a description.

This is also the reason to prefer a card programme that exposes reason codes at all. A decline you cannot inspect is a decline you can only respond to by guessing — and guessing is what turns a five-minute fix into a lost afternoon.

Related reading

For the mechanics beneath every authorisation on this page, start with how crypto cards work. For funding and the confirmation timing that catches people out, funding a Visa card with USDT. For recurring charges specifically, a virtual card for anonymous subscriptions. For the advertising case where BIN choice decides everything, best virtual card for Google Ads. The full library is on the guides hub, and the fee sheet behind every number quoted here is on the pricing page.