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 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. 1. Underlying card or payment-method cost Examples can include: * Interchange * payment-method operator cost * other underlying method economics depending on the method and contract. 2. PSP/acquirer markup The commercial amount charged by the acquiring or payment-service layer above relevant underlying costs. 3. Fixed transaction charges Examples: * Per-payment fee * per-authorization charge * per-attempt charge where applicable. 4. 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. 5. 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. 6. FX Identify: * Who performs conversion? * Which currencies trigger it? * What fee or spread applies? * Does settlement conversion occur separately? 7. Refund and dispute cost Include contractually applicable: * Refund charges * retained original charges * dispute fees * chargeback fees * representment charges as relevant. 8. Gateway, platform, and account charges Examples may include: * Monthly platform charge * gateway charge * account fee

* tokenization * reporting * ancillary services only where actually charged separately. 9. Monthly minimums and commitments Identify: * Minimum monthly fee * minimum transaction volume * minimum processing revenue * annual commitment * tier qualification 10. 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 SEO title: How to Read a PSP Pricing Proposal: Merchant Guide 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/ Primary keyword: how to read a 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: 1. What does the headline percentage include? 2. Is interchange included? 3. Are scheme fees included? 4. What portion is provider/acquirer markup? 5. Which card categories are excluded? 6. How are foreign-issued cards priced? 7. What constitutes cross-border? 8. Which payment methods have separate pricing? 9. Which transactions have fixed fees? 10. Are unsuccessful attempts billed? 11. How are refunds charged? 12. How are disputes charged? 13. Is FX separately charged? 14. What conversion methodology is used? 15. Are gateway/platform/account charges separate? 16. What minimums apply? 17. How do volume tiers qualify? 18. Which entities' volume can aggregate?

19. What triggers repricing? 20. Which costs can change automatically when networks change fees? 21. What settlement/remittance charges exist? 22. 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.