Routing by Cost

Payment Routing by Cost: How to Choose the Cheapest Route Without Losing More Valuable Payments

Provider A costs 1.5%.

Provider B costs 1.8%.

Which route is cheaper?

There is not enough information to answer.

If Provider A successfully completes materially fewer comparable payments, the 30-basis-point saving can disappear quickly. If its pricing excludes a fee incurred elsewhere in the route, it may never have been 30 basis points cheaper to begin with. If foreign-exchange or cross-border economics differ, the quoted PSP rate may describe only one component of the payment cost. And if routing itself introduces another platform charge, that belongs in the calculation too.

The mistake is the denominator.

Merchants often compare:

cost ÷ payment attempt

when the commercial objective is closer to:

cost required to produce a successful payment outcome.

That leads to the central principle of payment routing by cost:

The cheapest payment route is not necessarily the route with the lowest quoted processing rate. It is the route that produces the required payment outcome at the best acceptable economics for the merchant.

Cost can be an important routing input.

But routing should not optimize a price field while ignoring what the merchant receives in return.

•The cheapest route can have the wrong denominator

Suppose two routes are genuinely eligible for the same transaction population.

For illustration only:

Route

Average relevant cost per eligible attempt

Successful-payment rate

Route A

$1.50

87%

Route B

$1.80

91%

At first glance, Route A looks cheaper.

But if those costs are genuinely measured per eligible attempt, then:

Route A

$1.50 ÷ 0.87 ≈ $1.72 per successful payment

Route B

$1.80 ÷ 0.91 ≈ $1.98 per successful payment

On that narrow cost-per-success metric, A remains cheaper.

But the commercial question still is not finished.

Imagine the merchant earns $25 of contribution when a payment succeeds.

Per 1,000 eligible attempts:

Route A

870 successful payments × $25

= $21,750 contribution before route costs

Route costs:

1,000 × $1.50

= $1,500

Illustrative net contribution:

$20,250

Route B

910 successful payments × $25

= $22,750 contribution before route costs

Route costs:

1,000 × $1.80

= $1,800

Illustrative net contribution:

$20,950

Under those hypothetical assumptions, the “more expensive” route produces $700 more contribution per 1,000 eligible attempts.

The answer changes because the objective changed from:

Which payment attempt costs less?

to:

Which route leaves the merchant with more commercial value?

That is the foundation of outcome-adjusted cost routing.

These figures are illustrative only. Real routing analysis must use the merchant’s actual cost model, transaction population, margins, provider economics, and payment outcomes.

•Start with eligibility, not cost

Cost should never be the first routing filter.

Before comparing economics, determine whether each path can actually process the transaction correctly.

Potential eligibility constraints include:

•Merchant entity

•Customer or issuer geography

•Acquirer relationship

•Payment method

•Currency

•Card network

•Transaction type

•Recurring-payment support

•Authentication requirements

•Merchant category

•Provider availability

•Credential/token usability

•Contractual or regulatory restrictions

Conceptually:

PAYMENT

↓

ELIGIBILITY

↓

VALID ROUTES

↓

COST / PERFORMANCE ANALYSIS

↓

SELECTED ROUTE

An ineligible route does not become usable because it is cheaper.

And a route that cannot support the required payment lifecycle should not participate in the cost comparison at all.

•“PSP price” is not the same thing as route cost

A quoted PSP markup is only one possible component of card-payment economics.

Mastercard explicitly notes that interchange is one component of the Merchant Discount Rate charged in the acquiring relationship, rather than the entire merchant price. Its published U.S. guidance also distinguishes domestic U.S. interchange from interregional transactions involving non-U.S.-issued cards.

Visa's current U.S. interchange schedules similarly contain numerous combinations of percentage and fixed components that vary by program and transaction qualification rather than one universal card-processing rate.

For routing analysis, a merchant may therefore need to consider some combination of:

Interchange

Where applicable under the pricing/acquiring model.

Network or scheme fees

Relevant card-network costs attributable to the transaction.

Acquirer cost

Charges associated with the acquiring route.

PSP markup

Provider-specific processing charge.

Fixed transaction fee

Especially important at low average ticket sizes.

Cross-border components

Where the acquiring/issuer/merchant configuration creates additional cost.

Currency conversion

If the route introduces FX that another eligible route avoids.

Orchestration/routing cost

If the routing infrastructure itself is priced per transaction, per attempt, by volume, or another model.

Failed-attempt cost

Fees or operational costs attributable to attempts that do not become successful payments.

Not every merchant pays each item separately.

Pricing structures differ.

The point is not to invent a universal fee stack. It is to model the actual marginal economics of the route the merchant is deciding between.

•Why underlying card economics matter

Consider a routing engine choosing between two acquirers.

The PSP markup may differ by only a few basis points.

But the transactions may qualify differently because of factors such as:

•Card type

•Merchant category

•Geography

•Transaction characteristics

•Applicable interchange program

Current Visa rate schedules demonstrate just how granular interchange structures can be; rates vary across transaction programs, card products, merchant categories, and qualification conditions.

Mastercard likewise describes interchange as only one component of the merchant discount rate and publishes separate schedules and eligibility criteria for the rates that may apply.

That means:

Route A has a lower PSP markup

does not necessarily imply:

Route A has a lower total processing cost.

Cost routing requires either:

•sufficiently complete pre-transaction cost information to make a useful routing estimate, or

•an estimated cost model derived from historical reconciled economics.

The routing engine should not optimize a fee it can see while ignoring material costs it cannot.

•Quoted cost and realized cost are different

A merchant can calculate route economics at several levels.

Quoted route cost

What the commercial agreement says the provider charges.

Useful for:

•Initial modelling

•Negotiation

•Static routing configuration

But incomplete when actual cost depends on transaction mix.

Estimated transaction cost

What the merchant expects a particular transaction to cost before routing.

Potential inputs:

•Amount

•Card/network category

•Geography

•Currency

•Acquiring path

•PSP pricing

Useful for routing.

But still an estimate.

Realized transaction cost

What the merchant can establish after provider, network, fee, and settlement data become available.

Useful for:

•Validating routing logic

•Updating models

•Finance

•Provider negotiation

A robust cost-routing system should compare:

expected economics at decision time

with:

realized economics after processing.

Otherwise the merchant cannot tell whether its cost model is accurate.

•Fixed fees make ticket size matter

Percentage pricing is easy to compare.

Fixed costs complicate the decision.

Suppose, hypothetically:

Route A

1.5% + $0.20

Route B

1.7% + $0.05

For a $5 transaction:

Route A:

$0.275

Route B:

$0.135

For a $500 transaction:

Route A:

$7.70

Route B:

$8.55

The nominally higher percentage can therefore be cheaper for lower-value transactions because the fixed component changes the economics.

This is one reason cost-routing logic may legitimately use transaction value.

But the merchant should calculate the actual breakpoints using its real commercial terms rather than copying a generic threshold.

•Cross-border cost can change the preferred route

International payment architecture can change route economics materially.

A transaction might differ depending on:

•Merchant entity

•Acquirer location

•Issuer geography

•Processing relationship

•Currency

•Settlement setup

Mastercard's current U.S. interchange documentation distinguishes U.S. domestic and interregional interchange categories, illustrating that geography can change underlying card economics.

More broadly, cross-border payment systems involve additional complexity because payments can cross currencies, infrastructures, and institutional arrangements. Current ECB and BIS work continues to treat cross-border payment cost and efficiency as a distinct policy and infrastructure problem rather than assuming that international transactions behave economically like domestic ones.

For routing, however, do not jump from:

cross-border can cost more

to:

always route locally.

The alternative route might introduce:

•Different PSP fees

•Different approval performance

•Different settlement

•Another currency conversion

•Platform costs

The correct comparison is between the actual eligible routes.

•FX can turn a cheap processing route into an expensive commercial route

Payment cost and foreign exchange should not be analyzed independently when route choice changes currency handling.

A route might have:

•Lower processing markup

but require:

•Currency conversion that another route does not

or create:

•Different presentment/settlement currency relationships.

For every cost-routing candidate, identify:

Customer pays: currency A

Provider processes: currency B, if different

Merchant settles: currency C, if different

Then determine:

•Who performs the conversion?

•At what commercial terms?

•Is there a spread or explicit fee?

•Would another eligible route avoid the conversion?

•Does Finance want to retain the settlement currency?

Do not collapse FX into the PSP percentage unless the merchant's pricing model genuinely includes it.

•Failed attempts have economics too

The payment industry tends to organize pricing around successful financial transactions.

Routing systems operate on attempts.

That difference matters.

A failed payment can still consume:

•Provider/API resources

•Fraud checks

•Authentication

•Routing calls

•Engineering/operations capacity

and, depending on the commercial arrangement, may incur explicit payment-related charges.

The exact fee treatment depends on the provider and payment method and must be verified contractually.

But even when a failed attempt carries no explicit PSP transaction charge, it can still have an opportunity cost:

The customer did not successfully pay.

This is why a route that is five basis points cheaper but meaningfully worse for otherwise comparable payments may reduce merchant economics rather than improve them.

•Cost per attempt versus cost per successful payment

These metrics answer different questions.

Cost per eligible attempt

eligible payment attemptsrelevant route cost​

Useful for understanding:

•Routing/platform burden

•Attempt-level economics

Cost per successful payment

successful paymentsrelevant route cost​

Useful for understanding:

How much route cost was required to generate one successful payment?

This denominator can be much more useful for route comparison when approval or completion differs.

But even cost per success is not always the final commercial metric.

Why?

Because two successful payments may create different merchant contribution depending on:

•Order value

•Gross margin

•Product

•Market

•Refund likelihood

•Fraud/dispute outcome

That leads to the next layer.

•Processing cost versus merchant contribution

A cost-routing engine can minimize payment cost and still reduce profit.

Suppose the cheaper route saves:

$0.20 per eligible payment

but results in:

four fewer completed $100 orders per 1,000 attempts.

Whether that tradeoff is rational depends heavily on merchant margin.

For a low-margin business, the incremental payment cost of a higher-performing route can matter substantially.

For a high-margin digital service, one additional successful order might justify a significantly higher routing cost.

The merchant therefore needs to decide what routing is actually optimizing.

Possible objectives include:

Minimize payment processing cost

Appropriate in some contexts.

Minimize cost per successful payment

Better when route success differs.

Maximize net contribution

Potentially better when the merchant can accurately model transaction economics.

This article's position is not:

Every router should maximize profit transaction by transaction.

That can require more data, modelling, governance, and margin information than is practical.

The point is:

Do not optimize processing cost without understanding the commercial outcome being traded away.

•The Route Cost Function

A useful merchant model begins with the estimated marginal economics of each eligible route.

One conceptual formulation is:

Cr​=Cprocessing​+Cfixed​+Ccross−border​+CFX​+Crouting​+Cother​

where Cr​ is the expected relevant route cost per eligible attempt.

Then incorporate expected payment success:

CPSr​=P(success∣r)Cr​​

where:

•CPSr​ = expected cost per successful payment

•Cr​ = relevant route cost per eligible attempt

•P(success∣r) = estimated successful-payment probability for that route and comparable transaction population

For a fuller commercial comparison:

Expected Contributionr​=P(success∣r)×Contributionorder​−Cr​

This is the Route Cost Function.

It should not be interpreted as a universal formula.

Different merchants may include:

•Fraud loss

•Dispute cost

•Refund economics

•Settlement/FX effects

•Routing-platform fees

when those dimensions are material and reliably measurable.

The model's purpose is to force a better question:

What economic result does this route produce—not merely what does the PSP charge?

•Do not double-count costs

A sophisticated-looking cost model can still be wrong.

Suppose the provider charges:

interchange + scheme fees + 40 bps markup

and the merchant's realized provider invoice already incorporates the underlying components.

If the routing model then adds:

•Provider total

•Interchange again

•Scheme fees again

it exaggerates route cost.

Every cost field should therefore have:

•Source

•Definition

•Inclusion/exclusion rule

•Currency

•Applicable transaction population

•Effective date

This is particularly important when mixing:

•Provider quotations

•Contract schedules

•Invoice data

•Scheme-rate tables

•Internal estimates

The route model should be auditable by Finance.

•Cost routing requires comparable transaction populations

Suppose historical reporting shows:

PSP A

Average cost: 1.6%

PSP B

Average cost: 1.9%

It is tempting to route everything to A.

But A might receive:

•Domestic debit transactions

while B receives:

•Cross-border premium cards.

The cost difference may reflect transaction mix rather than provider economics.

The same selection-bias problem appears when comparing approval performance.

Therefore cost comparison should segment where relevant by:

•Merchant entity

•Market

•Issuer geography

•Card/network category

•Currency

•Transaction value

•Payment method

•Authentication

•Recurring status

•Cross-border/domestic status

Cost needs a denominator.

It also needs a comparable population.

•Segment-level routing is usually more defensible than one global “cheapest PSP”

Payment economics are rarely uniform across the merchant's full portfolio.

A provider may be cheaper for:

•Domestic debit

while another is cheaper for:

•Cross-border credit

and another may be economically attractive for:

•High-ticket payments.

So instead of:

PSP A is our cheapest provider.

the analysis may reveal:

PSP A has the best observed route economics for eligible domestic debit transactions in Segment X during the measured period.

That sentence is less exciting.

It is also much more useful.

•Cost routing must account for probability estimates carefully

The Route Cost Function depends on P(success∣r).

That probability cannot be taken casually from each provider's dashboard.

Suppose:

Route A

Historical approval: 92%

Route B

Historical approval: 87%

If routing already sent easier transactions to A, the difference is partly created by the router itself.

Then:

P(success∣A)=92%

is not necessarily a valid estimate of:

What would have happened if this same transaction went to A instead of B?

That requires controlled comparison.

Where material, use approaches such as:

•Randomized traffic allocation

•Controlled holdout

•Matched comparable cohorts

•Appropriate historical controls

This deeper causal problem belongs primarily in Routing by Approval Rate.

For cost routing, the rule is:

Do not feed biased success estimates into an economic model and call the output optimized cost.

•Approval and payment completion are not interchangeable

For cards, approval can be a useful route metric.

But approval is not necessarily the complete merchant outcome.

A transaction can be authorized and still fail to become a completed order because of:

•Authentication/customer-flow issues

•Capture failure

•Merchant-side errors

•Other downstream problems

For asynchronous payment methods, authorization may not even be the appropriate concept.

So choose the route success metric appropriate to the payment lifecycle.

Possible measures:

Authorization probability

For an authorization-routing problem.

Payment-completion probability

For full payment outcome.

Completed-order probability

Where checkout completion is the merchant objective.

Do not mix them.

•A more expensive route can be rational for high-value orders

Routing economics can change with transaction value.

Suppose two eligible routes have a small cost difference.

For a $10 transaction, a modest increase in approval may not justify significantly higher fixed processing costs.

For a $1,000 order, one additional successful payment can produce much larger merchant contribution.

That is why route logic can legitimately consider transaction value.

But avoid crude rules such as:

Always route high-value payments to the highest-approval provider.

High-value transactions can also have:

•Different fraud risk

•Different interchange

•Different authentication behavior

•Different issuer behavior

Value is one input.

Not a universal routing answer.

•Cost routing should optimize marginal cost, not average accounting cost

Some merchant payment expenses do not change when one transaction moves from PSP A to PSP B.

For example, an annual fixed platform fee may already be committed.

If the merchant cannot avoid it by shifting one payment, assigning a portion of that fee to every routing decision may distort the marginal decision.

Other costs do change transaction by transaction.

Useful distinction:

Marginal routing cost

Changes because this transaction uses Route A instead of B.

Fixed portfolio cost

Exists regardless of this individual route.

For transaction-level routing, marginal economics are usually the more relevant decision input.

For provider-portfolio decisions, total fixed cost belongs back in the analysis.

This distinction prevents routing logic from solving the wrong finance problem.

•Volume commitments can complicate the “cheapest” route

Commercial contracts can introduce another layer.

A provider may have:

•Volume commitments

•Minimum fees

•Tiered pricing

A route that appears marginally more expensive transaction-by-transaction could still affect a broader commercial commitment.

That does not mean routing should blindly protect contracted volume.

It means commercial constraints must be modelled deliberately if they are part of the merchant objective.

For example:

Eligibility

→ availability

→ minimum performance guardrail

→ commercial commitment constraint

→ cost optimization

This is preferable to hiding volume obligations inside undocumented routing rules.

•Cost should usually have performance guardrails

A practical cost-routing policy might say:

Among eligible, healthy routes whose payment performance remains within an approved guardrail, select the route with the lowest expected outcome-adjusted cost.

That is very different from:

Route everything to the lowest-cost provider.

Possible guardrails include:

•Minimum payment-success performance

•Maximum technical-error rate

•Maximum acceptable latency

•Authentication/customer-experience requirements

•Operational availability

•Risk constraints

Thresholds should be merchant- and segment-specific.

Do not invent universal values.

•A routing rule needs an owner and expiry date

Cost assumptions change.

Providers:

•Reprice

•Add fees

•Change minimums

Networks update schedules.

Transaction mix changes.

Acquiring relationships change.

FX changes.

A cost-routing rule created eighteen months ago may be optimizing a price that no longer exists.

Every material rule should therefore record:

•Owner

•Eligible population

•Cost model/version

•Data sources

•Objective

•Guardrails

•Effective date

•Review date

•Rollback method

Current Visa rate materials, for example, identify April 2026 effective dates, and Mastercard similarly publishes current interchange information and notes that official rates and criteria govern where discrepancies arise.

Pricing inputs require versioning.

•The routing engine should preserve why the route was selected

For every payment attempt, retain enough information to reconstruct:

•Eligible routes

•Selected route

•Cost estimate

•Cost-model version

•Expected success estimate where used

•Routing rule/version

•Provider/acquirer

•Transaction segment

•Actual outcome

•Realized cost when available

Without this record, the merchant cannot later answer:

Did cost routing actually save money?

It can only observe where payments went.

•Reconcile the predicted cost with realized cost

The routing decision occurs before the final financial record exists.

Finance learns more later.

A useful feedback loop is:

PRE-AUTHORIZATION

Estimated Route A cost

Estimated Route B cost

↓

ROUTING DECISION

↓

PAYMENT RESULT

↓

PROVIDER / ACQUIRER FEE DATA

↓

SETTLEMENT

↓

REALIZED ROUTE ECONOMICS

↓

MODEL VALIDATION

This turns routing from a static price table into an empirically testable payment-economics system.

The merchant should monitor:

Expected vs realized cost

Is the route estimator biased?

Cost per successful payment

What did completed outcomes actually cost?

Success rate

Did the route's payment performance remain within expectation?

Incremental contribution

Where measurable, did the supposedly cheaper choice improve the merchant's commercial result?

•Route-level economics must be reconciled to the provider bill

A routing engine might estimate:

1.72% expected route cost

while Finance later records:

1.91%.

Possible causes include:

•Incorrect card classification

•Cross-border qualification

•Different fee inclusion

•FX

•Fixed fees

•Provider pricing changes

•Missing network cost

•Data-mapping error

Do not merely update the average.

Investigate why the forecast and realized amount differ.

That is how the routing model becomes trustworthy.

•Latency is an economic consideration too—but usually a guardrail, not a fee

Routing through another decision layer or making sequential attempts can add latency.

That may affect customer experience.

But assigning a precise dollar cost to a few hundred milliseconds without merchant evidence is usually false precision.

Instead:

•Measure routing-decision latency

•Measure provider latency

•Observe customer/payment outcomes

•Establish operational guardrails

Then add latency into economic optimization only if the merchant has evidence connecting it to commercial outcomes.

•Failover should not be treated as cost routing

Normal cost routing selects among healthy, eligible payment paths before an attempt.

Failover addresses a different problem:

What should happen when the selected path cannot reliably complete the payment?

During a genuine provider incident, the lowest-cost route may no longer matter.

Reliability becomes the binding constraint.

Likewise, a timeout should not immediately trigger a second cheaper provider because the first payment may already have succeeded.

The dedicated Payment Failover article should own:

•Ambiguous states

•Cross-provider retries

•Idempotency

•Duplicate-payment prevention

For this article, keep the distinction:

Normal routing: optimize among eligible routes.

Failover: recover safely when the selected route is impaired.

•Cost routing is not least-cost routing at any price

The phrase least-cost routing can suggest a simple optimization:

Route=argminCost

For real merchant payment operations, a safer formulation is closer to:

Route=argmax[Expected Merchant Outcome]

subject to:

•Eligibility

•Compliance/network constraints

•Availability

•Performance guardrails

•Payment-method compatibility

•Merchant commercial rules

Cost can be a major component.

It should not automatically dominate every other component.

•The Route Cost Function in practice

A usable production model can be built in stages.

Stage 1 — Verify eligibility

Exclude routes that cannot legitimately execute the payment.

Stage 2 — Estimate route economics

For each candidate:

Processing

+ fixed fee

+ applicable cross-border component

+ FX impact

+ routing/platform marginal cost

+ other verified marginal costs

Stage 3 — Estimate payment outcome

Use an appropriate probability based on comparable traffic.

Do not blindly use global provider averages.

Stage 4 — Apply guardrails

Exclude:

•Degraded routes

•Materially underperforming routes

•Routes that create unacceptable customer or operational outcomes

Stage 5 — Compare expected commercial outcome

Use:

•Cost per success

or, where reliable:

•Expected contribution

Stage 6 — Route and record

Store:

•Candidate routes

•Cost estimates

•Decision

•Rule/model version

Stage 7 — Reconcile

Compare prediction against:

•Actual payment outcome

•Actual provider cost

•Settlement/fee data

Stage 8 — Review

Update:

•Pricing

•Performance assumptions

•Segmentation

•Guardrails

That is cost routing as an operating discipline.

•What a merchant should measure

Cost per attempt

Eligible AttemptsRelevant Route Cost​

Answers:

What does it cost to send eligible transactions through this path?

Cost per successful payment

Successful PaymentsRelevant Route Cost​

Answers:

How much route cost is required for one successful payment?

Payment success

Use the appropriate, consistently defined denominator.

Never compare one provider's authorization rate against another's completed-payment rate.

Incremental payment cost

CostRouteB​−CostRouteA​

Useful when comparing the additional cost of the higher-priced route.

Incremental successful payments

SuccessesRouteB​−SuccessesRouteA​

Use comparable populations or experiments where possible.

Incremental cost per additional successful payment

Incremental Successful PaymentsIncremental Route Cost​

This can answer an exceptionally useful merchant question:

How much are we paying for each additional successful payment produced by the more expensive route?

Then compare that amount with expected merchant contribution.

•The best routing metric may be net contribution per 1,000 eligible attempts

When the necessary merchant data exists, one useful commercial comparison is:

Net Contribution=Successful Orders×Contribution Per Order−Relevant Payment Cost

Normalize to:

1,000 eligible attempts

to make route comparisons understandable.

Example:

Metric

Route A

Route B

Eligible attempts

1,000

1,000

Successful payments

870

910

Contribution/order*

$25

$25

Gross contribution

$21,750

$22,750

Relevant route cost*

$1,500

$1,800

Illustrative net contribution

$20,250

$20,950

*Hypothetical.

Route B costs more.

It also leaves the merchant with more value under these assumptions.

That is the kind of tradeoff cost routing should reveal.

•What not to put into the routing model

More data does not automatically improve decisions.

Avoid adding factors simply because they are available.

Especially avoid:

•Estimated costs that cannot be validated

•Overly granular segments with tiny sample sizes

•Provider performance with incomparable traffic

•Historic pricing that has expired

•Arbitrary cost/performance weights

•Accounting allocations unrelated to marginal route choice

Every model input should answer:

Could changing this route actually change this economic variable?

If not, it probably does not belong in transaction-level cost routing.

•When simple cost routing is enough

Not every merchant needs expected-contribution optimization.

A simpler approach may work where:

•Eligible routes perform similarly

•Payment economics are transparent

•Approval differences are immaterial

•Few routes exist

•Traffic is homogeneous

•Routing volume is modest

Then:

Among equivalent healthy routes, choose the cheaper verified path.

can be entirely rational.

Sophistication should match the problem.

•When cost routing deserves more investment

A more advanced model becomes increasingly valuable when:

•Processing volume is high

•Small basis-point differences become material

•Multiple acquirers compete for similar traffic

•Cost differs substantially by geography or card segment

•Provider performance differs materially

•Cross-border and FX effects are significant

•Routing decisions can be tested at scale

•Finance can reconcile route-level cost accurately

At that point, a routing decision can become a meaningful unit-economics lever.

But only if the underlying data is trustworthy.

Final recommendation

Do not ask a routing engine:

Which PSP has the lowest rate?

Ask:

Among the eligible payment paths, which route produces the best acceptable commercial outcome for this transaction segment?

That requires separating:

provider markup

from:

total route economics.

It requires separating:

cost per attempt

from:

cost per successful payment.

And it requires separating:

processing cost

from:

merchant contribution.

A useful hierarchy is:

•Is the route eligible?

↓

•Is the route operationally healthy?

↓

•What is its expected relevant cost?

↓

•What is its expected payment outcome?

↓

•Does it satisfy performance/risk guardrails?

↓

•Which remaining route produces the strongest

outcome-adjusted economics?

↓

•Did realized performance and cost validate

the routing decision?

The merchant should still negotiate lower payment pricing.

It should still model interchange, network, acquiring, cross-border, FX, and provider costs correctly.

But the routing layer has a more demanding job than procurement.

Its goal is not to buy the cheapest attempt.

Its goal is to use verified cost as one signal in choosing the economically strongest eligible route for producing a successful payment.

That is the difference between routing by price and routing by cost.

This article provides general information and does not constitute legal, regulatory, financial, tax, security, network-rule, or compliance advice. Payment costs and routing eligibility vary by merchant, provider, acquirer, network, jurisdiction, transaction type, payment method, contract, and pricing structure. Merchants should verify applicable economics and requirements with qualified advisers and the relevant providers, acquirers, networks, banks, and platforms.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

The brief makes this article the cluster’s payment-economics routing article. Its purpose is not to explain payment pricing generally, and it should not turn into “always choose the cheapest PSP.” Instead, it should establish the economic denominator that routing actually needs: the commercial cost of producing a successful payment outcome for a comparable transaction—not the quoted fee attached to one attempt.

Brief interpretation

Article-owned question: When several payment routes are eligible, how should a merchant use cost as a routing signal without sending traffic to a cheaper route that produces fewer valuable completed payments?

Merchant operating problem: Finance or Payments compares PSP/acquirer price schedules and asks the routing engine to prefer whichever route has the lowest nominal rate.

Payment decision being controlled: Which eligible route should receive a payment attempt when route economics are part of the selection objective.

Architecture layer: Orchestration/routing control plane above eligible PSP/acquirer execution paths.

Routing signal: Verified marginal route economics.

Unique evidence anchor: The cheapest payment attempt is not necessarily the cheapest successful payment.

Editorial position: Cost should be optimized against successful commercial outcomes, not independently from payment success.

Common assumption challenged: “Always route to the cheapest PSP.”

Merchant decision: Does the expected saving from the cheaper route exceed the economic value lost if that route produces fewer successful payments—or introduces additional cross-border, FX, failure, or operating cost?

Original framework: Route Cost Function.

SEO, EDITORIAL & PRODUCTION ADVICE

Payment Routing by Cost: How to Find the Cheapest Payment Route

I would use a slightly more nuanced H1 while retaining “cheapest” in the title tag because it captures the likely commercial search intent.

H1

Payment Routing by Cost: How to Choose the Cheapest Route Without Losing More Valuable Payments

Meta title

Payment Routing by Cost | Cost-Based Payment Routing

Meta description

Learn how to route payments by true processing cost using PSP fees, acquiring costs, fixed fees, cross-border and FX economics, payment success, and cost per successful payment.

URL slug

/payment-routing-by-cost/

payment routing by cost

Secondary keywords

Prioritize naturally:

•cost based payment routing

•cheapest payment routing

•payment routing cost optimization

•route payments by processing cost

•PSP cost routing

•acquiring cost routing

•payment orchestration cost

•least cost payment routing

•payment route optimization

•payment processing cost routing

Related entities

•Payment orchestration

•PSP

•Acquirer

•Interchange

•Card scheme

•Network fee

•Merchant discount rate

•Cross-border fee

•Foreign exchange

•Authorization rate

•Payment success rate

•Routing engine

•Payment processor

•Merchant acquiring

Excerpt

The lowest quoted PSP rate does not necessarily produce the lowest-cost successful payment. Cost-based payment routing should compare verified route economics—including provider, acquiring, fixed, cross-border, FX, and routing costs—against the probability and commercial value of a successful payment.

Featured-snippet opportunity

Place this near the opening:

What is payment routing by cost?

Payment routing by cost selects among eligible payment paths using verified route economics such as provider and acquiring charges, fixed fees, cross-border or FX effects, and other marginal costs. A robust model also considers payment success because the cheapest attempt may not produce the cheapest successful payment.

Recommended H2 structure

•The cheapest route can have the wrong denominator

•Start with eligibility, not cost

•What route cost actually contains

•Quoted cost vs realized cost

•Why ticket size changes route economics

•Cross-border and FX cost

•Failed-attempt economics

•Cost per attempt vs cost per success

•Processing cost vs merchant contribution

•The Route Cost Function

•Cost routing requires comparable cohorts

•Segment-level payment cost

•Cost-routing guardrails

•Measuring the business case

•When simple cost routing is enough

•Final recommendation

That architecture keeps it clearly separated from the broader Payment Processing Fees and Routing by Approval Rate pieces.

Original practical asset

Route Cost Function

Recommended visual:

ELIGIBLE PAYMENT

|

v

┌────────────────────────┐

│ CANDIDATE PAYMENT PATHS│

└────────────┬───────────┘

|

┌─────────────┴─────────────┐

v v

ROUTE A ROUTE B

| |

v v

PROCESSING / PSP COST PROCESSING / PSP COST

+ FIXED FEES + FIXED FEES

+ ACQUIRING IMPACT + ACQUIRING IMPACT

+ CROSS-BORDER + CROSS-BORDER

+ FX + FX

+ ROUTING COST + ROUTING COST

| |

v v

EXPECTED ROUTE COST EXPECTED ROUTE COST

| |

÷ ÷

EXPECTED SUCCESS RATE EXPECTED SUCCESS RATE

| |

v v

COST PER SUCCESS COST PER SUCCESS

\ /

\ /

+------ GUARDRAILS -----+

|

v

EXPECTED COMMERCIAL

OUTCOME

|

v

Visual caption

The lowest route fee is only one input. Compare relevant cost with the expected probability and value of payment success.

Alt text

Route Cost Function diagram showing eligible payment routes evaluated using processing, acquiring, fixed, cross-border, FX and routing costs, divided by expected successful-payment probability and compared with merchant contribution before route selection.

Measurement scorecard

Metric

Definition

Primary use

Cost per eligible attempt

Relevant marginal route cost ÷ eligible attempts

Attempt economics

Cost per successful payment

Relevant route cost ÷ successful payments

Outcome-adjusted payment economics

Payment success rate

Successful payments ÷ properly defined eligible attempts

Cost/performance tradeoff

Incremental route cost

Cost of route B − cost of route A

Price of choosing alternative

Incremental successes

Comparable successes B − A

Performance value

Cost per incremental success

Incremental cost ÷ incremental successes

Commercial route threshold

Expected contribution

Success probability × merchant contribution − relevant cost

Commercial optimization

Expected vs realized route cost

Pre-route estimate compared with reconciled cost

Model accuracy

Route cost by segment

Economics by issuer/geography/card/method/etc.

Routing granularity

Cost model error

Difference between predicted and realized route economics

Governance

Internal-link recommendations

Payment Processing Fees

Use from the cost-component discussion.

Suggested anchor:

how payment processing fees are structured

Boundary: that article owns detailed interchange, scheme, acquiring, PSP pricing mechanics.

Routing by Approval Rate

Use where expected success enters the Route Cost Function.

Suggested anchor:

measuring approval performance across equivalent routes

Boundary: Approval Routing owns cohort design and causal authorization-performance comparisons.

Intelligent Payment Routing

Use near the multi-objective/guardrail discussion.

Suggested anchor:

combining cost with other payment-routing signals

Boundary: Intelligent Routing owns multi-signal optimization.

Routing by Country

Useful contextually from cross-border economics.

Suggested anchor:

routing payments by geographic eligibility

Do not let this article become a local-acquiring explainer.

Source recommendations

Mastercard — interchange and merchant discount rate

Mastercard's current U.S. merchant guidance is particularly useful because it explicitly states that interchange is one component of the Merchant Discount Rate rather than the entirety of merchant card-acceptance cost. It also distinguishes U.S. domestic and interregional interchange.

Use it to support the article's core distinction:

interchange ≠ total route cost.

Visa — current interchange schedules

Visa's April 18, 2026 U.S. interchange schedule demonstrates that pricing varies substantially across programs, transaction types, merchant categories, card products, qualification criteria, and fixed/percentage structures.

Do not reproduce large portions of the rate table. Use it to establish that underlying card economics cannot be represented by one universal percentage.

BIS / ECB

BIS and ECB material can support high-level discussion of cross-border payment economics and the structural complexity involved when payment systems cross currencies, intermediaries, and jurisdictions.

Do not use these sources to infer a merchant's specific PSP or acquiring cost.

Routing cost fact-check checklist

Before any route enters production cost optimization, verify:

Provider economics

•PSP markup

•Fixed transaction fee

•Monthly/minimum fees where transaction-relevant

•Volume tiers

•Failed-attempt charges

•Refund charges

•Authentication charges

•Routing/orchestration fee

Acquiring/card economics

•Interchange treatment

•Network/scheme treatment

•Acquirer markup

•Domestic vs cross-border qualification

•Card type/product effects

•Merchant category effects

Currency

•Transaction currency

•Processing currency

•Settlement currency

•FX provider

•FX rate/spread

•Conversion fee

Transaction context

•Merchant entity

•Customer/issuer geography

•Card network/product

•Transaction value

•Recurring/one-time

•Authentication treatment

Data quality

•Effective pricing date

•Currency normalization

•Source of each cost input

•Estimated vs realized

•Inclusion/exclusion rules

•Avoided double-counting

Approval-rate fact-check items

Because success probability appears in the cost function, verify:

•Numerator

•Denominator

•Same merchant/entity

•Same period

•Comparable country

•Comparable issuer/card mix

•Comparable transaction value

•Comparable authentication

•Comparable fraud controls

•Same retry position

•Technical failures treated separately

•Sufficient sample size

Do not feed raw provider dashboard approval rates into the route-cost model without checking comparability.

Routing architecture fact-check items

Verify whether the merchant's routing system can actually access, before authorization:

•Eligible PSP/acquirer paths

•Transaction amount

•Currency

•Merchant entity

•Country/issuer information where permitted

•Card/payment-method information required for cost estimation

•Current provider health

•Relevant cost model/version

Also determine whether cost data is:

•Static contract data

•Derived estimate

•Reconciled historical data

•Provider-supplied estimate

Label it appropriately.

Provider-support fact checks

Before saying Route B is economically available, verify that it supports the specific:

•Merchant entity

•Market

•Currency

•Payment method

•Card/network

•Transaction type

•Recurring model

•Authentication

•Settlement arrangement

The theoretical cheapest route is irrelevant if the merchant cannot use it.

Failover boundary checks

This article should only mention failover enough to prevent misuse of the cost model.

Verify separately before failover:

•Is the original route known to have failed?

•Is transaction state unknown?

•Could authorization have succeeded?

•Can status be retrieved?

•Is another attempt safe?

•Is another credential available?

•Is authentication portable?

•How are duplicates remediated?

Do not allow the cost router to trigger cross-provider retry merely because another path is cheaper.

Token / credential flags

Cost may suggest moving traffic to another PSP while credential architecture prevents it.

Verify:

•Credential/token type

•Provider ownership

•Merchant vault relationship

•Network token

•Eligibility on alternate provider

•Recurring-payment implications

•Authentication requirements

Do not assume every otherwise eligible route can process every stored customer credential.

Accounting and reconciliation requirements

Finance should be able to reconcile:

Merchant payment ID

→ payment attempt

→ route selected

→ provider transaction

→ fee components

→ settlement

→ realized route cost

Without this lineage, cost routing may optimize on estimates indefinitely without knowing whether savings actually occurred.

Governance requirements

Every material production cost model should have:

•Named owner

•Version

•Effective date

•Cost sources

•Currency

•Cost-component definitions

•Included/excluded fees

•Eligible transaction scope

•Performance guardrails

•Review cadence

•Rollback

•Expected-vs-realized validation

Routing rules should reference the model version used to make each decision.

Routing capability

•Which product/API provides it?

•Which providers/acquirers can participate?

•Is routing rules-based, dynamic, or both?

Cost inputs

•Which cost fields are available before routing?

•PSP markup?

•Acquirer cost?

•Network/interchange estimates?

•Cross-border status?

•FX?

•Are cost estimates merchant-specific?

Performance

•Can the router combine cost with authorization/payment-success data?

•At what segmentation?

•What sample controls exist?

•Can merchants define performance guardrails?

Observability

•Is the route choice exposed?

•Is the cost estimate exposed?

•Is rule/model version available?

•Are eligible alternative routes visible?

Reconciliation

•Are actual provider costs available?

•Can expected vs realized economics be calculated?

Governance

•Can merchants override routes?

•Are rules versioned?

•Can changes be rolled back?

Until verified, avoid statements such as:

Proposed author and reviewers

Proposed author: Payment pricing analyst, Head of Payments, or payments economist with practical multi-acquirer experience.

Primary reviewer: Finance/payment-cost specialist.

Validate:

•Cost construction

•Marginal vs fixed cost

•Contribution framework

•Reconciliation

Payments performance reviewer: Validate:

•Comparable cohorts

•Success-rate denominator

•Cost/performance tradeoff

Payments architect: Validate:

•Eligibility before optimization

•Pre-routing data availability

•Observability

•Route governance

A security reviewer is not central unless the article later expands materially into credential-routing mechanics.

First-hand contribution opportunity

The strongest original evidence would be a real, approved routing experiment that compares two genuinely eligible routes using:

•Same transaction cohort

•Actual realized costs

•Payment success

•Incremental successful payments

•Incremental processing cost

•Net contribution

A useful internal question for an expert contributor:

Have we ever discovered that the provider with the lowest quoted rate was not the lowest-cost route after failed payments, cross-border economics, FX, or payment success were incorporated?

If yes, that can become a powerful first-hand data contribution.

Do not invent the outcome.

Amber-flag claims

Require current, route-specific evidence before saying:

•PSP A is cheaper than PSP B.

•Local acquiring is always cheaper.

•Cross-border routing always costs more.

•Interchange is known exactly before authorization.

•Routing by cost reduces total payment expense.

•The cheapest route has the lowest cost per successful payment.

•Higher approval always justifies higher processing cost.

•One cost model works globally.

•FX is included in PSP pricing.

•Failed payment attempts are free.

•Orchestration always reduces payment costs.

•Cost routing improves net revenue.

Cluster sameness audit

Article: Routing by Cost

Opening device: Mathematical ambiguity—1.5% versus 1.8% cannot determine the better route without payment outcome economics.

Merchant operating problem: Routing engine optimizes quoted provider rate instead of outcome-adjusted economics.

Architecture layer: Routing control plane.

Routing signal: Verified marginal route cost.

Primary failure mode: Saving processing basis points while losing more valuable successful payments or overlooking hidden route costs.

Primary format: Route Cost Function.

Unique evidence anchor: Cheapest attempt ≠ cheapest successful payment.

Editorial position: Cost is one routing signal and should be evaluated against payment success and merchant contribution.

Common assumption challenged: Always route to the cheapest PSP.

Primary distinction: Cost per attempt vs cost per success.

Secondary distinctions: provider markup vs total route cost; quoted vs realized cost; processing cost vs contribution; marginal vs fixed cost.

Original framework: Route Cost Function.

Primary metric: Cost per successful payment.

Higher-order metric: Incremental cost per additional successful payment / expected contribution where merchant data permits.

Primary technical risk: Routing on incomplete or stale cost estimates.

Primary analytical risk: Biased route-performance estimates make a mathematically correct cost model economically wrong.

Merchant decision: Is the cheaper route still economically preferable after comparable payment-success probability and relevant route costs are included?

Conclusion: Optimize outcome-adjusted economics, not the nominal provider price.

Primary next links: Payment Processing Fees → Routing by Approval Rate → Intelligent Payment Routing.

Boundary: Does not own interchange education generally, full PSP pricing/TCO, authorization optimization, or multi-signal intelligent-routing methodology.

This gives the article a sharper position than a conventional least-cost-routing piece: Payments Pricing explains what merchants pay; Routing by Cost explains how verified payment economics become a decision variable before a transaction is sent to one of several eligible payment paths.