Why your alternative payment method approval rates plateau & how to fix it

There's a specific moment most payment operations teams reach: in markets where PIX, GrabPay, BLIK, iDEAL, or mobile wallets carry a significant share of transactions, approval rates for those methods fall below the card equivalent — even within the same customer base, with the same providers and payment routing⁠ infrastructure. The card stack has been optimised down to the issuer level. The APM stack is usually much less precise: it often routes based on provider averages, recent payment success rates, or the last provider that worked for a similar transaction.

There’s a structural reason for the gap. And three specific tools that address it at different points in the payment journey: retry flow for redirect payments, smart retry routing based on previous attempt resolution, and customer-to-provider binding for alternative payment methods. In this piece, I want to explain what each does, how they differ from card-era equivalents, and what changes operationally when teams apply them.

The reason APM approval rates stay behind cards

Card payments give routing engines a powerful signal: the PAN⁠.

Because the PAN is stable and tied to the customer’s card, the smart payment routing layer can build knowledge over time. It can learn which issuer is involved, which acquirer has historically performed best, what 3DS behaviour to expect, and which MID⁠ to prioritise. That’s why card routing can become highly precise. The system has a persistent identifier to learn from.

With digital wallets, local bank transfers, and other alternative payment methods⁠, there is often no equivalent customer-level identifier exposed to the routing layer. The orchestrator cannot rely on a PAN-like token to recognise the payment context and apply previous learnings. So, APM routing often happens with less signal.

Many platforms fall back on rules such as ‘use the last successful provider for this merchant account.’ This can help in simple cases, but it becomes fragile when conditions change. A different currency, commerce account, checkout flow, country, or provider configuration can make the previous result irrelevant. The routing decision then becomes much less informed.

That’s the structural reason APM approval rates often lag behind cards. The routing toolkit was built around PAN-based optimisation. Remove the PAN, and the system loses one of its most valuable sources of intelligence.

Three levers for fixing APM approval rates

APM approval rates suffer at multiple points in the payment journey: some failures happen because a customer abandons after the first decline and never gets another shot; some happen because a retry loops back through the same broken route; and some happen because a returning customer is treated as a stranger by the routing layer, even though they've successfully paid before.

Each of these is a distinct problem, and each has a distinct solution:

• Retry flow for redirect payments — keeps the customer inside the payment journey after a failed attempt so they can try again without starting from scratch.
• Smart retry routing — ensures the retry attempt goes to a different route when the previous one returned a technical failure.
• Customer-to-provider binding — gives returning customers a persistent route preference based on what has already worked for them in that payment context.

These three tools work independently, but they compound when layered. The sections below explain each one in detail and show how they fit together.

Lever 1: Retry flow for redirect payments

In redirect-based APM scenarios — Apple Pay, Google Pay, or any method that takes the customer through an external flow before returning them to the merchant's checkout — a failed payment used to mean the end of the current session. If the first attempt didn't go through, the customer had to create a new invoice or restart the payment process from the merchant's side. The flow broke.

Retry flow for redirect payments removes that constraint. Merchants can configure a ‘retry_limit’ parameter that defines how many additional attempts the customer can make within the same payment session, without creating a new invoice or restarting from the checkout page.

Retry flow gives the customer a second (or third) attempt while intent is still high and they're still on the checkout page. That alone reduces the share of failures that turn into abandoned payments. But retry flow on its own doesn't change where the retry attempt goes. That's the job of the second lever.

Lever 2: Smart retry routing

Retry flow keeps the customer in the session, but without additional routing logic, the retry may go through the exact same merchant account or provider route that just returned a ‘provider_error, timeout’, or ‘processing_error’. In that case, the retry loop isn't recovering the payment but repeating a known failure.

The ‘Previous payment request resolution’ routing attribute allows the routing engine to use the outcome of the previous attempt as input for the next one. When a retry is triggered, the engine checks the resolution of the most recent payment request. If that resolution matches a configured condition, the corresponding routing rule fires.

For example, if the previous attempt returned a ‘timeout’ or ‘provider_error’, the merchant can configure a rule to exclude that merchant account from the retry attempt. The next attempt then routes to a different, potentially more stable, provider.

If the previous resolution isn't available, the routing engine applies a ‘No result action’:

• Skip merchant account — the merchant account is excluded from routing regardless.
• Ignore filter — the filter is not applied, and routing continues as normal.

This turns retry flow from a simple ‘try again’ mechanism into context-aware retry routing. The system knows what just failed and why, and it can route around it.

Lever 3: Customer-to-provider binding

The first two levers operate within a single session: they help recover a payment after the first attempt fails. The third lever operates across sessions: it helps returning customers succeed on the first attempt by routing them to the provider that has already worked for them before.

Since APMs do not expose a PAN, the system has to build its own identifier from the information it has, and this detail matters. ‘Apple Pay’ alone is too broad. Apple Pay in UAH through HPP and Apple Pay in USD through HPP may perform differently with different providers. If the system treats both as just ‘Apple Pay,’ it loses the context needed to route the payment effectively.

Why failed payments shouldn’t always remove the binding

A failed payment doesn’t always mean the route is wrong. Some failures are temporary. A provider may have a short outage, a bank may decline a transaction for a one-off reason, or the issue may have nothing to do with the selected route.

That’s why customer-to-provider binding shouldn’t be removed after every failed APM transaction. The binding should remain active for soft declines and be removed only when the failure falls within a configured fatal error group.

How binding works within a payment routing strategy

Customer-to-provider binding doesn’t replace the routing strategy. It simply gives the previously successful route higher priority within the active routing logic. If that route is no longer available in the current routing scheme, the system can use the next successful route for the same service context and create a new binding.

This keeps the routing layer adaptive. It remembers what worked, but it does not lock the customer into a route that is no longer relevant.

Card bindings vs APM bindings: same idea, different engineering

Card bindings⁠ and APM bindings follow the same principle: remember the route that worked before and prioritise it when the customer returns. But the engineering behind them is different.

Card binding works because cards have a PAN. The identifier already exists, so the main challenge is building routing logic around it: which MID or route should be prioritised for this card, and how that preference should change after each transaction outcome. In simplified terms, it’s one card, one route preference, continuously updated as new payments are processed. This logic is well understood, and many card stacks have already solved it.

APM binding is more demanding because alternative payment methods don’t provide the same stable identifier. There is no PAN to anchor the logic on. Instead, the binding layer has to create and maintain a composite key for each customer and each payment context.

The unbinding logic is also more sensitive for APMs. Some alternative payment methods charge per attempt, regardless of whether the payment succeeds or fails. If the system removes a binding after a soft decline and immediately cascades to another provider, the merchant may pay for additional attempts without meaningfully improving the chance of approval. That’s why fatal-error-only unbinding matters. A binding shouldn’t disappear after every failed transaction. It should remain active through temporary failures and only be removed when the failure clearly shows that the route is no longer suitable.

How the three levers work together

Each lever addresses a different failure mode. Used in combination, they form a layered APM recovery and optimisation system.

Level 1: Don't lose the customer after the first failed attempt

The retry flow for redirect payments keeps the customer in the same payment session. Rather than ending the journey at the first decline, the merchant configures a retry limit, and the customer gets another attempt without a new invoice or a restart. This is the foundation: without it, the other two levers have nothing to work on.

Level 2: Don't repeat the route that just failed

Previous payment request resolution adds intelligence to the retry. If the first attempt returns a provider error or a timeout, the routing engine excludes that route and retries on a different, potentially more stable, path. The customer isn't just trying again — they're trying a different route.

Level 3: Prioritise routes that have already worked for this customer

Customer-to-provider binding operates at the session-to-session level. Once a customer has a successful payment on record, their binding gives that route higher priority the next time they pay. For repeat customers using the same APM context, this means fewer first-attempt failures before a session even needs retry logic.

When all three are active, the system can:

• Keep the customer within one invoice after a failed attempt
• Allow a repeated payment without creating a new invoice
• Take into account the resolution of the previous attempt
• Avoid the route that just returned a technical fail
• Prioritise the route that previously worked successfully for this customer
• Reduce the number of unsuccessful attempts
• Increase the chance of a successful payment completion

What changes operationally

For payment teams, the value of these three tools shows up in concrete operational outcomes.

• Higher approval rates for returning APM customers. Binding routes returning customers to the provider that has already processed them successfully in the same payment context. The clearest impact appears in the returning-customer APM cohort, where the historical routing signal is strongest.

• Fewer abandoned payments after first-attempt failures. Retry flow keeps the customer in the session. The alternative — asking them to restart — loses a meaningful share of customers who don't bother.

• Smarter recovery when retries are needed. Smart retry routing means a retry attempt goes somewhere different when the previous route returned a technical failure. This turns repeated failure into a genuine opportunity for recovery.

• Lower cost from unnecessary cascading. Some APM providers charge per attempt, even when the transaction fails. Binding reduces unnecessary retries for returning customers by prioritising the route that has already worked. Fatal-error-only unbinding prevents the persistence layer from eroding after transient failures, which would otherwise push traffic toward unproven routes and increase cascading costs.

• Better customer experience. A returning customer who is declined for a payment method that previously worked doesn't see a routing issue. They see a product failure. Reducing preventable declines across all three levers protects trust and makes the payment experience feel more reliable.

• Gradual performance gains over time. As more customers return and reuse APMs, the bound cohort grows, and the approval rate lift becomes more visible. Retry and smart routing deliver immediate session-level gains, binding compounds over the lifetime of the customer relationship.

When APM binding is and isn’t the right answer

Customer-level binding is a returning-customer payment optimization. It works best when there is a pattern worth reinforcing: the same customer coming back, using the same APM context, across a routing setup with more than one possible route.

However, APM binding is not the right answer when:

• You only use one APM provider. If all APM traffic goes through one PSP, there is no meaningful routing decision to make. Binding needs at least two available routes so the system can prioritise the one that worked before.
• Most customers are first-time buyers. Binding builds value over time. If repeat purchase rates are low, the bound cohort may be too small to create a material lift. For acquisition-heavy traffic, provider selection, checkout design, payment method coverage, and decline messaging will usually matter more.
• You don’t measure APM performance separately. Teams need visibility into APM approval rates by provider, method, currency, and flow. Without that baseline, it is hard to prove binding’s impact or configure fatal error groups properly. Binding depends on instrumentation; it does not replace it.
• The underlying provider fit is weak. If a provider consistently underperforms for your customer segment, binding can gradually route returning customers away from it. But it won’t fix the provider relationship itself. It optimises across your existing provider set; it does not replace provider due diligence.
  

How Corefy equips teams to improve APM approval rates

Improving APM conversion depends not only on the availability of popular payment methods, but on how the system behaves after an unsuccessful payment attempt. Corefy gives payment teams the tools to build a smarter APM recovery flow.

Merchants can enable retry flow so customers can repeat a failed redirect-based payment within the same CPI flow, without creating a new invoice or restarting the journey. With the previous payment request resolution, the next attempt can also become more informed: if the previous payment failed because of a provider error, timeout, or processing issue, the routing engine can avoid that route or merchant account and send the retry through a different path.

For returning customers, APM binding adds another layer of optimisation. Corefy can prioritise the route that has already successfully processed a payment for the same customer and payment context, helping to reduce avoidable first-attempt failures before retry logic is even needed.

The controls sit at the routing scheme, merchant account⁠, and route level, so teams can apply each capability precisely where it's useful rather than across every flow by default.

Key takeaways

• APM approval rates lag cards for a structural reason. The routing toolkit was built around PAN availability. Without a PAN, most orchestrators route APM transactions with far less signal, and the approval rate reflects it.
• Three distinct levers address the gap at different points in the journey. Retry flow keeps customers in the session after a failed attempt. Smart retry routing ensures the next attempt goes somewhere better. Customer-to-provider binding prevents first-attempt failures for returning customers by prioritising routes that have already worked.
• The levers compound. Used together, they form a layered APM recovery and optimisation system: the customer stays in the session, retries to avoid known-bad routes, and returning customers reach a provider that has processed them before.
• Binding is preserved through transient declines and removed only on configured fatal-error outcomes. This protects the persistence layer from eroding every time a provider has a bad minute and prevents unnecessary cascading costs on APMs that charge per attempt.
• The gain compounds over time. Bindings accumulate as customers return; the approval rate lift grows with the bound cohort. Track returning-customer APM approval rate separately from first-time transactions to see the curve clearly.
• The next meaningful conversion gains in payments will come from the APM stack. The platforms that build proper persistence and retry layers for APMs first will carry a structural advantage as APM volume grows.