Four Reasons Your Authorization Rate Is Lower Than It Should Be

Most of the gap is recoverable. The problem is that each failure point requires a different fix.

Image: Solidgate

A two-point drop in your authorization rate doesn’t sound like much.

Until you do the math: on $5M monthly volume, it’s $100K in direct revenue loss while on $20M, it’s already $400K.

That’s before you count the subscribers who churned because a renewal failed silently or the CAC you already spent acquiring them.

The frustrating part isn’t even the drop. It’s that decline codes tell you what the issuer said — not where in your stack the problem actually started.

So most teams do what’s intuitive, fixing what they can see.

Authorization rate is the percentage of payment attempts that get approved out of everything submitted.

There are four places it actually fails.

1. Your renewal stack is sending stale credentials to issuers

Cards get reissued constantly.

A customer disputes a charge — their bank issues a new card number. An annual card expires. An account gets upgraded. Whatever the reason, the credentials you stored at signup are now stale.

When the renewal runs, you’re sending a dead card number to the issuer, getting an immediate hard decline with no retry logic to recover it. The credential is invalid before the transaction even reaches the acquirer.

Standard bank tokenization doesn’t help here because bank tokens are tied to the physical card number, going stale with the card.

This is the part most teams don’t realize until they look specifically for it.

Network tokenization — Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) — works at the account level, not the card level. When the card changes, the token updates automatically and the subscriber doesn’t re-enter their details. The renewal succeeds without customers noticing.

The acceptance rate difference on the same cohort of subscribers: up to 15 percentage points better on tokenized transactions.

The retention impact from automatic card updates — renewals that would otherwise fail silently — runs up to 7.5% better.

2. Your routing logic is sending transactions into weak issuer relationships

Every acquirer has different approval rates by card type, issuer, and geography.

An issuer with a long, trusted relationship with Acquirer A may decline at a significantly higher rate with Acquirer B — same card, same transaction type.

The card is valid, the customer wants to pay, but the routing path creates friction that doesn’t need to be there.

Smart routing addresses this by selecting the acquirer with the best historical performance for that BIN range and corridor. When the primary acquirer returns a soft decline, cascading automatically retries through an alternative before the customer ever sees a failure.

The average LTV impact from payment cascades across a multi-acquirer setup: +14.8%.

That’s not an optimization gain. That’s revenue that disappears permanently when there’s no fallback in place.

3. Your retry logic hasn’t been reviewed since the original integration

Retry logic is the first thing most teams configure and the last thing they audit.

Most retry setups are still running on whatever defaults were in place when the integration went live. Nobody went back to segment by decline code because the documentation was confusing, the defaults felt safe, and there was always something more urgent on the roadmap.

That’s why there’s still so much recoverable revenue sitting there.

Flat retry logic — same timing, same interval, regardless of why the card declined — treats all declines as the same problem.

They’re not.

Hard declines should never be retried. A stolen card retried repeatedly won’t get approved. It raises your fraud score with the issuer and moves your account toward scheme monitoring thresholds.

Issuers track retry behavior across your entire portfolio, not just the individual transaction.

Soft declines are different. An insufficient funds decline retried immediately fails again for the same reason. The same decline retried 24–48 hours later — aligned to when the cardholder’s account typically resets — recovers at a meaningful rate.

Retry logic segmented by decline code, timed to billing cycles, capped within scheme limits: +11.6% LTV impact on recovered soft declines.

4. Your MCC is telling issuers you’re a different kind of business

This one is the hardest to find.

And it’s almost never the first thing anyone checks.

Your merchant category code (MCC) tells the issuer which risk scoring model to apply to every authorization request you send. A subscription media platform coded incorrectly gets scored against a benchmark built for a completely different transaction pattern.

The issuer’s model flags that mismatch as unusual, suppressing approvals systematically across every billing attempt, regardless of how well everything else in the stack is configured.

No routing improvement, no tokenization rollout, no retry optimization can reach this.

The wrong signal is baked into every request before any of those systems run.

HOLYWATER — the company behind My Drama and My Passion, with 85M users and $10M in monthly GMV — had a full stack in place. Orchestration configured, cascades live, MID management across six acquirers including Adyen, Checkout.com, Nuvei, Worldpay, and JPMorgan.

Everything looked right. But approval rates still plateaued.

The root cause was MCC misclassification across the acquirer mix. The wrong MCC meant issuers were scoring every billing attempt against the wrong risk model — a ceiling baked into every request, invisible in standard reporting.

After realigning MCC across all six acquirers simultaneously and testing against live transactions — including the recurring billing leg separately from the initial charge. The result was a 5–7 percentage point approval rate lift across both products.

No product changes. No engineering work. No checkout redesign.

Just a field in the merchant configuration that nobody had looked at.

How to figure out which one applies to you

The starting point is to figure out where in the transaction lifecycle your declines are actually clustering.

1. Renewals failing at a higher rate than initial payments, specifically on subscribers past their first renewal. That’s a credential problem. Check whether network tokenization is in place and whether card updater is running before renewal attempts, not after failures have already occurred.

2. Consistent soft decline rate with a specific issuer or market corridor. That’s a routing problem. Map your decline rates by BIN and acquirer before making any changes to routing configuration.

3. Retry volume climbing without a matching improvement in recovery rate. That’s a retry logic problem. Pull your decline code distribution — if your retry rules don’t distinguish between hard and soft declines, or between decline code types, that’s where to start.

4. Consistent decline patterns that don’t trace back to routing, credentials, or retry timing. Check MCC configuration across every MID you operate — including the recurring billing leg separately from the initial charge.

Final thoughts

Most teams start with retry logic because it’s the easiest thing to configure.

It’s also the lever with the lowest recoverable impact of the four.

The gap in your authorization rate is almost always recoverable. The question is which layer it’s actually sitting in — and that answer is rarely where you’re already looking.

Full diagnostic framework with benchmarks: solidgate.com/blog/authorization-rate-optimization