Card Scheme Fees Explained

Card Scheme Fees Explained: The Network Costs Between Authorization and Settlement

A merchant opens its monthly payment statement and sees:

•Interchange

•Assessment

•Cross-border assessment

•Processing fee

•Network service charge

•International fee

•Authorization-related fee

•Acquirer markup

•PSP markup

Which of those are interchange?

Which belong to Visa or Mastercard?

Which belong to the acquirer?

Which are simply the PSP's own commercial margin?

And why can two transactions with the same sale amount produce different network costs?

This is where otherwise sophisticated payment-cost analysis frequently breaks down.

Merchants learn that interchange is not the same thing as the total merchant service charge. Mastercard describes interchange as a fee paid by the acquirer to the card issuer, and Visa likewise describes interchange reimbursement as a transfer between acquiring and issuing institutions.

But that still leaves another cost layer:

The card scheme itself can levy fees for operating and providing services across the payment network.

These are commonly described as scheme fees or network fees.

And there is not one universal scheme-fee percentage.

A card transaction can attract different network-level charges depending on what occurred, where it occurred, what services were used, which network handled it, and how the network's current pricing rules classify it.

That leads to the central idea of this article:

Scheme fees are best understood as a family of network-level charges, not a single percentage added to interchange.

For merchants using Interchange++, cost-plus, or another model exposing underlying card economics, that distinction matters enormously.

If the merchant cannot separate:

interchange

from:

scheme/network cost

from:

acquirer/PSP margin

then it cannot accurately explain why card acceptance costs what it does.

The basic card-cost stack

At a high level, a card payment can create several economically distinct cost layers.

CUSTOMER

|

v

MERCHANT

|

v

PSP / ACQUIRER

|

+---- Provider / acquiring markup

|

+---- Card scheme / network costs

|

+---- Interchange transferred toward issuer

|

v

CARD NETWORK

|

v

ISSUER

That diagram is simplified.

Actual contracting and funds flows differ.

But for merchant pricing analysis, the categories are useful.

Interchange

Generally relates to issuer-acquirer economics.

Mastercard's public material describes interchange as a transaction fee paid by the acquirer to the issuer.

Scheme/network fee

A charge established by the card network under the applicable network pricing/service framework.

Acquiring fee or margin

Economics charged by the acquirer for the merchant acceptance relationship and services it provides.

PSP markup

Commercial compensation for the services the PSP provides, which may include processing, technology, acquiring access, payment methods, reporting, risk, support, settlement, or other functionality.

The same provider may perform several of these roles.

That does not make the underlying economic categories identical.

Scheme fee versus interchange

This is the most important distinction.

Suppose a €100 card transaction produces:

•Interchange: X

•Scheme/network fees: Y

•Acquirer/PSP markup: Z

Then the merchant's card cost might conceptually be:

X + Y + Z

under a sufficiently transparent pass-through structure.

Interchange and scheme fees both sit beneath the provider markup.

But they represent different economic layers.

Interchange

Connected to issuer-acquirer transaction economics.

Scheme fee

Connected to the card network and the particular network functions, services, transaction types, or geographic conditions being priced.

The European Commission explicitly treats these as separate fee categories. In explaining EU card-payment rules, it notes that acquiring contracts with retailers must identify merchant service charges, interchange fees, and scheme fees separately for each relevant card category and brand.

That regulatory distinction is useful even outside Europe as an accounting principle:

Interchange and scheme fees should not be treated as synonyms.

Scheme fee versus PSP markup

Suppose a PSP invoices:

Network fee: 0.XX%

That may represent an underlying scheme charge.

But the label alone does not establish whether it is:

•Exact pass-through

•Aggregated network fees

•Estimated network cost

•Network cost plus provider margin

•Blended approximation

The merchant must inspect the commercial agreement.

Likewise:

“Interchange + scheme fees + 25 bps”

might mean the provider passes through interchange and scheme cost and adds a 25-basis-point markup.

But different providers can define cost-plus structures differently.

Never infer exact fee ownership from the marketing name of the pricing model.

Scheme fee versus acquiring fee

The network establishes scheme charges.

The acquirer operates the merchant's acquiring relationship and may charge its own commercial margin or related fees.

These are distinct even if they are invoiced together.

That matters when a merchant negotiates.

A merchant may succeed in reducing:

acquirer margin

while underlying:

scheme cost

remains unchanged.

If the finance team compares only total effective cost, it may conclude:

The negotiation barely worked.

In reality, the merchant may have materially reduced the negotiable layer while network or interchange cost simultaneously increased because of card mix or geography.

Cost attribution is what makes the difference visible.

Why there are many scheme fees

A card network is not performing one function.

Across a transaction lifecycle, the network can participate in or support functions involving:

•Authorization messaging

•Clearing

•Settlement

•Data exchange

•Risk/security

•Tokenization

•Cross-border routing

•Currency-related services

•Product programs

•Network infrastructure

•Acceptance services

Visa's current Core Rules themselves separate areas including transaction processing, authorization, clearing, and settlement, illustrating that the network relationship consists of several operational functions rather than one monolithic service.

A network's commercial schedule can therefore contain different charges associated with different components of that ecosystem.

This is why a merchant trying to find:

“The Visa fee”

or:

“The Mastercard fee”

is starting with the wrong mental model.

There may be multiple applicable fees.

The Scheme Fee Classification

A more durable merchant framework groups scheme costs into six families.

•Volume/value assessments

Charges based principally on transaction or assessable payment volume.

•Transaction-processing fees

Charges tied to processing events or transaction messages.

•Cross-border/international fees

Charges triggered by defined geographic relationships in the card transaction.

•Currency-related network charges

Charges connected to defined currency or international-service conditions.

•Product/service-specific network costs

Charges associated with particular network services or product programs.

•Other scheme-defined charges

Additional fees established under the current network schedule that do not fit neatly into the first five categories.

This classification is more useful than memorizing today's fee names.

Names and schedules change.

The cost logic persists.

Category 1: volume or value assessments

Some network charges are assessed against payment value.

In other words:

The higher the processed value, the greater the charge.

Conceptually:

Assessment rate × qualifying transaction value

Mastercard provides a public example in Canada. Its current July 20, 2026 Network Assessment Fee document describes an Acquirer Volume Assessment alongside other transaction-based and cross-border assessments. It also demonstrates that different pricing can apply to defined transaction categories.

A merchant should not generalize the Canadian percentages to other countries.

The useful observation is structural:

a network assessment can be value-based.

Trigger

Qualifying card volume under the applicable scheme rule.

Fee owner

Card scheme/network.

Merchant visibility

Could appear as:

•Assessment

•Volume assessment

•Scheme fee

•Network fee

or could be aggregated by the provider.

Category 2: transaction-processing fees

Some scheme costs may be charged per event rather than solely as a percentage of sale value.

A network may price certain:

•Authorization messages

•Clearing activity

•Transaction processing

•Service events

through fixed or transaction-based fees depending on the applicable schedule.

Mastercard's Canadian public fee document, for example, includes specified transaction-based assessment components for particular domestic transaction categories, demonstrating that network pricing can combine percentage-based and fixed transaction charges rather than operating as a single ad-valorem rate.

For merchants, this matters especially when ticket size varies substantially.

Why fixed network charges matter more on low-ticket payments

Consider a hypothetical scheme cost of:

$0.01 per transaction

This is an illustration, not a quoted network fee.

On a:

$1 purchase

the fixed fee alone is:

1%

of transaction value.

On a:

$100 purchase

it is:

0.01%

So two merchants subject to the same nominal per-transaction network fee can experience very different effective economics.

This is why scheme-cost analysis should track both:

Scheme cost per transaction

and:

Scheme cost as percentage of processed volume

One metric is not enough.

Category 3: cross-border and international network fees

Cross-border payments can trigger additional network costs.

But “cross-border” must be defined according to the relevant scheme's rules.

It should not be inferred casually from:

•IP country

•Shipping address

•Customer nationality

Mastercard's published Canadian Network Assessment Fee documentation provides a concrete example: its Acquirer Cross-Border Assessment is tied to specified geographic transaction conditions involving merchant and cardholder country codes.

Visa likewise publicly references International Service Assessment terminology in discussion of cross-border transaction fees, though the specific merchant economic treatment needs to be verified in the relevant network/acquiring schedule.

The broad merchant lesson is:

A transaction becoming international can change network cost even when the merchant's PSP markup has not changed.

Domestic versus cross-border scheme cost

Imagine two transactions.

Transaction A

Merchant: Canada

Card: Canada

Transaction: CAD

Transaction B

Merchant: Canada

Card: another country

Transaction: CAD

The sale amount might be identical.

The provider markup might be identical.

The underlying network economics may not be.

That means a merchant expanding internationally can experience a rising effective card rate even though it never renegotiated its PSP pricing.

The driver could be:

traffic mix.

Not provider margin.

Cross-border share should therefore be a finance metric

Track:

Cross-border scheme cost rate

Cross-border-related scheme cost

÷ relevant cross-border processed value

× 100

and:

Cross-border scheme cost per transaction

Relevant cross-border scheme cost

÷ relevant cross-border transaction count

Segment where possible by:

•Card brand

•Merchant entity

•Acquirer

•Issuer/card geography

•Currency

•Market

Do not blend domestic and international traffic and then ask why the “Visa cost” changed.

Category 4: currency-related network charges

Currency can affect payment cost in several distinct ways.

Possible layers include:

•Network-defined international/currency fee

•PSP FX fee

•Acquirer FX

•Settlement conversion

•Customer issuer foreign-transaction fee

Those should not be conflated.

A network-related international-service fee is not the same thing as:

the merchant's settlement FX spread.

And neither is the same thing as:

the cardholder's bank charging a foreign transaction fee.

This article owns only the network cost layer.

The Currency & Pricing cluster should own detailed FX mechanics.

The merchant needs to know who converted what

Consider:

Customer pays: EUR

Merchant settlement: USD

Possible costs might arise from:

•Card-network transaction characteristics

•Scheme international/cross-border fees

•Acquirer or PSP FX conversion

•Settlement FX spread

The statement may show several of these close together.

Do not label all of them:

scheme fee.

The finance team should identify:

•Fee owner

•Currency event

•Calculation basis

for each line.

Category 5: product- or service-specific network costs

Networks offer more than authorization and settlement rails.

Services may involve areas such as:

•Digital commerce

•Credentials

•Token-related infrastructure

•Authentication/security

•Data services

•Acceptance services

The network may establish specific commercial terms around such services.

For example, Visa's May 2026 merchant-business update describes its Visa Credential Enrichment Service as covered within Digital Commerce Service Fees for specified token requestors from an October 2026 effective date rather than as a separate extra product charge.

The important lesson is not the particular service.

It is that:

Some network costs are tied to particular products or service bundles rather than simply transaction value.

A merchant should therefore not assume every network-fee line can be explained from:

sales volume × one rate.

Category 6: other scheme-defined charges

Networks can introduce, retire, modify, combine, or rename programs.

That is why an article that attempts to publish:

“Every Visa and Mastercard fee”

becomes stale quickly.

Visa's current public Core Rules are dated April 18, 2026, while Mastercard's current public Rules are dated June 2, 2026, underscoring that network standards continue to evolve.

Fee schedules can evolve as well.

A merchant should maintain an internal category:

Other scheme-defined charge

until finance/acquiring operations can determine:

•What triggered it

•Which network owns it

•Which merchant population incurred it

•Whether it is pass-through

Do not dump unexplained fees permanently into “miscellaneous.”

The Scheme Fee Classification

Classification

Typical trigger

Underlying owner

Possible merchant presentation

Volume/value assessment

Qualifying card value

Network

Assessment / network fee

Transaction-processing

Message or transaction event

Network

Processing / authorization / transaction fee

Cross-border/international

Defined geographic relationship

Network

Cross-border / international assessment

Currency-related network

Defined currency/international condition

Network

International/currency/network service fee

Product/service-specific

Use of defined network service

Network

Product/service/network charge

Other scheme-defined

Scheme-specific rule/program

Network

Other network/scheme fee

The final column is intentionally non-prescriptive.

Provider invoices do not use one universal naming convention.

Official fee schedule versus merchant invoice

This distinction is critical.

The scheme establishes the underlying fee framework.

The merchant may receive its bill from:

•Acquirer

•PSP

•Processor

Those businesses can present network costs differently.

Provider A might show:

Mastercard network fees — $18,432

Provider B might show:

•Mastercard assessment

•Cross-border assessment

•Processing fee

•Connectivity/service fee

Provider C might include those costs inside:

blended card rate

All three can produce different levels of merchant visibility.

That means:

Absence of a scheme-fee line does not necessarily mean the merchant has no underlying scheme cost.

It may be embedded in the commercial rate.

Pass-through pricing makes scheme fees more visible

In an Interchange++ structure, the merchant will often see some version of:

Interchange

•Scheme/network fees

•Provider/acquirer markup

The precise definition of each plus sign depends on the contract.

But that architecture generally exposes more of the underlying cost variability than a fully blended rate.

This can help merchants analyze:

•Card mix

•Geography

•Network cost

•Cross-border effects

It also creates more statement complexity.

That deeper packaging comparison belongs in Blended Pricing vs Interchange++.

The takeaway here is:

If scheme fees are passed through, finance needs to understand what is being passed through.

Blended pricing does not make scheme cost disappear

Imagine the provider charges:

2.7%

for a transaction population.

The merchant may not receive:

•interchange

•assessment

•cross-border

•processing

as separate lines.

The provider can still face those underlying costs.

It has simply priced the merchant through a blended rate.

That means a merchant should not compare:

2.7% blended

with:

interchange + scheme fee

and assume the second proposal is more expensive because it contains more lines.

The missing component is provider markup.

Normalize both proposals before comparing them.

Scheme fees are often much harder to negotiate directly

A merchant can frequently negotiate commercial layers such as:

•PSP markup

•Acquirer margin

•Fixed provider fee

•Volume tiers

depending on bargaining power and contract.

The merchant generally has much less direct control over an underlying network fee established by the scheme.

That does not make scheme cost irrelevant to cost optimization.

Instead, the merchant can sometimes influence exposure to it through variables such as:

•Acquiring model

•Traffic geography

•Payment method

•Routing

•Transaction design

where commercially, operationally, and contractually appropriate.

Those choices should not be made solely to reduce scheme cost.

They can also affect:

•Authorization

•Settlement

•Complexity

•Risk

The wrong negotiation question

Weak question:

Can you reduce our Visa scheme fee?

Better questions:

•Which network costs are pure pass-through?

•Which are bundled?

•Which fee schedules govern them?

•Are any network charges marked up?

•Can we see transaction-level or monthly attribution?

•What changed when network cost increased?

•Does the proposed acquiring structure change cross-border exposure?

•Can we validate the provider's invoiced network fees against our transaction mix?

This moves negotiation from:

lower this mysterious number

to:

show us the economic structure.

How a merchant should analyze scheme fees

Start with the statement.

Extract every line that appears plausibly network-related.

Example:

Visa assessment

Mastercard assessment

International assessment

Cross-border charge

Authorization processing

Network service

Digital commerce fee

Other scheme charge

Do not assume the labels are correct classifications yet.

Then map each line into the Scheme Fee Classification.

Step 1: identify the network

Record:

•Visa

•Mastercard

•Other relevant scheme

Do not aggregate them initially.

Fee programs differ.

Step 2: identify the calculation basis

For each line determine whether it is:

Percentage of value

Example:

rate × transaction volume

Fixed per transaction/message

Example:

amount × transaction count

Monthly/fixed

Example:

fixed service amount

Conditional

Example:

Only if transaction meets cross-border criterion.

A fee cannot be modeled correctly if its denominator is unknown.

Step 3: identify the triggering condition

Questions include:

•Domestic or international?

•Card present or card not present?

•Currency condition?

•Card/product class?

•Authorization event?

•Clearing event?

•Particular network service?

•Geographic corridor?

If the provider cannot explain the trigger, flag the charge for reconciliation.

Step 4: determine whether it is actually pass-through

Ask the PSP/acquirer:

•Is this the scheme's exact fee?

•Is it aggregated?

•Is there provider markup within this line?

•Which fee schedule/effective date applies?

•Are rebates or adjustments reflected?

•Is there a lag between transaction date and invoicing?

This is especially important under pricing described as cost-plus.

Step 5: reconcile the charge to transaction data

A merchant should eventually be able to answer:

Why did scheme cost rise 14% when processed value rose only 5%?

Possible explanations might include:

•More cross-border cards

•More low-ticket transactions

•Different network/card mix

•New network fee

•Changed currency mix

•More authorization attempts per successful payment

•Provider classification change

Without transaction-level or sufficiently granular data, the answer remains speculation.

Scheme cost per transaction

Scheme cost per transaction

Total identified scheme/network cost

÷ relevant card transaction count

Use this to spot:

•Per-message cost

•Low-ticket sensitivity

•Brand differences

•Change over time

Do not use it alone for high-ticket merchants.

Scheme cost as percentage of volume

Scheme cost rate

Total identified scheme/network cost

÷ relevant processed card value

× 100

This helps normalize merchant growth.

If:

•Volume increases 50%

•Scheme cost increases 50%

the effective scheme rate may be unchanged.

If scheme cost increases 80%, investigate mix.

Cross-border scheme cost

Cross-border scheme-cost rate

Identified cross-border network charges

÷ relevant cross-border card volume

× 100

Segment where possible by:

•Network

•Card geography

•Acquirer

•Merchant entity

•Transaction currency

This is more useful than:

cross-border fee ÷ all company volume.

Scheme cost by card brand

Where the data permits:

Network cost by brand

Identified scheme cost for brand

÷ corresponding brand processed value

Compare over time rather than reflexively declaring one network cheaper.

Traffic mixes may differ.

For example:

•Network A could receive more cross-border commercial cards.

•Network B could receive more domestic debit.

The raw fee rate would not be comparable.

Authorization attempts can influence network economics

A merchant usually focuses on:

successful transactions.

But network activity can occur before success.

Suppose 1,000 completed purchases require:

1,350 authorization attempts

because of:

•Retries

•Duplicate submission

•Fallback

•Technical errors

If relevant processing fees apply to authorization events, the merchant's cost economics can deteriorate even though completed transaction count is unchanged.

That makes:

Network cost per completed order

potentially more useful than:

Network cost per authorization.

This does not mean all authorization attempts universally generate the same scheme charge.

Verify the applicable schedule.

Failed attempts belong in cost analysis

A merchant can have:

Provider A:

lower nominal network/pass-through cost

but:

•more retries

•more authorization attempts

•poorer payment completion

Provider B:

slightly higher nominal fee

but:

•fewer failed attempts

•more completed orders

The right comparison is not simply:

scheme fee per transaction.

It may be:

Total payment cost per completed order

This includes scheme cost as one component.

The cluster pillar should own the full methodology.

Cross-border expansion can make scheme fees look like provider inflation

Suppose the merchant's business changes from:

90% domestic / 10% cross-border

to:

50% domestic / 50% cross-border

without changing its PSP contract.

Its effective processing cost may rise.

Finance may conclude:

PSP fees increased.

But a better cost bridge could show:

Prior period network cost

+ transaction growth

+ cross-border mix change

+ card-brand mix change

+ new/changed scheme programs

= current network cost

Only after that should the merchant examine whether provider margin changed.

Build a scheme-cost bridge

For month-over-month analysis:

Starting scheme cost

Prior period.

Volume effect

What cost would have changed purely because card value increased?

Transaction-count effect

What changed because transaction count changed?

Geography effect

What changed because domestic/cross-border mix changed?

Brand/product effect

What changed because network/card mix changed?

Currency effect

Where applicable.

Fee-schedule effect

What changed because scheme pricing itself changed?

Residual

Unexplained difference requiring reconciliation.

This is far more useful than:

Network fees increased 12%.

Hypothetical statement walkthrough

Assume a merchant statement contains:

Line

Amount

Interchange

$81,000

Visa assessment

$6,000

Mastercard network charges

$4,500

International assessment

$3,300

Acquirer markup

$14,000

Gateway

$2,000

These are entirely illustrative.

Do not treat them as live rates.

A good classification is:

Interchange

Issuer-acquirer economic layer.

Visa assessment

Potential scheme/network layer.

Mastercard network charges

Potential scheme/network layer.

International assessment

Likely network or acquiring cross-border cost—but verify exact owner.

Acquirer markup

Acquirer commercial layer.

Gateway

Technical/provider service layer.

The lesson is not the numbers.

It is that:

Five payment-cost lines should not be called interchange merely because all appear on a card statement.

Merchant cost waterfall

For a transparent card transaction, the finance model can conceptually use:

Gross card payment value

|

v

Interchange

|

v

Scheme/network costs

|

v

Acquirer cost / margin

|

v

PSP / processing markup

|

v

Other applicable payment costs

|

v

Merchant net economics

Do not interpret this diagram as literal settlement ordering.

It is an economic classification, not a universal funds-flow diagram.

What scheme fees can tell a merchant about architecture

An increase in network cost can reveal something about the merchant's payment mix.

For example:

Rising cross-border scheme charges

May indicate more international issuer traffic or a different acquiring configuration.

Rising fixed network cost per completed order

May indicate more authorization attempts or smaller average ticket.

Rising product/service network charges

May reflect increased usage of specific network services.

Different network cost by provider

May reflect:

•Acquirer

•geography

•card mix

•provider reporting

•route structure

Do not assume provider markup caused every difference.

What scheme fees cannot tell you

Scheme-cost analysis alone cannot answer:

•Whether authorization is good

•Whether the acquirer is optimal

•Whether provider support is adequate

•Whether local methods should be added

•Whether the merchant should change PSP

•Whether the cheapest route produces highest contribution

Scheme cost is a cost layer.

It is not the complete payment strategy.

Scheme-fee optimization should never ignore approval

Suppose Route A produces:

Lower scheme cost

but also lower authorization.

Route B produces:

Higher scheme cost

and more completed orders.

A useful commercial model is:

Net contribution per 1,000 eligible payment attempts

not:

Scheme bps.

The merchant may rationally pay higher network/acquiring costs if the route creates enough additional successful payments.

That belongs in the broader cost-performance analysis.

Scheme fees and local acquiring

Local acquiring can sometimes alter the domestic/cross-border characteristics of card traffic and therefore the cost stack.

But do not make the shortcut:

Local acquiring eliminates cross-border scheme fees.

That depends on the actual:

•Merchant configuration

•Merchant location

•Acquirer

•Issuer

•Network

•Transaction classification

•Currency

•Applicable fee schedule

The Local Acquiring cluster owns the broader architecture.

For pricing:

Model the network cost before and after the acquiring change using the actual expected transaction mix.

Scheme-fee reconciliation checklist

For every network-fee category, finance or payment operations should be able to answer:

•Which network charged it?

•What is the exact provider statement label?

•Which Scheme Fee Classification bucket does it belong to?

•What triggers it?

•What is its denominator?

•Which geography applies?

•Which transactions incurred it?

•Is it exact pass-through?

•Does the provider add margin?

•Which fee schedule/effective date applies?

•Does the invoice reflect adjustments/rebates?

•Can the total be reconciled to transaction data?

If the merchant cannot answer questions 4–8, its card-cost transparency is weak even if the statement has dozens of fee lines.

What to ask in an Interchange++ proposal

When a provider says:

Interchange++

ask:

What exactly is included in the first plus?

Is it:

•All scheme/network fees?

•A defined subset?

•Aggregated estimate?

What is the second plus?

Could be:

•Acquirer markup

•PSP markup

•Processing markup

depending on structure.

How are scheme adjustments handled?

Ask about:

•Monthly changes

•Rebates

•New network programs

•Effective dates

How are cross-border fees displayed?

Separate?

Bundled?

Can we export transaction-level fee data?

A merchant should not accept:

“++ means network cost”

as the entire explanation.

Pricing transparency is not cost optimization

A merchant may receive an extremely detailed scheme-fee statement and still pay too much overall.

Likewise, a blended arrangement can be commercially competitive even though the merchant sees less of the network cost.

The right evaluation combines:

•Transparency

•Total cost

•Payment performance

•Forecasting

•Operational burden

This article advocates classification, not one universal commercial model.

Final merchant recommendation

Merchants should stop treating card-network cost as:

the little bit between interchange and PSP markup.

It deserves its own analysis.

Start with six fee families:

•Volume/value assessments

•Transaction-processing fees

•Cross-border/international charges

•Currency-related network charges

•Product/service-specific network costs

•Other scheme-defined charges

For each fee determine:

•Which network owns it

•What triggers it

•What denominator it uses

•Which transactions incur it

•Whether it is domestic or international

•Whether it is exact pass-through

•How the provider presents it

•Whether it changed over time

Then measure:

•Scheme cost per transaction

•Scheme cost as percentage of card volume

•Cross-border scheme cost

•Cost by card brand

•Cost by route/acquirer where useful

And keep three cost categories separate:

Interchange is not scheme fee.

Scheme fee is not acquirer markup.

Scheme fee is not PSP markup.

That distinction is foundational for sophisticated card-cost management.

A merchant that reduces its PSP markup by five basis points but sees cross-border scheme exposure rise by seven has not necessarily lost the negotiation.

Its transaction mix changed.

A merchant whose scheme rate rises after expanding internationally has not necessarily been repriced by its PSP.

Its network economics may have changed.

And a merchant whose “Interchange++” invoice contains unexplained network lines does not yet have real pricing transparency simply because the contract uses a transparent-sounding pricing model.

The right question is:

Can we trace each network charge back to the transaction characteristic, scheme rule, or service that created it?

If the answer is yes, scheme fees become manageable payment economics.

If the answer is no, they remain exactly what merchants frequently experience today:

a collection of charges between interchange and settlement that nobody can confidently explain.

The uploaded brief makes this article the network-cost article for the Payments Pricing Fundamentals cluster. Its central problem is that merchants often learn to separate interchange from PSP markup, then still treat everything left over as miscellaneous processing cost. In reality, card schemes can impose multiple network-level charges tied to different functions, transaction characteristics, geographies, services, and processing events. Those costs may later appear on merchant statements as assessments, cross-border fees, processing charges, service fees, or bundled network cost.

Editorial interpretation

Merchant payment-cost problem: The merchant understands interchange reasonably well but cannot explain the network-related charges appearing elsewhere in its acquiring or PSP statement.

Fee layer owned by this article: Card-scheme/network costs.

Fee owner: The relevant card scheme/network establishes the underlying scheme charge. The merchant may encounter that cost through an acquirer, processor, or PSP rather than receiving an invoice directly from the network.

Unique evidence anchor: A single card transaction can produce several network-related charges that do not belong to interchange and do not necessarily share one denominator.

Editorial position: Merchants on pass-through or cost-plus pricing should treat scheme fees as an independent cost category rather than burying them in an “interchange” assumption.

Common assumption challenged: “Interchange plus provider markup explains the full card-processing cost.”

Primary cost variables: Network, geography, transaction value, number and type of transaction messages, domestic/cross-border characteristics, currency treatment, product/service usage, and the particular scheme schedule that applies.

Merchant decision: Determine which network fees the merchant actually incurs, why they trigger, whether the PSP passes them through transparently or bundles them, and how much of total card cost comes from network economics rather than interchange or provider margin.

Selected format: Network-fee classification.

Structural rationale: Rather than reproduce a transient Visa or Mastercard fee schedule, classify costs by the network function or condition creating them. That makes the framework durable even as names, amounts, and individual programs change.

Original practical asset: Scheme Fee Classification

The article's primary visual should classify scheme charges by their economic trigger rather than by one network's current fee names.

CARD NETWORK COST

|

+------------------------------+

| |

v v

•VOLUME / VALUE 2. TRANSACTION PROCESSING

ASSESSMENTS message / event-based

|

+------------------------------+

| |

v v

•CROSS-BORDER / 4. CURRENCY-RELATED

INTERNATIONAL NETWORK CHARGES

|

+------------------------------+

| |

v v

•PRODUCT / SERVICE 6. OTHER SCHEME-DEFINED

SPECIFIC COSTS CHARGES

For every box show three questions:

What triggers it?

Who owns it?

How does the merchant see it?

Central caption:

Scheme fee is a category of network costs—not one universal percentage.

Secondary asset: Fee Ownership Map

ISSUER

^

|

| Interchange economics

|

ACQUIRER

|

| Scheme/network charges

v

CARD NETWORK

MERCHANT

|

+--> Acquirer margin

|

+--> PSP markup

|

+--> Gateway/platform cost where applicable

Caption:

Several payment fees can appear on one merchant invoice even though different participants create the underlying economics.

Again, use this as an economic attribution diagram rather than a literal funds-flow sequence.

Measurement plan

Metric

Definition

Scheme cost per transaction

Identified network fees ÷ relevant transaction count

Scheme cost rate

Identified network fees ÷ relevant processed card value

Cross-border scheme cost rate

Identified cross-border scheme charges ÷ qualifying cross-border volume

Cross-border scheme cost per transaction

Cross-border network cost ÷ qualifying cross-border transactions

Scheme cost by brand

Network-specific scheme cost ÷ corresponding processed value

Scheme cost by acquirer

Scheme cost attributed to route/acquirer ÷ corresponding card value

Fixed network cost rate

Fixed scheme cost ÷ transaction count or processed value, explicitly defined

Network cost per completed order

Relevant scheme/network cost ÷ completed paid orders

Unclassified scheme-cost share

Unexplained network-related charges ÷ total identified network charges

Month-over-month scheme-cost variance

Current effective scheme cost − prior-period comparable cost

Segment where possible by:

•Network

•Acquirer

•Merchant entity

•Issuer/card geography

•Transaction currency

•Domestic/cross-border

•Card type

•Channel

•Route

•Ticket size

•Transaction outcome

Scenario analysis

A merchant analyzing scheme costs should model at least three mixes.

Scenario A — Current

Actual:

•Card volume

•Transaction count

•Network split

•Domestic/cross-border mix

•Average ticket

Scenario B — International growth

Increase:

•Foreign-issued cards

•Cross-border activity

•Multiple currencies

Keep provider markup constant.

This isolates potential network-cost exposure from expansion.

Scenario C — Low-ticket growth

Keep processed value reasonably similar but increase transaction count materially.

This exposes fixed/per-event network economics.

The goal is not to predict exact fees without current schedules.

It is to identify which structural variables can change cost.

SEO recommendations

Card Scheme Fees Explained: Network Costs for Merchants

H1:

Card Scheme Fees Explained: The Network Costs Between Authorization and Settlement

Meta description:

Understand card scheme fees, assessments, network processing costs, cross-border charges and how Visa and Mastercard network fees differ from interchange and PSP markup.

URL slug:

/card-scheme-fees-explained/

card scheme fees explained

Secondary keywords:

•card scheme fees

•card network fees

•Visa scheme fees

•Mastercard scheme fees

•network assessment fees

•payment network fees

•merchant card network cost

•card processing network fees

Related entities:

Visa, Mastercard, card network, card scheme, interchange, assessment, acquirer, issuer, PSP, Interchange++, cross-border assessment, authorization, clearing, settlement, network processing fee.

Article excerpt:

Card scheme fees are not one percentage and should not be confused with interchange. Networks can impose multiple assessments, transaction-processing, cross-border, currency-related, and service-specific charges that merchants may see separately or bundled through an acquirer or PSP.

Internal-link recommendations

Interchange Fees Explained

Link after the opening distinction.

Suggested anchor:

how interchange fees work

Boundary: that article owns issuer-acquirer economics.

Acquiring Fees Explained

Link when separating scheme cost from acquirer margin.

Suggested anchor:

what the acquirer charges

Blended Pricing vs Interchange++

Link when discussing scheme-fee visibility.

Suggested anchor:

how Interchange++ exposes underlying card costs

How to Read a PSP Pricing Proposal

Link from the proposal-analysis section.

Suggested anchor:

how to normalize a PSP pricing proposal

Authoritative source recommendations

Network pricing is highly time-sensitive. Reverify all specific amounts and program names immediately before publication.

Visa

Use current:

•Visa Core Rules and Visa Product and Service Rules

•Visa merchant fee/interchange resources

•Merchant Business News Digest

•Relevant official network notices

Visa's current public Core Rules are dated April 18, 2026 and should be treated as the present network-rule reference for claims derived from them.

Mastercard

Use current:

•Mastercard Rules

•Current public Network Assessment Fee documentation where available by market

•Merchant interchange resources

•Other official pricing notices

Mastercard's current public Rules are dated June 2, 2026. Its Canadian Network Assessment Fee document effective July 20, 2026 provides a useful primary-source illustration of multiple network assessment structures, including volume, transaction-based, and cross-border components.

Regulators

Use relevant regulators to explain separation of:

•Interchange

•Scheme fees

•Merchant service charges

The European Commission explicitly treats these as distinct pricing categories in its explanation of the Interchange Fees Regulation.

Do not use competitor PSP explainers as authority for live network pricing.

Proposed author and reviewers

Proposed author

Card payments pricing specialist or senior merchant payments strategist

Relevant experience should include:

•Card acquiring

•Interchange

•Network-fee analysis

•Merchant statements

•Cost-plus pricing

Do not assign a name until approved.

Required reviewer — card-network pricing specialist

Review:

•Fee classification

•Network terminology

•Current scheme programs

•Cross-border treatment

Required reviewer — acquiring analyst

Review:

•Scheme/acquirer boundary

•Merchant statement presentation

•Pass-through treatment

•Acquirer route effects

Required reviewer — finance/reconciliation specialist

Review:

•Fee attribution

•Denominators

•Cost bridge

•Statement reconciliation

•Effective-rate metrics

Potential first-hand contribution

Add an approved merchant cost review showing:

scheme-fee total increased

→ initial assumption was provider repricing

→ transaction analysis isolated network/geography mix

→ merchant identified the actual cost driver.

Use only approved:

•Merchant data

•Period

•Fee categories

•Transaction mix

•Cost impact

Do not invent the case or savings.

Pricing fact-check items

Before publication verify:

•Current network fee names

•Effective dates

•Calculation basis

•Currency

•Country/region

•Transaction class

•Percentage versus fixed amount

•Service/product applicability

•Cross-border conditions

•Adjustments/rebates

Never reuse an old fee table without checking its effective date.

Fee-owner fact-check items

For every fee mentioned determine whether the underlying owner is:

•Issuer/interchange

•Network

•Acquirer

•Processor

•PSP

•Gateway

•Other service provider

Do not classify based solely on statement label.

A provider can rename or aggregate underlying costs.

Network/interchange fact-check items

Verify that:

•Interchange is not described as a scheme fee.

•Scheme fees are not described as issuer revenue.

•Network fee examples apply to the stated region.

•Cross-border definitions match current network rules.

•Transaction-based assessments use the correct denominator.

•Any example percentage is current and precisely scoped.

The current Mastercard Canada document is useful evidence precisely because it specifies geography and effective date; its numbers should not be generalized to the United States, Europe, or another region.

Provider/acquirer fact-check items

For any provider example verify:

•Pricing model

•Whether scheme fees are exact pass-through

•Aggregation

•Markup

•Acquirer

•Invoice labels

•Network adjustment handling

•Rebate treatment

•Effective dates

Do not say:

“Provider passes through Visa at cost”

without contractual evidence.

Merchant-model assumptions

Every economic example should identify or make clear:

•Merchant market

•Acquirer market

•Customer/card geography

•Card brand

•Currency

•Transaction count

•Processed value

•Average ticket

•Domestic/cross-border mix

•Pricing model

Hypothetical examples should be labeled illustrative.

Proposal and statement fact-check items

Before drawing conclusions from a statement:

•Match invoice period to transaction period.

•Confirm whether costs are gross or net of adjustments.

•Identify delayed network adjustments.

•Match card-brand totals.

•Match transaction count.

•Match processed volume.

•Separate refund/reversal activity.

•Separate scheme fees from interchange.

•Separate provider markup.

•Identify monthly platform fees.

•Investigate unclassified network lines.

The pricing schedule and merchant statement may use different names for economically related charges.

Regulatory fact-check items

Where regulation is discussed verify:

•Jurisdiction

•Relevant law/regulation

•Scope

•Consumer/commercial cards

•Domestic/cross-border applicability

•Effective date

The EU Interchange Fees Regulation governs interchange under defined conditions; it should not be described as a general cap on all scheme fees. The Commission explicitly distinguishes interchange from scheme fees.

This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, or commercial advice. Merchants should verify current pricing, contractual terms, network rules, and regulatory requirements with qualified advisers, payment providers, acquirers, card networks, and relevant authorities.

Amber-flag claims

Require current primary evidence before publishing that:

•Visa charges X%.

•Mastercard charges X%.

•A network assessment is universal.

•Scheme fees are the same in every country.

•Cross-border scheme fees always apply at a stated rate.

•One network is cheaper than another.

•Interchange++ always passes scheme fees at exact cost.

•Scheme costs are non-negotiable in every commercial arrangement.

•Network tokens create or eliminate a particular fee.

•Local acquiring eliminates network cross-border charges.

•Scheme fees increased by a stated amount globally.

•A specific network product has a particular current fee.

Pricing structure

•Blended

•Interchange++

•Cost-plus

•Other models

•Market-specific variation

Scheme-fee treatment

•Exact pass-through

•Aggregation

•Markup

•Current network fee presentation

•Network adjustments

Card acquiring

•Acquirers

•Markets

•Card networks

•Domestic/cross-border configurations

Reporting

•Interchange visibility

•Scheme-fee visibility

•Acquirer/PSP markup visibility

•Transaction-level fee data

•Card brand

•Cross-border classification

•Currency

Commercial

•Negotiable markup

•Volume tiers

•Fixed fees

•Network-related service charges

Do not publish confidential pricing.

A safe eventual direction is:

A global payment provider can help merchants consolidate card acceptance and reporting across markets, but merchants should still distinguish underlying interchange, scheme costs, acquiring economics, and provider margin when evaluating the true cost of card processing.

Provider-specific verification template

For every PSP/acquirer under review, capture:

Pricing model

•Blended

•Interchange++

•Cost-plus

•Other

Interchange

•Exact pass-through?

•Aggregated?

•Adjustment timing?

Scheme costs

•Exact pass-through?

•Aggregated?

•Statement detail?

•Cross-border separated?

•Product/service charges separated?

Markup

•Percentage

•Fixed

•Acquirer component

•PSP component

Fixed fees

•Gateway

•Monthly

•Account

•Minimums

Data

•Transaction-level fee export

•Network

•Interchange category

•Cross-border

•Scheme fee

•Acquirer

•Currency

Changes

•How new network fees are communicated

•Effective-date process

•Rebates/credits

•Retrospective adjustments

A provider offering Interchange++ should be able to explain what both plus signs actually represent.

Cluster sameness-audit fields

Article: Card Scheme Fees Explained

Opening: A merchant statement shows interchange, assessment, cross-border, processing, and network-service charges and the merchant cannot identify which belong to the scheme.

Merchant cost problem: Network costs are fragmented and often confused with interchange.

Fee owner: Card scheme/network.

Primary fee type: Network/scheme assessments and service charges.

Primary format: Network-fee classification.

Unique evidence anchor: Several network-level costs can exist around one transaction and use different triggers or denominators.

Editorial position: Treat scheme fees as an independent cost category under pass-through pricing.

Common assumption challenged: Interchange plus provider markup equals complete card cost.

Merchant decision: Determine which network charges apply, what triggers them, how the provider passes them through, and what transaction characteristics cause their cost to move.

Main pricing example: Statement decomposition rather than a headline merchant rate.

Original framework: Scheme Fee Classification.

Secondary asset: Fee Ownership Map.

Primary metric: Scheme cost as percentage of relevant card volume.

Supporting metrics: Scheme cost per transaction, cross-border scheme cost, network cost by brand, unclassified network-cost share.

Conclusion: Scheme fees become manageable only when each charge can be traced to its network owner, trigger, denominator, and merchant transaction population.

CTA direction: Continue to Interchange Fees Explained to understand the issuer layer, Acquiring Fees Explained for the acquiring layer, or Blended Pricing vs Interchange++ for how those components are packaged commercially.

FAQ: None; classification and reconciliation questions replace a generic fee list.

Adjacent-content boundary: This article does not own interchange rates, acquiring margin, PSP markup, complete Interchange++ comparison, gateway pricing, or full PSP-proposal due diligence.

That keeps Article 3 sharply differentiated from the rest of the pricing cluster: Interchange Fees Explained asks what is transferred toward the issuer; Card Scheme Fees Explained asks what the network itself charges around the transaction; Acquiring Fees Explained and PSP Markup Explained then explain the commercial layers merchants pay above those underlying card costs.