Use a computer

For full performance and fluidity, please open Pay Engineers on a desktop or laptop. On mobile, the experience is limited — especially authenticated sections and advanced tools after login.

Product & strategy

Monetising a payment platform: fees that survive scrutiny

Interchange-plus-plus, blended pricing and platform take-rates each carry very different trade-offs between simplicity and transparency. We explain how to model fees against chargebacks, FX and support cost so commercial and engineering teams share one number.

Jul 15, 2026 5 min 2,148 0

Fee engines are product strategy encoded as arithmetic. The pricing model you choose shapes not just your margin, but your sales conversations, your support burden, and how defensible your pricing is the first time a sophisticated merchant asks exactly how their rate was calculated. Getting this wrong does not usually kill a business outright — it quietly erodes margin and trust over years.

Blended pricing: simple to sell, hard to defend

Blended rates — a single flat percentage regardless of card type, region or transaction characteristics — are easy for sales teams to pitch and easy for merchants to understand at signup. The problem surfaces later: your actual cost base (interchange, scheme fees, FX spreads) varies enormously by card type and corridor, so a blended rate that is profitable on domestic debit transactions can be loss-making on premium international credit cards.

Blended pricing also becomes commercially fragile the moment corridor mix shifts. A merchant who suddenly sells more internationally, or whose customer base shifts toward premium cards, can flip your margin on their account from healthy to negative without either party noticing until a margin review.

Interchange-plus-plus: transparent but demanding

Interchange++ passes through actual interchange and scheme fees, adding a transparent markup on top. This is far more defensible and margin-safe, but it requires real investment: merchants need education to understand statements that now show variable, multi-line fees instead of one flat number, and your reporting needs to be excellent enough that a finance-literate merchant can reconcile every line themselves.

The trade-off is real: interchange++ wins on defensibility and long-term margin protection, but loses on simplicity of the initial sales conversation. Platforms that choose it need to invest deliberately in merchant-facing reporting and education to avoid losing deals to competitors offering a simpler (if less honest) headline number.

Platform take-rates for marketplaces and SaaS-embedded payments

For platforms and marketplaces embedding payments, the relevant question shifts from "what percentage do we charge" to "what percentage lets us absorb chargebacks, FX exposure and support cost while remaining competitive". Modelling take-rate purely against "what competitors charge" ignores the cost structure that actually determines whether the take-rate is sustainable.

Costs that must be modelled explicitly

Chargeback rates vary enormously by vertical and directly affect net margin on a take-rate. FX exposure, if you settle sellers in a different currency than buyers pay in, can swing materially with exchange rate movements. Support cost per transaction — often ignored in pricing models — can dwarf the processing margin for high-touch verticals.

The ledger must attribute every fee

Whichever pricing model you choose, your ledger must attribute every single fee — interchange, scheme, FX spread, platform margin — to a specific posting linked to the originating transaction. Pricing models that cannot be reconciled to the ledger, transaction by transaction, cannot be defended when a merchant, auditor or regulator asks for a detailed breakdown.

A practical fee-design checklist

  • Model each pricing option against real chargeback, FX and support cost data, not competitor headlines alone.
  • Segment margin analysis by card type, corridor and merchant vertical before committing to a blended rate.
  • Invest in merchant-facing reporting proportional to the pricing complexity you choose to offer.
  • Ensure every fee line is a traceable ledger posting, not a number calculated only at invoice time.
  • Revisit pricing models whenever corridor mix, chargeback trends or FX volatility shift materially.

Prototyping fees early

We prototype fee scenarios early in discovery, alongside product and technical design, so commercial and engineering teams share one model of how money actually flows and where margin is captured or lost. Pricing decided in isolation by a commercial team, without ledger and cost-model input, tends to require painful renegotiation once real transaction data arrives.

A pricing model you cannot explain, line by line, to your most sophisticated merchant is a pricing model that will eventually cost you that merchant.

Revisiting pricing as the business matures

The pricing model that made sense at launch, when volumes were small and negotiating leverage limited, is rarely the right model once a platform has scale and better cost data. Many mature payment businesses migrate merchants gradually from blended toward interchange-plus-plus pricing as their reporting capability matures, or introduce volume-tiered take-rates once enough transaction history exists to model tiers responsibly.

These transitions need careful merchant communication, since any pricing change — even one that is fairer or more transparent — can be perceived as a price increase if not explained clearly. Pair any pricing model transition with improved reporting that lets merchants immediately see the itemised justification for their new fee structure, rather than asking them to simply trust that it is fairer.

Key takeaways

  • Blended pricing is easy to sell but fragile against shifting corridor and card-type mix.
  • Interchange++ is more defensible but requires real investment in merchant education and reporting.
  • Platform take-rates must be modelled against chargebacks, FX and support cost, not just competitor pricing.
  • Every fee must be a traceable ledger posting linked to its originating transaction.
  • Model pricing scenarios jointly with engineering early, not as a late commercial afterthought.

Comments

0 comments

Sign in to leave a comment.

Iniciar sesión

No comments yet. Be the first to comment.

Keep reading

Related articles

More content that may interest you

View all posts
Featured
Product & strategy

When to embed BaaS instead of applying for your own licence

Speed, control and exit options form a pragmatic matrix for founders weighing Banking-as-a-Service against a direct licence application. We cover roadmap dependency, concentration risk and the exit-path design decisions that protect optionality later.

10/07/2026 5 min 689 0
Product & strategy

Checkout conversion: the quiet compounder

Latency, local method coverage and disciplined retry logic quietly outperform flashy checkout redesigns almost every time we measure it. We explain how to instrument payment-specific funnel metrics and why treating checkout as reliability work beats treating it as design work.

04/07/2026 5 min 1,284 0
Product & strategy

White-label payments: brand speed without architecture debt

White-label suites let banks and platforms launch quickly under their own brand, but poorly scoped programmes create coupling that is very hard to reverse later. We explain how to demand clear tenancy boundaries and design a genuine path to deeper ownership.

28/06/2026 5 min 4,813 0