PSP Markup Explained

PSP Markup Explained: What Merchants Are Paying for Beyond the Payment Rail Provider A costs 20 basis points more than Provider B. But Provider A replaces three integrations, a separate fraud tool, reconciliation work, and several local-payment-method relationships. Which provider is more expensive? The answer cannot be found in the basis-point column alone. A PSP markup is the merchant-facing commercial price of a provider layer sitting above, around, or alongside underlying payment costs. Depending on the provider and contract, that layer may include processing connectivity, acquiring access, integrations, payment methods, risk capabilities, reporting, settlement operations, support, and infrastructure. That makes PSP markup unusual among payment-cost components. It is often negotiable, but reducing it can also change what the merchant receives. The commercial question is therefore not simply “How low can we negotiate the PSP fee?” It is: “What does the PSP markup buy, what would it cost us to replace that capability, and does a lower markup actually reduce cost per completed order?” What PSP markup is—and what it is not PSP markup should first be separated from the underlying economics of moving a payment.

For card transactions, interchange is generally an economic transfer from an acquirer to an issuer. Visa describes interchange reimbursement fees as transfers between acquiring and issuing institutions, while Mastercard likewise identifies interchange as a fee paid by the acquirer to the issuer. That is different from: * Card-scheme or network fees, associated with the card network. * Acquiring economics, charged for the merchant acceptance and acquiring relationship. * PSP markup, representing the provider's commercial charge for the relevant provider layer. * Gateway charges, where technical connectivity or routing is separately priced. * Payment-method-specific costs, where another method or operator has its own economics. The distinction between acquiring and technical processing matters. EU payment-services rules explicitly distinguish acquiring from technical activities such as mere transaction processing and data storage. A single PSP may nevertheless bundle several of these functions into one commercial arrangement. That is why the fee name on a proposal is not enough to establish who ultimately receives the money. Markup is also not the same thing as provider profit A merchant may be able to identify a PSP markup in its contract or invoice. That does not mean the merchant knows the PSP's actual profit margin.

The provider may have its own acquiring, payment-method, infrastructure, fraud, staffing, support, compliance, and technology costs. Commercial markup is therefore the merchant-facing price layer; provider margin is an accounting outcome inside the provider. For procurement, the first is observable and negotiable. The second generally is not. How PSPs can structure markup There is no universal PSP markup formula. A provider commercial layer may appear as: Percentage markup For example: Underlying eligible volume × provider percentage This structure makes PSP cost scale with transaction value. Fixed per-transaction markup For example: Successful transactions × fixed provider fee Fixed fees become proportionally more important as average ticket size falls. Percentage plus fixed markup A provider may combine both components. Volume tiers The price may change after particular monthly or annual processing thresholds. Merchants should model the tiers they are realistically likely to achieve, not only the most attractive rate in a pricing schedule. Recurring or platform charges A commercial arrangement may include monthly platform, gateway, account, reporting, or other recurring charges. Bundled pricing Some providers bundle the provider layer together with underlying costs or other services. In that situation, the merchant may not be able to observe the provider markup directly. The relevant task becomes separating the parts that can be identified and comparing the all-in commercial result.

What the markup may actually be buying The useful way to evaluate PSP pricing is to work backward from the functions the merchant would otherwise need to operate. 1. Processing and access The provider supplies the technical and operational connection required to accept and process transactions. The merchant should ask: What processing infrastructure would we need if this provider disappeared? 2. Integration A PSP can consolidate work that would otherwise require several direct connections. The economic benefit can include: * fewer APIs to build * fewer integrations to maintain * fewer credential and configuration systems * fewer release cycles * less provider-specific monitoring The relevant cost is not simply initial engineering. It is the continuing cost of maintaining the alternative architecture. 3. Acquiring relationships A provider may provide acquiring access directly or through relationships with acquiring partners. The merchant should distinguish the economics of that acquiring layer from the PSP's own commercial charge rather than assuming everything above interchange is PSP margin. 4. Payment-method coverage A single provider relationship can sometimes replace multiple payment-method integrations and commercial relationships. That capability should be evaluated economically. Removing an expensive provider only to recreate several payment-method contracts, implementations, operational processes, and reconciliation feeds can move cost rather than eliminate it. 5. Risk

Risk screening, fraud controls, case management, dispute operations, and related tools can be part of the provider layer. Payment performance and fraud control should be measured together: aggressive risk decisions can reduce fraud while also rejecting legitimate buyers. Authorization optimization is a real operational capability rather than purely a pricing consideration. Both Visa and Mastercard publish merchant-facing material focused on improving authorization performance. 6. Reporting and reconciliation Transaction reporting has an operational cost. The merchant may need to connect authorizations, captures, refunds, adjustments, fees, settlement batches, payouts, and accounting records. Visa, for example, describes transaction-level reporting designed to improve reconciliation speed and accuracy. A merchant evaluating PSP markup should therefore ask how many manual or custom reconciliation processes the provider eliminates. 7. Settlement Settlement capabilities can involve: * payout operations * settlement reporting * currency handling * entity-specific requirements * reconciliation between processed and paid amounts Settlement economics should be separated from detailed treasury and FX strategy, but the operational cost belongs in a provider-value calculation when the PSP is performing the work. 8. Support and operations Payments generate exceptions.

Declines, refunds, disputes, settlement questions, outages, integration issues, payment-method incidents, and risk reviews all require operational ownership. A cheaper provider that transfers much of that work back to the merchant may reduce the PSP invoice while increasing the merchant's internal cost. 9. Platform infrastructure Finally, the provider maintains the systems supporting the payment layer. That can include connectivity, APIs, payment data infrastructure, monitoring, routing, security functions, and provider-side operational tooling. The merchant does not need to assign an arbitrary monetary value to every technical feature. It needs to determine which capabilities it actually uses and what replacing them would cost. The PSP Markup Decomposition A practical PSP evaluation can normalize the provider layer into the following framework: Capability Does the merchant need it? Replacement question Useful measurement Processing/access Yes/no Which processor or connection replaces it? Cost per transaction Integration Yes/no How many integrations would be rebuilt? Engineering cost; integrations avoided Acquiring access Yes/no What alternative acquiring relationships are required? Total acquiring/provider cost Payment-method coverage Yes/no Which direct contracts and integrations replace it? Methods actually used; completed orders Risk Yes/no Which fraud/risk products and team processes replace it? Fraud loss, false positives, approval performance Reporting/reconciliation Yes/no

What finance/data work becomes internal? Hours/FTE cost; reconciliation exceptions Settlement Yes/no What settlement infrastructure replaces it? Settlement errors, delay, operational workload Support/operations Yes/no Who owns exceptions and incidents? Support volume, incident cost, resolution time Platform infrastructure Yes/no What architecture must the merchant operate instead? Infrastructure and maintenance cost Then ask four questions for each row: 1. Do we actually need this capability? 2. Could we replace it more cheaply without losing performance? 3. Does its pricing scale sensibly as our volume grows? 4. Can we measure whether the capability creates value? That turns PSP procurement from rate negotiation into economic decomposition. What parts of PSP pricing are realistically negotiable? The provider's own commercial economics are usually a better negotiation target than pass-through payment costs. Potential negotiation areas can include: * percentage PSP markup * fixed provider transaction fee * volume tiers * minimum commitments * recurring platform charges * gateway charges where separately priced * bundled service scope * ancillary services * settlement commercial terms * contract duration and commitments But the merchant should not assume every line item is equally flexible.

Interchange and card-network charges are different economic layers. Some interchange is also constrained by regulation in particular jurisdictions. For example, the EU Interchange Fee Regulation places caps on specified consumer-card interchange transactions within its scope. Negotiating with a PSP therefore does not automatically change every underlying payment cost. Negotiate the denominator, not only the number When a provider offers “20 basis points,” the merchant should establish: 20 basis points of what? Possible denominators can differ: * processed volume * settled volume * successful transactions * particular payment methods * domestic transactions only * specific currencies or markets For fixed fees, determine which events trigger the charge. For tiers, determine whether they are marginal, retrospective, market-specific, or conditional on a commitment. A smaller number with a broader denominator can cost more than a larger number applied narrowly. How to compare price with capability Consider a hypothetical merchant with: * 100,000 completed orders per month * $5 million in monthly successful processed value * identical underlying interchange, network, and acquiring economics under both options Those underlying costs are excluded here so the example isolates the provider layer. Provider A * 0.40% provider markup * $0.03 per completed transaction * $2,000 monthly platform charge Monthly provider-layer cost: * Percentage markup: $20,000 * Fixed transaction markup: $3,000 * Platform charge: $2,000

Total: $25,000 Provider B * 0.20% provider markup * $0.03 per completed transaction * $500 monthly platform charge Monthly provider invoice: * Percentage markup: $10,000 * Fixed transaction markup: $3,000 * Platform charge: $500 Total: $13,500 Provider B appears $11,500 cheaper. But suppose the merchant's own documented replacement-cost estimates are: * separate fraud tooling: $5,000/month * additional integration maintenance: $10,000/month * reconciliation operations: $6,000/month * payment-method administration/infrastructure: $4,000/month These are hypothetical merchant assumptions, not live provider pricing. Adjusted monthly provider-layer economics become:

Provider A Provider B Provider invoice $25,000 $13,500 Replacement capabilities Included in assumption $25,000 Adjusted provider-layer cost $25,000 $38,500 Cost per completed order $0.25 $0.385 The provider with the 20-basis-point higher markup is cheaper under these assumptions. The lesson is not that expensive PSPs are better. It is that a merchant cannot conclude that a markup reduction is a saving until it has accounted for the capabilities moved elsewhere. When the cheaper PSP really is cheaper Capability analysis must not become an excuse for excessive provider pricing. A lower-markup provider can be the economically correct choice when: * the merchant already operates its own payment orchestration * internal fraud infrastructure makes bundled PSP tools redundant * payment-method connections are already built * reconciliation is standardized internally * the merchant has direct acquiring relationships * provider support receives little use * overlapping services create duplicate cost * growing volume has made the current commercial tier uneconomic For a sophisticated merchant, paying two providers for the same capability is just as wasteful as removing a capability that creates value. This is why the PSP Markup Decomposition begins with: Does the merchant need it? Not: Does the PSP offer it? Approval performance can overwhelm small markup differences Pricing analysis becomes particularly incomplete when providers deliver different payment performance.

Suppose one architecture produces a marginally higher provider charge but converts more legitimate payment attempts into completed orders. The economic comparison should not be: PSP fee ÷ successful transaction value alone. A stronger measure is: Net payment contribution per 1,000 attempts Completed orders × contribution per completed order − payment costs − fraud/dispute losses − relevant payment operating costs This forces the merchant to put payment cost and payment performance on the same economic denominator. The merchant should use contribution, not merely gross transaction value, when estimating the value of additional completed orders. And any claimed approval improvement must be tested against the merchant's own traffic, markets, issuers, authentication configuration, customer mix, and measurement methodology rather than copied from a provider's portfolio-level marketing result. Measure cost per completed order The article's core commercial metric should therefore be: Payment cost per completed order All relevant payment costs associated with payment attempts ÷ completed paid orders For a PSP-markup analysis, useful inputs can include: * PSP markup * other provider charges * relevant external tools * payment operations cost * integration maintenance * reconciliation cost * failed-attempt costs where material * fraud and dispute costs where within scope Separately track: PSP markup rate Identifiable PSP markup ÷ applicable processed value Total provider cost

All charges paid to the provider within the defined scope. Provider-layer cost per completed order Provider cost + replacement/internal provider-related operating costs ÷ completed orders Engineering cost avoided Use documented internal cost or a defensible replacement-cost model rather than an arbitrary value assigned to “simplicity.” Integrations replaced Count active production connections genuinely eliminated by the provider. Payment-performance impact Measure authorization and completion performance using comparable populations and stable definitions. Provider simplicity also creates provider dependency Bundling has another side. A PSP that replaces several integrations can reduce merchant complexity, but it can also become more difficult to replace. The merchant is effectively exchanging: internal architectural complexity for: provider concentration and migration dependency. That trade can be rational. But procurement should evaluate: * data portability * token portability where relevant and available * contract exit provisions * payment-method migration effort * reporting-data access * integration portability * operational knowledge retained internally * migration timelines * business-continuity options A capability is more valuable when it simplifies operations without making an eventual provider change prohibitively difficult. A better PSP negotiation process Instead of opening a commercial review with “reduce the markup by 10 basis points,” use the following sequence.

1. Reconstruct the current provider layer List every PSP charge and every operational capability being consumed. 2. Separate underlying payment costs Identify which amounts represent interchange, network costs, method costs, acquiring economics, provider markup, gateway charges, or other fees as far as the contract and reporting allow. Do not infer fee ownership from labels alone. 3. Quantify actual service use Determine which capabilities are actively used and which are duplicative. 4. Establish replacement cost For each capability that would disappear under an alternative provider, calculate the realistic internal or third-party replacement cost. 5. Model realistic volumes Calculate commercial outcomes under: * current volume * expected growth * downside volume * changing geographic or payment-method mix 6. Measure payment performance Compare approval, completion, fraud, disputes, refunds, and operational outcomes on equivalent transaction populations. 7. Negotiate the economic gap Now negotiate. Possible conclusions include: * the PSP markup is too high for the capabilities used * the markup is acceptable but tiers need restructuring * a bundled service should be removed * a lower-cost provider wins even after replacement costs * the incumbent remains cheaper economically despite its higher headline markup * the merchant should unbundle selected capabilities but retain others That is a stronger negotiation position than simply asking for a discount.

Those capabilities illustrate why a provider should be evaluated as an operating layer rather than only as a transaction-rate line item.

Those questions require the merchant's actual commercial schedule, service scope, payment mix, statements, and operational requirements. Final recommendation Treat PSP markup as a price that needs an object. For every percentage point, fixed transaction fee, platform charge, or commercial tier, determine what the merchant receives in return. Then compare three numbers: 1. Provider price What does the PSP charge? 2. Replacement cost What would the merchant have to buy, build, and operate without those capabilities? 3. Economic outcome What is the resulting cost per completed order after payment performance and operational cost are included? Negotiate hard when the provider layer contains unused capability, duplicated services, uncompetitive tiers, or margin unsupported by measurable value. But do not optimize PSP markup in isolation. The objective is not to obtain the lowest provider rate. It is to build the lowest-cost payment operation that still delivers the required customer access, approval performance, risk control, reporting, settlement reliability, support, and architectural flexibility.

Negotiation and value FAQ Is PSP markup the same as interchange? No. Interchange is part of the underlying card-payment economics and is generally transferred from the acquirer to the issuer. PSP markup is the provider's commercial charge for the provider layer. Is the PSP with the lowest markup always cheaper? No. Compare provider charges plus the cost of replacing capabilities the other provider includes. Then evaluate the result per completed order rather than using markup alone. How can a merchant identify markup inside blended pricing? Ask the provider to explain the treatment of interchange, network costs, acquiring economics, fixed transaction charges, provider fees, and other components. If the contract does not expose the markup directly, model the total commercial cost instead of inventing an implied margin. What data should merchants bring to a PSP negotiation? At minimum: transaction volume, successful value, average ticket, payment-method mix, customer/card geography, cross-border share, refund and dispute rates where material, current provider charges, service usage, integration inventory, and payment-performance data. What should a merchant ask before removing a bundled PSP service? Ask what replaces it, how much replacement costs, who operates it, whether payment performance changes, and how the new architecture affects cost per completed order. Disclaimer

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.

This package covers the requested article, original framework, measurement model, negotiation logic, SEO metadata, visual concept, sourcing, human-review plan, verification lists, and sameness-audit fields from the delivery brief. Editorial interpretation Merchant payment-cost problem: The merchant sees PSP markup as the obvious negotiable excess in payment costs and tries to minimize it without determining what operating capabilities would have to be rebuilt, bought elsewhere, or sacrificed. Unique evidence anchor: A PSP can be more expensive in basis points yet cheaper economically if its markup replaces integrations, risk tooling, payment-method contracts, reconciliation work, support, or other payment operations. Editorial position: Optimize PSP markup against the economic value of the operating and capability layer being purchased. Common assumption challenged: “The PSP’s margin is the easiest payment cost to cut with no downside.” Fee owner: The PSP or commercial payment provider charging the merchant. In some commercial structures, acquiring and PSP economics may be bundled, so the merchant must verify exactly which entity is charging which component. Primary cost variables: Processed value, transaction count, payment-method and geographic mix, transaction size, volume commitments, service scope, risk profile, acquiring structure, and negotiated commercial terms.

Merchant decision: Determine whether a lower PSP charge actually reduces total payment cost after replacing the capabilities included in the more expensive provider. Selected format: Provider value decomposition. Structural rationale: Start with two differently priced providers, separate the provider commercial layer from underlying payment-rail costs, decompose the capabilities financed by the markup, then normalize price and capability before negotiating. SEO metadata SEO title: PSP Markup Explained: What Merchants Really Pay For H1: PSP Markup Explained: What Merchants Are Paying for Beyond the Payment Rail Meta description: Learn what PSP markup pays for, how providers structure it, what merchants can negotiate, and how to compare markup with payment capabilities and total cost. URL slug: /payments-pricing/psp-markup-explained Primary keyword: PSP markup explained Secondary keywords: PSP markup; payment provider markup; PSP fees; payment processor markup; payment gateway markup; merchant PSP pricing; payment service provider fees; PSP margin Related entities: payment service provider; acquirer; issuer; card network; payment gateway; interchange; acquiring; payment orchestration; fraud management; reconciliation; settlement

Article excerpt: PSP markup is not merely basis points added to payment cost. It may pay for integrations, payment-method access, risk, reporting, settlement, support, and infrastructure. Merchants should decompose those capabilities and measure their replacement cost before deciding whether a lower provider fee is actually cheaper. Suggested structured data: Article, plus FAQPage only if the FAQ remains in the published version.

Internal-link recommendations Gateway Fees Explained — Link from the distinction between PSP and separately priced gateway functionality. Blended Pricing vs Interchange++ — Link where the article discusses markup visibility inside different pricing structures. How to Read a PSP Pricing Proposal — Link from the negotiation and fee-normalization sections. International Payment Architecture — Link from provider concentration, integration consolidation, and merchant dependency.

Authoritative source recommendations 1. Visa merchant interchange and rules documentation — for issuer/acquirer/interchange role definitions and current card-rule verification. 2. Mastercard merchant interchange documentation — as a second primary network source for interchange ownership and current schedules. 3. EUR-Lex / European Commission — for jurisdiction-specific acquiring definitions and interchange regulation where relevant. 4. PCI Security Standards Council — if the final article expands on outsourced processing, tokenization, or merchant security scope. PCI SSC notes that outsourcing processing may reduce which requirements apply directly to the merchant environment but does not remove the merchant's PCI DSS responsibilities altogether.

Supporting visual Visual title: PSP Markup Decomposition Recommended format: Horizontal value stack. Center: “PSP commercial layer” Branch to nine capability blocks: Processing/access → Integration → Acquiring relationships → Payment-method coverage → Risk → Reporting/reconciliation → Settlement → Support/operations → Platform infrastructure Below every block show the same four evaluation prompts: Need it? → Replacement cost? → Volume-scaled? → Measurable? Bottom line: Provider price + replacement/internal operating cost → cost per completed order Image alt text: Diagram showing nine capabilities that may be funded by PSP markup and four questions merchants can use to evaluate their economic value.

Proposed human contribution Proposed author: Named payments procurement or payments-commercial lead — TBD; do not invent a person. Recommended reviewers: * Payment architect — named reviewer TBD * Finance reviewer — named reviewer TBD * PSP commercial/pricing specialist — named reviewer TBD Useful first-hand contribution would be an anonymized provider-proposal decomposition showing which services were retained, removed, or separately sourced.

Publication fact-check checklist Pricing * Verify every non-hypothetical PSP percentage and fixed charge against the effective contract or current official schedule. * Confirm denominators for percentage fees. * Confirm transaction events triggering fixed fees. * Confirm volume-tier mechanics. * Confirm minimums and recurring charges. * Keep the numerical Provider A/B model explicitly labeled hypothetical. Fee ownership * Verify whether each commercial item belongs to the PSP, acquirer, network, issuer, gateway, or payment-method operator. * Do not infer ownership solely from invoice terminology. * Confirm whether gateway functionality is bundled or separately billed. * Confirm whether acquiring and PSP economics are combined. Network/interchange * No universal interchange rate should be inserted. * If rates are later added, verify network, jurisdiction, transaction type, card type, effective date, and merchant context from first-party documentation. * Keep interchange separate from scheme/network fees. Provider/acquirer * Verify whether the provider is acting as gateway, processor, PSP, acquirer, acquiring intermediary, or multiple roles for the transaction being discussed. * Verify any local-acquiring claim market by market. * Do not imply technical processing is necessarily acquiring. Merchant-model assumptions For any published example specify: * processed value * transaction count * completed orders * average ticket * geography * payment-method mix * excluded underlying costs

* engineering-cost methodology * operations-cost methodology * fraud/dispute scope * whether taxes and FX are included Proposal/statement verification If a real merchant example replaces the hypothetical model: * reconcile proposal → invoice → settlement * normalize different fee names * test whether contract pricing matches billed pricing * identify delayed adjustments * include recurring/platform charges * document excluded costs Regulatory * Verify the jurisdiction and current status of any interchange regulation mentioned before publication. * Do not extrapolate EEA rules to transactions outside their scope. * Distinguish regulatory pricing constraints from provider commercial negotiations. Amber-flag claims Require evidence before publishing claims that: * one PSP markup is cheaper than another * a provider improves approval rates * a service reduces fraud * an integration saves engineering cost * reporting reduces reconciliation cost * a provider reduces total payment cost * local acquiring reduces cost * a negotiated tier produces savings * a provider replaces a specific number of merchant systems

Before publication confirm internally: * actual commercial/pricing model being described * which services are bundled versus separately priced * current payment-method availability * current acquiring availability by market * reporting and reconciliation capabilities * risk-service scope * support scope and contractual SLAs * settlement terms * gateway scope * any approval-performance claim * any merchant outcome * any savings claim

Cluster sameness-audit fields Field Article 5 value Title PSP Markup Explained: What Merchants Are Paying for Beyond the Payment Rail First two sentences “Provider A costs 20 basis points more than Provider B. But Provider A replaces three integrations, a separate fraud tool, reconciliation work, and several local-payment-method relationships.” Opening device Higher-rate provider versus lower-rate provider capability comparison Merchant cost problem Merchant targets PSP markup as negotiable waste without pricing replacement capability Fee owner PSP/commercial provider Primary fee type Provider commercial markup Primary format Provider value decomposition Unique evidence anchor Expensive markup can be good value; cheap markup can be poor value Editorial position Optimize provider price against measurable capabilities and replacement cost Merchant decision Whether reducing markup actually reduces economic cost Original framework PSP Markup Decomposition Primary metric Provider-layer/payment cost per completed order Pricing example $5m/month hypothetical provider-layer comparison Conclusion Negotiate unsupported margin, not capability blindly CTA Decompose current PSP pricing into capability, replacement cost, and measured outcome before the next commercial review Closing element Negotiation/value FAQ Distinctive boundary Does not own interchange, scheme fees, acquiring economics, gateway pricing, or full proposal due diligence