When a payment is declined, the customer usually does not try again. For a merchant, a better approval rate is one of the most direct ways to grow revenue without buying a single extra visitor.
Improving it is less mysterious than it sounds. It starts with understanding why payments decline, then removing the causes you can influence. This article walks through that approach and explains where payment orchestration fits.
Start with the reasons
A decline is a response with a reason attached. Those reasons fall into rough groups, and the groups tell you what to do.
- Customer-side declines, such as insufficient funds or a closed account, are real and you cannot change them.
- Issuer risk declines happen when the bank is not confident about the payment. Better data and authentication can help.
- Technical declines come from timeouts, format errors or system issues. They are often fixable on your side.
- Credential declines occur when stored card details are out of date.
- Configuration declines come from how you set up routing, authentication and retries.
Group your declines this way before you do anything else. The result is a map of where improvement is possible.
Read your data by slices
An overall approval rate is a blunt tool. Break it down:
- By payment method and card type
- By issuer, where you can see it
- By country
- By device and browser
- By authenticated and non-authenticated payments
- By decline reason
Patterns usually jump out. One issuer declines a lot of your payments after a challenge. One method fails mostly on mobile. One country has a spike in a particular code. Each pattern points to a specific fix.
Authentication strategy
How you handle authentication has a large effect on approvals. Too little, and issuers decline payments they consider risky. Too much friction, and customers abandon.
Send complete data so issuers can approve more payments without asking customers for anything. Handle challenge outcomes well. Understand which exemptions your providers and issuers support, and use them where appropriate. Our article on 3DS2 for MENA merchants covers where these flows break.
Routing
Routing decides which provider or path handles each payment. With a single provider, routing is simple. With several, it becomes a lever.
Different providers can perform differently for different issuers, regions and card types. Smart routing sends each payment where it has the best chance, and can fall back to another path when one fails.
Routing choices should come from your own data. A rule such as "send this issuer's cards through that provider" is only worth making if the numbers support it.
Retries
Retrying a failed payment can recover revenue, and mishandled retries can do harm.
Good retry logic follows a few principles:
- Retry based on the reason. Technical and certain temporary declines may succeed on a second attempt. Hard declines will not.
- Space attempts sensibly. Immediate repeats rarely help and can look abusive to an issuer.
- Limit attempts. There should be a ceiling per payment and per customer.
- Respect network rules. Card networks set their own limits on retries, so check your provider's guidance.
- Protect against duplicates. Use idempotency so a retry cannot charge twice.
For subscriptions, retries are central. Failed renewals are often recoverable, and timing and messaging both matter.
Stored credentials
Cards expire, are replaced and are reissued. If you store them, make sure they are kept up to date. Tokens and network-level tokens can reduce declines caused by stale details, and account updater services can refresh credentials automatically.
Track declines caused by outdated credentials separately. They are among the most fixable.
Pending and technical failures
Some payments are lost not because they were declined, but because they were never resolved. Pending payments, timeouts and missed webhooks all cost revenue and trust. We explain how to deal with them in why payments get stuck in pending.
Where orchestration fits
Payment orchestration puts a layer between your checkout and your providers. That layer decides routing, applies retry rules, manages authentication choices and gives you one place to see results.
It can help when:
- You use more than one provider or acquirer
- You sell in several markets with different payment mixes
- You want fallbacks if a provider has an outage
- You need one consistent view of payments across providers
It will not help if:
- You do not yet understand your declines
- Your data and reporting are weak
- Your basic integration has gaps, such as unhandled webhooks
Orchestration amplifies a good setup. It does not replace one. Fix the basics first, then decide whether a layer is worth the added complexity and dependency.
What good reporting looks like
You cannot improve what you cannot see. A useful payments report lets someone answer, in minutes, why approvals moved last week. It shows approval rate by method, issuer and country, decline reasons grouped as above, authentication outcomes, retry results and pending counts. It also keeps a history, so you can line up a change in the numbers with a change in your configuration.
If your provider's dashboard does not offer this, export the data and build it yourself. The effort pays for itself the first time a number moves unexpectedly.
How to test changes safely
Payment changes touch revenue directly, so roll them out with care.
- Change one thing at a time. Otherwise you will not know what caused the result.
- Start with a small share of traffic. Compare it with the rest over a comparable period.
- Decide success in advance. Pick the metric and the time window before you start.
- Watch the side effects. An improvement in approvals that raises fraud or disputes is not an improvement.
- Keep a rollback ready. Make it easy to return to the previous setting.
This discipline matters most for routing and authentication changes, where small shifts can affect many payments.
Questions to ask before adopting an orchestration layer
If you are weighing an orchestration product, ask:
- Which providers and methods does it connect to, and how quickly are new ones added?
- Can you see and change the routing and retry rules yourself?
- What data does it return, and can you export it?
- What happens to payments if the layer itself is unavailable?
- How would you leave, including stored credentials?
Anything that sits in the path of every payment deserves the same scrutiny as a core system.
A simple order of work
- Collect decline reasons and group them
- Slice approval rates to find the biggest gaps
- Fix technical issues, pending payments and webhook handling
- Improve authentication data and flows
- Tighten retry logic based on decline reasons
- Keep stored credentials current
- Consider routing and orchestration if your setup needs them
Pitfalls
- Chasing a single average
- Retrying everything on a timer
- Changing several things at once, so you cannot tell what worked
- Loosening authentication without understanding the risk
- Adding a new layer before the basics are solid
Where to go next
Our approval-rate optimization service audits exactly these areas and gives you a prioritized list of fixes. If you are building or rebuilding a payment flow, see our payment gateway integration service.
