How Payments Unit Economics and Interchange Really Work

A payment's take rate is what survives after three other parties are paid out of the fee you charge: the card-issuing bank takes interchange, the card network takes an assessment, and your processor or partner takes a markup. What's left, minus fraud and chargeback losses, is your actual margin. Model that stack line by line before you build, because it — not the product — usually decides whether a payments idea is a business.

Quick Answer: A card transaction's fee splits four ways: interchange to the issuing bank, an assessment to the card network, a markup to your processor or partner, and a net take rate to you once fraud and chargeback losses are subtracted. Interchange is not a single public number you can quote from memory — it varies by card network, card type, transaction channel, and region, and it changes over time. Treat any rate you see cited as an input to verify with your own processor agreement, not a fact to design a business around.

Most first-time payments founders build a pricing page before they build a P&L. They pick a number that feels competitive — a flat percentage plus a few cents, say — without ever mapping where that money actually goes once a card is swiped, tapped, or typed into a checkout form. If you haven't already walked the broader sequence this sits inside, start with how to validate a payments startup idea, which treats unit economics as one of six required gates alongside licensing, rails, and incumbent mapping. This piece goes deep on that one gate: the mechanics of the fee stack, how to model your take rate before you commit to a price, and the signs that your specific version of the model doesn't survive contact with reality.

The Fee Stack: Interchange, Network Assessment, Processor Markup, and Net Margin

Every card transaction's fee splits among four parties in a fixed order, and you only ever control one of those splits directly. Money moves from the merchant, through your pricing, and out to the issuing bank, the card network, and your processing partner — in that sequence — before whatever remains becomes your margin.

Interchange is the largest and least flexible piece. It flows to the bank that issued the customer's card, and it compensates that bank for extending credit or holding the deposit account, guaranteeing the funds, and absorbing a share of fraud and credit risk. You do not set this fee and you cannot negotiate it as an individual merchant or platform — it is published by the card network on the issuing bank's behalf, and it moves with variables outside your control: which network the card runs on, whether the card is debit, standard credit, or a premium rewards tier, whether the transaction is card-present or entered remotely, the merchant category, and the region the transaction happens in. Some jurisdictions regulate interchange directly — the EU's Interchange Fee Regulation is the best-known example — which is exactly why "region" belongs on that list: a take-rate model calibrated on one market's interchange environment does not automatically transfer to a market where interchange is capped by law.

The network assessment is smaller and goes to the card network itself — the brand running the rails, the dispute infrastructure, and the routing that gets an authorization from a checkout page to an issuing bank and back in under a second. Like interchange, this is not something you negotiate.

Processor or partner markup is the one line you actually influence. Whether you route through an acquirer, a payment facilitator, or a platform reselling someone else's processing, this is the layer added on top of interchange and the network assessment. It is set by your agreement, your volume, and your risk profile — and it is the only lever in the stack that responds to how good a partner you are to work with, not to a published schedule.

Net take rate is what's left after all three are subtracted, before you even account for fraud and disputes. The table below lays out the four components structurally — treat it as a map of who controls what, not a source of current rate figures.

The takeaway: two of the four rows are fixed costs you inherit, one row is where your actual business lives, and the last row is the only number that tells you whether you have a business at all.

How to Model Your Take Rate

Modeling a payments take rate is a four-step exercise: map the flow, estimate the price you can realistically charge, subtract every real cost against it, and then stress-test the result at the volume you'll actually process. Skipping any one of these steps is how a spreadsheet that looks healthy turns out to be wrong once real transactions start flowing.

Map the Payment Flow First

Before you can subtract anything, you need to know which pieces of the fee stack you actually see. If you operate as a registered payment facilitator with a direct acquiring relationship, you likely see interchange, the network assessment, and your own markup as separate lines — often called interchange-plus or cost-plus pricing. If instead you're a software platform reselling a processor's service, you may only ever see one blended rate quoted to you, with interchange and the network assessment already folded in and invisible. That distinction matters enormously: you cannot optimize a cost you cannot see, and a blended rate can hide whether your processing partner's own markup is reasonable or is quietly eating the margin you think you're capturing.

Estimate the Take Rate You're Actually Charging

Translate your pricing model into an honest per-transaction revenue figure. A flat percentage, a percentage plus a fixed fee, a tiered structure, a subscription with a reduced per-transaction rate, and a spread model on an account-to-account rail all produce different effective take rates at different transaction sizes — a flat percentage favors you on large transactions and a fixed fee favors you on small ones, so model your actual transaction-size distribution, not a single average.

Subtract Every Real Cost, Not Just Processing

Interchange, the network assessment, and your processor's markup are the obvious costs, but they are rarely the only ones. Also account for:

• Fraud tooling and vendor costs — most payments businesses run a third-party fraud-scoring or verification service, and that's a real per-transaction or subscription cost.
• Chargeback handling — both the labor to fight or process a dispute and the per-dispute fee your network or processor charges you regardless of who is at fault.
• Compliance and assurance costs — PCI scope, audits, and the ongoing program that keeps you eligible to process at all. This is its own line item large enough to deserve its own model; see how to estimate fintech compliance costs before you finalize a budget.
• Reserves — many processors hold back a rolling reserve against your expected chargeback exposure, which is a real cost of capital even though it never shows up as a fee.

Stress-Test at Volume

Interchange does not improve as your volume grows — issuers charge it regardless of how much you process. Processor markup often does improve at higher volume, through a renegotiated wholesale agreement, but that improvement usually only unlocks once you clear a volume threshold you may not have the capital to reach on today's thinner margin. If your model only works after a volume-based rate improvement you don't currently have, you've built a plan that depends on surviving long enough to get a better deal — not a plan that's profitable today. And a positive per-transaction take rate is a precondition, not a substitute, for the acquisition math that comes next: only once this margin is real is it worth running the CAC, LTV, and payback period framework against your customer acquisition plan.

Worked Example: Modeling Margin on a Card Checkout Product

Here's how the arithmetic actually works, using letters instead of numbers on purpose — none of the variables below stand in for a real published rate, and you should replace them with figures from your own signed processor agreement before trusting any output.

Suppose you're building a checkout product for a vertical SaaS platform's merchants, charging a single blended rate per card transaction. Define:

• P — the price you charge the merchant per transaction
• X — the interchange your processor passes through to the issuing bank
• Y — the network assessment
• Z — your processor or partner's markup (or, if you are the processor yourself, your own cost of running the transaction)
• W — the fraud and chargeback loss you provision for, as a rate against volume

Net take rate = P − (X + Y + Z + W)

The point of writing it this way is what it reveals about which levers are actually yours. P is bounded by what the market will pay for a checkout button — price too far above competitors and you lose the deal. X and Y are set by the network and are not negotiable at your scale. That leaves Z and W as the only two variables you genuinely control, which reframes the whole business: a payments startup competing purely on price is competing over a number it doesn't own. The more durable competition is over how small you can make W — through better underwriting, verification, and fraud monitoring — and how much of Z you can retain, either by negotiating a better wholesale agreement as volume grows or by owning more of the processing stack yourself.

One more nuance worth modeling separately: a checkout product that only ever processes card-not-present transactions inherits a different X than one that also handles in-person tap-to-pay, and typically carries a heavier W too, since remote transactions are harder to authenticate than a chip or tap read in person. If your product spans both channels, model them as two separate take rates rather than one blended average — blending them hides which channel is actually the profitable one and which is being subsidized by it.

Signs the Economics Invalidate the Idea

A payments idea's economics are invalidated the moment the modeled net take rate goes to zero or negative under realistic conditions — not your best-case assumptions. Watch for these patterns while you build the model, because each one is a reason the spreadsheet looks fine today and breaks in production:

• Your margin only works at a volume tier you haven't reached. If profitability depends on a wholesale processor rate that only kicks in above a volume threshold, you're modeling the business you hope to have, not the one you have the capital to run today.
• Your vertical has structurally elevated dispute rates. Categories like digital goods, subscriptions with negative-option billing, and travel are widely known to run heavier chargeback exposure than typical retail — if you're entering one of these, provision W accordingly rather than borrowing a generic assumption.
• You're relying on an optimization gap that networks periodically close. Techniques like enhanced data submission for lower-cost B2B card categories, or particular debit routing choices, can shrink X or Y today — but networks and regulators revisit these mechanisms over time, and a model that only works because of a gap you're exploiting is fragile by construction.
• You haven't separated card-present from card-not-present. A single blended average across two channels with genuinely different X and W values hides which one is carrying the business.
• Z is already thin and it's your only lever. If competitive pressure has already pushed your processor markup toward the floor, you have no room left to absorb a fraud spike, a dispute-ratio penalty, or a rate change from the network — the model has no shock absorber left.
• A rail owner could bundle your exact feature for free. If your entire margin depends on a service the network or a larger processor could ship natively, your take rate is borrowed time, not a moat.

Key Takeaways

• Two of the four fee-stack components are fixed costs you inherit. Interchange and the network assessment are set by the card network, not by you — your negotiating leverage lives entirely in processor markup.
• Net take rate, not gross revenue, is the number that matters. P minus interchange, assessment, and markup still isn't your real margin until you also subtract fraud and chargeback losses.
• Model card-present and card-not-present separately. They carry different interchange and different fraud exposure, and blending them into one average hides which channel is actually profitable.
• Compliance and reserves are real costs, not footnotes. PCI scope, audits, and a processor's rolling reserve against chargebacks all reduce the capital and margin you have to work with.
• A volume-dependent rate improvement is not a current business model. If profitability requires a wholesale rate you'll only get after scaling, you're modeling a future state, not today's economics.
• Interchange is not a number to memorize — it's a variable to verify. It changes by card network, card type, channel, region, and over time; pull the current figures from your own processor agreement, not from a blog post.
• A positive take rate is the floor, not the finish line. Only once per-transaction margin is real does it make sense to run acquisition math on top of it.

Frequently Asked Questions

What is interchange in payment processing?

Interchange is the fee paid to the bank that issued the customer's card, deducted from a transaction before the merchant or platform sees the rest. It compensates the issuing bank for extending credit or holding the account, guaranteeing settlement, and absorbing a share of fraud risk. It's set by the card network on the issuer's behalf and varies by card type, transaction channel, and region — you don't set or negotiate it directly.

How much of a card transaction fee is interchange versus processor markup?

The split varies by card network, card type, and your specific processor agreement, so there's no fixed ratio to quote — but interchange is typically the larger portion of a blended rate, with network assessment and processor markup making up the remainder. The only reliable way to know your own split is to get an interchange-plus or cost-plus quote from your processor that itemizes each line, rather than accepting a single blended number.

Can a payments startup negotiate interchange rates?

No. Interchange and the network assessment are set by the card networks and are not negotiable by an individual merchant, platform, or payment facilitator, regardless of size. What is negotiable is your processor or acquiring partner's markup, and — at meaningful volume — the terms of your processing agreement, including reserve requirements and any wholesale rate tiers.

Why do some payments startups avoid card interchange entirely?

Because interchange and the network assessment are fixed costs outside their control, some payments companies route transactions over account-to-account rails — bank transfers or real-time payment rails — instead of cards, which avoids card interchange altogether. That trade isn't free: these rails carry their own constraints, including settlement timing and different fraud and dispute handling, and they require persuading customers to leave a card habit they already trust.