Why Virtual Card Payments Get Declined and How to Reduce Failures

Virtual card payments can be declined even when the card itself is valid. An occasional failed transaction is normal. A consistently high decline rate is an operational problem once a company runs cards at scale — issuing them to its own users, embedding card issuing into a platform, or using virtual cards for advertising, subscriptions, or corporate spend.

A decline can originate at several points in the authorization chain: the balance, the card status, a spending rule, the BIN, the merchant, the authentication step, a risk control, or the processing infrastructure itself. Treating every failed payment as the same event makes it hard to fix anything.
The CardsPro team breaks down how virtual card decline rate works, what causes failed authorizations, how to trace a decline to its actual source, and which parts of the payment flow can be optimized.

Decline rate is an operational metric:

Decline rate = declined authorization attempts / total authorization attempts × 100

The formula is simple. What it doesn't say is what belongs in the denominator, or whether repeated attempts on the same payment get counted separately. That distinction matters more than the headline number.

One payment is declined three times and succeeds on the fourth attempt. Gross authorization rate: 1 approval out of 4 attempts, 25%. Net result: the payment went through, 100%. A card program can show a mediocre gross authorization rate while every legitimate payment still succeeds — a strong net authorization rate can still hide a large number of failed attempts and retries underneath it.

Decline rate is only useful alongside the number of authorization attempts, successful authorizations, retries, decline reasons, and the payment use case behind them. Read on its own, it doesn't say much.

That authorization-level metric is not the same thing as the account decline rate CardsPro tracks. CardsPro defines its own decline rate as the percentage of declined transactions out of total card transactions on an account, and caps the allowable decline rate at 15% under its service rules. The two figures don't necessarily share a denominator: authorization decline rate is measured per authorization attempt, while CardsPro's account-level rate is measured per transaction on the account. The 15% threshold is a CardsPro account rule, not an industry benchmark — it says nothing about what a normal or optimal decline rate looks like elsewhere.

Virtual card payments can be declined for different reasons at different layers of the authorization process. Identifying the exact decline reason is the first step toward fixing the problem and reducing a high decline rate.

The most direct case: the authorization request reaches the issuing side, but the required funds aren't there. Insufficient balance, insufficient available credit where applicable, account restrictions, unavailable funding.

A card can be frozen, inactive, closed, or expired. A transaction can exceed a per-transaction limit, a daily or monthly spending limit, or a velocity limit on transaction count. At scale, these failures often come from the program's own card-management logic — not from the merchant or the cardholder.

MCC restrictions, merchant-country restrictions, currency restrictions, transaction-type restrictions, geography rules. A transaction can be technically valid and still get declined because it doesn't match the rules configured for that card or card product.

Cardholder verification failure, failed 3DS authentication, an issuer requiring additional authentication that isn't completed or adds enough friction to break the flow. Authentication can help an issuer approve a transaction that needs extra assurance, but a failed or poorly designed authentication step produces payment failures of its own — it isn't a one-directional fix.

A fraud decline can result from suspected fraud, issuer risk rules, processor or program risk controls, velocity limits, or behavioral rules. Some of these declines are correct and stop genuine fraud. Others are false declines: legitimate transactions blocked because the system lacked context or the rules were set too tight. Telling the two apart is a program-management task, not something a single metric can do.

Not every decline traces back to the cardholder, the merchant, or the balance. Processor errors, issuer or acquirer configuration errors, network failures, authorization timeouts, and — where a client runs real-time authorization logic — timeouts on the client's own authorization endpoint can all produce an authorization failure or decline that has nothing to do with the underlying payment.

Don't treat every failed card payment as the same decline. Start with the decline reason or issuer response before deciding what to change or whether to retry.

A practical diagnostic checklist, worked through in whichever order the available data allows:

Decline reason/code - card status and balance - card controls - merchant/MCC/GEO · 3DS result - BIN/card product - infrastructure error

Record, for each declined authorization: decline reason or response code, BIN, card product, merchant, MCC, merchant country, transaction currency, transaction amount, 3DS result, transaction type, card status, the limits and controls in effect, and retry history.

Then segment the decline rate instead of reading it as one account-wide figure. A single BIN may produce a disproportionate share of declines at a specific merchant type. One MCC may be blocked by a configured card rule. One geography may show more failed authorizations than the rest of the portfolio. 3DS failures may account for a large share of declines. Repeated retries may inflate the gross decline rate without changing the actual outcome. None of this shows up in an aggregate percentage.

Some declines are actionable. Insufficient funds — fund the balance. Spend limit exceeded — review the limit. Blocked MCC or GEO — review the card control if the payment is legitimate. Authentication required — complete it. Temporary technical failure — retry according to the applicable payment logic.

If a payment is marked “declined by issuer,” it means the issuer or issuing-side authorization logic rejected the transaction. The next step is to check the decline reason or response code rather than assume the merchant caused the failure.

Others won't change on a second attempt: a closed card, invalid card data, a permanent card restriction, a prohibited transaction, an explicit fraud rejection where retry isn't permitted. Repeating the same request against any of these adds noise to the decline rate without changing the result.

Response and advice codes classify recoverability differently across providers and networks, so a blanket "soft decline vs. hard decline" table isn't reliable without the specific codes behind it. Diagnosis happens at the level of the actual decline reason, not a generic category.

No single change guarantees a higher approval rate. These are the levers a card-program operator actually controls.

BIN selection is one part of payment configuration — BIN country, network, commercial or consumer product type where applicable, card type, and the use cases the program was built for. "US BINs approve more" and "Visa performs better than Mastercard" aren't claims that hold up in general terms, and switching BIN doesn't fix insufficient funds, an expired card, or a restrictive limit.

If failed authorizations cluster around a payment use case, merchant type, or card configuration, the BIN or card product is one variable worth investigating — not the first or only one.

CardsPro provides access to 20+ BINs across regions including the US, UK, Hong Kong, Singapore, and Estonia, with card products built around specific use cases such as advertising, SaaS subscriptions, and corporate expenses. For matching BIN geography to a payment scenario, see How to Choose a BIN for Virtual Cards.

Controls need to match the actual payment scenario. Rules set too tight cause legitimate transactions to fail: spending limits, MCC restrictions, merchant or geography rules, currency restrictions, transaction types, velocity limits. But removing controls just to push approval rate up defeats their purpose. Controls should block transactions the card program is not meant to allow.

3DS is part of authorization optimization, not only a security layer. A transaction that needs additional issuer assurance can succeed after authentication. A challenge step also adds friction, authentication can fail, and the added latency can reduce completion. Apply authentication where the transaction and issuer actually require it — 3DS is not a universal approval fix.

CardsPro provides card issuing infrastructure built on Capitalist technology through its platform and API. CardsPro provides tools to address several of these decline causes directly.

CardsPro's 20+ BINs across the US, UK, Hong Kong, Singapore, and Estonia support card products for advertising, subscriptions, corporate expenses, and general online payments. The goal is to match the card configuration to the payment scenario rather than look for one universally "best" BIN. CardsPro's BIN-selection functionality lets a client specify what they're paying for and get back suitable card and BIN options. No BIN guarantees merchant acceptance. See [How Card Issuing APIs Work].

CardsPro exposes transaction data that shows why an authorization failed: insufficient funds, blocked MCC, restricted country, frozen card, failed 3DS, among the reasons already documented in the platform. A client's backend can use this data to determine the failure point and react to it. See Virtual Card Issuing API: How to Issue and Manage Cards Inside Your Product.

Businesses manage cards through spending limits, MCC restrictions, country restrictions, freeze and block actions, and other lifecycle controls. If a transaction is declined because it exceeds a configured limit, raising the limit removes that specific restriction — it doesn't guarantee the next attempt will be approved, since other checks still apply. If the transaction is blocked by a deliberately restricted MCC, the decline is correct and shouldn't be optimized away.

Most CardsPro BINs support Silent 3DS: the issuing side authenticates eligible transactions without requiring the user to manually enter a 3D Secure code. This is relevant for subscription renewals, advertising platforms, recurring payments, and other flows where manual confirmation would interrupt the transaction. Silent 3DS doesn't guarantee authorization — it reduces authentication friction where the applicable issuer and card flow support it.

CardsPro webhooks deliver authorization events such as authorization.approved and authorization.declined, attached to card_id, user_id, project_id, or an internal balance. That makes it possible to surface payment status inside the product, alert operations or support, detect repeated declines, isolate problematic cards, and analyze decline patterns by project or use case.

Decline data becomes part of the product's payment logic instead of a support issue discovered after the fact.

Once a business operates a large number of cards, a high decline rate should never be analyzed only at the account level. Track it by BIN, card product, merchant, MCC, merchant country, currency, transaction type, 3DS result, decline reason, and project or card group. Watch for changes, not just absolute numbers.

A sudden increase in declines on one BIN. Failures concentrated at one merchant. Rising 3DS failures. One card product generating more limit-related declines. Repeated attempts against frozen or unusable cards. Each of these is worth investigating on its own — repeated failed attempts can inflate decline rate without changing the actual payment outcome.
The purpose of monitoring is to find avoidable declines, not to push a headline metric toward zero.