Why Virtual Cards Get Declined: BIN Risk Scoring in 2026

It's not your balance. It's the issuer's trust score.

The most common complaint from virtual card users: the card has funds, the issuance fee was paid, but the first attempt to bind it to OpenAI, run a Google Ads campaign, or pay an Anthropic subscription gets declined. Support tells you to "try another card." Nobody explains why.

Here is the truth. The decline happens before the page shows an error. The issuing bank's authorization system, the merchant's acquiring bank, and the card network's fraud layer in the middle run a full risk assessment on your card in under a second. If the score fails, the authorization returns code 05 — Do Not Honor. Behind that code sit at least three independent risk verdicts.

Three risk layers, three independent vetoes

The first layer is the authorization rules at the bank behind the issuing platform. The BIN of your card determines which issuer it lands at, and each issuer applies its own anti-fraud model. When users say "changing cards fixed it," what actually happened is they changed issuers and skipped that issuer's blacklist.

The second layer is the card network's own fraud control — Visa Risk and Fraud Decisioning, Mastercard Decision Intelligence Pro. Mastercard pushed Decision Intelligence fully onto AI in 2025, and by early 2026 it was running real-time machine learning scoring on every online transaction worldwide. Its inputs are not just your card; they include whether the merchant category has been historically abused.

The third layer is merchant-side fraud control. Stripe Radar, Adyen RevenueProtect, Shopify Risk Filter — the merchant receives a risk score (in Stripe Radar's case, 0 to 100) that decides whether to even send the transaction to the card network. This layer can reject you even if your card is completely legitimate.

The BIN is the dividing line of fate

The BIN — the first six or eight digits of the card number — is the first signal the entire risk system reads. The same BIN, such as 556150, 531993, or 527375, is shared across multiple virtual card platforms: PokePay, VCard, FotonCard, DogPay, and PrivCards all carry these BINs. The problem is that once a BIN gets flagged as a "high-risk virtual card range" by any risk system, every platform sharing it suffers collateral damage.

Concrete scenario: you take a card with BIN 531993 to subscribe to ChatGPT Plus. That BIN range may have been hit with a wave of OpenAI chargebacks last year. The issuer raised the authorization threshold for online subscriptions on that range, or OpenAI's payment processor put it on a grey list directly. You see no explanation, just "Your card was declined."

This is why experienced users keep several cards with different BINs at the same time. Switching between FotonCard and DogPay, or swapping VCard for PokePay, is fundamentally switching the issuing institution to bypass a flagged BIN range.

3DS doesn't protect you. It protects the merchant.

After PSD2 in Europe made SCA (Strong Customer Authentication) mandatory, 3D Secure 2.x became the default for online card payments. On the surface, 3DS adds a layer of security for the consumer. In practice, the biggest beneficiary of 3DS is the merchant — a transaction authenticated via 3DS shifts fraud liability from the merchant to the issuing bank.

Here's the problem: many virtual card platforms don't support the full 3DS challenge flow. The issuing bank sees a transaction that needs a 3DS challenge, but the issuer's 3DS service isn't integrated, or only a stripped-down version is — the result is a soft decline with "Unable to authenticate." This is especially common in subscription scenarios, because subscription merchants tend to optimize for frictionless payment flows.

For users this means that even with $1000 on the card, if the issuer's 3DS link is broken, ChatGPT, Claude, and Midjourney subscriptions still won't go through. When you troubleshoot with platform support, don't ask "why was it declined." Ask whether their 3DS challenge link is fully integrated.

The invisible veto of merchant-side risk

The merchant-side layer is the least transparent. Acquirers and processors like Stripe, Adyen, and Checkout.com each run their own anti-fraud engines. Checkout.com published research in 2024 showing that global e-commerce loses tens of billions of dollars every year to false declines — a large volume of legitimate transactions rejected because the risk model treats the combination of "high-risk BIN plus new device plus new IP plus subscription merchant" as suspicious.

Mastercard released a report in February 2026 emphasizing that AI is reshaping bank-side payment anti-fraud. In plain terms, the decline decisions on the issuing side are increasingly made by machine learning models whose logic is a black box to both users and platforms.

This explains an otherwise counterintuitive pattern: the same card, the same device, the same amount — but switching the merchant makes the payment go through. Each merchant has its own Stripe Radar threshold and Adyen RevenueProtect configuration. Ad merchants (Google Ads, Meta Ads) and crypto exchanges fall into "high-risk merchant categories" (MCC) inside the model. Even with a perfectly healthy card, the merchant side can reject you outright. Take a look at the providers we've profiled — EPN and 79Card are both built specifically to filter BIN ranges for the ad-spend scenario, which fundamentally means filtering for friendliness to merchant-side risk systems.

Decline codes: read them before you troubleshoot

The decline code is your starting point. The common ones:

• 05 Do Not Honor — the most common and the vaguest. Issuer refused without explanation. 90% of the time it's a risk verdict, 10% a balance or limit issue.
• 41 Lost Card / 43 Stolen Card — the BIN range has been added to a lost or stolen list. Usually means the platform or issuer has banned the entire range.
• 51 Insufficient Funds — balance is too low. If you confirmed funds are present and still got 51, the platform's pre-auth logic is broken or the available balance is locked.
• 14 Invalid Card Number — card number validation failed. Usually the platform generated a malformed number or the Luhn check failed.
• 57 Transaction Not Permitted to Cardholder — the card type doesn't support that merchant category. For example, prepaid cards are blocked by default from many MCCs by the issuer.
• 61 Exceeds Withdrawal Limit — per-transaction or daily cap. The easiest to fix: raise the limit.
• 62 Restricted Card — the card is restricted to specific countries or merchants.
• R1 / R2 Recurring — subscription-specific. The issuer refused recurring billing authorization, usually requiring the cardholder to re-confirm.

One thing worth noting: 05 and 62 are routinely misread by platforms as "the card is fine." In practice, if multiple cards in a row all return 05, the problem is almost certainly that the BIN range is under risk control, not a single-card failure.

The 2026 troubleshooting playbook

Step one: confirm the decline code. Not every platform passes through the issuer's raw code, but having the code at least lets you separate issuer-side from merchant-side. Codes like 05, 51, and 57 are usually issuer-side. Network timeouts and "Authentication Failed" point more to the merchant side or the 3DS link.

Step two: switch merchants to test. Take the same card and run a payment at a "low-risk" merchant — a well-known SaaS subscription, a major e-commerce platform — once. Confirm whether the card can authorize at all. If it works at Amazon but fails at OpenAI, the problem is OpenAI's payment processor or merchant category, not your card.

Step three: switch the BIN range. This is the most direct and effective move. In our directory, Crospay, ZANVCC, and Paymier all offer BIN ranges from different issuers. Changing cards means changing the issuer, which means changing the risk model.

Step four: check 3DS. If the subscription merchant enforces 3DS challenges and your platform's 3DS link is incomplete, switch to a platform that supports full 3DS 2.x. Generally the standard BIN cards from large platforms support full 3DS; cards from obscure issuers may not.

Step five: keep records. Log every decline — date, merchant, amount, code, BIN. After two weeks of observation you'll find patterns: one BIN range gets declined in clusters on Tuesday mornings, a specific merchant's decline rate climbs at month-end. These are patterns support will never tell you about.

The difference between "declined" and "banned"

A lot of users conflate payment declines with account bans. A decline is a verdict in the payment chain — the account is still alive, no funds were taken, you can retry with another card. A ban (or suspension) is the merchant's action against the account itself based on risk, compliance, or anti-fraud, and it's only indirectly tied to payment behavior.

The two get confused most often in ad scenarios: you bind a virtual card to Google Ads or Meta Ads, run it for a while, and the account gets suspended. Users assume it was the card. In reality, ad-platform risk control primarily watches IP, device fingerprint, ad content, and historical behavior — the card is just one signal. Frequent card swaps, binding the same card to multiple ad accounts, or a mismatch between card registration info and ad account info are the real triggers. The card here is a passive signal source, not the cause.

Three overlooked details

First, card age. A freshly issued card has a significantly higher decline rate in its first 24 hours than a card that has been used. Risk systems are inherently suspicious of card numbers they've never seen. If your use case demands a high success rate, open the card a few days in advance and run a couple of small transactions to "warm" it.

Second, geography. When the card's registered country, the IP address, and the merchant's location don't line up, the risk model flags it. VPNs that switch IPs, cross-border subscriptions, paying for a European service with a US card from a Chinese IP — every one of these combinations looks high-risk to the model.

Third, amount anomalies. A first transaction that's a $500 or $1000 subscription or top-up has a far higher decline rate than a gradual spend pattern that starts small and grows. This is most visible in ad spend — an account that opens a $2000 ad budget on day one looks suspicious by default.

So which card is actually stable?

There is no "most stable card." There is only "the most stable card for your scenario." General rules:

• Subscribing to OpenAI, Anthropic, Midjourney — prefer Visa/Mastercard non-prepaid issuing ranges, avoid heavily shared BINs (531993 and 556150 are now higher risk).
• Running Google Ads or Meta Ads — you need an issuer that's friendly to merchant-side risk. EPN's 102+ BIN ranges are filtered specifically for this, and 79Card is a common choice for the ad-spend scenario.
• Paying subscriptions at strong-3DS merchants like ChatGPT and Claude — pick cards with full 3DS 2.x challenge support; avoid niche issuers.
• Cross-border payments into Africa or Southeast Asia — regional BINs can actually be more stable, because local merchants have high decline rates for international cards and local BINs pass more easily.

Don't judge a card's stability by platform marketing. Open two cards with different BINs, run a two-week real-world test across different merchants, and record the success rate. That is the only reliable way to evaluate.

Closing notes

On declines, the platform won't tell you the reason, the issuer won't, and the merchant won't. The entire payment chain is a black box with three parties each running their own models. What you can do is turn "try another card" from a blind reflex into a deliberate diagnostic process built on decline codes, BIN ranges, and merchant categories.

Payment anti-fraud in 2026 has been rewritten by AI. The risk models are faster and less transparent than ever. That means user-level "rules of thumb" are getting less reliable by the month. The only thing that works is continuous real-world testing, continuous logging, and continuous switching. Those virtual cards marketed as "stable for ChatGPT verification" are simply riding a BIN range that hasn't been flagged yet — and the risk systems' field of view expands every day.