Routing by Approval Rate
Routing Payments by Approval Rate: How to Improve Authorization Without Fooling Yourself With the Data Provider A: 94% approval. Provider B: 88% approval. Route more traffic to Provider A? Not yet. Provider A receives mostly returning domestic customers using familiar cards. Prov
Routing Payments by Approval Rate: How to Improve Authorization Without Fooling Yourself With the Data
Provider A: 94% approval.
Provider B: 88% approval.
Route more traffic to Provider A?
Not yet.
Provider A receives mostly returning domestic customers using familiar cards.
Provider B receives disproportionately more first-time international customers.
The six-point gap exists in the dashboard.
What has not yet been established is whether Provider A caused it.
This is the central difficulty in payment routing by approval rate:
Approval routing is a measurement problem before it is a routing problem.
Once a merchant starts sending different types of transactions to different PSPs or acquirers, the resulting provider approval rates describe both:
how the provider performed
and:
which transactions the routing system chose to give it.
Those effects become entangled.
A merchant that ignores that fact can build an apparently data-driven routing system that steadily sends more traffic to yesterday's statistical winner—even when much of the observed advantage came from easier traffic rather than the payment route itself.
The solution is not to stop measuring approval.
It is to measure the incremental approval effect of a route on comparable transactions.
Start by defining exactly what “approval rate” means
“Approval rate” sounds self-explanatory until two teams calculate it differently.
For routing analysis, the denominator has to be explicit.
A useful high-level routing measure is:
Authorization approval yield
=
approved authorizations
÷
eligible authorization attempts assigned to the measured route
The word eligible matters.
A provider should not be penalized in an approval comparison for transactions it legally, technically, commercially, or operationally could not process in the first place.
Eligibility can depend on factors such as:
merchant entity;
acquiring relationship;
payment method;
currency;
card network;
issuer geography;
recurring status;
authentication context;
merchant category;
provider availability.
The orchestration brief explicitly puts eligibility before optimization: first determine which paths can process the transaction, then rank those candidates.
So approval routing begins with:
Transaction
→ eligible routes
→ comparable authorization attempts
→ approval measurement
→ route decision.
Not:
all transactions
→ highest dashboard percentage wins.
Do not hide technical failures inside issuer declines
A non-approved transaction can have materially different causes.
Visa's current developer documentation, for example, distinguishes an approved authorization response from outcomes such as insufficient funds and from error/system-related responses. That is one network-specific illustration of the broader point: issuer/cardholder declines and technical processing failures are different events.
A routing dataset should therefore distinguish at least:
Approved authorization
The authorization was approved.
Issuer/payment decision decline
The authorization reached the relevant decision path and was declined.
Technical failure
The attempt did not produce an ordinary issuer approval/decline outcome because of a technical or processing failure.
Unknown/unresolved
The merchant cannot yet establish the final authorization state.
Those categories serve different analytical purposes.
If Provider B suffers a technical outage for ten minutes, calling every affected attempt an “issuer decline” would make B's apparent issuer performance worse even though issuers never made those decisions.
Conversely, simply deleting technical failures from every metric can hide the fact that a route is operationally poor.
A mature dashboard therefore benefits from separating:
Issuer-decision approval rate
Among attempts that reached the relevant authorization decision:
approvals ÷ defined issuer-decision attempts
from:
Route authorization yield
Among transactions legitimately assigned to the route:
approvals ÷ eligible assigned authorization attempts
The first helps diagnose authorization decisioning.
The second tells the merchant more about what the route actually delivered operationally.
The naming is less important than documenting the denominator and keeping technical failures distinct from issuer declines.
Global approval rate is usually too coarse for routing
Suppose:
Provider
Approved
Attempts
Raw approval
A
94,000
100,000
94%
B
88,000
100,000
88%
At first glance, the routing recommendation seems easy.
Then segment the data.
Provider A traffic
70% domestic debit cards
20% returning domestic credit cards
10% international cards
Provider B traffic
15% domestic debit cards
20% returning domestic credit cards
65% international cards
Those proportions are hypothetical, but the methodological point is real.
The providers are answering different questions.
A's 94% asks:
How did A perform on the traffic A received?
B's 88% asks:
How did B perform on the traffic B received?
Neither answers:
How would A and B have performed on the same traffic?
That last question is the one approval-based routing actually needs.
Routing by approval rate is counterfactual
For every transaction routed to A, the merchant observes:
what happened at A.
It does not simultaneously observe:
what would have happened if the identical transaction had been sent to B instead.
That missing outcome is the counterfactual.
The general statistical problem is well established outside payments. Research on off-policy evaluation describes the challenge of estimating the value of a target decision policy using data collected under another policy. Once the existing system determines which action receives each observation, evaluating an alternative policy from those logs becomes a distinct statistical problem rather than a simple average comparison.
Approval routing has the same structural issue.
The current router generated the dataset.
Therefore:
Historical route performance is policy-generated data.
That does not make it useless.
It means the merchant must account for how the policy allocated traffic before treating observed differences as evidence of incremental route performance.
Control the traffic mix before ranking PSPs
The brief requires approval-rate comparisons to control, where relevant, for:
issuer;
card product/category;
country;
currency;
authentication treatment;
merchant entity;
fraud policy;
transaction amount;
retry position;
comparable time period.
Not every dataset needs every dimension.
The objective is not infinite segmentation.
It is to identify variables that affect both:
which route receives the transaction
and:
the likelihood of authorization.
Those are potential confounders.
Issuer mix
Provider A may appear stronger because it receives more traffic from issuers that already approve the merchant at higher rates.
Card product/network mix
Debit, credit, commercial, prepaid, tokenized and other card populations can behave differently.
Geography
Domestic and cross-border payment paths may not be directly comparable.
Customer cohort
Returning customers can differ from first-time customers in transaction history, risk treatment, credential quality, or merchant relationship.
Transaction value
Average ticket size can alter the composition of provider traffic.
Fraud controls
If the merchant blocks a different population before sending traffic to one route, downstream approval-rate comparisons can reflect merchant-side selection.
Authentication
Authentication treatment can affect the transaction context sent toward authorization.
EMVCo's current EMV 3DS material explains that issuers can receive transaction, payment-method, device and other contextual information during authentication and use it in risk assessment. That means differently authenticated cohorts should not automatically be treated as equivalent authorization populations.
Retry position
A route handling mostly first attempts is not directly comparable with a provider disproportionately receiving retries after another route already failed.
That last distinction deserves its own section.
First attempt and retry are different populations
Suppose the architecture is:
First attempt → PSP A
If declined:
Retry → PSP B
The resulting dashboard says:
A: 91% approval
B: 38% approval
Does that make B terrible?
No.
PSP B received transactions that had already failed elsewhere.
Its denominator was preselected for difficulty.
That is retry-position bias.
Now reverse the order:
First attempt → B
Retry → A
Observed provider averages can change substantially even if the underlying route capabilities have not.
So every authorization record used for route comparison should retain, where relevant:
payment intent
attempt number
primary route
retry/fallback status
previous outcome
reason for second attempt.
Do not compare:
PSP A first attempts
with:
PSP B rescue attempts
and interpret the difference as provider quality.
Failover traffic creates the same problem
Technical failover produces another selected population.
Imagine PSP B mostly receives transactions when PSP A is degraded.
B's observed cohort now over-represents:
incident periods;
unusual routing conditions;
perhaps specific countries or methods;
transactions with an unresolved original attempt.
That traffic may be valuable for measuring failover recovery.
It is poor evidence for B's ordinary first-route approval rate unless separated appropriately.
The dedicated Payment Failover article should own safe recovery logic.
For approval routing, simply preserve this rule:
Normal route traffic, retry traffic and failover traffic require separate analytical treatment.
Observed performance and incremental lift are different metrics
Suppose comparable historical data shows:
Provider A: 92.4%
Provider B: 91.7%
The descriptive difference is:
+0.7 percentage points for A.
That is not necessarily the incremental effect of routing future transactions to A.
A causal or experimental comparison might later estimate:
A causes +0.2 percentage points for this defined cohort
or:
no credible difference
or even:
B performs better once traffic is normalized.
Use separate labels:
Observed approval difference
Difference between approval rates in historical routed traffic.
Adjusted approval difference
Difference after statistical adjustment/segmentation for known population differences.
Experimental approval difference
Difference measured under controlled allocation of comparable eligible traffic.
Incremental approval effect
Estimated change in approval caused by selecting one eligible route rather than another for the defined cohort.
Only the last two usually justify strong causal language.
Descriptive winner ≠ incremental winner.
The cleanest test is controlled allocation
Where commercially, legally and operationally appropriate, the cleanest way to compare two eligible routes is controlled allocation.
Define an eligible cohort.
For example:
same merchant entity
same currency
same card network/category
same authentication treatment
first authorization attempt
both PSPs operationally eligible
Then allocate some traffic independently of the historical routing preference.
Conceptually:
Eligible transaction cohort
↓
Controlled allocation
↙︎ ↘︎
Route A Route B
↓
Authorization outcomes
↓
Compare equivalent denominators
This gives each route traffic drawn from the same underlying population.
The experiment should preserve normal fraud, security, network and compliance constraints. Randomization is never a reason to send transactions through an otherwise ineligible path.
Use a holdout when the router starts optimizing
A common failure appears after the merchant identifies A as the provisional winner.
The router sends A more traffic.
A therefore gets more recent data.
B gets less.
B's estimate becomes noisier.
The router sees more confidence in A.
It sends even more traffic to A.
The system has created a feedback loop:
A looks better
→ A receives more traffic
→ A receives more data
→ B receives less data
→ B becomes harder to evaluate
→ A becomes structurally favored.
The brief identifies this as an exploration-versus-exploitation problem and specifically recommends holdout or exploration traffic, minimum samples, recency treatment and re-entry logic where dynamic routing is used.
A controlled holdout preserves some evidence about what the alternative route can currently do.
Without one, the merchant risks eventually knowing a great deal about the route it already prefers and very little about whether its alternatives have improved.
Small segments create fake winners
Segmentation is necessary.
Over-segmentation creates another problem.
Suppose:
Provider A — Issuer X: 92%
based on:
37 attempts
while:
Provider B — Issuer X: 88%
based on:
8,000 attempts.
The four-point lead for A should not automatically trigger issuer-level routing.
The sample for A is tiny.
The brief deliberately uses this example to require minimum sample sizes, uncertainty controls, recency windows and appropriate segmentation before declaring issuer-specific routing winners.
At minimum, a production approval-routing process should ask:
How many eligible attempts support this estimate?
How uncertain is the estimate?
How recent is the data?
Is the segment stable enough to act on?
Would one unusual hour/week reverse the result?
Does the route still need exploration traffic?
The problem is not merely statistical elegance.
A noisy winner becomes a production rule.
Production rules alter future traffic.
That means a random fluctuation can become self-reinforcing.
The denominator should follow the question
Different questions need different denominators.
“How often does the issuer approve?”
Use a denominator representing attempts that reached the relevant authorization decision, as precisely as the merchant's data permits.
Keep technical failures separately visible.
“How often does this route produce an approval when selected?”
Use the defined eligible assigned-attempt population.
Technical failures belong in the route outcome because the route did not produce an approval.
But classify them as technical failures, not issuer declines.
“How often does the customer ultimately pay?”
Authorization attempts are no longer the correct denominator.
Use the full checkout/payment population appropriate to the business question.
This distinction prevents a team from using one percentage called approval rate to answer three different questions.
Approval rate is not payment conversion
A route can improve authorization and still reduce completed-payment conversion.
For example, it might involve:
additional authentication;
higher latency;
more customer interaction;
another redirect or step;
a retry pattern that customers abandon.
EMVCo's current documentation explicitly distinguishes frictionless and challenge authentication experiences, showing why authentication behavior can affect the broader customer journey independently of the final authorization decision.
So:
authorization success
≠
checkout completion
≠
payment conversion.
A routing experiment should therefore track at least:
eligible checkout/payment population
→ authentication where applicable
→ authorization attempt
→ authorization result
→ completed payment
when the merchant's business objective is actual payment completion rather than authorization alone.
The brief explicitly assigns this article the distinction between approval and eventual payment conversion.
Higher approval can also cost more
This article does not own route economics, but approval should not be optimized without a commercial boundary.
Suppose, hypothetically:
Route
Cost
Approval
A
1.5%
88%
B
1.8%
91%
Neither route is automatically better.
The merchant needs to compare:
incremental successful payments
against:
incremental processing cost
and:
merchant economics.
The brief therefore recommends considering net commercial impact instead of treating approval as the only routing objective.
The deeper calculation belongs in Routing by Cost.
The approval-routing principle is:
Optimize authorization performance subject to explicit economic and operational constraints—not in isolation from them.
The Approval Routing Measurement Framework
The article's operating framework has six stages.
Comparable cohort
Define the transactions for which both routes are genuinely eligible and the comparison is meaningful.
Record relevant dimensions such as:
merchant/entity;
market;
issuer or issuer group;
card/network category;
currency;
authentication;
customer cohort;
transaction-value band;
fraud policy;
first attempt versus retry.
The objective is not maximum granularity.
It is exchangeability: traffic that could reasonably have gone to either route.
Random or controlled allocation
Where appropriate, allocate comparable eligible transactions so provider selection is not wholly determined by previous performance assumptions.
Possible approaches include:
randomized split;
controlled holdout;
carefully designed matched analysis where randomization is unavailable;
statistically rigorous off-policy evaluation where the historical routing policy is known and suitable.
General off-policy research demonstrates that evaluating a new decision policy from data created by an existing policy requires explicit methodology; it is not equivalent to comparing raw outcome averages.
Route outcome
For every attempt distinguish:
approved
issuer/payment decline
technical failure
authentication failure where separately relevant
unknown/unresolved.
Preserve provider-native codes for investigation.
Visa's own current response-code documentation illustrates why approval, insufficient-funds outcomes, and system/error conditions are meaningfully distinct.
Issuer/card normalization
Check whether observed differences remain after controlling for meaningful card/issuer composition.
Do not stop at a global provider mean if one provider received materially different issuers, countries, card products, authentication, fraud treatment or retry positions.
Incremental approval effect
Estimate:
What changed because this route was selected?
Report the effect with uncertainty and scope.
For example:
For defined Cohort C during Period T, controlled allocation estimated Route A's approval rate above Route B by X percentage points.
Only publish X when real, verified merchant evidence exists.
Do not generalize:
Route A is better globally.
Commercial impact
Ask whether the incremental approvals produce enough economic value to justify:
route cost;
orchestration cost;
latency;
operational complexity;
provider commitments;
fraud/dispute changes where applicable.
This is the brief's Approval Routing Measurement Framework:
Comparable cohort
→ controlled allocation
→ route outcome
→ issuer/card normalization
→ incremental approval effect
→ commercial impact.
The route decision should retain its evidence
A production approval-routing rule should not merely say:
Issuer group X → PSP A.
It should carry operational metadata:
Owner
Who is accountable for it?
Objective
Approval rate, not vague “performance.”
Eligibility scope
Which transactions does it govern?
Evidence
What experiment or analysis supports it?
Sample
How much evidence?
Measurement period
When was it true?
Effect
Observed or estimated incremental difference.
Rule version
Which production logic implemented it?
Review date
When should the evidence be refreshed?
Rollback
How can traffic be restored if results deteriorate?
The brief requires comparable routing governance to prevent “mystery rules” from remaining indefinitely after their original rationale disappeared.
Recency matters because route performance can change
A provider/acquirer relationship that performed better six months ago does not have to remain better forever.
Potential underlying populations and operating conditions can change.
The correct response is not to route on yesterday's winner indefinitely.
Nor is it to make route changes every hour based on noise.
Routing stability matters.
Too-frequent changes can create:
insufficient samples;
debugging difficulty;
commercial unpredictability;
constantly shifting denominators.
The brief therefore recommends explicit confidence requirements, rule lifetime/change controls, versioning and rollback.
A merchant needs a balance:
enough stability to learn
and:
enough re-evaluation to detect change.
Do not mistake authorization routing for decline optimization
Suppose the analysis establishes that a particular issuer frequently returns insufficient-funds declines.
Sending those transactions to another PSP may not solve the underlying cardholder balance problem.
Likewise, another route may not fix:
an invalid account;
an expired credential;
a genuine issuer risk decision;
an invalid transaction;
customer authentication failure.
Visa's current authorization response taxonomy illustrates that non-approval reasons can describe materially different payment conditions.
The question for approval routing is narrower:
Does choosing another eligible payment path change authorization outcomes for comparable transactions?
The broader question:
How should merchants diagnose and improve authorization declines?
belongs in Improving Authorization Rates.
Keeping that boundary matters for both editorial clarity and actual payment operations.
Routing by issuer is a related but separate decision
Once the merchant discovers that a provider difference concentrates around one issuer or issuer group, the natural next question is:
Should the route be issuer-specific?
That belongs in Routing by Issuer.
Issuer routing has its own problems:
BIN/IIN data quality;
issuer identification;
tokenized credentials;
small samples;
issuer-versus-country granularity.
This article should provide the measurement foundation:
An issuer-level route still requires comparable traffic and credible incremental evidence.
It should not own the entire issuer-routing architecture.
“Smart routing” does not fix bad measurement
Dynamic software can optimize the wrong metric faster.
A router could update its preference continuously based on observed PSP approval rates.
If those rates are biased by:
traffic allocation;
retry position;
issuer composition;
fraud policy;
authentication;
incomplete samples;
then dynamically responding to them does not make the system more intelligent.
It makes the feedback loop faster.
The brief explicitly warns that “dynamic” does not necessarily mean AI, machine learning, real-time or optimal. The routing mechanism and its evidence need to be defined.
So avoid:
“Smart routing automatically sends every payment to the PSP most likely to approve it.”
A more defensible description is:
Approval-based routing selects among eligible routes using authorization-performance evidence whose comparability, recency and uncertainty have been evaluated.
That is less magical.
It is also more technically useful.
routes between arbitrary PSPs using approval rate;
performs causal approval optimization;
uses issuer-specific approval models;
maintains experimental holdouts;
dynamically reallocates traffic according to live approval performance;
guarantees an approval uplift;
exposes merchant-configurable approval-routing policies.
Those claims require current internal product verification.
A routing capability is not evidence of approval uplift. The measurement design has to establish the effect.
What a credible approval-routing dashboard should show
A useful route-performance view should let the payments team answer:
What population am I looking at?
Which PSPs were eligible?
Which PSP actually received the attempt?
Was this the first attempt, retry or failover?
What authentication treatment applied?
Which issuer/card segment was involved?
Did an issuer return a decision?
Was the failure technical instead?
What was the final authorization outcome?
Did the customer ultimately complete payment?
Was the traffic experimentally allocated or policy-selected?
How large is the sample?
When was the data collected?
If the dashboard provides only:
PSP
Approval
A
94%
B
88%
it may be useful for monitoring.
It is not sufficient evidence for a routing policy.
The final test: would the difference survive equal traffic?
Before shifting additional traffic toward an apparently higher-approval PSP, ask:
What would happen if both providers received comparable eligible transactions?
Then work through the evidence:
Are the denominators identical?
Are technical failures separated from issuer declines?
Is first-attempt traffic separated from retries?
Are issuer and card mix comparable?
Is authentication treatment comparable?
Are fraud controls comparable?
Does the result have enough observations?
Did routing itself create the observed population?
Is there a controlled holdout or experiment?
What is the estimated incremental approval effect?
Does that effect improve eventual payment conversion?
Is the commercial value worth the route's additional cost and complexity?
If those questions cannot yet be answered, the merchant may still have a useful descriptive signal.
It does not yet have proof that the route should receive more traffic.
That is the discipline approval-rate routing requires.
The objective is not:
Send every transaction to the provider with the highest approval rate.
It is:
For each meaningful group of transactions with more than one eligible route, determine whether choosing one route rather than another credibly causes more authorizations to succeed—and continue measuring the alternative well enough to know when that conclusion stops being true.
Fix the denominator first.
Then optimize the route.
This article provides general information and does not constitute legal, regulatory, financial, tax, security, network-rule, or compliance advice. Merchants should verify applicable requirements with qualified advisers, payment providers, acquirers, payment networks, banks, platforms, and relevant authorities.
🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
END OF ARTICLE
A. Brief interpretation
This is Payment Orchestration — Article 8: Routing by Approval Rate, within the larger merchant problem Operations That Don’t Scale.
Merchant operating problem: The merchant observes different approval rates across PSPs or acquirers and starts steering traffic toward the apparent winner without first establishing whether the providers received comparable transactions.
Payment decision being controlled: Which eligible provider or acquiring route should receive an authorization attempt when the objective is better authorization performance.
System making the decision: A merchant-owned, PSP-integrated, or independent orchestration/routing layer.
Primary routing signal: Historical authorization performance, segmented by relevant transaction context.
Primary evidence anchor: Routing itself changes which transactions each provider receives, so raw provider approval rates become biased as soon as routing begins.
Editorial position: Route on approval differences only when those differences remain credible after controlling for transaction mix, retry position, fraud/authentication treatment, technical failures, and routing-induced selection bias.
Most important technical distinction: Observed approval difference ≠ incremental approval effect.
Common assumption challenged: “Send more traffic to whichever PSP currently shows the highest approval rate.”
Merchant decision: Would this route still be expected to approve more comparable transactions if it received the traffic currently going elsewhere?
Format: Approval Routing Measurement Framework.
Structural rationale: Fix the denominator, normalize the populations, establish a credible counterfactual, and only then optimize the route. This page owns approval performance as a routing objective and its causal measurement, not authorization optimization generally.
Everything below is SEO, editorial, sourcing, measurement, verification, visual, and production guidance and is not part of the publication article.
C. Original practical asset — Approval Routing Measurement Framework
The visual should communicate causal progression, not simply rank providers.
Recommended production visual
COMPARABLE COHORT
Define:
merchant/entity
eligible providers
issuer/card segment
market/currency
authentication treatment
fraud policy
first attempt / retry position
↓
CONTROLLED ALLOCATION
Randomized traffic / controlled holdout / defensible comparison design
↙︎ ↘︎
ROUTE A ROUTE B
↓
OUTCOME TAXONOMY
Approved
Issuer/payment decline
Technical failure
Unknown
↓
NORMALIZE / VERIFY MIX
Issuer
Card/network category
Authentication
Customer cohort
Amount
Time period
↓
ESTIMATE INCREMENTAL EFFECT
Observed difference
≠
causal approval effect
↓
COMMERCIAL IMPACT
Incremental completed payments
Processing cost
Latency
Operational complexity
↓
ROUTING DECISION
Expand
Hold
Keep experiment running
Revert
Footer
Fix the denominator before optimizing the route.
This develops the framework explicitly assigned by the brief.
D. A useful measurement table
Metric
Recommended definition
Diagnostic purpose
Eligible attempts
Transactions for which measured routes were valid candidates
Correct comparison population
Authorization approval yield
Approved authorizations ÷ eligible assigned authorization attempts
Operational route performance
Issuer-decision approval rate
Approvals ÷ defined attempts with issuer/network authorization decisions
Authorization decision quality
Technical failure rate
Defined technical failures ÷ route submissions/eligible attempts, denominator stated
Route reliability
Soft/hard decline mix
Provider/network-defined decline categories, mapped cautiously
Diagnose decline composition
Approval by issuer/card segment
Approval under sufficiently supported comparable segments
Detect heterogeneity
First-attempt approval
Approval on attempt 1 only
Avoid retry bias
Retry approval
Approval on defined subsequent attempts
Measure recovery separately
Incremental approval effect
Controlled/causally estimated difference between eligible routes
Routing decision
Holdout performance
Alternative-route outcomes on reserved comparable traffic
Prevent stale winner
Eventual payment conversion
Completed payments ÷ defined eligible checkout/payment population
Business outcome
Incremental commercial contribution
Verified additional contribution from route change
Economic boundary
Do not combine these into one vague “routing performance” percentage.
E. SEO package
Payment Routing by Approval Rate: How to Measure What Works
H1
Routing Payments by Approval Rate: How to Improve Authorization Without Fooling Yourself With the Data
Keep the brief's H1. It gives the page a distinctive methodological hook rather than making it another generic authorization-rate article.
Meta description
Learn how payment routing by approval rate works, why raw PSP approval rates can mislead, and how to use comparable traffic, holdouts and controlled measurement to route by authorization performance.
Suggested URL slug
/solve/payment-operations-dont-scale/payment-orchestration/routing-by-approval-rate/
payment routing by approval rate
Secondary keywords
approval rate payment routing
authorization routing
route payments by authorization rate
smart routing approval rates
acquiring approval routing
PSP approval rate routing
payment performance routing
These are the article-specific targets.
Related entities
Payment orchestration, authorization rate, issuer decline, acquirer, payment service provider, PSP, payment routing, intelligent routing, issuer routing, routing policy, controlled experiment, holdout traffic, traffic allocation, selection bias, routing bias, payment conversion, authorization attempt, retry, failover, EMV 3DS, payment performance.
Article excerpt
The PSP with the highest observed approval rate is not automatically the best route. Routing determines which transactions each provider receives, so provider averages become selection-biased as soon as traffic is allocated differently. Credible approval routing starts with comparable eligible attempts, controlled allocation, correct failure classification and measurement of incremental—not merely observed—approval differences.
Featured-answer opportunity
Payment routing by approval rate means choosing among eligible payment paths using authorization-performance evidence. Merchants should not route solely on raw PSP approval averages because different providers may receive different issuer, country, card, authentication and retry populations. The relevant metric is the incremental approval effect on comparable traffic.
F. Internal-link strategy
Priority
Recommended anchor
Destination
Role
1
routing by issuer
Routing by Issuer
Deepens issuer-level segmentation
2
intelligent payment routing
Intelligent Payment Routing
Owns multi-signal optimization
3
improving authorization rates
Improving Authorization Rates
Owns broader authorization tactics and decline diagnosis
4
payment failover
Payment Failover
Owns technical recovery and ambiguous-state handling
5
rules-based vs dynamic routing
Rules-Based vs Dynamic Routing
Useful where measurement becomes a production-routing methodology
6
routing by cost
Routing by Cost
Owns economics when approval and cost conflict
The first four are explicitly required internal-link destinations.
I would keep Routing by Issuer and Improving Authorization Rates particularly prominent because they resolve the two most likely reader follow-ups without cannibalizing this article.
G. Authoritative source recommendations
Visa
Visa's current developer response-code documentation is appropriate for illustrating that:
approval
issuer/cardholder decline
and:
technical/error conditions
should not be collapsed into one outcome category.
Do not use those codes as a universal taxonomy for every network/provider.
EMVCo
EMVCo's current EMV 3DS documentation is useful for supporting the claim that authentication context can differ materially between transactions and that issuers can receive transaction, payment-method and device information during the authentication process.
Use this to justify controlling authentication treatment in approval comparisons, not to claim that 3DS universally increases authorization rates.
Statistical / experimentation research
The PMLR contextual-bandit literature is an appropriate primary methodological source for the general concept of off-policy evaluation: estimating a target policy's expected outcome from data generated by another decision policy.
Use it as methodological support.
Do not imply the paper studied payment routing.
Neither source establishes approval-rate optimization specifically.
H. Proposed author and reviewers
Recommended author:
Senior payment data analyst, payment-performance lead, or payments architect with hands-on multi-acquirer analysis experience.
Primary acquiring reviewer:
Acquiring specialist who can validate authorization lifecycle, issuer-versus-technical outcome classification, and route comparability.
Statistics reviewer:
Experimentation/data-science specialist familiar with selection bias, randomized testing, uncertainty, holdouts, and off-policy analysis.
Payments engineering reviewer:
Useful for confirming how route, attempt, error and authentication data are actually logged.
The brief specifically recommends a payment data analyst, acquiring specialist, and experimentation/statistics reviewer.
Strongest first-hand contribution
An approved merchant analysis showing:
raw Provider A approval > Provider B
→ cohort normalization reveals materially different traffic
→ controlled allocation produces a smaller, reversed, or better-supported route difference
→ routing policy changes based on incremental rather than raw performance.
Do not invent the actual percentages.
I. Architecture and observability requirements
For every authorization attempt used in routing analysis, retain where available and appropriate:
Merchant payment ID
Payment attempt ID
Attempt position
Eligible route set
Selected route
Route rule/version
Provider
Acquirer/path
Issuer or issuer group where permitted
Card/network category
Country variables used
Currency
Amount/value band
Authentication treatment/outcome
Fraud-policy version or relevant segment
Provider submission result
Authorization response
Technical failure classification
Fallback/retry relationship
Final payment outcome
Decision timestamp
This aligns with the broader orchestration observability requirement: routing systems need to log route selection, rule/version, provider, payment context and downstream outcome rather than only a success boolean.
J. Approval-rate fact-check checklist
Before publishing or operationalizing any statement such as:
“Route A approves better than Route B.”
verify:
Same merchant/entity?
Same transaction type?
Same authorization definition?
Same numerator?
Same denominator?
Same time window?
Same retry position?
Comparable issuer mix?
Comparable card/network category?
Comparable country/currency?
Comparable authentication?
Comparable fraud controls?
Comparable credential type?
Comparable transaction-value mix?
Both routes genuinely eligible?
Technical failures classified separately?
Unknown states resolved or explicitly excluded?
Sufficient sample?
Uncertainty reported?
Historical routing policy understood?
Controlled allocation or holdout available?
Selection bias addressed?
Incremental versus descriptive language correct?
Eventual payment conversion checked?
Commercial cost checked?
The brief expressly requires issuer mix, card product, country, network, recurring status, authentication, retry position, fraud blocks and technical failures to be checked in approval-routing claims.
K. Experimentation checklist
For a controlled route experiment:
Define hypothesis
Example:
For Cohort C, Route A increases authorization approval relative to Route B.
Define eligibility
Both routes must legitimately be able to process the transaction.
Define assignment
Random or otherwise controlled allocation should not be influenced by the expected outcome being measured.
Define primary metric
Prefer one documented authorization metric rather than changing denominator after results arrive.
Define secondary outcomes
Relevant examples:
technical failure;
latency;
eventual payment conversion;
cost;
fraud/dispute outcomes where sufficient maturity exists.
Predefine sample/decision rules
Avoid ending the experiment merely because one route temporarily looks ahead.
Retain holdout after launch where justified
Especially if routing becomes adaptive.
Version the production policy
Know exactly which measured result led to which routing change.
The brief explicitly recommends randomized allocation, matched issuer analysis, controlled holdouts, pre/post controls and shadow evaluation where appropriate, with the objective of measuring incremental effect rather than correlation after routing.
L. Routing feedback-loop warning
Approval routing deserves a specific monitoring alert:
Route-concentration loop
Route A performs better
→ traffic shifts to A
→ B loses sample
→ B estimate becomes stale/noisy
→ router grows more confident in A
→ B stops receiving enough traffic to prove it has improved.
Monitor:
route concentration;
sample per candidate route;
age of alternative-route evidence;
holdout volume;
re-entry after outages/performance changes.
Do not allow the system's traffic allocation policy to destroy the evidence required to evaluate its own alternatives. The brief explicitly identifies this feedback-loop problem.
M. Provider-specific verification checklist
For each PSP/acquirer being used for approval routing, verify current:
Route eligibility
merchant entities;
countries;
currencies;
card networks;
card products;
recurring transactions;
authentication requirements;
merchant-category restrictions.
Authorization data
response fields;
issuer/network response visibility;
technical error codes;
timeout behavior;
provider-generated decline categories;
retry guidance.
Routing data
BIN/IIN or issuer information available before authorization;
network information;
tokenized-card implications;
route decision data;
route override/configuration.
State
pending/unknown authorization handling;
status retrieval;
asynchronous updates;
reversals.
Analytics
raw authorization attempts;
provider technical failures;
comparable denominator support;
downloadable event-level data;
route attribution.
The brief's provider checklist requires this type of product-specific verification before recommending an orchestration platform or routing implementation.
N. Failover boundary
Approval degradation should not automatically trigger failover.
Separate:
Performance routing
Route B is preferred because credible comparable evidence indicates better authorization performance.
from:
Technical failover
Route A cannot reliably execute the intended payment, so an alternative eligible route may be required.
The latter has additional requirements:
original transaction state;
timeout resolution;
duplicate-payment risk;
idempotency;
authentication;
credential eligibility;
retry/network/provider rules.
The brief explicitly distinguishes technical availability from payment performance and warns that routing away based on observed approval deterioration can itself create feedback loops.
Keep the implementation details in Payment Failover.
O. Token/authentication fact-check boundaries
Tokens
For recurring/stored-credential populations, verify whether both compared routes can legitimately process the same credential.
Do not compare:
PSP A's eligible stored-card population
against:
PSP B's smaller subset of customers whose tokens happen to be portable
without recognizing that selection.
Token portability itself belongs in the appropriate credential/token content. The orchestration brief warns that provider abstraction does not automatically make credentials portable.
Authentication
When route cohorts have different 3DS/authentication treatment, record it.
EMVCo documents that EMV 3DS exchanges contextual information with issuers for authentication/risk assessment and that different authentication experiences can occur.
Do not attribute the resulting authorization difference solely to the PSP without controlling for authentication treatment.
P. Cost fact-check boundary
If the final article adds numerical route economics, verify:
PSP/acquirer markup;
interchange effects where applicable;
network/scheme costs;
fixed transaction charges;
cross-border costs;
currency conversion;
failed-attempt cost;
orchestration/platform cost.
Do not rank routes using headline PSP markup alone.
The dedicated Routing by Cost article should own the full economics methodology.
Q. Regulatory/network-rule flags
Approval routing can interact with:
acquiring contracts;
card-network rules;
retries;
stored credentials;
authentication;
merchant entity;
payment method;
jurisdiction.
For consequential operational recommendations distinguish:
law/regulation
from:
network rule
from:
provider/acquirer contract
from:
merchant routing policy.
Do not infer that a statistically attractive route is legally, contractually, technically, or network-eligible.
R. Amber-flag claims
Require real, scoped evidence before publishing:
“PSP A has the highest approval rate.”
“Route A improves approvals by X%.”
“Smart routing increases authorization.”
“Issuer routing increases approval.”
“Dynamic routing automatically chooses the best route.”
“A provider decline should be retried through another PSP.”
“3DS improves approval rates.”
“The highest-approval route produces the highest conversion.”
“Historical approval rates prove future incremental lift.”
“A small segment with the highest observed rate should receive more traffic.”
Whether routing is formally productized or service-operated.
Whether merchants can configure routing rules.
Which providers/acquirers are eligible.
Which countries are eligible.
Which merchant entities are eligible.
Which card networks.
Which currencies.
Whether routing can use issuer country.
Whether routing can use BIN/IIN.
Whether routing can use issuer identity.
Whether tokenization affects issuer visibility.
Whether routing can use historical approval.
Whether routing can use real-time/recent approval.
Exact authorization denominator.
How provider technical failures are classified.
How authentication failures are classified.
Whether first attempts and retries are separated.
Whether failover attempts are separated.
Whether fraud blocks are excluded from issuer approval metrics.
Whether comparable traffic normalization exists.
Whether minimum sample requirements exist.
Whether uncertainty/confidence controls exist.
Whether controlled traffic allocation exists.
Whether randomized experiments are supported.
Whether holdout traffic is maintained.
Whether exploration traffic exists in dynamic routing.
Whether dynamic approval routing exists.
If so, whether it is rules-based, statistical, ML-based or hybrid.
Whether route changes are versioned.
Whether merchant overrides exist.
Whether rollback exists.
How performance feedback loops are controlled.
What route-observability fields merchants receive.
Whether issuer-level performance is merchant-visible.
Whether route decision reasons are exposed.
Whether routing latency is measured.
Whether cost is included as a constraint.
Whether approval-routing decisions consider payment conversion.
Whether recurring/stored credentials are route-compatible.
Whether 3DS/authentication treatment is controlled across routes.
Whether an approved incremental approval result exists.
Exact cohort and experiment methodology for any such result.
Whether any details are proprietary and should remain unpublished.
T. Supporting visual
Primary visual: Approval Routing Measurement Framework.
Avoid a graphic with:
PSP A 94% → winner
PSP B 88% → loser
unless the purpose is explicitly to show why that comparison is misleading.
A stronger opening graphic is:
RAW DASHBOARD
A — 94%
B — 88%
↓
WHAT THE DASHBOARD HIDES
A traffic: repeat / domestic / first attempt
B traffic: first-time / international / retries
↓
QUESTION
What would happen on comparable traffic?
That visually communicates the article's information gain immediately.
Alt text
Approval Routing Measurement Framework showing comparable eligible payment traffic being allocated across two payment routes, with issuer and card mix normalized before estimating incremental authorization approval and commercial impact.
U. Structured-data recommendation
Use Article structured data with accurate:
headline;
author;
datePublished;
dateModified;
publisher;
image.
Do not add FAQ markup merely to gain more query coverage.
The Approval Routing Measurement Framework, measurement definitions and controlled-allocation methodology provide much stronger original information value for this advanced search intent.
V. Cluster sameness audit
Field
Routing by Approval Rate
Cluster article
Article 8
Intellectual starting point
A 94% PSP may not outperform an 88% PSP on comparable traffic
Opening device
Reveal hidden traffic mix behind apparently obvious provider ranking
Merchant operating problem
Provider averages are used as routing evidence without comparability
Architecture layer
Routing measurement/control layer
Routing input
Authorization performance
Primary failure mode
Routing-induced selection bias
Evidence anchor
Routing changes provider denominators
Editorial position
Approval routing is measurement before optimization
Primary distinction
Observed performance ≠ incremental uplift
Other distinctions
Authorization ≠ conversion; technical failure ≠ issuer decline; first attempt ≠ retry; global ≠ segment performance
Primary format
Measurement framework
Original asset
Approval Routing Measurement Framework
Primary metric
Incremental approval effect on comparable eligible traffic
Supporting metrics
Holdout performance, issuer-level approval, retry position, eventual payment conversion
Technical risk
Feedback loop sends more traffic to a noisy or biased winner
Statistical risk
Small samples / policy-generated data
Operational boundary
Performance routing ≠ failover
Authorization boundary
Routing comparison ≠ general decline optimization
Issuer boundary
Measurement foundation only; Routing by Issuer owns issuer-selection mechanics
Cost boundary
Commercial check only; Routing by Cost owns economics
Conclusion
Fix the denominator before optimizing the route
Does not own
Multi-signal intelligent routing, rules-vs-dynamic methodology, issuer routing architecture, route cost optimization, failover implementation, general authorization optimization
That keeps the article exactly in its assigned territory: approval performance as a routing objective and, critically, the causal measurement required before historical approval differences are allowed to drive production traffic.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗