Authorization sits at an awkward intersection. It is measured by finance, operated by payments, constrained by fraud and shaped by product — which means it is frequently discussed and rarely owned. When approval rates fall, the common response is to escalate to the processor and ask what changed on their side.
Sometimes something did. More often, the decline pattern reflects an accumulation of merchant-side decisions: a checkout change that dropped a data field, a fraud rule that pushed more traffic to step-up, a subscription retry schedule that never distinguished between decline reasons, a token strategy that was never implemented for one of the card brands.
The issuer makes the final decision. The merchant designs almost everything the issuer sees before making it.
The Approval Rate Hides More Than It Reveals
A blended approval rate is an average across populations that behave nothing alike. Domestic and cross-border traffic decline differently. Debit and credit decline differently. A first-time guest checkout and a returning stored-credential customer are different risk propositions to an issuer, and are treated as such.
This is why cross-company approval-rate comparisons are usually meaningless. A competitor quoting a higher number may simply have a more domestic customer base, a different card-type mix, more returning customers or a lower-risk product category.
Any approval-rate comparison must control for
- — Geography: issuing country and cross-border share
- — Payment method and card type: debit, credit, prepaid, wallet, local methods
- — Customer type: new versus returning, guest versus authenticated
- — Issuer concentration: a handful of issuers often drive most declines
- — Transaction type: one-time, initial stored credential, merchant-initiated, recurring
- — Risk mix: product category, ticket size, velocity profile
Without those controls, movement in the blended number tells you that something changed in the mix, not that something changed in performance. Mix shifts alone can move an approval rate in either direction while every underlying segment holds steady.
Why Issuers Decline Transactions
Issuers are not adversaries. They are managing their own losses, their own customer experience and their own regulatory obligations, using the information available at the moment of the request. Declines generally fall into a few broad families.
Insufficient funds or account condition
The account cannot support the transaction, is closed, or the credential has expired or been reissued. Some of these are temporary and legitimately retryable. Others are permanent instructions that will never succeed.
Risk assessment on the issuer's side
The issuer's own models evaluate the request against the cardholder's history and the broader pattern of activity it sees across its portfolio. A merchant with a history of disputes or unusual submission patterns is a different proposition than one without.
Incomplete, inconsistent or unrecognizable data
When the authorization message lacks fields the issuer's models rely on, or those fields conflict, the request is harder to evaluate. Ambiguity is not neutral — it tends to resolve against the merchant.
Authentication and liability context
Whether the transaction was authenticated, how, and what liability position that creates all form part of the picture the issuer evaluates.
The specific rules and codes vary by network and issuer and change over time. The durable point is simpler: most decline families are influenced by the completeness and consistency of what the merchant submits.
The Merchant-Controlled Variables
These are the levers that sit inside the merchant's own decisions. None of them guarantees an approval. Collectively they determine the quality of the case the issuer is asked to judge.
1. Transaction data quality
The authorization message is evidence. Missing or malformed address data, inconsistent name formatting, absent email or phone, truncated fields and unpopulated optional elements all reduce what the issuer can verify. Data quality degrades quietly: a checkout redesign, a new mobile SDK or an A/B test that removes a field can change submission content without anyone in payments being told.
The descriptor deserves specific attention. An unrecognizable descriptor generates cardholder confusion, inbound service calls and disputes — all of which feed back into how the issuer views the merchant over time.
2. Merchant and processor routing
Where a transaction is sent, which acquirer presents it, which local entity is used and which network path it travels all affect how the request appears. Local acquiring for a material foreign customer base is a routing decision, not a processor decision, and it changes the cross-border character of the transaction.
3. Stored credentials and transaction indicators
Card networks provide a framework for distinguishing customer-initiated from merchant-initiated transactions, and for signalling the relationship between an initial credential-on-file transaction and subsequent ones. When these indicators are absent or applied inconsistently, recurring and repeat transactions can appear unmoored from any prior customer consent. This is one of the most common implementation gaps in subscription and marketplace businesses.
4. Tokenization and account updating
Network tokenization replaces the stored card number with a credential that can be maintained as the underlying card is reissued. Account-updater services perform a related function for stored PANs. Both address the same failure: a customer who still wants to pay, using an instrument that no longer exists in the form the merchant stored. This is a significant and entirely preventable source of decline in recurring-billing businesses.
5. 3DS and authentication strategy
Authentication is not binary. Applied everywhere, it adds friction and abandonment to transactions that would have been approved regardless. Applied nowhere, it removes a tool that can materially help on higher-risk or issuer-sensitive traffic and forfeits the liability position it can create.
The right posture is selective and data-driven: authenticate where the evidence says it improves the net outcome, exempt where the rules and risk profile allow, and measure the effect on completion — not just on approvals of transactions that reached authorization.
6. Retry timing and decline-code discipline
Retries are where good intentions cause real damage. A soft decline — a temporary condition such as insufficient funds or an issuer-side timeout — may reasonably be retried on a considered schedule, ideally informed by when funds are likely to be available.
A hard decline is an instruction. Repeatedly resubmitting a closed account, a stolen-card indication or a do-not-honour response does not eventually produce an approval. It produces processing cost on every attempt, degrades the merchant's submission profile with the issuer and, where network rules impose retry limits, can create compliance exposure with the acquirer.
Retry discipline in practice
- — Map every decline code you receive to an explicit retry policy: retry, retry once, or never
- — Cap attempts per credential and per billing period, and log the cap
- — Space retries deliberately rather than in tight bursts
- — Repair the credential — token refresh, account updater, customer outreach — before retrying again
- — Review retry cost against retry recovery at least quarterly
7. Fraud-control quality
A merchant's dispute and fraud history is visible in the ecosystem. Elevated disputes affect how issuers treat future requests, and can affect standing with the acquirer. Precise fraud controls therefore protect approvals; blunt ones suppress good traffic before authorization is ever attempted.
Why Adding Another Processor Is Not a Strategy
Redundancy has genuine value. A second processor protects against outages, provides commercial leverage and enables local acquiring in markets where it matters. Those are good reasons.
What a second processor does not do is improve the quality of the transaction being submitted. If the data is incomplete, the credential indicators are missing, the tokens are stale and the retry logic ignores decline codes, all of that travels with the transaction to the new route.
What a new processor typically changes — and does not
- — Changes: resilience, commercial terms, acquiring geography, available features
- — Does not change: data completeness, descriptor clarity, credential indicators, retry logic
- — Adds: integration surface, reconciliation complexity, a second set of configurations to keep aligned
Early gains after a migration are also easy to misread. New routes are often compared against an old configuration that had drifted, and traffic is rarely allocated randomly. Without a controlled comparison on matched segments, the improvement attributed to the processor may belong to the cleanup that happened during integration.
Segmenting Authorization Performance Properly
Segmentation is what converts an approval rate from a number into a diagnosis. The objective is to find the specific population where performance is weak, rather than applying a global change to fix a local problem.
Two habits make this useful. First, always report decline reason alongside approval rate — a segment at the same approval rate for different reasons requires different action. Second, hold the mix constant when comparing periods, so a change in customer composition is not read as a change in performance.
The Connection Between Fraud and Payment Acceptance
Fraud and payments are usually separate teams with separate targets, and the targets work against each other. Fraud is measured on losses. Payments is measured on approvals. Each can improve its own number by worsening the other's.
The interactions are direct. Fraud rules that decline or step up traffic remove transactions from the authorization population entirely. Elevated disputes influence how issuers assess future requests. Authentication strategy sits in both domains at once — it is a fraud control and an acceptance lever, and it cannot be optimized by either team alone.
A fraud decline and an issuer decline cost the same revenue. Only one of them appears in the payments report.
The practical fix is a shared view of the funnel: from checkout attempt through fraud screening, authentication, authorization and settlement, with drop-off measured at every stage. When both teams look at the same funnel, the trade-offs become explicit rather than departmental.
A Practical Authorization Optimization Framework
The sequence matters more than the sophistication. Most organizations attempt step four before completing step one, which is why results are hard to attribute.
- 01Establish measurement. Build the segmented view described above and confirm the data is reliable end to end, including the stages before authorization.
- 02Audit what you submit. Review actual authorization messages for data completeness, descriptor clarity, credential indicators and transaction-type flags. Verify configuration against intent, per processor and per route.
- 03Repair the credential base. Implement or complete network tokenization and account updating, and measure decline recovery on recurring and returning traffic specifically.
- 04Impose retry discipline. Map every decline code to an explicit policy, cap attempts, and stop resubmitting hard declines.
- 05Tune authentication selectively. Place 3DS where segment evidence supports it, apply exemptions where appropriate, and measure completion rather than authorization alone.
- 06Sharpen fraud controls. Retire stale rules and improve precision so fewer good transactions are removed before the issuer sees them.
- 07Review routing last. With the inputs clean, evaluate acquiring geography and route selection on matched segments.
- 08Govern it. Assign a single owner, review the segmented scorecard on a fixed cadence, and change one variable at a time with a stated expected effect.
No responsible advisor can promise a specific authorization lift. The available improvement depends entirely on where an organization is starting from — a business with clean data, mature tokenization and disciplined retries has far less headroom than one that has never audited its submissions.
What is reliable is the method: measure properly, fix the inputs, change one thing at a time and hold the mix constant when you evaluate the result.
Five Executive Takeaways
If authorization is currently treated as a bank outcome in your organization, these are the five positions worth adopting.
- 01Treat authorization as an engineered outcome with a named owner, not a metric that arrives from the processor.
- 02Stop managing to a blended approval rate; segment by geography, method, customer type, issuer, transaction type and risk mix before drawing any conclusion.
- 03Fix what you submit before you change where you send it — data quality, descriptors, credential indicators and tokenization travel with the transaction.
- 04Make retry logic decision-code aware; retry soft declines deliberately and stop resubmitting hard declines entirely.
- 05Govern fraud and payments against one funnel, because a transaction lost to a fraud rule and one lost to an issuer cost exactly the same.
If it would be useful to review where your own authorization performance is being shaped — and which of these levers is available to you — we are happy to have that conversation.