Why the Cheapest PSP May Cost More

Why the Cheapest PSP May Cost More

A PSP quote is easy to rank.

Processing percentage.

Fixed fee.

International uplift.

Monthly charge.

Put the numbers into a procurement spreadsheet, sort ascending and a winner appears.

The apparent precision is misleading if the spreadsheet stops there.

A payment provider does not merely invoice transactions. It sits between customer demand and money the merchant successfully retains. Its acquiring setup, payment coverage, transaction performance, reliability, risk controls, reporting, settlement design and operational requirements can all influence the economics surrounding that payment.

So the relevant procurement question is not:

Which PSP charges the lowest rate?

It is:

Which PSP produces the highest defensible merchant contribution after payment cost and the economically relevant consequences of using that provider?

Those are not necessarily the same provider.

“Cheapest” needs a denominator

A percentage rate by itself has an obvious denominator:

processed payment value

But the merchant does not operate to minimize fees per dollar processed.

Depending on the decision, it may care about:

Direct cost per successful payment

Direct provider cost

÷ successful payments

Payment cost per completed order

Relevant payment cost

÷ completed paid orders

Provider cost as a percentage of successful payment value

Relevant provider cost

÷ successful processed value

Net payment contribution per eligible attempt

Net payment contribution

÷ eligible payment attempts

The choice changes the answer.

A provider can be cheaper per processed dollar but worse per customer payment attempt if fewer profitable payments complete.

That is why the brief requires every economic metric to make its denominator explicit.

Begin with direct price—but do not finish there

Commercial pricing still matters.

The comparison should begin with the actual contract:

•percentage processing cost;

•fixed transaction charges;

•applicable gateway/platform/account charges;

•payment-method fees;

•cross-border or FX cost where explicitly inside the comparison;

•relevant refund/dispute charges;

•contractual minimums or other directly attributable fees where material.

Do not replace a careful rate analysis with vague claims about “value.”

A provider that charges more requires an economic reason to justify the difference.

But that is precisely the point:

the quoted price difference should be quantified before the merchant asks what it buys or sacrifices.

Price is not total cost of ownership

A commercial rate answers:

What does the provider charge for this defined payment activity?

Provider total cost of ownership asks a broader question:

What does the provider relationship cost the merchant to implement and operate over a defined period?

TCO may additionally involve:

•implementation;

•certification;

•engineering maintenance;

•reporting integrations;

•reconciliation;

•support effort;

•provider management;

•incident handling;

•migration;

•eventual exit.

The full accounting methodology belongs in Total Cost of Ownership for a Payment Provider, as the cluster map requires.

For this article, the important distinction is:

Price < TCO < full economic decision

because even TCO does not necessarily capture the value of additional or lost profitable payment completion.

TCO is not payment contribution either

Suppose one provider costs more to own.

That does not automatically make it economically inferior.

If that provider creates enough incremental profitable completed orders, it can have:

higher TCO

and:

higher merchant ROI

at the same time.

Conversely, a low-maintenance, low-price provider could still be economically weak if the merchant measurably loses profitable orders through the payment experience.

So keep three concepts separate:

Provider price

Contractual commercial charges.

Provider TCO

Commercial + implementation + attributable ongoing ownership cost over the defined horizon.

Payment contribution

A merchant management metric describing the economic value retained after the payment costs and losses explicitly included in the model.

The brief expressly warns against treating TCO and ROI as synonyms.

Approval performance can overwhelm small rate differences

Authorization approval rate is:

approved authorizations

÷ authorization attempts

But that is not necessarily the correct final merchant metric.

An approved authorization can still fail to become a completed paid order.

For provider economics, merchants may also need:

Completed-payment rate

completed successful payments

÷ eligible payment attempts

or, where checkout cohort data exists:

Completed-order rate

completed paid orders

÷ relevant checkout/payment-intent cohort

These rates must not be used interchangeably.

The provider question is not simply:

“Does this PSP have a higher approval rate?”

It is:

“For comparable merchant traffic, does this provider create incrementally more legitimate completed orders?”

That second question is harder.

It is also economically meaningful.

Never turn a provider's claimed approval advantage directly into revenue

A 1-percentage-point approval difference does not automatically mean 1% more revenue.

The populations may differ.

One provider might handle:

•easier countries;

•more returning customers;

•smaller tickets;

•more debit;

•fewer high-risk transactions.

Another might receive a much harder transaction mix.

Even a measured approval increase can contain payments that would have completed through another retry, route or method anyway.

The brief therefore requires comparable cohorts and incrementality controls. Useful dimensions include country, currency, method, device, issuer geography, transaction value, customer segment and time period.

Use:

measured incremental completion

rather than:

headline approval difference

whenever possible.

Translate performance into contribution, not gross payment value

Suppose an alternative provider produces 4,000 additional completed orders.

If the average order is $100, it is tempting to call that:

$400,000 of incremental value

But the merchant does not economically retain the entire order value.

There may be:

•product cost;

•fulfillment;

•service cost;

•fraud;

•refunds;

•variable operating cost.

The relevant economic input is closer to:

Incremental contribution

Incremental legitimate completed orders

× contribution per incremental order

Then subtract any incremental payment, fraud or operating costs caused by the alternative configuration.

The brief explicitly recommends contribution or gross-profit economics where the merchant has sufficient margin data, rather than treating recovered gross order value as profit.

The 15-basis-point question

Suppose a competing PSP is 15 basis points cheaper.

That is:

0.15 percentage points

On $50 million of eligible processed volume, the gross fee difference is:

$50,000,000 × 0.0015 = $75,000

That is real procurement value.

Now assume the higher-priced configuration produces incremental completed orders worth $25 of contribution each, after the merchant's relevant variable costs.

The number of additional completed orders needed to offset the $75,000 fee disadvantage is:

Break-even incremental orders

$75,000 ÷ $25 = 3,000 orders

If the relevant cohort contains 1,000,000 eligible payment attempts, that corresponds to:

0.30 percentage points of incremental completed-order performance

under these purely illustrative assumptions.

The conclusion is not:

“Paying 15 basis points more is better.”

The conclusion is:

a 15-basis-point price advantage has a calculable performance break-even point.

Procurement can now test whether the measured performance difference exceeds it.

Break-even formula

More generally:

Required incremental completed orders

Incremental provider/payment cost

÷ contribution per incremental completed order

Or, if the eligible attempt cohort is known:

Required completion-rate lift

Required incremental completed orders

÷ eligible payment attempts

This turns a debate about “premium PSP quality” into a falsifiable economic question.

Payment-method coverage: count reach, not logos

A provider can support many payment methods.

A longer list does not automatically create more merchant value.

The relevant question is:

Does the provider give the merchant incremental access to customers who would otherwise fail to complete a profitable order?

A new payment method can:

•reach previously unpayable customers;

•improve completion for a relevant local audience;

•support retention;

•reduce payment failure.

It can also merely shift existing customers away from another cheaper method.

So do not value:

method count

Value:

incremental profitable completion attributable to method coverage

where merchant data makes that measurable.

Acquiring coverage can matter—but it requires a controlled test

An acquiring setup may affect authorization economics for a particular market.

That makes acquiring geography potentially relevant to provider selection.

For a merchant-economic model, however, do not convert that product claim into:

“local acquiring will improve our approvals by X.”

The merchant must test its own comparable cohort.

Measure:

•country;

•issuer geography;

•network;

•card/product type where available;

•transaction value;

•customer type;

•time period;

•relevant risk treatment.

Then compare completed legitimate orders and resulting contribution.

The causal effect belongs to the merchant experiment, not the marketing claim.

Reliability has an economic value only when it is measured

A provider outage can affect:

•payment failures;

•delayed orders;

•customer retries;

•support tickets;

•engineering intervention.

But a procurement presentation should not use generic statements such as:

“Provider X is more reliable.”

Use merchant evidence:

•incident logs;

•failed-payment counts;

•duration;

•affected cohorts;

•recovered versus permanently lost payments;

•engineering hours;

•support contacts.

Then estimate the economic effect.

The brief expressly prohibits inventing uptime or reliability differences.

Fraud performance works in two directions

A provider's risk layer can affect economics through:

Too little control

•fraudulent approvals;

•lost goods/services;

•disputes;

•investigation work.

Too much control

•legitimate customers rejected;

•friction;

•lower completion;

•possible customer loss.

Therefore:

lower fraud is not automatically better economics

if the reduction comes from rejecting profitable legitimate customers.

The objective is risk-adjusted contribution, not minimum fraud at any cost.

Reconciliation can change the real cost of a PSP

A provider can have excellent headline pricing and still require:

•manual invoice matching;

•spreadsheet settlement reconciliation;

•recurring investigation of unexplained differences;

•manual payment-status checks;

•finance-close work;

•provider-specific operational processes.

Those hours have a cost.

A defensible allocation might use:

provider-specific operating hours

× loaded hourly labor cost

rather than assigning the entire payments team's salary to the PSP.

The brief encourages activity-based allocations and warns against creating false precision from arbitrary cost allocation.

Engineering cost belongs in the comparison

A provider relationship can generate engineering work through:

•initial implementation;

•API maintenance;

•SDK changes;

•payment-method activation;

•custom retry/routing logic;

•reporting integrations;

•incident handling;

•migration.

But avoid two errors.

Error 1: ignoring implementation completely

A lower variable rate may take years to repay if the migration is expensive.

Error 2: charging sunk cost to the future decision

Engineering expense from a five-year-old integration is not automatically a future economic cost.

Include sunk historical costs only if the analysis intentionally evaluates historical TCO.

For forward provider selection, compare future incremental cost.

Switching cost changes the price of “cheaper”

A merchant replacing an incumbent provider may face:

•re-integration;

•certification;

•payment-method reactivation;

•dual running;

•token portability issues;

•contract termination;

•customer migration;

•new reconciliation work.

A new PSP can therefore offer a lower annual processing cost yet have a negative first-year economic result.

That does not make switching wrong.

It means the correct comparison requires a time horizon.

At minimum specify:

Year 1

and, where strategically relevant:

multi-year expected relationship

The full TCO article can own detailed three-year modeling. Here the point is simply: compare recurring savings with the migration investment required to obtain them.

Settlement and FX belong in the model only when they materially differ

A provider can change the merchant's economics through:

•settlement timing;

•payout costs;

•currency conversion;

•cross-border payment structure.

But this article should not recreate the dedicated Foreign Exchange, Cross-Border Costs or Hidden & Ancillary Fees analyses.

Import verified outputs from those models.

For example:

Annual provider FX cost: $X

can be one row in this comparison.

Do not rebuild the entire FX spread calculation here.

Likewise, a settlement-delay working-capital cost should be imported once, not counted here and again in another provider-cost row.

The brief specifically requires avoiding cross-cluster double counting.

Cheapest PSP Economic Comparison

A practical scorecard should separate observed cost, observed performance, and estimated economic effect.

Dimension

Required input

Economic question

Direct processing cost

Contract + actual mix

What will payment processing cost?

Completed-payment performance

Comparable transaction cohorts

How many legitimate payments complete?

Incremental customer reach

Method/country cohort data

Which profitable orders become possible only with this provider?

Fraud/disputes

Merchant risk data

How much value is lost or protected after false positives are considered?

Integration

Engineering estimate

What incremental work is required?

Operations

Activity/time study

How much provider-specific labor is created?

Reconciliation/reporting

Finance workflow data

How much exception and close effort is required?

Settlement/FX

Imported verified cost

Does the provider materially alter cash/FX economics?

Reliability

Merchant incident records

What measurable economic losses arise from provider incidents?

Exit/migration

Contract + architecture analysis

What will leaving the provider eventually cost?

Then calculate three separate outputs.

•Provider commercial cost

Contractually attributable provider charges.

•Provider ownership cost

Commercial cost plus the defined implementation and operational costs included in the model.

•Net payment contribution

One possible merchant-management construct:

Completed legitimate payment contribution

− refunds where included

− fraud/dispute loss where included

− direct payment cost

− directly attributable payment operating/ownership cost

This is a management framework, not a GAAP or IFRS metric. The brief specifically recommends terminology such as payment contribution rather than presenting an internally constructed metric as standardized accounting “net revenue.”

Provider comparison worksheet

For each shortlisted PSP, use the same measurement period and transaction assumptions.

Commercial

•Percentage processing charges

•Fixed transaction charges

•Other included contractual payment charges

•FX/cross-border inputs where relevant

Payment outcome

•Eligible attempts

•Authorization approvals

•Successful payments

•Completed paid orders

•Completed legitimate order value

•Contribution per completed order

Reach

•Incremental method-supported orders

•Incremental market/country reach

•Evidence that orders are actually incremental

Risk

•Fraud losses

•Dispute/chargeback losses

•False-positive effect where defensibly measured

Operations

•Reconciliation hours

•Support hours

•Payment-operations hours

•Provider-management hours

•Incident-management hours

Engineering

•Initial integration

•Ongoing maintenance

•Migration

•Dual running

•Exit work where relevant

Infrastructure

•Reporting

•Reliability

•Settlement/FX cost

•Required merchant accounts/configuration

Output

•Provider cost

•Cost per completed order

•Net payment contribution

•Contribution per eligible attempt

•One-year economic result

•Multi-year result where decision warrants it

Cost per completed order

One particularly useful comparison metric is:

Payment cost per completed order

Relevant payment/provider cost

÷ completed paid orders

Why?

Because two providers can generate the same $10 million of processed value from different numbers of attempts and operational paths.

But remember that even this metric measures cost, not value.

A provider that costs $0.10 more per completed order can still be superior if it creates additional profitable orders.

That is why it belongs beside—not instead of—contribution.

Contribution per eligible attempt

For provider-selection experiments, another useful metric is:

Net payment contribution per eligible attempt

Net payment contribution from the cohort

÷ eligible payment attempts

This metric forces price and performance into the same denominator.

A lower fee helps.

Incremental profitable completion helps.

Fraud hurts.

False declines hurt.

Operational cost hurts.

None gets to win the model by itself.

Do not double count lost revenue

Suppose a transaction is declined.

It should not automatically appear as:

•lost order value;

•lost contribution;

•decline loss;

•provider-performance loss;

four separate times.

Choose one economic representation.

Likewise, if a fraudulent transaction later becomes a chargeback and its full loss is already included under fraud, do not subtract the payment value again under chargeback losses unless the categories have deliberately different scopes.

The brief explicitly requires fraud, disputes, refunds and payment costs to be reconciled without duplicate deductions.

Do not count every declined payment as lost revenue either

A declined attempt may:

•retry successfully;

•switch method;

•be fraudulent;

•lack funds;

•represent a customer who would never have finished checkout.

The economically interesting amount is the incrementally recoverable legitimate cohort, not gross declined value.

The same incrementality discipline applies to provider comparison.

If a second PSP “recovers” a payment that the first provider would have successfully retried five seconds later, the second provider did not create an incremental order.

Feature count versus economic value

Procurement scorecards often contain rows such as:

•local acquiring: yes/no;

•routing: yes/no;

•3DS controls: yes/no;

•alternative methods: 100+;

•reporting dashboard: yes/no;

•risk engine: yes/no.

Those are useful for technical qualification.

They are poor economic weights.

The fact that a feature exists does not tell finance:

how much contribution it creates or protects.

Instead translate features into hypotheses:

Local acquiring → possibly different card acceptance economics in Market X

Additional method → possible incremental completion in Segment Y

Reporting → possible reduction in reconciliation workload

Routing → possible resilience/performance effect

Then verify each with merchant evidence.

A PSP should not receive an arbitrary financial advantage simply for having the longest feature matrix.

That contractual definition should not be confused with the article's internally constructed net payment contribution metric.

But it demonstrates an important point:

merchant payment economics extend beyond a headline transaction rate.

•local acquiring and dedicated MIDs in selected markets;

•dynamic routing across acquiring banks through its Waterfall Algorithm;

•risk-processing capabilities;

•transaction tracking;

•Reporting API access;

•settlement reports;

•broad local-payment-method coverage.

These are valid categories to include in a PSP evaluation.

Those outcomes require merchant-specific evidence.

What procurement should request

A pricing proposal should be accompanied by enough information to build an economic model.

Request:

Commercial definition

•Rates

•Fixed fees

•Account/platform fees where applicable

•International/FX pricing where relevant

•Volume tiers

•Contract term

•Termination/migration terms

Processing definition

•Which payment event is billable?

•Are failed attempts charged?

•Are refunds charged?

•What settlement/payout costs apply?

•Which rates are blended versus pass-through?

Coverage

•Payment methods by target market

•Acquiring availability

•Currency/settlement support

•Eligibility constraints

Data

•Transaction-level reporting

•Decline/response data

•Settlement reporting

•Reconciliation identifiers

•Risk/dispute data where relevant

Performance evidence

Ask for evidence with:

•geography;

•merchant type;

•method;

•period;

•denominator;

•cohort definition.

Do not treat a provider's aggregated approval-rate marketing statistic as the merchant's forecast.

Implementation

•Integration scope

•Certification

•Payment-method activation

•Token portability

•Migration requirements

•Ongoing API/SDK maintenance

Operations

•Support model

•Escalation

•Reporting tools

•Settlement reconciliation

•Incident handling

Procurement now has inputs for economics, rather than a decorative checklist around the rate card.

A decision model for the procurement committee

The decision can be organized in three layers.

Layer 1 — Price

How much will this provider charge under our actual transaction mix?

If this cannot be answered, the proposal is not normalized yet.

Layer 2 — Ownership

What incremental implementation and operating resources will the relationship require?

If these are ignored, the merchant is comparing price rather than cost.

Layer 3 — Contribution

After measured differences in legitimate payment completion and relevant risk are included, what economic value does the merchant retain?

If this is ignored, the merchant is comparing cost rather than economics.

The provider should win on the layer appropriate to the decision—not because one rate-card cell is lower.

The three numbers that should end the procurement memo

A provider-selection memo should not end with:

“This PSP is 12 basis points cheaper.”

It should end with three clearly defined numbers:

•Expected provider ownership cost

Over the stated decision horizon.

•Expected net payment contribution

Under the same merchant transaction mix and explicitly stated assumptions.

•Economic difference versus the current or next-best configuration

Including:

what drives the difference

and what assumptions could reverse it.

That last clause matters.

If 80% of the modeled advantage comes from an unverified assumption about approval performance, the committee should know that.

If almost all of the advantage survives even with zero assumed performance uplift because integration and operations are materially simpler, it should know that too.

The cheapest provider should win when its lower price remains cheaper after the economically relevant differences are measured.

When it does not, procurement has not “chosen an expensive PSP.”

It has identified that price was never the whole cost in the first place.

I used the new brief as the controlling specification and preserved its boundary: this piece owns the strategic case for evaluating PSP economics beyond price, while the later TCO article owns exhaustive ownership-cost accounting. I also followed the added instruction to avoid another comparison-story opening.

Why the Cheapest PSP May Cost More: Comparing Providers on Net Payment Economics

Editorial brief interpretation

The procurement mistake this article owns is simple: merchants often make the transaction rate the primary decision variable, then treat authorization performance, local payment access, reliability, fraud, reconciliation and engineering effort as qualitative modifiers.

The economics should run in the opposite direction.

Provider price is one input into merchant payment economics. It is not the economic outcome.

Field

Editorial decision

Merchant economics problem

A low processing quote can look attractive while economically relevant provider differences remain outside the procurement model.

Primary denominator

Completed paid orders for unit economics; eligible payment attempts for performance analysis; processed value where evaluating percentage fee cost.

Direct-cost scope

Contractual transaction and fixed fees plus other provider costs explicitly included in the comparison.

Performance scope

Authorization/payment completion, method reach, measured reliability, fraud/disputes where materially different.

Revenue mechanism

A provider may protect or lose incremental profitable completed orders through differences in acceptance, coverage and reliability.

Unique evidence anchor

The lowest transaction price can coexist with the worst overall merchant economics.

Editorial position

Select providers using modeled net payment contribution under comparable real merchant cohorts, not headline pricing alone.

Assumption challenged

“Once PSPs meet the technical requirements, choose the lowest rate.”

Merchant decision

Decide whether fee savings exceed performance, operational and ownership differences.

Format

Provider economic comparison.

Original framework

Cheapest PSP Economic Comparison.

The brief requires the comparison to incorporate direct cost, completed-payment performance, incremental reach, fraud/disputes, integration, operations, reconciliation, settlement/FX where material, reliability and exit cost.

Proposed architecture

•A PSP quote is an input, not a verdict

•Define what “cheapest” actually means

•Direct price: the part procurement sees first

•Payment performance: the value a rate card cannot show

•Coverage: method count versus incremental customer reach

•Reliability and fraud: use measured economics, not feature claims

•Operations, integration and reconciliation

•Price versus TCO versus payment contribution

•Cheapest PSP Economic Comparison

•Break-even economics for a higher-priced provider

•What procurement should request

•The three numbers that should end the procurement memo

Original practical asset: Cheapest PSP Economic Comparison

Stage 1 — Normalize commercial price

Input

PSP value

Evidence

Percentage processing cost

Contract

Fixed fee

Contract

Other included direct fees

Fee schedule

Applicable volume tier

Contract

Eligible processing volume

Merchant data

Annual direct provider cost

Calculated

Stage 2 — Normalize performance

Metric

Value

Denominator

Authorization approval

Authorization attempts

Completed-payment rate

Eligible payment attempts

Completed-order rate

Relevant checkout cohort

Incremental completed orders

Experiment/comparable cohort

Fraud loss

Define value/count denominator

Dispute loss

Define cohort

Stage 3 — Normalize ownership

Cost

Method

Integration

Incremental engineering estimate

Reconciliation

Attributable finance hours

Payment operations

Activity-based allocation

Support/incident work

Provider-specific hours

Migration

Incremental future switching work

Stage 4 — Calculate merchant outcome

Provider ownership cost

**Direct provider cost

•incremental implementation cost

•attributable operating cost**

Net payment contribution

Legitimate completed-order contribution

− included payment/risk/refund costs

− provider ownership cost

Contribution per eligible payment attempt

Net payment contribution

÷ eligible payment attempts

Break-even worksheet

If the higher-priced option costs an additional:

Δ Payment Cost

and each truly incremental completed order contributes:

Contribution per Order

then:

Incremental orders required

Δ Payment Cost

÷ Contribution per Order

Then:

Required incremental completion-rate lift

Incremental orders required

÷ Eligible Attempts

The result should be tested against merchant evidence.

Do not substitute a provider marketing claim for the measured incremental lift.

Measurement plan

Track by provider and comparable cohort:

Cost

•Direct provider cost

•Provider cost per successful payment

•Payment cost per completed order

•Attributable operating cost

•Incremental implementation cost

Performance

•Eligible payment attempts

•Authorization approval rate

•Completed-payment rate

•Completed-order rate

•Retry/recovery rate where relevant

Revenue/contribution

•Incremental legitimate completed orders

•Contribution per incremental order

•Net payment contribution

•Contribution per eligible attempt

Risk

•Fraud loss

•Dispute loss

•False-positive effect where defensibly measured

Operations

•Reconciliation hours

•Payment-operations hours

•Incident hours

•Support burden

Reliability

•Provider-attributable incidents

•Affected attempts

•Recovered payments

•Permanently lost completed orders where defensibly measured

SEO metadata

H1: Why the Cheapest PSP May Cost More: Comparing Providers on Net Payment Economics

Meta description: A low PSP transaction rate does not guarantee lower payment costs. Learn how to compare providers across fees, payment completion, coverage, operations, reliability, integration and net contribution.

URL slug: /why-cheapest-psp-may-cost-more

Secondary keywords:

•cheapest PSP

•payment provider total cost

•compare payment providers

•payment processing provider cost

•PSP approval rate cost

•PSP economics

•payment provider ROI

•PSP cost comparison

Related entities:

•payment service provider

•merchant acquiring

•authorization rate

•payment completion

•local payment methods

•fraud

•chargebacks

•payment operations

•reconciliation

•payment routing

•payment provider TCO

•net payment contribution

Article excerpt: The lowest transaction rate can produce the wrong PSP decision when differences in payment completion, customer reach, operations, reliability and implementation outweigh the quoted fee saving.

Suggested structured data: Article and BreadcrumbList.

Internal links

PSP Total Cost of Ownership

Link when provider implementation, operating and exit costs need full accounting.

Payment Cost vs Conversion

Link from the performance break-even section for deeper cost/completion analysis.

International Payment Architecture

Link when multi-provider routing, abstraction or provider redundancy becomes an architecture problem.

How to Read a PSP Pricing Proposal

Link from commercial normalization and procurement requirements.

How to Calculate the True Cost per Transaction

Optional link where the reader needs detailed direct and allocated unit-cost methodology.

Authoritative source recommendations

•Merchant transaction data — primary source for comparable approval and completed-payment cohorts.

•Merchant finance data — source for payment cost and contribution assumptions.

•Merchant payment-operations time studies — source for provider-specific operational cost.

•Merchant incident logs — source for reliability economics.

•PSP contracts and fee schedules — governing evidence for commercial pricing.

Supporting visual: From Rate Card to Provider Economics

Column 1 — Commercial quote

Transaction rate

Fixed fee

Other direct fees

↓

Column 2 — Ownership

Integration

Operations

Reconciliation

Support

Migration

↓

Column 3 — Payment outcome

Eligible attempts

Completed payments

Incremental reach

Fraud/disputes

Reliability

↓

Net Payment Contribution

Bottom callout:

Lowest rate ≠ lowest TCO ≠ highest payment contribution

Suggested alt text: Diagram showing PSP transaction pricing expanding into ownership cost and payment performance before arriving at net merchant payment contribution.

Proposed author and reviewers

Do not imply completed review.

Payments reviewer: [Named Head of Payments]

Commercial reviewer: [Named Procurement Lead]

Financial reviewer: [Named Merchant Finance Specialist]

Architecture reviewer: [Named Payment Architect]

Recommended first-hand contribution: an anonymized provider evaluation showing how an initial commercial-rate ranking changed after actual merchant completion, reconciliation and migration data were added.

These roles align with the article-specific brief.

Cost fact-check items

For every provider:

•Contract version

•Effective date

•Merchant/entity

•Geography

•Method

•Transaction event charged

•Percentage fee

•Fixed fee

•Volume tier

•Cross-border/FX input if included

•Other direct fees

•Refund/dispute treatment where relevant

•Minimums

•Time horizon

Do not infer enterprise pricing from generic public material.

Approval and conversion fact-check items

Verify:

•precise metric definition;

•denominator;

•geography;

•card/method;

•transaction value;

•customer cohort;

•provider/acquirer;

•risk treatment;

•time period;

•sample size;

•statistical/experimental methodology where relevant.

Do not describe a higher observed approval rate as provider-caused incremental revenue without a comparable-cohort design.

Decline fact-check items

Where decline recovery influences the provider case, distinguish:

•issuer decline;

•merchant risk decline;

•technical failure;

•potentially recoverable decline;

•successful retry;

•alternative-method recovery;

•unrecovered legitimate order.

Do not classify all declined value as revenue lost.

Fraud fact-check items

Verify:

•fraud definition;

•count or value denominator;

•time window;

•whether chargeback losses are included;

•false-positive methodology;

•fraud tool/provider cost;

•goods/service loss;

•recovery.

Do not claim that a provider's risk capability increases contribution without merchant evidence.

Chargeback fact-check items

If materially different across providers, define:

•dispute rate and denominator;

•reversed transaction value;

•dispute fees;

•fulfillment/goods cost included;

•operations effort;

•representment recovery;

•fraud overlap.

Avoid double counting fraud and chargeback losses.

Operations/TCO assumptions

For every allocated cost state:

•period;

•labor role;

•loaded hourly cost methodology;

•hours attributable to provider;

•recurring versus one-time;

•historical sunk versus future incremental;

•allocation basis.

For migration:

•integration;

•certification;

•dual running;

•token migration;

•method activation;

•contract termination;

•cutover support.

The dedicated TCO article should own the complete methodology.

Merchant-margin assumptions

To translate incremental orders into economic value, document:

•average transaction/order value;

•contribution or gross-margin assumption;

•variable fulfillment/service costs included;

•refunds included/excluded;

•fraud included/excluded;

•taxes excluded/included;

•payment cost included/excluded.

Do not call gross recovered payment value “profit.”

Experiment and incrementality fact-check items

For a provider test ask:

Would the payment have completed anyway?

Control where practical for:

•country;

•currency;

•issuer;

•payment method;

•transaction amount;

•new/returning customer;

•device;

•risk segment;

•time period.

Guardrails should include:

•fraud;

•disputes;

•refunds;

•latency;

•support complaints;

•cost;

•completion.

The primary decision metric should be the merchant's net economic outcome where data permits.

Amber-flag claims

“The cheapest PSP is often the most expensive.”

Too broad. The thesis is conditional: cheaper pricing can produce worse economics when other measurable costs or performance differences exceed the price advantage.

“A 1% approval uplift equals 1% more revenue.”

Unsupported without cohort and incrementality analysis.

“More payment methods increase revenue.”

Only incremental profitable completion matters.

“A local acquirer will improve approval.”

Requires market/provider-specific evidence.

“Better risk tooling reduces fraud without hurting conversion.”

Requires both fraud and false-positive measurement.

“Provider downtime costs $X.”

Requires merchant incident and recovery data.

Do not publish without a merchant-specific comparison.

The current public coverage claim is verifiable; incremental merchant revenue is not.

Current public sources verify Reporting API and settlement-report capabilities, not a quantified labor reduction.

Before publication:

•Verify the current merchant fee schedule applicable to any pricing example.

•Verify how current Brick blended pricing applies to the intended merchant/product.

•Confirm current local-acquiring markets and merchant eligibility.

•Verify Waterfall Algorithm/routing applicability to the intended setup.

•Confirm the exact risk capabilities applicable to the merchant.

•Verify local-payment-method availability by target market.

•Confirm Reporting API fields available to support the proposed economic analysis.

•Confirm settlement-report data and reconciliation identifiers.

•Verify all support/account-management claims before publication.

•Do not publish approval, completion, fraud, TCO or merchant-saving claims without approved merchant-specific data and a defined cohort.

Cluster sameness-audit fields

Title: Why the Cheapest PSP May Cost More: Comparing Providers on Net Payment Economics

First two sentences: A PSP quote is easy to rank. Processing percentage, fixed fee, international uplift and monthly charge can all be placed into a procurement spreadsheet and sorted.

Opening device: A procurement model whose precision disappears once the omitted economics are examined—not a Provider A/Provider B anecdote.

Merchant economics problem: Headline provider price is mistaken for total provider economics.

Primary denominator: Completed paid orders / eligible payment attempts, depending on metric.

Direct cost variable: Provider commercial cost.

Performance variable: Incremental legitimate payment completion.

Revenue leakage/protection variable: Lost/protected merchant contribution.

Primary format: Provider economic comparison.

Unique evidence anchor: The lowest transaction rate can coexist with the highest economic cost.

Editorial position: Choose using modeled net payment contribution under the merchant's real mix.

Merchant decision: Determine whether direct fee savings exceed verified performance and ownership differences.

Original framework: Cheapest PSP Economic Comparison.

Primary metric: Net payment contribution.

Secondary metrics: Provider cost, cost per completed order, contribution per eligible attempt, incremental orders and provider-specific operational hours.

Conclusion pattern: Procurement memo ending in three numbers rather than a generic “Final Recommendation” or FAQ.

CTA: Re-run the PSP shortlist with direct fees, completed-payment economics, attributable operations and migration cost on the same comparable merchant cohort.

Differentiation: This article owns the strategic argument that provider price can diverge from merchant economic outcome. Article 9 owns comprehensive provider TCO; Article 2 owns cost-versus-conversion mechanics; Article 10 owns full net-revenue optimization.