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. 1. Volume/value assessments Charges based principally on transaction or assessable payment volume. 2. Transaction-processing fees Charges tied to processing events or transaction messages. 3. Cross-border/international fees Charges triggered by defined geographic relationships in the card transaction. 4. Currency-related network charges Charges connected to defined currency or international-service conditions. 5. Product/service-specific network costs Charges associated with particular network services or product programs. 6. 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: 1. Card-network transaction characteristics 2. Scheme international/cross-border fees 3. Acquirer or PSP FX conversion 4. 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: 1. Which network charged it? 2. What is the exact provider statement label? 3. Which Scheme Fee Classification bucket does it belong to? 4. What triggers it? 5. What is its denominator? 6. Which geography applies? 7. Which transactions incurred it? 8. Is it exact pass-through? 9. Does the provider add margin? 10. Which fee schedule/effective date applies? 11. Does the invoice reflect adjustments/rebates? 12. 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: 1. Volume/value assessments 2. Transaction-processing fees 3. Cross-border/international charges 4. Currency-related network charges 5. Product/service-specific network costs 6. 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 1. VOLUME / VALUE 2. TRANSACTION PROCESSING ASSESSMENTS message / event-based | +------------------------------+ | | v v 3. CROSS-BORDER / 4. CURRENCY-RELATED INTERNATIONAL NETWORK CHARGES |

+------------------------------+ | | v v 5. 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 SEO title: 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/ Primary keyword: 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.