An 8% decline rate sounds like a single problem with a single fix. It isn’t. That number is an average sitting on top of at least four distinct failure modes, each with a different cause and a different response, and treating them as one problem is why so many teams burn a quarter chasing a fix that only moves the needle by half a point.
What Your Decline Rate Number Actually Hides
A blended decline rate tells you that transactions are failing. It doesn’t tell you why, and why is the only thing you can act on.
One Number, Four Failure Types
Hard declines, soft declines, gateway timeouts, and BIN-specific failures all get folded into the same top-line percentage. A hard decline means the card itself won’t work here, stolen, closed account, insufficient funds. A soft decline means the same card could work through a different path or a different attempt. A timeout means the request never got a real answer from anyone. A BIN-specific failure means one issuer’s cards are struggling against one processor’s configuration while everything else looks fine. Each of those needs a different intervention, and a blended rate erases the distinction before you ever see it.
Why Single-PSP Visibility Falls Short
If every transaction runs through one processor, you’re seeing that processor’s interpretation of the failure, not the underlying cause. A single PSP can tell you a transaction declined and hand you its own decline code, but it can’t tell you whether a different processor would have approved the same card. That comparison point doesn’t exist until you have more than one data source to check it against.
Reading Decline Codes Without Guessing
Decline reason codes are the first real signal, but they’re standardized loosely enough that reading them literally will mislead you as often as it helps.
Decline Reason Codes and What They Tell You
Codes like “insufficient funds,” “do not honor,” or “call issuer” come from the card network or the issuing bank, and they map to a general category of refusal. “Do not honor” in particular is a catch-all that issuers use for everything from fraud suspicion to a mismatched CVV to no reason they’re willing to disclose. Reading codes at the category level, hard versus soft versus fraud-flagged, gives you a usable starting point. Reading them as a precise diagnosis of the individual transaction usually doesn’t.
What Decline Codes Don’t Tell You
A code won’t tell you if the same card would have cleared through a different acquirer, and it won’t tell you if the decline was a one-off issuer hiccup or part of a pattern tied to a specific BIN range. It also won’t separate a genuine risk decline from a false decline rate problem, where legitimate customers are getting rejected by overly aggressive fraud rules. That distinction matters because the fix for real fraud and the fix for false declines pull in opposite directions.
Hard Decline vs Soft Decline: The First Split
Before anything else, every declined transaction needs to be sorted into hard or soft, because the wrong instinct here wastes engineering time on transactions that were never going to clear.
Hard Declines: Don’t Waste Cycles Retrying
Hard declines mean the account is closed, the card is reported lost or stolen, or the issuer has permanently blocked the transaction type. Retrying a hard decline, on any processor, produces the same result, and repeated attempts on a hard-declined card can trigger network penalties from Visa or Mastercard for excessive retry volume. The correct response to a confirmed hard decline is to stop, prompt the customer for a different payment method, and move on.
Soft Declines: Recoverable, But Only With the Right Response
Soft declines are temporary: a processor outage, a rate limit, an issuer system hiccup, or a routing mismatch that a different path would resolve. The hard decline vs soft decline distinction is what determines whether retry logic can help at all, and once a transaction is confirmed soft, the mechanics of resolving it through alternate routing are a separate problem worth solving well, covered in how waterfall retries recover soft declines through backup processors.
Get Started
Not sure whether your decline rate reflects a processor issue, an issuer issue, or a configuration gap? Orchestra’s intelligent routing gives you the cross-processor data to find out and act on it.
Isolating the Pattern: PSP, Issuer, or Configuration
Once declines are sorted into hard, soft, and timeout buckets, the next question is where the pattern originates. That answer usually falls into one of three categories.
Signs of a PSP-Side Problem
If decline rates spike across multiple card types and issuers at the same time, and the timing lines up with a processor status page or a known outage window, the problem lives with the processor, not the card. Repeated timeouts with no completed authorization response, rather than an actual decline code, also point here; the request never reached a definitive answer. A failover architecture built to detect and reroute around these outages is the standard response once this pattern is confirmed.
Signs of an Issuer-Side Problem
If declines cluster around one issuing bank, one card brand, or one BIN range while everything else performs normally, the issue sits with how that issuer evaluates transactions from your specific processor relationship. This is the pattern that BIN-level routing exists to solve, since some processors clear certain BIN ranges far more reliably than others.
Signs of a Configuration Problem
If the decline pattern doesn’t correlate with any processor or issuer signal, check your own setup first: mismatched currency formatting, missing AVS or CVV data, an expired API credential, or a fraud rule tuned too aggressively. Configuration problems are the easiest to fix and the easiest to overlook, because they don’t show up in anyone else’s dashboard but yours.
What to Pull Before You Diagnose Anything
Diagnosis depends entirely on having the right data in front of you before you start drawing conclusions.
The Data Set You Actually Need
Pull decline codes by processor, by card BIN, by time window, and by transaction amount. Segment hard declines from soft declines before calculating any rate, because blending them into one percentage is the exact problem this framework exists to fix. If you’re only running one processor, this data set will be thin no matter how carefully you build the query; there’s no comparison point to work against.
Tracking False Decline Rate Separately
False decline rate deserves its own line item rather than living inside your general decline number. It’s measured by tracking customers who got declined and then successfully purchased elsewhere, or by correlating abandonment spikes with fraud-rule triggers rather than genuine card failures. A high false decline rate usually means your risk rules are tuned for a threat level that doesn’t match your actual fraud exposure, a pattern worth checking against how fraud rule tuning affects legitimate transaction approval.
Diagnose First, Then Decide What Orchestration Can Actually Fix
None of this framework requires a vendor to apply. Reading decline codes correctly, splitting hard from soft, and isolating whether the pattern is a PSP, issuer, or configuration problem is work any technical team can do with the data they already have. What a single-PSP setup can’t give you is the comparison point, the ability to see whether a soft decline on one processor would have cleared on another, or whether a BIN range is genuinely difficult everywhere or just difficult with your current provider.
That’s the gap Orchestra was built to close. Cross-processor data turns a diagnosis from a best guess into a confirmed pattern, and once you know what category a decline falls into, routing around it becomes a configuration decision instead of a development project. Reach out to talk through what that diagnostic picture looks like for your transaction volume.
