How to Read a PSP Pricing Proposal
How to Read a PSP Pricing Proposal: A Merchant Guide to Rates, Markups, Minimums, and Hidden Assumptions Provider A quotes: 1.9% Provider B quotes: 1.3% + interchange + scheme fees Which PSP is cheaper? There is no responsible answer yet. Provider A's 1.9% might include most card
How to Read a PSP Pricing Proposal: A Merchant Guide to Rates, Markups, Minimums, and Hidden Assumptions
Provider A quotes:
1.9%
Provider B quotes:
1.3% + interchange + scheme fees
Which PSP is cheaper?
There is no responsible answer yet.
Provider A's 1.9% might include most card costs but exclude international cards, FX, refunds, disputes, and a monthly platform fee.
Provider B's 1.3% might be only the provider/acquiring component sitting on top of transaction-dependent interchange and network costs.
One proposal might assume a domestic consumer-card portfolio.
The other might have been priced against global card volume.
One might display the best rate available after a volume threshold the merchant has never reached.
The other might carry a monthly minimum that disappears from the sales presentation but not from the contract.
Both quoted percentages can be accurate.
They still may not be comparable.
A PSP pricing proposal becomes commercially meaningful only after it has been translated into the merchant's actual transaction economics.
The task is therefore not to find the smallest percentage in a spreadsheet.
It is to normalize every proposal against the same:
payment volume
→ transaction count
→ ticket size
→ card mix
→ payment-method mix
→ countries
→ currencies
→ cross-border share
→ FX requirements
→ refunds
→ disputes
→ fixed costs
→ commitments
and then ask which provider produces the strongest commercial outcome.
The lowest quoted rate may not be the lowest-cost proposal
A PSP proposal typically gives procurement a pricing expression.
What finance needs is a cost function.
Those are different things.
Consider:
Proposal A
1.90%
Proposal B
1.30% + interchange + scheme fees
The merchant sees:
1.3 < 1.9
and may instinctively rank B first.
But interchange is itself transaction-dependent. Mastercard's current merchant documentation says interchange can depend on factors including merchant category, authorization-to-clearing timing, transaction data, product type, geography, and merchant volume, and that different requirements apply to different interchange programs.
Visa similarly distinguishes interchange from the merchant discount—the commercial amount a merchant negotiates with its financial institution—and notes that the merchant's price can encompass multiple processing services.
So:
1.30% + unknown underlying costs
cannot be compared directly with:
1.90% with unknown inclusions and exclusions.
First normalize both.
Step 1: identify the pricing model before comparing the price
Do not begin with the number.
Begin with:
What does this number represent?
A card proposal might be structured as:
Blended pricing
Interchange++
another cost-plus arrangement
flat merchant pricing
multiple card-category rates
region-specific pricing
a hybrid structure
A local payment method might use an entirely different commercial structure.
The labels matter less than the contract mechanics.
Ask:
Does the quoted rate include underlying card costs?
If yes:
Which ones?
Is interchange passed through?
If yes:
At actual transaction-level cost, modeled cost, or another basis?
Are network/scheme costs included?
Or separately charged?
Does the percentage include the acquirer's economics?
Does it include the PSP markup?
Is there also a fixed transaction charge?
Does the same rate apply to every card category?
Until these are answered, the percentage is not decision-ready.
A proposal should be decomposed before it is evaluated
The merchant's first task is to translate provider terminology into common economic categories.
Use the:
PSP Pricing Proposal Normalizer
Every charge belongs in one of ten buckets.
Underlying card or payment-method cost
Examples can include:
Interchange
payment-method operator cost
other underlying method economics
depending on the method and contract.
PSP/acquirer markup
The commercial amount charged by the acquiring or payment-service layer above relevant underlying costs.
Fixed transaction charges
Examples:
Per-payment fee
per-authorization charge
per-attempt charge
where applicable.
Payment-method-specific fees
Cards may price differently from:
Bank payments
wallets
direct debit
local methods
carrier payments
BNPL
cash/voucher products
Do not assume one merchant-wide percentage applies to all of them.
Cross-border costs
Identify separately:
Network cross-border costs
acquiring surcharge
PSP surcharge
where applicable.
Do not combine them into one imaginary universal international fee.
FX
Identify:
Who performs conversion?
Which currencies trigger it?
What fee or spread applies?
Does settlement conversion occur separately?
Refund and dispute cost
Include contractually applicable:
Refund charges
retained original charges
dispute fees
chargeback fees
representment charges
as relevant.
Gateway, platform, and account charges
Examples may include:
Monthly platform charge
gateway charge
account fee
tokenization
reporting
ancillary services
only where actually charged separately.
Monthly minimums and commitments
Identify:
Minimum monthly fee
minimum transaction volume
minimum processing revenue
annual commitment
tier qualification
Conditional and ancillary charges
Anything commercially relevant that does not fit neatly above.
Examples might include:
Additional risk services
specialized reporting
payout/remittance costs
compliance administration
special support packages
The objective is not to decide whether every fee is good or bad.
The objective is to make the two proposals speak the same accounting language.
Step 2: separate pass-through cost from provider economics
This distinction changes negotiation strategy.
Pass-through cost
An underlying cost that the provider passes to the merchant under the applicable pricing model.
For cards, that can include interchange and scheme/network costs.
Provider or acquirer markup
Commercial pricing added by the institution providing acquiring, processing, PSP, or related services.
Mastercard explicitly distinguishes interchange from the Merchant Discount Rate negotiated between acquirers and merchants and states that Mastercard does not participate in acquirer–merchant pricing agreements.
Visa likewise states that merchants negotiate merchant discount with their financial institution rather than directly paying interchange reimbursement fees.
That means procurement needs at least two questions:
What underlying costs does this proposal expose?
and:
What economics does the provider itself control?
Those are not the same negotiation.
Do not assume “pass-through” means “no markup”
A proposal might say:
Interchange at cost
or:
Scheme fees passed through
That wording still needs contractual definition.
Verify:
Which fee schedule is used?
Which geography?
Which network?
How adjustments are treated?
Are costs passed through exactly?
Is any uplift applied?
Are costs aggregated?
How are corrections and delayed charges handled?
The phrase:
pass-through
is not a substitute for a fee definition.
Step 3: find the markup
Under an Interchange++ or another pass-through structure, markup may be relatively visible.
For example:
**Interchange
scheme cost
0.25%
$0.05**
The 0.25% and $0.05 may represent part of the commercially negotiable provider/acquirer pricing.
Under a blended structure:
1.90% + $0.05
the provider's retained economics may be less obvious because underlying cost variability sits inside the merchant rate.
This does not make the blended proposal automatically expensive.
It makes margin attribution harder.
Provider-margin visibility and total cost are separate questions.
A visible markup can be small while total cost is high
Suppose:
Proposal A
Blended:
1.85%
Proposal B
Interchange + scheme + 0.15%
Procurement focuses on:
only 15 basis points of markup.
But if the merchant's actual weighted interchange and scheme costs equal:
1.90%
then Proposal B costs:
2.05%
before any other charges.
The smaller visible markup did not create the cheaper proposal.
Always compare:
total modeled cost
before celebrating:
low provider markup.
Step 4: identify every fixed fee
Percentages attract attention because they scale with revenue.
Fixed costs are easier to overlook.
A proposal may contain:
$0.05 per payment
$0.10 per authorization
monthly gateway charge
monthly account charge
fixed refund charge
fixed dispute fee
payout/remittance charge
A fixed charge has different economics at different ticket sizes.
Suppose a fictional provider charges:
$0.20 per successful transaction.
On a:
$5 purchase
the fixed fee alone equals:
4% of transaction value.
On:
$200
it equals:
0.10%.
That is why procurement needs:
transaction count
and:
transaction value.
Volume alone is insufficient.
Average ticket is useful—but transaction distribution is better
Suppose both merchants average:
$50 per transaction.
Merchant A mostly processes transactions between $45 and $55.
Merchant B processes:
thousands of $5 payments
a smaller number of $500 payments
They can have the same average ticket and very different fixed-fee economics.
For a high-quality model, use:
Transaction count
median ticket
ticket-size distribution
where available.
Do not let the average conceal the portfolio.
Step 5: test the volume tiers
Pricing proposals often contain something like:
From 1.5%
or:
1.5% at $20 million monthly volume
while the merchant currently processes:
$8 million.
Do not put 1.5% into the model.
Put the rate the merchant is reasonably expected to qualify for.
For every tier record:
Qualification period
qualifying volume
qualifying products
qualifying countries
whether volume aggregates across entities
whether the tier applies retrospectively or prospectively
consequences of falling below it
The best-case tier belongs in an upside scenario.
It does not belong in the base case unless the merchant actually expects to meet it.
Monthly minimums can reverse a headline-rate advantage
Suppose:
Provider A
Higher variable rate.
No minimum.
Provider B
Lower variable rate.
$50,000 monthly minimum fee commitment.
If the merchant's modeled transaction fees total:
$62,000
the minimum does nothing.
If seasonal volume falls and modeled fees total:
$34,000
the merchant may still owe the contractual minimum, depending on how the clause is written.
The economically relevant rate then rises.
A minimum is therefore not merely a contract term.
It is part of the pricing formula.
Annualize commitments
For every proposal calculate:
Annual fixed and minimum contractual cost
even if the provider quotes it monthly.
Include, where applicable:
Monthly account fees
platform fees
minimum revenue commitments
gateway minimums
support packages
annual fees
A merchant comparing:
1.70%
with:
1.75%
may spend days debating five basis points while overlooking a six-figure annual fixed commitment.
Normalize first.
Step 6: isolate cross-border costs
“International pricing” is one of the easiest places for unlike proposals to look deceptively similar.
A cross-border card payment can potentially involve different:
Interchange treatment
network costs
acquiring economics
provider pricing
FX
Mastercard's current U.S. merchant documentation, for example, explicitly distinguishes U.S. interchange from interregional interchange for non-U.S.-issued cards used at U.S. merchants.
That demonstrates the principle:
international-card mix can alter the underlying card economics before a PSP-specific international surcharge is even considered.
Therefore separate:
Underlying cross-border card cost
from:
Provider cross-border surcharge
from:
FX.
Do not merge all three into:
international fee = 0.8%
unless the proposal truly packages them that way.
Merchant country and card country are different fields
A proposal may describe:
domestic cards
without saying:
domestic relative to what?
Potential reference points include:
Merchant legal entity
acquiring entity
merchant location
issuer country
transaction processing region
Get the provider to define it.
A multinational merchant cannot reliably model cross-border cost with only:
customer country.
Step 7: isolate FX
FX can quietly overwhelm differences in transaction markup.
Imagine:
Provider A
Card processing:
1.80%
FX:
1.25%
Provider B
Card processing:
1.95%
FX:
0.50%
If a large share of the merchant's volume requires conversion, A's lower processing rate may be commercially irrelevant.
The model needs:
Presentment currency
processing currency
settlement currency
conversion provider
conversion point
FX fee/spread
proportion of volume converted
The Currency & Pricing cluster should own the deeper FX mechanics.
For proposal analysis, the requirement is simpler:
Put merchant FX cost into the same economic model.
“No FX fee” is not enough information
Ask:
What rate is used?
A proposal can contain no separately labeled conversion fee while still producing conversion economics through the applied exchange rate.
Do not mark:
FX = zero
solely because the fee table contains no row called:
FX fee.
Verify the conversion methodology.
Step 8: model refunds
Refund economics vary by provider, payment method, network, and contract.
Questions include:
Is there a refund-processing fee?
Is the original PSP fee returned?
Are fixed charges retained?
How are underlying card costs handled?
What happens with partial refunds?
Does a local method allow merchant-initiated refund at all?
The correct model therefore needs the merchant's:
refund count
and, where relevant:
refund value.
A travel merchant and a digital-goods merchant may evaluate the same PSP proposal very differently simply because their refund profiles differ.
Do not use the provider's perfect-sale scenario if that is not the merchant's business.
Step 9: model disputes separately from refunds
A refund is not a chargeback.
A dispute can create:
Dispute fee
lost transaction value
representment cost
payment-operations labor
fraud loss
depending on the case.
Visa describes a dispute as a reversal of some or all of the transaction value through the issuer/acquirer process.
The merchant's provider contract determines any additional provider-side charge.
Therefore ask for:
dispute fee
chargeback fee
representment fee if applicable
alert/early-warning fees if used
fee treatment if merchant wins
fee treatment if dispute is prevented
Then model actual merchant dispute frequency.
Step 10: find the charges outside transaction pricing
The proposal may have an attractive transaction page and an expensive appendix.
Check for:
Gateway charge
platform fee
merchant-account fee
setup charge
tokenization/vault fees
reporting charges
payout charges
remittance fees
specialized risk products
support packages
compliance administration
termination obligations
Do not assume these exist.
Do not assume they do not.
Ask for a complete fee schedule.
Public pricing is not the negotiated proposal
A provider website may show:
From X%
That is useful for preliminary screening.
It is not necessarily the economics an international merchant will contract.
Likewise, an enterprise sales proposal may contain:
Merchant-specific pricing
volume assumptions
product scope
country restrictions
negotiated tiers
special service terms
Always distinguish:
Public/list pricing
General published commercial information.
Sales proposal
Commercial offer presented to the merchant.
Contracted pricing
What the signed agreement actually makes enforceable.
Billed pricing
What appears on transactions, invoices, and settlement after launch.
Procurement should reconcile all four.
Now normalize the proposals
Consider this completely hypothetical merchant.
Merchant profile
Monthly successful payment value:
$10,000,000
Successful payments:
200,000
Average ticket:
$50
Value mix:
70% cards
20% local alternative methods
10% bank-based methods
Of card volume:
25% international-issued cards
FX required:
15% of total payment value
Refund frequency:
3% of successful payments
Dispute frequency:
0.4% of successful card payments
These figures are invented solely to demonstrate the model.
Hypothetical Proposal A
Cards
Domestic:
1.90% blended
International-issued:
1.90% + 0.60%
Local methods
2.40%
Bank methods
1.00%
Fixed transaction fee
$0.05
FX
0.80%
Refund
$0.20
Dispute
$15
Platform
$2,000/month
No minimum.
Again: these are fictional numbers.
Hypothetical Proposal B
Cards
1.30% + actual interchange + scheme costs
For this scenario only, assume modeled combined underlying card cost:
0.90%
Local methods
1.90%
Bank payments
$0.25 per successful bank payment
Fixed transaction fee
$0.03
International-card surcharge
0.30%
FX
0.60%
Refund
$0.10
Dispute
$20
Platform
Included.
Monthly minimum
$25,000
The modeled transaction fees already exceed that minimum in this scenario, so it creates no incremental cost.
Normalize Proposal A
Card cost
Card value:
$7,000,000
Domestic card value:
$5,250,000
International card value:
$1,750,000
Domestic card cost:
$99,750
International card cost:
$43,750
Total:
$143,500
Local methods
$2,000,000 × 2.40%:
$48,000
Bank methods
$1,000,000 × 1.00%:
$10,000
Fixed transaction charges
200,000 × $0.05:
$10,000
FX
$1,500,000 × 0.80%:
$12,000
Refund charges
6,000 × $0.20:
$1,200
Dispute charges
Approximately 560 modeled disputes × $15:
$8,400
Platform
$2,000
Modeled monthly payment cost
$235,100
Modeled effective rate
2.351%
Normalize Proposal B
Cards
$7,000,000 × modeled 2.20%:
$154,000
That 2.20% combines the fictional:
0.90% underlying card cost + 1.30% quoted commercial component.
Local methods
$2,000,000 × 1.90%:
$38,000
Bank methods
20,000 modeled transactions × $0.25:
$5,000
Fixed transaction charges
200,000 × $0.03:
$6,000
International-card surcharge
$1,750,000 × 0.30%:
$5,250
FX
$1,500,000 × 0.60%:
$9,000
Refund charges
6,000 × $0.10:
$600
Dispute charges
Approximately 560 × $20:
$11,200
Modeled monthly payment cost
$229,050
Modeled effective rate
2.291%
Under the fictional current merchant mix:
Proposal B is approximately $6,050 cheaper per month.
Not because:
1.3% is lower than 1.9%.
Because after every modeled component is normalized, B produces the lower total cost for this specific portfolio.
That distinction matters.
One scenario is not enough
The merchant has learned what the proposals would cost under one assumed month.
It has not learned which contract is safer for the next two years.
Now run the:
Three-Scenario Pricing Model
Scenario 1 — Current
Use actual recent merchant data.
For example:
Current volume
actual payment-method mix
current international-card share
current FX volume
current refund frequency
current dispute frequency
current ticket size
This tells procurement:
What would each proposal have cost us if it had been in place recently?
This should usually be the base case.
Scenario 2 — Growth
Now model the business the merchant expects to become.
Suppose expansion changes the mix to:
Higher total volume
more local payment methods
more international cards
more FX
different payment-method distribution
Under the fictional model above, a growth scenario could increase the importance of Provider B's lower local-method and FX pricing enough that B remains cheaper even as its pass-through card cost rises.
That result should not be assumed.
It should be calculated.
The important question is:
Does the contract improve or deteriorate as our actual growth strategy changes the payment mix?
Scenario 3 — Adverse
Now test a mix that is economically worse.
For example:
Volume falls
average ticket falls
international-card share rises
premium/commercial-card share rises
refunds increase
disputes increase
FX volume increases
In such a scenario, the same hypothetical Proposal B can become more expensive because:
more underlying card cost passes through;
the merchant has more international cards;
dispute costs rise;
a minimum commitment could become relevant.
Meanwhile the blended card component of Proposal A may shelter the merchant from some card-cost variability within its contractual scope.
The winner can flip.
That is exactly why the adverse case exists.
A useful scenario output
Procurement should end up with something like:
Metric
Current
Growth
Adverse
Payment volume
$___
$___
$___
Transactions
Average ticket
$___
$___
$___
Card share
___%
___%
___%
International-card share
___%
___%
___%
FX volume
___%
___%
___%
Refund rate
___%
___%
___%
Dispute rate
___%
___%
___%
Provider A total cost
$___
$___
$___
Provider B total cost
$___
$___
$___
A effective rate
___%
___%
___%
B effective rate
___%
___%
___%
This is procurement analysis.
Two rows containing:
1.9%
and:
1.3%
are not.
Calculate effective rate consistently
For each proposal:
Effective payment rate
All included modeled payment costs
÷ successful processed payment value
× 100
Before publishing or circulating the number, document the numerator.
Does it include:
Interchange?
scheme costs?
PSP/acquirer markup?
fixed charges?
platform fees?
FX?
refunds?
disputes?
minimums?
If Team A reports:
2.1%
and Team B reports:
2.4%
they may simply be using different numerator definitions.
Denominator discipline begins with numerator discipline.
Calculate payment cost per successful payment
Formula
Total applicable payment costs
÷ successful payments
This matters where ticket sizes vary.
A provider with a higher percentage but lower fixed fee can look different on:
$5 transactions
versus:
$500 transactions.
Calculate payment cost per completed order
Where checkout-performance data is available:
Formula
Relevant payment costs across the defined attempt population
÷ completed paid orders
This lets merchants consider costs from:
Failed attempts
risk tools
retries
payment processing
in relation to actual commercial outcomes.
Define the scope explicitly.
Known cost, estimated cost, excluded cost
Every model input should receive one of three labels.
Known
Supported by:
Signed proposal
contract
provider statement
historical transaction data
Example:
PSP markup = 0.25%
Estimated
An assumption required to model the proposal.
Example:
Future international-card share = 18%
Excluded
Not yet modeled.
Example:
Internal reconciliation labor
Never hide estimates inside apparently exact effective-rate calculations.
A model that reports:
2.1734%
while using six unverified assumptions is not more accurate because it has four decimal places.
Put the assumptions on the first page
For each provider comparison show:
Data period
Which merchant months supplied the base data?
Volume
What successful processed value?
Transaction count
How many successful payments?
Card mix
Debit/credit, commercial, international, premium where relevant.
Method mix
Cards, wallets, bank payments, local methods.
FX
What proportion converts?
Refunds
What frequency/value?
Disputes
What frequency?
Growth assumptions
What changes?
If those assumptions are hidden, the pricing conclusion cannot be audited.
The best-case tier is not the expected rate
Suppose a provider offers:
Monthly volume
Rate
$0–5m
2.10%
$5–10m
1.95%
$10–20m
1.80%
$20m+
1.65%
A merchant processing:
$8 million
should not put:
1.65%
in the current scenario because sales believes it will grow.
Use:
the expected applicable tier.
Put 1.65% in the growth scenario only if the assumptions support $20 million-plus volume.
Then test the downside.
Ask how volume is measured
A volume tier can depend on:
Authorization volume
successful volume
settlement volume
gross transaction value
net value after refunds
one country
one legal entity
globally aggregated entities
These definitions can change the price without changing the published threshold.
Contract language matters.
Look for cliffs
Some pricing tiers are incremental.
Others can create a sharp change when a threshold is crossed.
Ask:
Does the new rate apply only to volume above the threshold?
Does it apply to all monthly volume?
Does it start the following month?
Is qualification quarterly?
Can prior months be repriced?
A one-line tier table does not answer those questions.
Read the exclusions before the rates
A proposal may say:
1.70% for cards
then exclude:
International cards
commercial cards
premium products
certain countries
certain MCCs
some currencies
from that price.
Those exclusions may contain the transactions that matter most to an international merchant.
A useful due-diligence habit is:
Read the footnotes and exclusions before comparing the headline rates.
Ask what happens when the card mix changes
This matters especially under pass-through pricing.
Mastercard's current interchange guidance explicitly states that different interchange rates have qualification requirements and identifies product type, geography, merchant category, timing, and transaction data among the relevant dimensions.
Therefore an IC++ model built on:
1.2% assumed interchange forever
is not a serious forecast.
At minimum, scenario-test the card mix.
Ask which party bears network-fee changes
Suppose network fees change during the contract.
Under one proposal:
the change is passed through automatically.
Under another:
the provider absorbs the change until repricing.
Under a third:
some components pass through and others do not.
That is not a footnote.
It determines who carries cost volatility.
Ask how repricing works
Identify:
Notice period
network-cost pass-through
regulatory change provisions
material-adverse-change clauses
annual repricing
volume repricing
risk-related repricing
new-country pricing
A three-year contract does not necessarily mean:
today's rate lasts three years.
The pricing-adjustment language matters as much as the initial quote.
Settlement terms belong in commercial due diligence
Settlement speed is not necessarily a fee.
But it can affect merchant liquidity.
Compare:
Settlement cadence
payout threshold
reserve
holdback
settlement currencies
remittance cost
separately from the processing-rate model.
Do not incorrectly add an entire reserve to processing expense.
A reserve is a liquidity restriction, not automatically a fee.
But procurement should still evaluate its working-capital effect.
Capability comparison must be separate from price comparison
After normalization, suppose:
PSP A
Effective modeled rate:
2.10%
PSP B
Effective modeled rate:
2.18%
Does A automatically win?
No.
Now compare provider capability.
For the merchant's actual requirements:
Which countries are supported?
Which local methods?
Which currencies?
Which recurring methods?
Which acquiring markets?
Which refund flows?
Which reporting APIs?
Which dispute tools?
Which settlement currencies?
Which integration architecture?
A cheaper provider that cannot process a strategically important customer population is not functionally equivalent.
Cost comparison and capability comparison should be two scorecards
Do not bury everything in one weighted score too early.
First calculate:
Cost scorecard
Monthly modeled cost
effective rate
cost per successful payment
cost per completed order
downside scenario
fixed commitment
FX exposure
Then separately:
Capability scorecard
Payment-method coverage
market coverage
acquiring reach
currencies
tokenization
recurring support
reporting
reconciliation
refund/dispute workflows
support
implementation requirements
Only then make the commercial decision.
Otherwise the team can accidentally assign:
one point for 10 basis points
and:
one point for missing Brazil
as if those were equivalent.
Authorization performance can dominate a small price difference
Suppose a merchant processes:
100,000 payment attempts
with:
$50 average order value.
Provider A costs less per successful transaction but approves or completes meaningfully fewer valid customer payments.
The lost orders can exceed the fee savings.
That does not justify assuming the more expensive PSP has better acceptance.
It means procurement needs measured performance data where available.
The relevant decision may become:
Net contribution per 1,000 payment attempts
rather than:
Processor fee percentage
This is why commercial pilots and historical provider data can matter alongside the pricing model.
A local payment method can look expensive while creating incremental value
Suppose a local method costs more than card acceptance.
If every user selecting it would otherwise have paid successfully by card, it may simply shift volume to a more expensive method.
If it reaches customers who could not otherwise pay, it can create incremental completed orders.
Do not ask only:
What does Method X cost?
Ask:
What economically valuable transaction does it enable?
The dedicated Payment Method Fees Explained article should own the detailed method comparison.
The pricing proposal should still model each method separately.
Negotiate the provider-controlled parts first
Once the proposals are normalized, procurement can see where negotiation has leverage.
Potential targets may include:
PSP markup
acquirer margin
fixed per-transaction markup
volume tiers
gateway/platform fee
monthly minimum
refund/dispute fees
settlement terms
ancillary services
Underlying network and regulated costs may be less directly negotiable by the individual merchant depending on the model.
Visa and Mastercard both distinguish interchange from the merchant's commercial acquiring relationship, reinforcing why the cost owner should be identified before negotiation.
Negotiate the fee that matters, not the fee that is easiest to see
Suppose provider markup equals:
0.20%
but FX creates:
0.90%
on 40% of the merchant's volume.
Procurement spends two weeks reducing markup by:
3 basis points
while leaving FX unchanged.
The negotiation achieved:
0.03% × applicable processing volume
while ignoring a much larger cost pool.
Normalize before prioritizing negotiation.
Rank negotiation targets by annual impact
For every negotiable component calculate:
current modeled annual cost
then:
realistic negotiated annual cost
then:
Potential annual savings
Current modeled cost − proposed negotiated cost
This stops procurement from treating:
$5 less per dispute
and:
10 basis points on $100 million
as similar wins.
Price minimums using downside volume
A minimum should be negotiated using the month when the merchant is most likely to miss it.
Ask:
What was our lowest month last year?
What happens during seasonality?
What if a major market migration is delayed?
What if we multi-source volume?
A minimum calibrated to today's entire payment volume can become expensive if the merchant later adds a second PSP.
Architecture decisions therefore belong in commercial forecasting.
Multi-PSP strategy changes proposal economics
If the merchant expects to route only:
40% of total transactions
to Provider B, then B's:
Volume tier
minimum
pricing commitment
must be modeled against that 40%.
Do not give each competing PSP the entire merchant volume inside its business case unless the merchant genuinely plans to award all volume to each one.
That creates fictional pricing.
Use provider statements to validate the proposal after launch
The due-diligence process should not end at signature.
Reconcile:
Proposal
→ Contract
→ Transaction data
→ Provider invoice
→ Settlement
→ Accounting
For each month verify:
Correct transaction rate
correct tier
correct card classification
correct country pricing
correct FX treatment
correct fixed fees
correct refund/dispute charges
correct minimum
The model becomes the benchmark for invoice QA.
EU card regulation provides a useful transparency example
Within its scope, Article 9 of Regulation (EU) 2015/751 requires acquirers to offer merchant service charges individually specified for card brands/categories with different interchange levels unless the merchant requests blended charges in writing. It also calls for agreements to specify merchant service charges, interchange fees, and scheme fees by relevant card category and brand unless the merchant requests otherwise.
Article 12 additionally requires transaction information that separately indicates the merchant service charge and interchange amount, while allowing aggregation with the merchant's prior explicit consent.
This is useful evidence for the principle of cost disaggregation, but it should not be generalized into a universal global disclosure rule.
Jurisdiction matters.
The same terms also explicitly state that additional fees may apply for:
cross-border transactions;
foreign-exchange services;
and identify other potential deductions or costs including:
transaction fees;
dispute-related charges;
remittance costs;
refund costs;
monthly account fees;
third-party processing fees;
chargebacks;
currency-exchange fees;
within the applicable agreement and fee schedule.
This is precisely why a merchant should never summarize a PSP proposal as:
or any other provider as:
“Provider Y costs Y%.”
The contracted economic model is broader than one number.
Merchant-specific commercial terms still need to be modeled.
The PSP Pricing Proposal Normalizer
Before a pricing proposal goes to final approval, procurement should complete this table for every provider.
Cost bucket
Provider A
Provider B
Source
Status
Underlying card/payment cost
Contract / assumption
Known / estimated
PSP/acquirer markup
Proposal
Known
Fixed transaction charge
Proposal
Known
Card category exceptions
Contract
Known
Local-method fees
Fee schedule
Known
Cross-border cost
Contract
Known
FX
Contract / methodology
Known/estimated
Refund cost
Contract
Known
Dispute cost
Contract
Known
Gateway/platform/account
Contract
Known
Monthly minimum
Contract
Known
Volume tiers
Proposal
Known
Settlement/remittance cost
Contract
Known
Other ancillary fees
Contract
Known
Modeled total monthly cost
Model
Calculated
Effective rate
___%
___%
Model
Calculated
A blank cell means:
the proposal is incomplete.
It does not mean:
zero cost.
The Three-Scenario Pricing Model
Run the completed normalizer through three merchant futures.
Current
Use actual transaction data.
Purpose:
Which proposal would have been cheaper recently?
Growth
Use planned:
Markets
methods
currencies
volume
ticket size
Purpose:
Which contract fits the business we are building?
Adverse
Stress:
International cards
expensive card mix
lower ticket
refunds
disputes
FX
lower volume against minimums
Purpose:
Where can this contract hurt us?
A procurement decision based only on the current scenario is incomplete.
A decision based only on the growth case is optimism disguised as finance.
Keep the model versioned
For every commercial decision record:
Proposal date
provider
proposal version
contract version
merchant dataset period
assumptions
exchange-rate assumptions if relevant
card-cost assumptions
growth scenario
approval date
When pricing changes later, the organization can answer:
What did we believe when we signed?
rather than reconstructing the model from old email threads.
Final procurement checklist
Before selecting a PSP, procurement should be able to answer all of the following.
Pricing structure
Is pricing blended, IC++, cost-plus, flat, hybrid, or method-specific?
What exactly does the headline rate include?
What is excluded?
Cards
Is interchange included or passed through?
Are scheme fees included?
What is the PSP/acquirer markup?
Are international cards priced separately?
Are commercial/premium cards different?
Is recurring ecommerce priced differently?
Transaction fees
Is there a fixed fee?
Authorization fee?
Failed-attempt fee?
Tokenization or vault charge?
Alternative payment methods
What is each method's pricing?
Are fixed costs involved?
Do countries have different commercial terms?
International
How is cross-border defined?
What surcharge applies?
Who performs FX?
What conversion methodology applies?
Which settlement currencies are available?
Events
Refund pricing?
Partial-refund pricing?
Dispute/chargeback pricing?
Representment or alert pricing?
Fixed economics
Platform fee?
Gateway fee?
Account fee?
Monthly minimum?
Annual commitment?
Setup cost?
Tiers
Which tier will current volume actually reach?
How is qualifying volume measured?
Are legal entities aggregated?
What happens when volume falls?
What happens when volume grows?
Commercial terms
Contract length?
Repricing provisions?
Network-fee pass-through?
Regulatory-change language?
Termination conditions?
Settlement terms?
Reserve requirements?
Modeling
Current scenario complete?
Growth scenario complete?
Adverse scenario complete?
Effective rate calculated?
Cost per successful payment calculated?
Cost per completed order calculated where possible?
Known versus estimated assumptions labeled?
Capabilities
Required countries?
Required methods?
Required currencies?
Recurring?
Refunds?
Reporting?
Reconciliation?
Routing/acquiring?
Support requirements?
If procurement cannot complete the checklist, it is not yet comparing two payment providers.
It is comparing two marketing quotes.
Final recommendation
Do not ask:
Which provider quoted the lowest processing percentage?
Ask:
What will each contract cost our actual business?
Take every proposal and break it into:
underlying card/payment cost
PSP/acquirer markup
fixed transaction charges
method-specific pricing
cross-border cost
FX
refunds and disputes
gateway/platform/account charges
minimums and commitments
conditional costs
Then apply the same:
volume
transaction count
ticket distribution
card mix
payment-method mix
country mix
currency mix
refund profile
dispute profile
to every provider.
Calculate:
total monthly payment cost
effective payment rate
cost per successful payment
and, where the data supports it:
payment cost per completed order.
Then run the model again for:
growth
and:
an adverse mix.
Only after the economic comparison is complete should the merchant compare:
payment performance
customer access
operational reliability
settlement
reporting
and:
required capabilities.
A 1.3% quote is not automatically cheaper than a 1.9% quote.
A pass-through proposal is not automatically cheaper than a blended proposal.
The highest volume tier is not your price if you will never reach it.
A missing line item is not zero.
And a provider with a lower modeled processing cost can still be the more expensive commercial choice if it materially reduces successful payment completion or lacks payment capabilities the merchant needs.
A PSP pricing proposal is not a rate.
It is a set of equations, assumptions, exclusions, and commercial obligations applied to the merchant's transaction portfolio.
Normalize those equations first.
Then decide.
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 brief makes this the commercial decision-making capstone of the Payments Pricing Fundamentals cluster. Earlier articles explain individual cost layers; this one should force those layers back into a single merchant model and answer the procurement question: what will this contract actually cost our business under the transaction mix we expect to process?
Editorial decision
Direction
Merchant cost problem
Providers quote unlike rates, assumptions, tiers, and fee labels that merchants compare as though they were equivalent
Unique evidence anchor
Two proposals cannot be compared until both are translated into the same merchant economics
Editorial position
Reject headline-rate comparisons; normalize every offer against identical volume, ticket, method, card, geography, refund, dispute, and FX assumptions
Assumption challenged
“The provider quoting the lowest percentage is offering the lowest-cost contract.”
Fee owner
Multiple underlying participants; the PSP proposal is the commercial wrapper that must be decomposed
Merchant decision
Compare expected total cost, downside sensitivity, payment performance, capabilities, and negotiable provider economics
Format
PSP proposal teardown and normalization exercise
Primary asset
PSP Pricing Proposal Normalizer
Secondary asset
Three-Scenario Pricing Model
Original asset: PSP Pricing Proposal Normalizer
The supporting visual should start with two deliberately incompatible offers:
PROVIDER A
1.90%
versus
PROVIDER B
1.30% + Interchange + Scheme
Then both feed into a large normalization block:
1 — Underlying Card / Method Cost
2 — PSP / Acquirer Markup
3 — Fixed Transaction Fee
4 — Method-Specific Fees
5 — Cross-Border
6 — FX
7 — Refund / Dispute
8 — Gateway / Platform / Account
9 — Minimums / Commitments
10 — Conditional Charges
Then:
APPLY SAME MERCHANT MIX
Volume · Transactions · Ticket Size · Cards · Methods · Countries · FX · Refunds · Disputes
Then three columns:
CURRENT | GROWTH | ADVERSE
Each ends with:
Total Monthly Cost
Effective Rate
Cost / Successful Payment
And finally:
COST COMPARISON
plus, separately:
CAPABILITY / PERFORMANCE COMPARISON
Suggested caption: “A PSP quote becomes comparable only after both proposals are translated into the same merchant transaction economics.”
Image alt text: “PSP Pricing Proposal Normalizer comparing two unlike payment-provider quotes by underlying costs, markup, fixed fees, payment methods, cross-border fees, FX, refunds, disputes, platform charges and minimum commitments across current, growth and adverse merchant scenarios.”
SEO metadata
H1: How to Read a PSP Pricing Proposal: A Merchant Guide to Rates, Markups, Minimums, and Hidden Assumptions
Meta description: Learn how to compare PSP pricing proposals by normalizing interchange, scheme fees, markup, fixed costs, cross-border, FX, refunds, disputes, minimums and volume tiers against your actual payment mix.
URL slug: /how-to-read-psp-pricing-proposal/
Secondary keywords: PSP pricing proposal, payment provider pricing proposal, compare PSP pricing, payment processing pricing quote, merchant payment pricing, payment provider fees, payment processing contract, effective payment rate.
Related entities: merchant service charge, interchange, scheme fee, acquirer markup, PSP markup, Interchange++, blended pricing, effective payment rate, monthly minimum, volume tier, FX spread, cross-border charge, payment fee schedule, merchant contract.
Article excerpt: Two PSP proposals cannot be compared from their headline percentages. Merchants need to normalize underlying card costs, provider markup, fixed fees, method pricing, cross-border costs, FX, refunds, disputes, minimums and other conditions against the same real transaction portfolio before choosing a provider.
Suggested structured data: Article or BlogPosting, BreadcrumbList, and ImageObject. A generic FAQ is unnecessary because the procurement checklist and proposal-normalization model provide more distinctive utility.
Internal-link architecture
This article should link to all ten preceding pricing-fundamentals pieces, but only at the point where the reader needs the deeper mechanism.
Link How Payment Processing Fees Work when explaining the overall cost stack; Interchange Fees Explained, Card Scheme Fees Explained, Acquiring Fees Explained, and PSP Markup Explained from the relevant normalizer buckets. Link Blended Pricing vs Interchange++ and Flat-Rate vs Cost-Plus Pricing when the first step asks the merchant to identify its pricing model. Link Gateway Fees Explained and Merchant Account Fees Explained from fixed/platform/account charges, and Payment Method Fees Explained when method-specific prices are normalized.
This article should not re-explain those subjects in depth. It owns recombination and commercial decision-making.
Authoritative source recommendations
For card-cost ownership and qualification, use current Visa and Mastercard documentation. Visa currently distinguishes interchange from merchant discount, while Mastercard identifies interchange as one component of MDR and documents several variables that determine qualification.
For European transparency/unblending claims, use Regulation (EU) 2015/751 directly. Article 9 provides the primary legal text on blended versus individually specified merchant service charges and disclosure of interchange and scheme fees; Article 12 addresses transaction-level merchant information.
Proposed author and reviewers
Payments procurement specialist: validate proposal teardown, RFP workflow, commercial assumptions, and negotiation sequence.
CFO / merchant finance reviewer: validate denominators, effective-rate accounting, fixed-cost treatment, scenario analysis, and working-capital boundaries.
Payment pricing analyst: validate interchange/scheme assumptions, payment-method mix, and proposal simulation.
Commercial contracts specialist: review commitments, tiers, repricing, termination, exclusions, and contract-versus-proposal differences.
Payment operations reviewer: validate refund, dispute, reporting, reconciliation, and settlement assumptions.
Named individuals should only be published after completing review.
Pricing fact-check items
Before publication or use in an actual RFP, verify every:
Percentage rate
fixed transaction charge
interchange assumption
scheme-fee assumption
cross-border fee
FX charge/spread
refund fee
dispute fee
platform/gateway fee
account fee
monthly minimum
volume tier
settlement/remittance charge
ancillary service charge
repricing clause
against the current proposal and contract.
A prior provider invoice or public webpage is not proof of the pricing offered to this merchant today.
Fee-owner fact-check items
Every fee should answer:
Field
Requirement
Fee name
Provider terminology
Normalized category
Common merchant model
Economic owner
Issuer/network/acquirer/PSP/method/etc.
Merchant invoicing party
Who actually bills/deducts it
Calculation
% / fixed / monthly / conditional
Pass-through or markup
Verified from contract
Applicable geography
Defined
Applicable method
Defined
Effective date
Defined
Negotiability
Verified rather than assumed
This prevents a PSP line item from being treated as provider margin merely because the PSP invoices it.
Network/interchange fact-check items
Where card pricing is pass-through or partially unblended, verify:
Network
debit/credit
consumer/commercial
card product
issuer geography
merchant/acquiring geography
ecommerce/card-present
recurring status
MCC
transaction value
qualification/data
applicable regulation
Mastercard's current merchant guidance confirms that interchange categories have specific qualification requirements and vary across several of these dimensions.
Provider/acquirer fact-check items
Ask each provider the exact same questions:
What does the headline percentage include?
Is interchange included?
Are scheme fees included?
What portion is provider/acquirer markup?
Which card categories are excluded?
How are foreign-issued cards priced?
What constitutes cross-border?
Which payment methods have separate pricing?
Which transactions have fixed fees?
Are unsuccessful attempts billed?
How are refunds charged?
How are disputes charged?
Is FX separately charged?
What conversion methodology is used?
Are gateway/platform/account charges separate?
What minimums apply?
How do volume tiers qualify?
Which entities' volume can aggregate?
What triggers repricing?
Which costs can change automatically when networks change fees?
What settlement/remittance charges exist?
Which rates differ by country or currency?
Require written answers for commercially consequential terms.
Merchant-model assumptions
The normalizer should ingest the merchant's actual or planned:
Successful payment volume
payment attempts
successful payment count
completed orders
median and average ticket
ticket-size distribution
payment-method mix
card network mix
debit/credit mix
consumer/commercial mix
domestic/international card mix
countries
merchant entities
currencies
FX share
refunds
disputes
recurring/one-time mix
seasonal volume
For future-market assumptions, visibly mark them as estimates.
Proposal and statement fact-check items
Keep separate copies of:
Public pricing → sales proposal → final fee schedule → signed contract → amendments → monthly invoice → settlement report
Then test whether:
transaction prices match;
tiers are correct;
fixed fees match;
card classifications match;
FX matches the contracted methodology;
refund/dispute fees match;
excluded categories are applied correctly;
agreed discounts appear.
The normalizer should remain in use after contract signature as an invoice-control framework.
Regulatory fact-check items
For EU card acquiring, Article 9 and Article 12 of Regulation (EU) 2015/751 provide relevant transparency and unblending rules within the regulation's scope.
Do not generalize those obligations globally.
For every regulatory statement record:
jurisdiction;
merchant/acquirer scope;
card category;
current effective text;
relevant exemptions.
Legal review should confirm any contractual interpretation.
Amber-flag claims
Require direct evidence before saying:
“Provider A is cheaper.”
“Provider B's interchange is X%.”
“Scheme fees are X%.”
“This is a pass-through fee.”
“This charge is non-negotiable.”
“The provider absorbs cross-border costs.”
“FX is free.”
“The highest tier will apply.”
“There are no gateway fees.”
“Refunds are free.”
“Dispute fees are refunded when won.”
“The blended rate includes everything.”
“The price is fixed for three years.”
A blank or omitted fee line should be classified as unknown, never automatically zero.
Applicable legal entity and merchant jurisdiction
current proposal/fee schedule
blended versus unblended options
whether IC++ is offered and under what terminology
interchange treatment
scheme-fee treatment
acquiring margin
PSP markup
fixed transaction pricing
authorization/failed-attempt pricing
local-method pricing
card-category exceptions
cross-border pricing
FX methodology
refunds
disputes
platform/account fees
minimums
volume tiers
settlement/remittance costs
reserve requirements
repricing rights
contract term
reporting granularity
Do not substitute the public Terms page for the merchant's negotiated commercial proposal.
Cluster sameness-audit fields
Title: How to Read a PSP Pricing Proposal: A Merchant Guide to Rates, Markups, Minimums, and Hidden Assumptions
Opening device: 1.9% versus 1.3% + interchange + scheme fees, with no answer possible until normalization.
Merchant cost problem: Unlike provider quotes are treated as comparable percentages.
Fee owner: Multiple layers recombined into one merchant commercial decision.
Primary format: Proposal teardown and normalization exercise.
Unique evidence anchor: Different labels and assumptions make direct rate comparison economically invalid.
Editorial position: Normalize every offer against an identical merchant portfolio.
Merchant decision: Select on modeled total economics plus required capabilities/performance.
Original framework: PSP Pricing Proposal Normalizer.
Secondary framework: Three-Scenario Pricing Model.
Primary metric: Modeled effective payment rate.
Secondary metrics: Monthly payment cost, cost per successful payment, cost per completed order, adverse-scenario exposure.
Pricing example: Two fictional PSP proposals normalized against a $10 million monthly merchant portfolio.
Risk profile: Unknown exclusions, best-case tiers, FX/cross-border exposure, fixed commitments, and card/method-mix changes.
Conclusion: A proposal is a set of equations and assumptions—not a headline percentage.
Closing device: Detailed procurement checklist rather than FAQ.
Cluster differentiation: This is the only article that owns recombining every earlier pricing layer into a merchant procurement decision. It should point to the ten preceding articles for fee mechanics rather than re-owning interchange, scheme fees, acquiring, markup, gateway pricing, or card-pricing-model theory.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗