categorize first, then troubleshoot
The same card worked yesterday and suddenly fails today; the same BIN works with A but is declined by B — virtual card declines look similar on the surface but can have completely different root causes. So the first move after a decline shouldn't be "try again", but determining which category it falls into.
Group the common root causes into five categories; land on the category first, then the item:
- BIN level: the BIN is blacklisted by the merchant, or card-network-level risk control;
- Identity matching: the sign-in location, account region, and card issuing country don't match;
- Verification: 3DS verification doesn't complete, or the verification code never arrives;
- Card parameters: insufficient balance, insufficient pre-authorization, expired card number, or a wrong CVV / card number;
- Rules: the BIN doesn't permit the merchant's category, or the single-card limit is exhausted.
Which category do most declines fall into
If you sort returned decline tickets by category, the structure is remarkably stable — a few categories account for the vast majority. The table below is ordered by relative frequency from handling experience, to help judge "which category to check first":
| Category | Frequency by experience | Solution |
|---|---|---|
| Risk control at the BIN (BIN range) level | Highest (most common) | Can't fix it yourself; switch the BIN |
| Identity and geographic mismatch | High | Align the sign-in location, account region, and card country |
| Verification chain (3DS / OTP) | Medium | Use a BIN that supports verification; confirm the code |
| Card parameter errors (balance / card number / expiry) | Medium-low | Check the three card elements and the balance |
| Category restrictions and per-card limits | Low | Use a BIN that permits the category; spread the limits |
This isn't a statistical sample: the ranking comes from ticket-handling experience and is only for deciding troubleshooting priority; the structure varies by platform and time period — don't treat it as precise percentages.
This table matters for one reason only: when the top-ranked category applies, looking for a cause in the card itself is futile. Recognizing this early saves a lot of wasted attempts.
Top 10 decline reasons summary table
Breaking the five categories down into concrete items gives the ten below, from most to least frequent in our experience:
| # | Root cause | Frequency (experience) | Common platforms |
|---|---|---|---|
| 1 | BIN blacklisted internally by the platform | Highest | Major ad platforms |
| 2 | 3DS required but fails / verification code never arrives | High | Subscriptions and digital goods |
| 3 | Sign-in location, account region, and card issuing country don't match | High | Region-priced subscription platforms |
| 4 | BIN doesn't permit the merchant category (MCC) | Medium-high | Ad spending, certain high-risk categories |
| 5 | Insufficient card balance or pre-authorization amount | Medium-high | Almost all platforms |
| 6 | Billing address doesn't match card records | Medium | E-commerce, subscriptions |
| 7 | Per-card limit exhausted | Medium | Large ad spending |
| 8 | Card-network-level risk control | Medium-low | High-risk categories |
| 9 | Wrong card number / expiry / CVV | Low | Common on a beginner's first card bind |
| 10 | Browser fingerprint or device risk control | Low | Operating multiple accounts in one environment |
The frequency is a relative ranking from ticket-handling experience, not a statistical share; when troubleshooting, check the high-frequency items first, then the low-frequency ones.
The ten reasons, item by item
Category 1: A blacklisted BIN — the most common, and the hardest to fix yourself
Ad platforms maintain their own BIN blacklists. If a BIN accumulates a large number of failed bindings, abnormal refunds, or complaints over a period, the whole card-number prefix gets silently blocked. The symptom is accounts on the same BIN going down together, rather than an issue with a single account.
There's only one solution: switch to a clean BIN. This also explains why people operating across multiple platforms tend to hold several cards across different BINs — once a single BIN is blacklisted, the loss is the whole segment.
Category 2: The verification chain — 3DS fails or the code never arrives
Merchants with high compliance requirements ask for extra verification when you bind a card. If the BIN doesn't support it, or the code can't be retrieved, you get stuck at this step. The full troubleshooting for this category is in the no-3DS BIN FAQ.
Category 3: Identity and geographic mismatch — all three must align
Region-priced platforms cross-check the sign-in location, the account's registration region, and the card's issuing country. If any one of the three doesn't line up, you can be blocked before payment. A common mismatch is "a sign-in environment from an unsupported region + an account from one region + a card from another region".
Categories 4 and 7: Category restrictions and per-card limits
Every merchant has a merchant category code (MCC), and BINs allow or deny based on preset rules. If the BIN doesn't permit the category you need, it fails no matter how much balance you have. On the other side is the limit: a prepaid card's available balance is simply the amount loaded onto it, so when a large campaign exhausts the limit, it gets declined — that's not a card problem, the money is just used up.
Categories 5, 6, 8, 9, and 10: Parameter and matching problems
Insufficient balance or pre-authorization, a mismatched billing address, card-network-level risk control, a wrong card number or expiry, and the association risk of binding multiple cards on one device — each of these alone accounts for a small share, but combined they push the failure rate up significantly, and most can be fixed yourself: check the three card elements, keep enough balance, and keep the address consistent.
Five-step isolation: pin down your category
Follow this order after a decline; in most cases you'll narrow it down within minutes:
- Read the raw error: the returned decline reason code is the first clue — "insufficient funds"-type messages point to the balance; "not honored"-type messages usually point to BIN risk control.
- Check the balance: is the card balance clearly above this transaction or its pre-authorization amount?
- Check whether the three align: are the sign-in location, the account region, and the card's issuing country the same country?
- Same card, different platform: does this card work on a platform with lower requirements? If yes, the card itself is fine and the problem lies with the target platform;
- Same platform, different card: does a card from a different BIN work on the same platform? If yes, your original BIN is blacklisted; if not, it's an account-side problem.
How to read the raw error: common wording lookup
The first step in troubleshooting is reading the raw error. The prompts acquirers return to the merchant page are mostly taken from the card networks' standard decline wording, so the English itself carries a clue — it usually tells you which layer declined you:
| Common English in the error | Usually points to | What to do first |
|---|---|---|
| do not honor / not honored | A catch-all; often BIN risk control or insufficient balance | Try once with a card from a different BIN to split the possibilities fast |
| insufficient funds / insufficient balance | Card parameters (balance) | Confirm the balance is above the transaction amount and the pre-authorization |
| expired card / card expired | Card parameters (expiry) | Check the expiry shown on the card and how it's entered |
| incorrect number / card number wrong | Card parameters (card number) | Check the card number and CVV digit by digit |
| transaction not permitted | Rules layer (category or BIN restriction) | Confirm whether the BIN permits this merchant category (MCC) |
| authentication required / 3DS | Verification layer | Go through the 3DS troubleshooting flow; confirm the code can be retrieved |
Different acquirers use slightly different wording and codes for the same meaning — the raw text you actually receive is authoritative; the table covers the most common phrasings.
This "look up by wording" approach shares its source with Stripe's official decline code documentation — acquirers pass the card networks' decline wording through to the merchant, so the explanation of each code in the documentation can be used like a dictionary. For the decline codes themselves, see Authorization and declines: soft declines, hard declines and codes. External links are provided for reference only and do not constitute an endorsement.
The four most common "combined decline" traps
In reality, declines are often two or three causes stacked together. The four combinations below are the most typical:
| Combination | Why it compounds | Countermeasure |
|---|---|---|
| New account + new card + large first payment | Platforms default to low trust for new cards and new accounts; an oversized first payment is easily blocked | Keep the first few payments small |
| Multiple accounts sharing one card | If one account has trouble, all accounts on the same card are dragged down together | One card for one or two accounts |
| Same BIN running concurrently across platforms | If any platform triggers risk control, the whole BIN gets flagged and other platforms are affected | Use different BINs on different platforms |
| Binding multiple cards in one device environment | The device and browser fingerprints get linked, entering the high-risk queue | Separate your environments; avoid multiple accounts under one fingerprint |
Combined declines are characterized by "each item alone looks harmless". So the question to ask isn't "which single item looks most likely", but "did I trip several at once".
Your self-help order after a decline
To get from a decline back to normal payments, follow this order without skipping steps:
- Stop first. Retrying immediately after a decline only keeps raising this transaction's risk score;
- Record three things: the raw error, the time, and the platform — all useful for the troubleshooting ahead;
- Run the five-step isolation to pin down whether it's the BIN layer, the matching layer, or the parameters;
- Move one lever based on the root cause: switch the BIN, align the region, keep enough balance, or fix the address; a blacklisted BIN and card-network risk control can't be fixed by you — only by switching cards;
- Start small after recovery. Don't jump straight to a large payment; verify one small transaction first, then scale up.
This discipline is the same as the general declined-payment troubleshooting: see ChatGPT payment declines: two-stage troubleshooting. Fees and card-opening terms are as stated on the pricing page.
FAQ
The same card worked yesterday and is suddenly declined today. Why?
The most common cause is the BIN being blacklisted by the platform — the platform blocked the whole card-number prefix at some point, so accounts on the same BIN fail collectively. You can't fix this category yourself; the solution is a card from a different BIN, and waiting out the possible unblocking of the original BIN (timing uncertain).
What does "not honored (do not honor)" mean?
It's the card networks' standard decline reason code, a catch-all statement — the issuer usually doesn't want to disclose the specific reason to the merchant. The most common situations are BIN risk control, insufficient balance, or a verification anomaly. Trying a card from a different BIN is the quick way to find direction.
Can changing my network egress fix a decline?
It only addresses the "geographic mismatch" category; it does nothing for a blacklisted BIN, category restrictions, address mismatches, or card-network risk control. And many platforms recognize data-center egress and may push your risk score up instead — prioritize consistent, truthful information over frequent switching.
Should I file a chargeback immediately after a decline?
No. A failed card binding or declined payment usually never successfully charged you, so it isn't a dispute scenario. Filing disputes wrongly puts the account or card on a frequent-dispute list, which makes risk controls more likely instead.
How can I reduce the chance of declines?
Five things: use a relatively clean BIN and spread it out; keep the balance well above the pre-authorization amount; align the sign-in location, account region, and card issuing country; don't run one card across too many accounts; and for merchants that require verification, use a BIN that supports it.
Can one card be bound to multiple platforms?
Technically yes, but from a risk perspective it isn't advised to spread one card across too many accounts — if one of them has trouble, the accounts on the same card get dragged down. The steadier approach is to allocate cards by purpose instead of piling every platform onto one card.
The message only says "transaction failed" with no code. Where do I start?
First check this card's transaction history to see whether the request reached the card side: with a record, the request got to the card and was declined there — focus on the BIN and account matching; with no record, the request never went out — focus on the card details you entered and the verification step. Then use the "fix one variable" cross-test to narrow it down.
Is the English in the error message (like do not honor) made up by the platform?
No. Most of these phrasings are the card networks' standard decline language, passed through to the merchant page by the acquirer; wording varies slightly by provider but the meaning is the same. The "How to read the raw error" section below has a lookup of common phrasings and their corresponding troubleshooting actions.
Instead of retrying over and over, start with a clean BIN
Card types, BINs, and use cases are listed item by item on the products page; card-opening fees and all rates are on the pricing page — review before you submit.