Authorization Rate Optimization: How High-Risk Merchants Recover Declined Revenue

Your approval rate is 82 percent and you have no idea whether that is good. Your processor's rep says it is normal for the category. Someone on a podcast says they run 94. The gateway dashboard reports one number, the MID statements imply another, and neither counts the customers who abandoned the payment page before an authorization was attempted. Somewhere in that gap is real revenue, and a slice of it is recoverable this quarter. Most of it is not recoverable by anything a vendor will sell you. This post covers where authorization rate actually leaks in a high-risk business, which levers move it, and how to measure the result honestly.

Define the number before you try to move it

Authorization rate is approved authorizations divided by attempted authorizations. Every argument about whether your rate is good is really an argument about what went into the denominator.

A blended rate is close to useless. A business doing cold-traffic acquisition and monthly rebills is two different businesses averaged into one statistic, and they fail for opposite reasons. New-customer traffic declines because issuers do not recognize the cardholder-merchant pair and your category makes them cautious. Rebills decline because cards expire, get reissued, and run out of money. A single number moves when your traffic mix moves, which means you can "improve" it by running fewer ads.

Segment before you optimize. Cut approval rate by MID, by card brand, by issuing bank BIN, by new versus returning customer, and by first attempt versus retry. Almost every real finding shows up in one of those cuts and disappears in the average.

Three kinds of decline, and only one of them is interesting

Declines you caused. Codes like 03 Invalid Merchant, 58 Transaction Not Permitted to Terminal, 12 Invalid Transaction, 13 Invalid Amount, and 30 Format Error are configuration failures. The card was fine, the customer was ready, and your setup rejected the sale. These are the cheapest points you will ever recover, and a spike in 03 across all issuers usually means a MID was suspended and your routing did not notice.

Declines the cardholder owns. 51 Insufficient Funds, 54 Expired Card, 46 Closed Account, 41 Lost Card, 43 Stolen Card. Some are recoverable with better timing or refreshed credentials, and several are permanently dead.

Declines that are the issuer's opinion of you. 05 Do Not Honor is the catch-all here, along with 01 and 02 referrals, 59 Suspected Fraud, and 62 Restricted Card. For most high-risk merchants this is the biggest bucket and the one worth working, because a 05 is not a fact about the cardholder. It is a scoring decision that a different merchant identity, a different acquiring BIN, or a cleaner transaction can reverse. The full decline code reference breaks down which codes are safe to reattempt and which are not.

The levers, ranked by what they actually return

Lever	Effort	Where the lift comes from	Honest limits
Fix configuration declines	Low, one-time	Sales you were rejecting yourself	Usually a small share of volume, but it is pure recovery
Decline-code-aware retries	Low to medium	Soft declines that clear with time	Wrong retries make issuer scoring worse, not better
Network tokens and account updater	Medium, integration work	Reissued and expired cards on rebills	Little help on one-time cold traffic
Routing by issuer behavior	High, needs multiple MIDs	Issuer-level category blocks	Requires real redundancy you may not have yet
AVS, CVV, and 3DS tuning	Medium, ongoing	Fewer false fraud declines	Loosening checks buys approvals and pays for them in disputes
Amount and currency handling	Low	Cross-border and validation friction	Small, but nearly free

Notice what is not on the list. There is no lever called "switch gateways," because a gateway does not authorize anything. It hands your transaction to an acquirer, and the acquirer and the issuer decide.

Retry discipline is a rules problem, not a persistence problem

The networks have codified reattempt behavior, and treating retries as a volume game puts you on the wrong side of it. Visa's framework sorts declines into categories that permit no reattempt, a limited number of reattempts, or normal reattempts, and it caps reattempts on a declined transaction within a rolling window. Mastercard publishes merchant advice codes alongside the decline, which tell you plainly whether to try again later, whether updated account information exists, or whether to stop permanently. Both networks revise these thresholds and some acquirers charge for excessive reattempts, so confirm current limits with your acquirer rather than with a blog post.

The practical rule is that timing beats volume. A 51 retried three times in an hour is three declines. The same 51 retried once, several days later, on a schedule that respects when people get paid, converts a meaningful share of the time. A 41 or 43 retried at all is an attempt to charge a card the issuer has already declared compromised.

Build the retry logic to read the decline reason and the advice code, and give it a hard stop. Merchants doing recurring billing get the most out of this, which is why retry scheduling shows up as a core feature on the subscription and continuity billing page rather than as an optimization afterthought.

Network tokens and account updater

Network tokenization replaces the card number in your stored credential with a network-issued token, provisioned through Visa Token Service, Mastercard's MDES, or the equivalent at Amex and Discover. Two things follow from that. The credential stays current when the issuer reissues the card, so an expiry or a replacement no longer breaks the rebill. And issuers frequently score tokenized transactions more favorably, because the token carries a cryptographic assurance a raw PAN does not.

Account updater services, Visa Account Updater and Mastercard Automatic Billing Updater, solve a narrower slice of the same problem for merchants not yet tokenized.

Be sober about the size of the lift. Providers report gains from network tokens that are usually low single digits, they are self-reported, and they are concentrated almost entirely in recurring billing where credential churn is the dominant loss. If your revenue is one-time purchases from cold traffic, tokens will not fix your approval rate.

There is a structural catch worth naming. Network tokens are provisioned to a token requestor, and if your gateway is the requestor, the tokens are not portable to a competitor. That reproduces the lock-in problem covered in the token vault guide, one layer up. Ask who holds the requestor ID and what happens to the tokens if you leave, before you integrate rather than during the migration.

What high-risk changes about all of this

Mainstream authorization content assumes the issuer is neutral about your business. Yours is not.

Some issuers maintain standing blocks against specific merchant category codes. When that is what is happening, no amount of retry tuning helps, because the decline is a policy, not a score. The only thing that converts that traffic is presenting a different merchant identity, meaning a properly underwritten MID at a different acquirer with a different acquiring BIN. That is the payoff of the architecture described in the MID load balancing guide, and it is the one authorization lever that requires infrastructure rather than configuration.

Your own history also prices into the decision. A MID carrying a fresh dispute problem gets scored down by issuers who have seen those chargebacks, so approval rate and dispute rate are not independent metrics. Working your ratio, as covered in chargeback ratio explained, is authorization work with a lag.

One honest clarification about descriptors. Descriptor quality is mostly dispute work rather than authorization work, since the issuer's authorization decision happens before any human reads the statement. The exception is the referral codes, where a cardholder ends up on the phone with their bank and a recognizable descriptor is the difference between a vouch and a shrug. The descriptor optimization guide covers that in detail, and it belongs on your list for reasons that mostly are not this one.

Measure it in a way that can embarrass you

Track approval rate per MID and per issuer BIN, weekly, with new and returning traffic separated. Then track the number that actually matters, which is net approved revenue after refunds and chargebacks.

Every lever that loosens fraud screening lifts approvals. Some lift disputes more than revenue, and the approval chart looks great the whole time your ratio climbs toward a monitoring program. If a change adds two points of approval and half a point of chargebacks, you have bought an expensive problem with a flattering dashboard.

Give any change a few weeks, hold the traffic mix roughly constant, and write down what you expected before you look.

Practical takeaway

The path that fails is treating approval rate as a vendor selection problem. Merchants switch gateways, buy a smart-routing add-on that has no volume to learn from, and turn retries up until the issuer models learn to distrust them. The number does not move, and the disputes do.

The path that lasts is boring and sequenced. Fix the declines your own configuration is causing, then make retries read the decline code and the advice code instead of counting attempts, then tokenize stored credentials if recurring revenue is a real part of the business. After that, the remaining ceiling is usually issuer policy toward your category, and the only way through it is a second properly underwritten MID at a different acquirer. Judge all of it on net approved revenue, not on the approval percentage alone. If you want a read on which of those steps is the actual constraint in your setup, apply for an architecture review.