How Payment Processing Fees Work
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
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:
Is the card considered international relative to this acquiring transaction?
Does interchange change?
Is there a network cross-border charge?
Does the acquirer add a cross-border markup?
Does the PSP add one?
Does FX occur?
Who performs that FX?
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
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/
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:
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.
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.
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.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗