How Payment Processing Fees Work

V2 How Payment Processing Fees Work: Where the Money Goes on Every Transaction A customer pays $100 at an online checkout. The payment succeeds. But the merchant may not ultimately retain the full $100. Who kept the difference? There may not be one answer. For a card payment, some of the economics may relate to the customer's issuer. Some may belong to the card network. The merchant's acquirer or payment provider has its own commercial economics. A gateway or other technical service may be priced separately. Refunds, disputes, failed attempts, currency conversion, account fees, risk tools, or minimum commitments may create additional cost elsewhere. And depending on the merchant's pricing agreement, several of those components may be collapsed into one line. That is why the most useful way to understand payment processing fees is not as one percentage. It is as a cost stack. A merchant cannot meaningfully optimize payment costs until it can distinguish the major cost layers, identify who controls them, and understand why they change.

Start with a $100 card payment Consider a deliberately hypothetical $100 ecommerce transaction. Suppose the merchant's economics looked like this: Illustrative component Hypothetical amount Interchange $1.40 Card-network costs $0.15 Acquirer / PSP commercial charge $0.30 Fixed transaction charge $0.10 Total modeled processing cost $1.95 Amount remaining before other costs $98.05

The merchant's actual statement might not show those four lines. It might simply say: Merchant service charge: $1.95 Or: 1.95% Or: Interchange + network fees + 30 bps + $0.10 Or some other commercial formulation. Same underlying transaction. Different pricing presentation. That distinction—economic cost versus contractual presentation—runs through almost every payment-pricing discussion.

The payment fee is not necessarily what the PSP keeps This is the misconception that causes many merchant pricing analyses to fail. For card payments, the amount a merchant pays can contain economic components associated with several participants. Visa explicitly distinguishes interchange reimbursement fees from the merchant discount charged to a merchant, while Mastercard describes interchange as one component of the Merchant Discount Rate established between acquirers and merchants. The European Central Bank likewise notes that interchange is only one component of merchant card costs; scheme fees and acquirer-related charges also contribute to merchant service charges. So when a merchant says: “Our processor charges us 2%.” that sentence may mean several different things. The provider could be: * keeping 2% as its own commercial price; * passing through underlying card costs and adding a markup; * combining several underlying and provider costs into a blended rate; * charging 2% plus other fixed or conditional fees elsewhere. Until the pricing model is understood, the headline percentage does not tell you who receives the money.

Who participates in a card payment? A simplified four-party card transaction contains several distinct roles. Customer The cardholder initiating the purchase. Issuer The financial institution that issued the customer's card. The issuing side can receive interchange in applicable card-payment models. Card scheme or network The system under whose rules and infrastructure the card transaction operates. Visa and Mastercard, for example, distinguish the network from the issuer and acquirer in their descriptions of card economics. Acquirer The institution providing card acceptance to the merchant, directly or through other providers. PSP A payment service provider may provide some combination of: * Gateway connectivity * processing * acquiring access * local payment methods * risk services * tokenization * reporting * reconciliation * settlement * merchant support The PSP and acquirer can be separate organizations. They can also be commercially integrated. Gateway or technical payment layer A gateway can provide technical connectivity between checkout and the relevant processing infrastructure. It may be: * Separately contracted and separately charged * bundled into the PSP * bundled into an acquiring relationship * part of a larger payment platform That is why “gateway fee” should never be inserted automatically into every merchant cost model.

The Payment Fee Stack A useful merchant model has six layers. Layer 1 — Underlying payment-method economics For cards, this includes interchange. For another payment method, the underlying economics may follow a completely different model. Layer 2 — Network or scheme costs For cards, these are costs associated with the card scheme/network rather than the issuer's interchange. Layer 3 — Acquiring cost The economics of providing merchant acceptance, processing, settlement, risk-taking, and related acquiring services. Layer 4 — PSP or provider markup Commercial margin and service pricing charged by the merchant's payment provider. Layer 5 — Technical, platform, gateway, and account costs Potentially including separately priced gateway, platform, account, reporting, tokenization, or other services. Layer 6 — Conditional operating costs Costs triggered by particular events or merchant characteristics, such as: * Failed attempts * refunds * disputes * currency conversion * cross-border processing * account minimums * compliance administration * additional risk services Not every merchant pays every layer separately. Some providers bundle multiple layers. That is precisely why merchants need the model.

Layer 1: interchange Interchange is one of the most misunderstood payment fees. In a typical four-party card model, it is an economic transfer between the acquiring and issuing sides of the transaction. Visa says merchants do not directly pay interchange reimbursement fees; they negotiate a merchant discount with their financial institution. Mastercard similarly describes interchange as generally paid by acquirers to issuers and as only one component of the Merchant Discount Rate. Interchange can vary according to factors such as: * Debit versus credit * consumer versus commercial cards * card product * card geography * merchant geography * transaction channel * merchant category * transaction data * qualification * regulatory treatment * ticket size There is therefore no useful universal interchange percentage for an international merchant. Regulation can constrain it in particular markets. The EU Interchange Fee Regulation, for example, caps in-scope consumer debit interchange at 0.2% of transaction value and consumer credit interchange at 0.3%, while its scope and exclusions matter. In the U.S., Regulation II applies a different debit framework to covered issuers, currently using a $0.21 plus 0.05% standard with a possible eligible fraud-prevention adjustment. Those regulatory examples are interchange rules, not complete merchant processing prices. The dedicated Interchange Fees Explained article should own the detailed economics.

Layer 2: card scheme and network costs Interchange is not the card network's entire economic charge. The network can levy its own scheme-related fees. The ECB specifically distinguishes interchange from fees charged by card schemes to acquirers and from the economics of the acquirer itself. That gives a merchant three different card-cost questions: What did the issuing side receive? What did the card network charge? What did my acquiring/payment provider charge? Those are not interchangeable. The earlier version of this article used the term assessments, which can be a useful shorthand in some card-pricing contexts. But “scheme/network fees” is a better global category because network fee structures contain multiple fee types and terminology differs by network, geography, and processing arrangement. The merchant should not budget scheme fees using one universal percentage. Current network costs must be verified for: * Network * country * card * transaction type * acquiring model * effective date The dedicated Card Scheme Fees Explained article should own that detail.

Layer 3: acquiring cost The acquirer enables the merchant to accept card transactions within an acquiring relationship. Its economics can reflect factors such as: * Merchant category * risk * transaction profile * geography * processing volume * ticket size * fraud * disputes * service requirements * settlement structure The merchant service charge is therefore not the same thing as interchange. EU legislation makes that distinction explicit by separately defining interchange and merchant service charges, and it generally requires acquirers to offer merchant service charges specified by card category and brand unless the merchant requests blended charging. That is useful conceptually well beyond the EU: The amount the merchant pays for acquiring is a merchant commercial relationship; interchange is an underlying card-system component. The dedicated Acquiring Fees Explained article should go deeper.

Layer 4: PSP markup A PSP's commercial price can pay for much more than transaction forwarding. Depending on the provider and product, the PSP may supply: * APIs and checkout * acquiring relationships * multiple payment methods * payment routing * merchant onboarding * risk management * tokenization * transaction reporting * reconciliation * refunds * settlement * customer or merchant support That means: Provider markup is not automatically wasted money. The correct commercial question is: What capabilities are we purchasing, and are those capabilities worth their incremental cost? Two PSPs charging different markups may not be providing equivalent services. A merchant cannot compare their percentages responsibly until the service scope has been normalized.

A useful—but incomplete—mnemonic: MAI The earlier version used: MAI for: Markup Assessments Interchange That is useful as a memory aid for card costs. But it should not become the entire merchant cost model. Why? Because “markup” can hide multiple participants. And other charges can sit outside those three buckets: * Gateway/platform charges * account fees * monthly minimums * FX * refunds * disputes * risk tools * failed-attempt costs So use MAI as a quick card-cost mnemonic. Use the Payment Fee Stack for financial analysis.

Layer 5: gateway, platform, and account costs A transaction percentage is not always the only recurring commercial charge. Depending on the merchant agreement, additional pricing could include: * Gateway charges * monthly platform fees * merchant-account charges * account minimums * reporting services * tokenization or vault services * risk-product fees The important qualifier is: could. Do not assume every merchant pays all of these. A modern PSP may bundle gateway, account, tokenization, reporting, and risk into one transaction price. Another architecture may use: gateway provider + acquirer + fraud provider + orchestration platform with four commercial relationships. A supposedly cheap acquiring rate can become expensive once all four are included.

PCI DSS is a requirement, not a universal “PCI fee” The first version correctly called attention to PCI-related merchant costs, but the distinction should be tighter. PCI DSS is a payment-card security standard. PCI SSC states that validation and reporting requirements are generally determined through the applicable payment brands and acquirers, and even merchants that outsource payment processing can retain validation obligations. A provider or acquirer may separately charge: * PCI administration * compliance services * non-compliance charges * security services under its contract. But there is no universal merchant “PCI fee” set by PCI SSC. Therefore the pricing question is: Does my provider contract contain a PCI-related charge, what service or condition triggers it, and is it avoidable? not: What is the standard PCI fee? There is no globally useful answer to the second question.

Layer 6: conditional costs Some payment costs do not appear on a normal successful transaction. They appear when something changes or goes wrong. That makes them easy to miss in provider comparisons.

Refund economics Refunds can produce several different outcomes depending on payment method and provider. Questions include: * Is a refund-processing fee charged? * Is any original provider fee returned? * Is interchange reversed or partially recovered in the applicable model? * What happens to scheme fees? * Is a fixed fee retained? * Do partial refunds behave differently? Never assume: processing cost is always refunded or: processing cost is never refunded. The answer belongs in the contract and payment-method rules. A merchant with a high cancellation or return rate should model refund economics directly rather than considering them a back-office exception.

Disputes and chargebacks A dispute can create costs beyond the original processing charge. Visa describes a dispute as a reversal of all or part of the transaction value from issuer to acquirer and usually onward from the merchant bank to the merchant. It also notes that merchants can bear product/service and operational costs around disputes. Provider contracts can additionally contain dispute or chargeback handling charges. Do not use a universal dollar range. Model the merchant's actual: * dispute fees * lost transaction value * lost goods/service * representment costs * operational labor * fraud exposure A payments team analyzing only successful transaction fees can significantly understate cost for a dispute-heavy business.

Failed payment attempts can cost money too A failed payment does not always cost zero. Depending on provider and architecture, a failed attempt can still consume: * Gateway calls * authorization processing * fraud screening * orchestration * retry capacity * engineering/support effort And its largest cost may simply be: the order never completed. This creates two useful denominators: Cost per transaction attempt and: Cost per successful payment They are not the same.

Percentage fees versus fixed fees This distinction from the earlier article is worth preserving because it changes economics dramatically. Suppose a merchant pays an illustrative: 1.5% + $0.20 per successful transaction. On a $2 payment: Percentage component = $0.03 Fixed component = $0.20 Total = $0.23 Effective cost: 11.5% On a $200 payment: Percentage component = $3.00 Fixed component = $0.20 Total = $3.20 Effective cost: 1.6% Same contract. Very different economics. This is why a gaming merchant selling $1.99 digital goods and a travel company selling $1,000 bookings should not evaluate provider pricing using the same generic “percentage rate” framework.

The effective transaction cost For an individual transaction: Effective transaction cost Total applicable fees ÷ transaction value × 100 This helps expose the effect of: * Fixed charges * ticket size * method-specific pricing But do not stop there. Individual payments are noisy. Merchant pricing should be evaluated over a meaningful portfolio.

Fixed monthly costs create another denominator problem Suppose a merchant pays: $1,000/month platform fee A merchant processing $100,000 per month experiences that as an additional: 1.0% of processed value before transaction pricing. At $1,000,000: it represents: 0.10%. Same platform fee. Different effective economics. That is why fixed and minimum charges need to be annualized or allocated across realistic merchant volume when comparing providers.

Monthly minimums are economically different from monthly fees A recurring platform fee is owed because the merchant uses the service. A monthly minimum typically creates a payment obligation when usage or fee generation falls below a contractual threshold. Those are different structures. A merchant comparing providers should model: * Current volume * downside volume * growth volume * seasonal low months A low transaction rate with an unreachable minimum can be more expensive than a slightly higher rate without the commitment.

Pass-through cost versus markup This distinction is one of the most important pricing concepts in the cluster. Pass-through An underlying cost is passed through to the merchant. In an applicable card model, this could include: * Interchange * network fees depending on the contract. Markup The acquirer or PSP adds its commercial price. A cost-plus statement might therefore look conceptually like: **actual interchange * actual network cost * provider markup** But never assume that a fee labeled: pass-through automatically contains no provider economics. Read the contract and statement definition.

Blended pricing Under a blended model, several underlying card-cost variations are incorporated into a simpler merchant price. This can provide: * More predictable pricing * simpler statements * easier budgeting But it can also reduce visibility into: * Interchange variation * network costs * provider margin * card-mix changes The European Interchange Fee Regulation explicitly recognizes the distinction between individually specified merchant service charges and blended merchant charges. Blended pricing is not automatically bad. A competitive blended price can be commercially attractive. Its weakness is not inherently price. It is reduced attribution.

Interchange++ “Interchange++” generally refers to a commercial structure that exposes more of the underlying card-cost stack rather than folding everything into one merchant rate. Conceptually, it often represents: **Interchange * scheme/network cost * acquirer/provider margin** The exact contract needs to define each component. Do not assume every provider uses the ++ identically. Potential advantages include: * Better attribution * easier interchange analysis * greater visibility into provider markup Potential disadvantages include: * More variable invoices * more complex reconciliation * more difficult forecasting Transparency does not guarantee low cost. A transparent expensive offer remains expensive. The dedicated Blended Pricing vs Interchange++ article should own the full decision.

Flat-rate versus cost-plus A flat-rate model shifts much of the underlying transaction-cost variability into one merchant price. The merchant gains predictability. The provider absorbs more variability in the mix. A cost-plus model exposes more of the changing underlying economics to the merchant and adds defined commercial pricing. Neither structure is universally superior. A smaller merchant can reasonably value: * Simplicity * predictable billing * limited reconciliation work A larger merchant may value: * Underlying cost visibility * provider-margin transparency * card-mix analysis * optimization opportunities The right decision depends on: * Volume * ticket size * card mix * geography * accounting capability * expected growth * commercial terms The dedicated Flat-Rate vs Cost-Plus Pricing article should handle the full comparison.

Do not automatically classify monthly membership pricing as a separate economic universe The first version identified “subscription-based pricing” as another provider model. The useful idea is the fixed-versus-variable tradeoff, not the label. Some providers may charge: monthly platform/membership fee + low per-transaction price Others combine the same economics differently. Instead of asking: Is this subscription pricing? normalize it as: Fixed annual cost * Variable cost * Transaction cost * Conditional cost That makes offers comparable regardless of provider terminology.

Online payments do not have one universal surcharge The first version stated broadly that online and keyed transactions cost more than card-present transactions. There is an important idea underneath that statement: Transaction channel can affect card-cost qualification. Current card-network schedules distinguish card-present and card-not-present programs and can apply different criteria and rates across transaction types. But the stronger claim: “Every online payment costs X more than card present” is not defensible globally. Actual cost depends on: * Card * country * merchant category * network * authentication * tokenization * data * acquiring setup * interchange program The correct merchant practice is to segment costs by transaction channel rather than apply one universal ecommerce premium.

The same applies to AVS, tokenization, and settlement timing The earlier draft suggested that specific actions such as AVS matching or settlement within a particular number of hours would automatically produce lower interchange. That is too broad. Current network qualification rules can consider transaction data, authentication, tokenization, authorization-to-clearing timing, merchant category, and other program-specific conditions. Mastercard, for example, explicitly identifies transaction data and timing among factors used in interchange qualification, while Visa's current schedules contain distinct token/authentication incentive structures for particular programs. The safe operational rule is: Submit transactions accurately and completely according to the network, acquirer, and payment-provider requirements that apply to the merchant's actual program. Do not build a global “AVS saves X basis points” assumption.

Cross-border payments add cost layers rather than one “international fee” An international card transaction can potentially affect several layers at once: Interchange treatment Network cross-border costs Acquirer pricing PSP pricing Currency conversion Settlement conversion These are distinct. A merchant asking: “What is our cross-border fee?” may therefore receive an answer that describes only one component. Instead ask: 1. Is the card considered international relative to this acquiring transaction? 2. Does interchange change? 3. Is there a network cross-border charge? 4. Does the acquirer add a cross-border markup? 5. Does the PSP add one? 6. Does FX occur? 7. Who performs that FX? 8. In which currency does the merchant settle? Do not collapse all eight into one percentage.

Card pricing is not the pricing model for every payment method The card anatomy is useful because it shows how several institutions participate. But a merchant should not force every alternative payment method into: Interchange + scheme + acquirer + markup A bank payment may have: * Payment-rail economics * bank/provider fee * PSP fee A digital wallet may: * inherit underlying card economics; * use a wallet-specific commercial model; * rely on bank or stored-value funding. A carrier-billed payment can have completely different economics. Cash and voucher methods can involve collection networks. BNPL can embed financing economics. This is why Payment Method Fees Explained deserves its own article. The merchant-level question remains consistent: Who gets paid, how is the charge calculated, and what commercial capability does it purchase?

A method with a higher fee can still be cheaper commercially Suppose: Method A Costs 1.5%. Customers already have a successful alternative. Method B Costs 2.5%. But it allows customers who could not otherwise pay to complete orders. Calling B simply: “one percentage point more expensive” misses the business result. The correct comparison may involve: incremental contribution from additional completed orders minus: incremental payment cost. This is the difference between: expensive and: unprofitable. They are not synonyms.

Start measuring with effective processing cost The earlier version's strongest recommendation was to stop comparing quoted rates and calculate what the merchant actually pays. That remains central. Effective processing cost Define the numerator first. For example: **Interchange * network fees * acquiring / PSP transaction fees * fixed transaction charges * gateway/platform/account fees allocated to the period * relevant conditional payment fees** Then calculate: Effective processing rate Total included payment costs ÷ successful processed payment value × 100 The word included matters. A merchant should document whether the metric includes: * FX * refunds * disputes * fraud tools * monthly account charges Otherwise two teams can report different “effective rates” and both be mathematically correct.

Example effective rate Suppose a hypothetical merchant processes: $1,000,000 of successful payment value during a month. Its modeled costs are: Cost Amount Transaction/card-method costs $16,500 Provider transaction markup $2,000 Fixed transaction charges $900 Gateway/platform allocation $600 Relevant refund/dispute charges $400 Included payment cost $20,400 Then: Effective processing rate = $20,400 ÷ $1,000,000 = 2.04% Again, these are invented values. The value of the example is not 2.04%. It is the accounting discipline. The merchant knows what is in the numerator.

Cost per successful payment Rate alone can still hide transaction-size differences. Track: Effective payment cost per successful payment Total applicable payment costs ÷ successful payments This is especially useful for: * Low-ticket digital goods * high-ticket businesses * recurring transactions * different payment-method portfolios

Payment cost per completed order For ecommerce and other merchant use cases, a more commercially useful metric can be: Payment cost per completed order Payment costs associated with the defined checkout/payment population ÷ completed paid orders Depending on scope, the numerator can include: * Successful payment fees * failed attempt costs * payment fraud tooling * applicable disputes * applicable refunds This connects the payment bill to the merchant outcome.

Why a cheaper PSP can cost more Consider two hypothetical providers processing 1,000 payment attempts worth $100 each. Provider A Processing cost on success: 1.7% Payment completion: 90% Provider B Processing cost on success: 2.0% Payment completion: 94% If all other factors were genuinely comparable, Provider B creates: 40 additional completed payments per 1,000 attempts. Whether the higher processing price is economically justified depends on: * Gross margin * fraud * refunds * customer value * method mix * operational costs The point is not that B is better. The point is: You cannot determine which provider is cheaper commercially from the processing percentage alone. The relevant metric may be: net contribution per 1,000 payment attempts.

Normalize pricing proposals before comparing them Provider terminology is not standardized enough to compare proposals line by line. Normalize each offer into common buckets. Normalized bucket What to place here Underlying payment cost Interchange or method-level pass-through economics Network/scheme Card-network or payment-scheme charges Acquirer/provider markup Commercial margin Fixed transaction cost Per-authorization/payment charges Method-specific charges Wallet, bank, BNPL, carrier, voucher pricing Cross-border Explicit international transaction costs FX Currency conversion/spread Refund/dispute Event-driven costs Platform/gateway/account Monthly or usage-based infrastructure Minimums/commitments Contractual minimum economics Other conditional charges Risk, tokenization, ancillary services where applicable Only after normalization should finance calculate effective cost.

Headline pricing should be the beginning of procurement, not the end When a PSP says: “1.8% + $0.10” procurement still needs to ask: * What underlying costs are included? * What is excluded? * Are network fees separate? * Is interchange included or passed through? * Are international cards different? * Is FX separate? * Do currencies have different rates? * Do different payment methods have different rates? * Are authorizations charged? * Are failed attempts charged? * How are refunds priced? * How are disputes priced? * Is the gateway included? * Is tokenization included? * Are there account fees? * Are there monthly minimums? * Are there volume commitments? * What happens when volume falls? * What happens when volume grows? That is the real fee schedule. The headline rate is one field.

Model your actual merchant mix Do not compare providers using an imaginary universal transaction. At minimum, model: * Monthly payment volume * payment count * average and median ticket * country mix * card-country mix * debit/credit mix * consumer/commercial card mix * payment-method mix * transaction currency * cross-border share * refunds * disputes * recurring versus one-time * authorization/completion rates Pricing that looks excellent for: $100 domestic debit may look poor for: $5 international digital goods or: $800 commercial-card travel transactions. Your transaction mix is part of your price.

Model three scenarios A provider comparison should include more than today's business. Current mix Use actual recent merchant data. Growth mix Model what happens when: * New markets launch * local methods increase * transaction count rises * international-card share changes Adverse mix Model exposure to: * Higher cross-border share * smaller tickets * more premium/commercial cards * higher refunds * lower volume relative to minimum commitments A pricing contract is a future cost function. Do not select it using only one historical month.

Reconcile the quote to the invoice Merchant payment-cost analysis should connect: Commercial proposal ↓ Contract ↓ Transaction record ↓ Provider invoice ↓ Settlement report ↓ General ledger The names may change at each stage. For example: A proposal might call something: cross-border surcharge while a monthly report classifies it differently. Or network and interchange costs may be aggregated. Or fees may be netted from settlement instead of separately invoiced. Do not assume a provider is charging incorrectly merely because reporting labels differ. Reconcile the economics.

Which payment fees can merchants negotiate? Merchants typically have more direct commercial leverage over provider-controlled charges than underlying regulated or network-established costs. Potential negotiation areas can include: * PSP markup * Acquirer margin * Fixed transaction charges * gateway/platform charges * account charges * volume tiers * minimum commitments * settlement terms * ancillary services Interchange and card-network costs generally operate under network and regulatory frameworks rather than being a simple PSP margin the merchant can individually negotiate away. The exact contract still matters. Do not label a fee negotiable or non-negotiable until its owner is identified.

Negotiate the layer that is actually expensive Suppose the merchant's effective cost rises from: 2.0% to: 2.2%. The payments team asks the PSP for a 20-basis-point discount. But analysis shows: * Provider markup did not change. * Cross-border card mix increased. * Scheme and interchange economics changed with that mix. The PSP discount request attacks the wrong layer. A better sequence is: What changed? ↓ Which fee layer changed? ↓ Why did it change? ↓ Can the merchant influence it? ↓ Which intervention has the best commercial effect? Pricing optimization is diagnosis before negotiation.

Reserves belong in the analysis—but not in the fee total A reserve can reduce merchant liquidity. It can impose a meaningful financing cost. But a reserve is not automatically a payment fee. Distinguish: Fee Economic cost paid to another participant. Reserve Merchant funds temporarily retained or restricted under an applicable risk arrangement. A merchant can model the liquidity cost of a reserve separately. Do not add the entire reserve amount to payment processing expense as if the funds disappeared.

Settlement timing can also have economic value Two providers with identical transaction fees can still affect working capital differently if: * one settles faster; * one holds larger reserves; * one requires more FX conversion; * one creates more reconciliation exceptions. That does not mean settlement delay should be artificially converted into a payment fee without a methodology. It means provider economics can extend beyond the processing rate. Large merchants should evaluate: payment cost and: working-capital impact as separate but related measures.

A merchant payment-cost dashboard At minimum, finance and payments should track: Gross successful processed value The denominator for effective processing rate. Successful payments The denominator for cost per successful payment. Completed orders The denominator for payment cost per completed order. Total transaction fees Split by method and provider. Interchange Where separately visible. Network/scheme cost Where separately visible. PSP/acquirer markup Where separable. Fixed fees Including allocated monthly platform/account charges. Cross-border/FX costs Separately identified. Refund/dispute costs Where material. Then segment by: * Country * payment method * provider * card category * transaction value * currency A single blended global effective rate is useful for management. It is not sufficient for diagnosis.

The Payment Fee Stack The final merchant framework should look like this: Layer 1 — Underlying payment-method economics Who: issuer/payment-method ecosystem Calculation: method and transaction dependent Varies with: card/method, geography, customer, transaction Merchant influence: usually indirect ↓ Layer 2 — Network/scheme cost Who: payment network/scheme Calculation: network-specific Varies with: network, market, transaction, currency, program Merchant influence: generally limited ↓ Layer 3 — Acquiring cost Who: acquirer Calculation: merchant commercial arrangement Varies with: risk, volume, geography, vertical, services Merchant influence: moderate ↓ Layer 4 — PSP/provider markup Who: payment provider Calculation: blended, percentage, fixed, cost-plus, other contractual structure Varies with: commercial agreement, volume, services Merchant influence: potentially meaningful ↓ Layer 5 — Technical/platform/account Who: gateway/provider/platform/acquirer depending on architecture Calculation: transaction, usage, monthly, account Varies with: infrastructure and contract Merchant influence: architecture + negotiation ↓ Layer 6 — Conditional operating costs Who: provider/network/payment ecosystem/merchant operations depending on event Calculation: event or merchant-specific Examples: disputes, refunds, FX, failed attempts, extra risk products Merchant influence: varies substantially That is the anatomy merchants need before attempting cost optimization.

Foundational questions merchants ask Is interchange the same as the processing fee? No. Interchange is an underlying card-economic component. Visa, Mastercard, the ECB, and EU regulation distinguish it from what the merchant pays its acquirer or provider.

Are card-network fees the same as interchange? No. Network/scheme costs are a separate card-cost layer.

Does the PSP keep the entire headline fee? Not necessarily. It depends on the pricing model. The headline merchant charge may incorporate underlying costs that are paid elsewhere in the ecosystem.

Is Interchange++ always cheaper than blended pricing? No. Interchange++ can make cost attribution clearer, while blended pricing can make cost more predictable. Actual economics depend on the merchant's mix and the specific commercial rates.

Is the lowest transaction rate the cheapest provider? Not necessarily. You need to include: * Fixed fees * method charges * FX * refunds/disputes * failed attempts * payment completion * required capabilities before comparing total economics.

Are PCI compliance fees mandatory? PCI DSS obligations can apply to merchants, but PCI SSC does not impose one universal merchant compliance fee. Separately billed compliance or non-compliance fees are contractual matters involving providers/acquirers/payment brands.

Those capabilities can be relevant to the merchant cost problem because pricing analysis becomes more useful when payments teams can compare: * Transaction performance * market * method * acquiring configuration * settlement * reporting rather than consider processing price in isolation. But the public information does not justify universal statements about:

* scheme-fee pass-through * Interchange++ availability * acquirer markup * PSP markup * merchant-specific rates * guaranteed savings Those need commercial verification.

A global payments provider can help merchants consolidate payment access and reporting across cards and local payment methods, but merchants should still model the actual commercial terms, transaction mix, payment performance, and conditional costs associated with their own account. The value is not simply: one low percentage. It is being able to understand: what the merchant pays, what payment capability it receives, and what commercial result that spending produces.

Final recommendation Do not begin a payment-cost project by asking: “Who has the lowest rate?” Begin with: “What exactly are we paying for?” Break the merchant's payment costs into: underlying payment-method economics network/scheme costs acquiring PSP/provider markup technical/platform/account charges conditional operating costs Then classify every meaningful charge by: owner calculation method transaction dependency fixed versus variable pass-through versus commercial markup negotiability Next, calculate: effective processing cost effective processing rate cost per successful payment and, where commercially appropriate: payment cost per completed order. Finally, compare those costs with: * Payment completion * customer access * authorization * fraud * refunds * operational complexity * required payment capabilities A merchant paying 1.8% is not necessarily better off than one paying 2.0%. A merchant on Interchange++ is not necessarily cheaper than one on blended pricing. A bank payment is not automatically cheaper than a card. A transparent provider is not automatically inexpensive. And a provider that quotes the lowest transaction rate does not necessarily create the lowest commercial payment cost. The goal is not to minimize one fee line. It is to understand which participant creates each cost, identify which pieces the merchant can realistically influence, and choose the payment architecture that produces the best total cost per successful commercial outcome.

That is how payment processing fees should be evaluated. 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.

The biggest upgrades are: interchange is no longer described as a fixed percentage of total cost; network fees are not assigned a universal percentage; processor markup is not assumed to be the only negotiable cost; Interchange++ is not automatically called cheapest; tiered pricing is not categorically rejected; PCI, dispute, gateway, and account fees are treated as contract-dependent; and card-not-present transactions are described as qualifying under different card programs rather than carrying one universal ecommerce surcharge. Editorial decision Direction Merchant cost problem Merchant sees one processing charge but cannot attribute it to the economic layers underneath Unique evidence anchor The amount deducted from a payment can reflect costs belonging to issuers, networks, acquirers, PSPs, technical infrastructure, and conditional events Editorial position Do not optimize payment pricing until the major costs are normalized by owner, calculation method, and merchant transaction mix Assumption challenged “The processing fee is what the PSP charges.” Merchant decision Optimize total cost per successful payment/completed order, not merely the advertised processing percentage Format Payment-cost anatomy Structural principle Begin with one $100 transaction and move outward through the economic layers Original asset Payment Fee Stack What the first version contributed—and what changed

The revised article keeps the earlier version's strongest merchant concepts: the MAI mnemonic, the emphasis on fee ownership, fixed-fee ticket-size effects, conditional fees, effective-rate measurement, statement analysis, and full-fee-schedule diligence. It deliberately removes or qualifies the weaker elements. Specifically, I would not carry forward the assertions that interchange is universally 70–80% of total merchant cost, network assessments universally equal roughly 0.13–0.16%, processor markup is always the remaining 20–30%, total processing commonly belongs in one universal 1.5–3.5% range, Interchange++ generally produces a 1.7–2.1% rate, flat rate necessarily “overcharges,” tiered pricing should categorically be avoided, PCI fees have one normal annual range, chargebacks have one universal merchant fee range, or keyed transactions carry one standard percentage premium. Those claims depend too heavily on market, network, provider, contract, transaction mix, and time. Original asset: Payment Fee Stack The supporting visual should use a $100 payment at the top, then show where the merchant's economic cost can accumulate: $100 CUSTOMER PAYMENT ↓ 1 — Underlying Payment Economics Interchange / method-specific underlying cost ↓ 2 — Network / Scheme Card-network or payment-scheme costs ↓ 3 — Acquiring Merchant acceptance and acquiring economics ↓ 4 — PSP / Provider Commercial markup and service layer ↓ 5 — Gateway / Platform / Account Only where separately priced ↓ 6 — Conditional Costs

Refund · dispute · FX · failed attempt · risk product · minimum ↓ MERCHANT NET PAYMENT ECONOMICS A sidebar should classify each layer: Pass-through? · Markup? · Fixed? · Variable? · Negotiable? Then a footer should show: Effective cost = all included payment costs ÷ successful payment value and: Commercial cost = payment economics considered alongside completed orders and payment performance Suggested caption: “The merchant sees one payment charge; the economics underneath can belong to several different participants.” Image alt text: “Payment Fee Stack showing underlying payment-method economics, network fees, acquiring cost, PSP markup, gateway and account costs, and conditional fees between a customer payment and merchant proceeds.” SEO metadata SEO title: How Payment Processing Fees Work: Merchant Cost Guide H1: How Payment Processing Fees Work: Where the Money Goes on Every Transaction Meta description: Learn how payment processing fees work, including interchange, card-network fees, acquiring costs, PSP markup, gateway and account charges, refunds, disputes, and how to calculate your true effective payment cost. URL slug: /how-payment-processing-fees-work/ Primary keyword: how payment processing fees work Secondary keywords: payment processing fees, merchant processing fees, payment processor fees, credit card processing fees, payment fee breakdown, PSP fees, merchant payment costs, payment processing cost.

Related entities: interchange, card scheme fee, merchant service charge, merchant discount rate, acquirer, issuer, payment service provider, gateway, Interchange++, blended pricing, cost-plus, effective processing rate. Article excerpt: Payment processing is a cost stack, not one percentage. A merchant's payment bill can include issuer-side interchange, network fees, acquiring economics, PSP markup, fixed platform charges, and conditional costs such as refunds, disputes or FX. Understanding who owns each layer is the first step toward lowering total cost. Suggested structured data: Article or BlogPosting, BreadcrumbList, and ImageObject for the Payment Fee Stack. Internal-link architecture The pillar should link to all ten supporting articles only where their topic first becomes materially relevant. Interchange Fees Explained belongs immediately after the interchange section; Card Scheme Fees Explained, Acquiring Fees Explained, and PSP Markup Explained follow their respective layers. Blended Pricing vs Interchange++ and Flat-Rate vs Cost-Plus Pricing belong in the pricing-packaging sections. Gateway Fees Explained and Merchant Account Fees Explained belong under fixed/platform charges, Payment Method Fees Explained from the non-card section, and How to Read a PSP Pricing Proposal from the proposal-normalization section. That keeps this article as the cluster's complete conceptual map without cannibalizing any single cost layer. Authoritative source recommendations

Use Visa and Mastercard for current card-participant and interchange terminology. Both explicitly distinguish interchange from the merchant's overall acceptance price. Use the European Central Bank for the conceptual decomposition of merchant card costs into interchange, scheme, and acquiring components. Use EUR-Lex for current EU interchange, merchant-service-charge, and pricing-transparency requirements. Use the Federal Reserve Board for current U.S. Regulation II debit interchange rules rather than secondary payments blogs.

Proposed author and reviewers

Payments pricing specialist: validate the complete stack, blended/cost-plus terminology, and pass-through distinctions. Acquiring expert: verify interchange, acquiring, network, MCC, domestic/cross-border, and merchant-service-charge mechanics. Merchant finance lead: validate effective-rate, fixed-cost allocation, scenario modeling, and statement reconciliation. Payment operations reviewer: validate refunds, failed attempts, disputes, account charges, and operational-cost boundaries.

Named individuals should be added only after they have actually reviewed the article. Pricing fact-check items Immediately before publication, verify current: * Network interchange schedules where quoted * regulatory interchange caps * scheme/network fee terminology

* gateway/account product structure * refund treatment * dispute pricing * FX structure * cross-border treatment * minimums and volume tiers if any provider-specific example is added No percentage range should be published merely because it appeared in the earlier version. Fee-owner fact-check items Every fee used in the article should answer four questions: Question Required answer What is it? Exact fee/category Who economically owns it? Issuer, network, acquirer, PSP, gateway, method operator, etc. Who invoices the merchant? May differ from economic owner How is it calculated? Percentage, fixed, monthly, event-based, blended This prevents who charges the merchant from being confused with who ultimately receives the underlying economic value. Network/interchange fact-check items Verify by: * Network * country/region * debit/credit * consumer/commercial * issuer geography * merchant/acquiring geography * transaction channel * MCC * recurring status * authentication/token qualification * ticket size * effective date Do not use “the interchange rate” without specifying the relevant transaction population. Provider/acquirer fact-check items

* Pricing model * whether interchange is included or passed through * network-fee treatment * provider markup * acquiring margin * fixed transaction fees * authorization/failed-attempt fees * gateway/platform fees * merchant-account charges * cross-border charges * FX * refunds * disputes * minimum commitments * volume tiers * settlement * merchant/category/country eligibility Merchant-model assumptions Before comparing providers, define: Monthly volume · transaction count · median ticket · average ticket · payment-method mix · card mix · issuer-country mix · merchant countries · currency mix · cross-border percentage · refunds · disputes · successful payments · failed attempts · completed orders A proposal comparison without merchant mix is a rate comparison, not a cost model. Proposal and statement verification Normalize every provider's terminology before comparison. One provider's: processing fee may incorporate costs another provider labels: interchange + scheme + markup. One may net fees from settlement. Another may invoice monthly. The pricing analysis needs to reconcile: proposal → contract → transaction → invoice → settlement. The earlier version's recommendation to request the complete fee schedule remains one of its best practical points. Regulatory fact-check items For any regulatory pricing claim identify: * Jurisdiction * payment method * consumer/commercial status * transaction scope * effective date * exceptions

For example, EU consumer-card interchange caps and U.S. covered debit rules are both regulatory interventions, but they operate through materially different structures. Do not generalize either model globally. Amber-flag claims Require evidence before publishing: * “Interchange is X% of processing cost.” * “Network fees are X%.” * “Provider markup is X%.” * “Interchange++ is cheapest.” * “Flat rate is expensive.” * “Tiered pricing is bad.” * “Bank payments are cheaper.” * “Wallets cost less.” * “Online cards cost X more.” * “AVS reduces interchange by X.” * “Settle within 24 hours to get the best rate.” * “The chargeback fee is X.” * “PCI compliance costs X.”

Those are precisely the kinds of statements that turn a useful merchant explainer into a fragile pricing article.

Before adding stronger pricing positioning, internal commercial/product owners should verify: * Current merchant pricing models * Blended versus pass-through options * Interchange++ availability * network-fee treatment * acquiring markup * PSP markup * transaction-level fees * authorization fees * gateway/platform charges * minimum commitments * high-volume pricing * method-specific pricing * cross-border charges * FX * refund charges * dispute charges * reporting granularity * local-acquiring cost treatment * whether cost-per-transaction analysis is available directly in merchant reporting Do not publish confidential rates or infer commercial structures from product documentation. Cluster sameness-audit fields Title: How Payment Processing Fees Work: Where the Money Goes on Every Transaction Opening device: One $100 card transaction with several possible economic recipients. Merchant cost problem: Merchant sees one processing charge but cannot attribute its components. Fee owner: Multiple participants; this article owns the complete stack rather than one participant. Primary format: Payment-cost anatomy. Unique evidence anchor: One merchant charge can contain several underlying economic layers. Editorial position: Attribute cost before optimizing it. Merchant decision: Optimize effective cost per successful commercial outcome rather than the headline rate. Original framework: Payment Fee Stack. Primary metric: Effective processing rate.

Secondary metrics: Cost per successful payment and payment cost per completed order. Pricing example: Hypothetical $100 payment decomposed into underlying card cost, network cost, provider/acquiring cost, and fixed charge. Conclusion: The merchant must know who creates each cost and why before deciding which fee to negotiate or architecture to change. Closing device: Foundational FAQ plus cost-stack framework. Cluster differentiation: This is the only article that owns the complete conceptual payment-cost anatomy. Every other article should drill into one fee layer, pricing structure, or proposal-analysis problem rather than rebuilding the entire stack. This version is stronger than V1 primarily because it keeps V1's practical merchant instincts while replacing market-generalized fee benchmarks with a more durable framework based on ownership, transaction mix, contract structure, denominators, and current primary-source verification.

V1 How Payment Processing Fees Work The rate on a payment processor's homepage is rarely the rate a merchant actually pays. Every card transaction moves through several financial institutions before it settles, and each one takes a cut — but how those cuts are disclosed, bundled, or hidden varies enormously by pricing model. Understanding the underlying components is what separates a merchant who can meaningfully negotiate their costs from one who's simply trusting the number on the invoice. The three components behind every card transaction Regardless of what a merchant's statement shows as a single number, every card payment fee is actually built from three distinct pieces — commonly remembered by the mnemonic MAI: Markup, Assessments, Interchange:

1. Interchange — paid to the customer's card-issuing bank, and the largest component of the total cost by far, typically 70–80% of the overall fee. It compensates the issuing bank for the fraud risk it absorbs, the cost of extending credit, and the operational cost of processing the transaction. Interchange is set by the card networks (Visa, Mastercard, and others) in published rate schedules with hundreds of categories, and it's identical across every processor — no processor pays a different interchange rate than any other for the same transaction. It fluctuates based on card type (a basic debit card carries a far lower rate than a premium rewards credit card), how the transaction is processed (card-present versus card-not-present), and the merchant's industry classification. 2. Assessments (network fees) — paid directly to the card network itself (Visa, Mastercard, Discover, Amex) as a licensing fee for using its infrastructure. This is the smallest component, commonly cited around 0.13–0.16% of volume, plus a handful of small per-transaction and periodic fixed fees the networks charge directly (Visa's Fixed Access Network Fee and Mastercard's Network Access Brand Usage fee are commonly cited examples). Like interchange, assessments are non-negotiable and identical across processors, though the networks do review and adjust them roughly twice a year.

3. Processor markup — the only piece that varies between providers, and the only piece a merchant can actually negotiate or shop around. This is what the payment processor, acquiring bank, and any intermediary payment facilitator charge for their own services, technology, and profit. Markup typically makes up the remaining 20–30% of the total cost. Interchange plus assessments together are often called the "wholesale" or "base cost" of processing — money that flows through the processor to the issuing bank and card network rather than money the processor keeps. The combined effective rate merchants typically end up paying across all three components commonly lands somewhere in the 1.5–3.5% range, though the exact figure depends heavily on card type, transaction method, and pricing model. The four common pricing models How a processor packages these three components into a bill to the merchant is where the real variation — and the real risk of overpaying — shows up.

Interchange-plus (also called interchange++ or cost-plus) passes the actual interchange and assessment cost through directly, itemized separately from a fixed markup on top (something like "interchange + 0.25% + $0.08 per transaction"). This is consistently described as the most transparent model available: the merchant's statement shows exactly what went to the issuing bank, what went to the network, and what the processor kept. Because the markup is disclosed and isolated, it's also the easiest model to audit and negotiate, and it's generally recommended as the most cost-effective option for established or higher-volume merchants — commonly landing in an effective-rate range of roughly 1.7–2.1%. Flat-rate pricing charges one fixed rate on every transaction (a widely cited example is 2.9% + $0.30, the model popularized by providers like Square, Stripe, and PayPal), regardless of the actual underlying interchange cost. This blends cheap debit transactions and expensive rewards-card transactions into a single number — set, necessarily, high enough that the processor comes out ahead on average across the whole mix. The genuine advantage is simplicity and predictability, which matters for new or low-volume merchants who don't want to parse a detailed statement; the tradeoff is that the model structurally overcharges on the cheaper end of the transaction mix to subsidize a flat number, and offers little visibility into where the actual cost is coming from.

Tiered pricing buckets transactions into categories — commonly "qualified," "mid-qualified," and "non-qualified" — each carrying a different rate (a frequently cited example: 1.69% qualified, 2.49% mid-qualified, 3.49% non-qualified). The problem, described consistently and bluntly across independent sources, is that the processor — not an objective, disclosed standard — decides which transactions get downgraded into the more expensive tiers, and the criteria are often deliberately unclear. A transaction quoted at the attractive headline rate can quietly settle at the expensive tier because a rewards card was used or because some transaction data was incomplete. This model draws the most consistent criticism of the four: multiple independent sources explicitly recommend against it, characterizing it as structured to benefit the processor at the merchant's expense rather than to reflect actual cost. Subscription-based pricing charges a flat monthly or annual fee plus a lower, often near-cost, fixed fee per transaction (rather than a percentage). This can outperform both flat-rate and interchange-plus for high-volume merchants specifically, since the processor isn't taking a percentage cut of sales — but it only pays off once volume is high enough to justify the fixed subscription cost, making it a poor fit for low-volume or highly seasonal businesses. Beyond the base rate: the fees that don't show up in a quoted percentage

A processing rate quote is not a complete picture of what a merchant will actually pay. A long list of additional fees sits alongside the base rate, and several are specifically structured around things going wrong rather than routine processing: * PCI compliance fees — an annual or monthly charge (commonly cited around $75–$150/year, though monthly variants exist) tied to maintaining Payment Card Industry Data Security Standard compliance; some processors include this at no extra charge, others bill it separately, and non-compliance can trigger an additional penalty on top. * Chargeback fees — a per-dispute charge, commonly cited in the $15–$100 range, applied every time a customer disputes a transaction — and critically, this fee is typically charged regardless of whether the merchant ultimately wins the dispute. Some processors additionally charge for retrieval requests even when resolved in the merchant's favor. * Gateway fees — a monthly access fee for the payment gateway used to process online transactions, sometimes bundled into the headline rate and sometimes itemized separately. * Batch fees — a small per-batch charge applied each time a day's transactions are settled and closed out, which sounds trivial per instance but compounds daily. * Statement and account fees — small recurring administrative charges (commonly $5–$15/month) for account maintenance, sometimes including a specific line for generating a monthly statement.

* Monthly minimum fees — if a merchant's processing volume falls below a contracted threshold in a given month, the processor charges the shortfall as an additional fee (commonly $25–$50) to cover its own expected revenue. * Cross-border and FX conversion fees — applied to cross-border transactions, and frequently marked up above the underlying network exchange rate; this specific line is repeatedly flagged as one of the more opaque items in a processor contract, since the true FX markup (expressed in basis points above the network's own rate) isn't always disclosed clearly upfront. * Early termination fees — a contract exit penalty that can run into the hundreds or low thousands of dollars, worth checking before signing any multi-year agreement. A repeated, practical piece of guidance across sources: request a complete fee schedule, not just the headline processing rate, before comparing offers between providers — a rate that looks competitive on its own can be entirely offset by a stack of fixed monthly fees that a competing, slightly-higher-rate offer doesn't charge at all. Why online transactions cost more than in-person ones

A recurring, specific point worth calling out on its own: card-not-present transactions (online, phone, or keyed-in payments) carry meaningfully higher interchange rates than card-present transactions, because the issuing bank is taking on greater fraud risk without the physical card verification a swipe or chip read provides. Manually keyed-in transactions specifically are commonly cited as carrying an additional 0.3–0.5% premium over a standard swipe or tap, purely due to the elevated fraud risk of unverified manual entry. How to tell what you're actually paying Calculate your effective rate, not your quoted rate. Divide total processing fees paid in a given period by total card volume processed in that same period, then express it as a percentage. Comparing this effective rate to the rate originally quoted at signup is the single most reliable way to spot whether a merchant's transaction mix is being routinely downgraded into more expensive categories (a tiered-pricing risk) or whether hidden fixed fees are eating into an apparently competitive headline rate (a flat-rate or subscription risk). Ask specific, itemized questions before signing with any processor, rather than comparing only the headline rate: * What is the FX markup on cross-border transactions, expressed in basis points above the underlying network rate? * Is there a monthly minimum, and what specifically triggers it? * Is PCI compliance billed separately, and what's the non-compliance penalty?

* What are the early termination terms and cancellation cost? * What is the exact chargeback fee per dispute, and is a separate fee charged for representment? A few concrete, low-effort ways to lower the underlying cost, independent of which processor is chosen: * Ensuring proper AVS (address verification) matching on online transactions can qualify a transaction for a lower interchange category, since it demonstrates additional verification the issuer's risk model rewards. * Batching out (settling) transactions promptly, ideally within the window some interchange categories require (commonly cited as within 24 hours) to qualify for the lowest available rate on that transaction type. * Reducing manually keyed-in entries where possible, since keyed transactions carry a meaningful, avoidable premium versus swiped, tapped, or properly tokenized entries. Quick reference Component / model Who sets it Negotiable? Typical share/range Interchange Card networks No 70–80% of total cost Assessments (network fees) Card networks No ~0.13–0.16% of volume Processor markup Your processor Yes 20–30% of total cost Interchange-plus pricing

Markup portion only ~1.7–2.1% effective rate Flat-rate pricing

Rate itself, sometimes ~2.9% + $0.30 (common example) Tiered pricing

Rarely worth negotiating — avoid Headline rate often not the real rate Subscription pricing

Subscription fee + per-transaction fee Best at high volume Chargeback fee Processor Sometimes $15–$100 per dispute PCI compliance fee Processor Sometimes $75–$150/year

This guide synthesizes publicly available payment-industry documentation, processor pricing guides, and merchant-advisory content on payment processing fee structures. Specific rates, fee amounts, and ranges vary by processor, card type, region, and merchant risk profile — treat the figures here as directional benchmarks rather than fixed pricing for any specific provider.