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.

•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?

•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.

•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.

•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.

•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.

•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.

•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.

•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.

•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:

•Do we actually need this capability?

•Could we replace it more cheaply without losing performance?

•Does its pricing scale sensibly as our volume grows?

•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.

•Reconstruct the current provider layer

List every PSP charge and every operational capability being consumed.

•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.

•Quantify actual service use

Determine which capabilities are actively used and which are duplicative.

•Establish replacement cost

For each capability that would disappear under an alternative provider, calculate the realistic internal or third-party replacement cost.

•Model realistic volumes

Calculate commercial outcomes under:

•current volume

•expected growth

•downside volume

•changing geographic or payment-method mix

•Measure payment performance

Compare approval, completion, fraud, disputes, refunds, and operational outcomes on equivalent transaction populations.

•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:

•Provider price

What does the PSP charge?

•Replacement cost

What would the merchant have to buy, build, and operate without those capabilities?

•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

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

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

•Visa merchant interchange and rules documentation — for issuer/acquirer/interchange role definitions and current card-rule verification.

•Mastercard merchant interchange documentation — as a second primary network source for interchange ownership and current schedules.

•EUR-Lex / European Commission — for jurisdiction-specific acquiring definitions and interchange regulation where relevant.

•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