Interchange, Fees, and Float: The Unit Economics Every Payments PM Must Model

A payments feature can drive adoption, delight users, and still lose money on every single transaction if you haven't modeled interchange, scheme fees, processor markup, and float. The take rate — what you keep after every pass-through cost — is the only number that tells you whether volume helps or hurts you.

Quick Answer: Every card transaction splits into interchange (paid to the card-issuing bank), scheme fees (paid to Visa/Mastercard/etc.), and processor markup — what's left is your take rate. Model it per transaction, at your real average ticket size, before you ship.

Most payments PMs learn this the hard way: a feature ships, usage climbs, and finance flags that the unit economics are underwater. That's not a finance failure — it's a product-spec failure. If interchange economics aren't in the PRD, the feature was scoped incomplete.

What Actually Happens to $100 When a Customer Pays

Roughly 70-90% of a typical U.S. card transaction's total processing cost goes to interchange, with the remainder split between scheme fees and processor margin — though the exact split varies heavily by card type, merchant category code, and region. Understanding this waterfall is the foundation of every payments monetization decision you'll make.

Here's the flow for a simple $100 card purchase, illustrated with realistic (not exact — these vary by network and card tier) rates:

Interchange is set by the card networks (Visa, Mastercard) but paid to the issuing bank, and it's non-negotiable for any single merchant — it's published in interchange tables that run hundreds of line items, segmented by card type (debit, credit, rewards, corporate), transaction channel (card-present, card-not-present, recurring), and industry code. A rewards credit card costs more to accept than a basic debit card, often by 1-1.5 percentage points, because the issuer is funding the cardholder's rewards program out of that fee.

Why This Isn't Just a Finance Concern

The PM who owns a payments feature owns its unit economics, not just its user experience. Every design decision — which card types you accept, whether you push ACH as an alternative, how you price a subscription — shifts where you land in that waterfall. A feature that ignores this ships blind.

Interchange-Plus vs. Flat-Rate Pricing: The Model That Determines Your Margin

Interchange-plus pricing passes through the real interchange cost and adds a transparent, fixed processor markup on top, while flat-rate pricing bundles everything into one advertised percentage regardless of card type. The pricing model your company (or your processor) uses determines whether your margin is predictable or volatile, and it changes which features are safe to build.

How the two models diverge

A payment facilitator (PayFac) or platform aggregating many sub-merchants almost always needs interchange-plus visibility internally, even if it quotes flat-rate to end customers — otherwise it can't tell which merchant segments are profitable. If your product lets users choose acceptance methods, model both: a subscription box business skewing toward rewards cards looks very different from a B2B invoicing tool where corporate cards dominate and interchange runs even higher.

The trap: flat-rate pricing hides your real card mix

1. You quote 2.9% flat to every merchant regardless of the cards their customers actually use.
2. Your real blended interchange cost moves as your merchant base skews toward higher-reward or corporate cards — often invisibly, quarter over quarter.
3. Margin compresses silently until someone reconciles the ledger against actual network settlement files and finds the gap.

If you're building the reconciliation layer that catches this gap, the mechanics of matching settlement files to expected fees are covered in more depth in payment reconciliation systems for PMs — interchange modeling and reconciliation are two ends of the same pipe.

Float: The Time-Value Lever Most Payments PMs Underweight

Float is the money sitting in your custody between when a customer pays and when you settle it to the recipient, and the interest or investment return it can earn during that window is real, if usually modest, revenue. For any product holding balances — marketplaces, neobanks, expense cards — float economics can matter as much as fee economics.

Classic examples of float-driven business models include:

• PayPal and early e-wallets, which earned meaningful interest income on customer balances sitting in FDIC-insured or money-market accounts before instant-transfer features became standard.
• Marketplaces with delayed seller payouts (7-14 day holds), where the platform earns float on funds held between buyer payment and seller disbursement.
• Prepaid and gift card issuers, whose breakage (unredeemed balances) combined with float on the redeemed float period has historically been a significant, if unglamorous, profit center.

Float cuts both ways in product decisions

Faster payouts — a feature customers explicitly want — directly reduce your float window and its associated revenue. Instant payout features are usually priced separately (a 1-1.5% instant-transfer fee) precisely because they cannibalize float income the standard payout schedule was quietly generating. If your roadmap includes an instant-disbursement feature, the float loss needs its own line in the model, not just the interchange or scheme cost of moving money faster.

Federal Reserve research on payment system float has documented for decades that even small per-transaction float, aggregated across high transaction volume, adds up to material balance-sheet interest income for institutions holding customer funds — a dynamic still relevant wherever a product holds a balance between receipt and settlement.

The Per-Transaction P&L: A Worked Example

A single transaction's profit and loss statement should list every fee paid out, every fee collected, and the net margin in both percentage and absolute-dollar terms — because a healthy percentage margin can still be an unprofitable transaction below a certain ticket size. This is where most payments features quietly break.

Consider a fintech charging merchants a flat 2.6% + $0.10 per transaction, paying interchange-plus costs of 1.9% + $0.08 to its underlying processor, with a fixed $0.05 per-transaction operational cost (fraud screening, support allocation, infrastructure):

The breakeven ticket size here sits around $8-9 — below that, the fixed $0.10 revenue floor and $0.05 op cost don't cover the fixed $0.08 interchange floor plus the fixed cost. Any feature that drives adoption among low-ticket use cases (tipping, micro-donations, small P2P transfers) needs either a minimum fee, a different pricing structure, or an explicit subsidy decision — not a hope that volume fixes it.

Why "just get more volume" doesn't rescue a broken model

Volume amplifies whatever margin already exists per transaction — it doesn't create margin that wasn't there. A feature with negative or near-zero per-transaction margin becomes a bigger loss at scale, not a bigger profit. This is the single most common unit-economics mistake in payments product work: treating growth and margin as the same problem when they compound in opposite directions if the base transaction is unprofitable.

This is also where the connection to the broader ledger matters. If you're new to how payments products actually track money moving between parties, the double-entry ledger data model for PMs explains the accounting structure underneath every fee line in the table above — understanding debits and credits at the entry level makes take-rate modeling far more intuitive.

Building the Feature Spec Around a Take-Rate Model

A payments feature spec should state its assumed average ticket size, its fee structure, and its break-even point explicitly, the same way a growth feature states its activation-rate assumption. Treat unit economics as a first-class requirement, not a finance afterthought discovered in a QBR.

Practical steps for embedding this into your product process:

1. Get the real interchange table for your card mix from your processor or acquiring bank rather than assuming a single blended rate — the variance between debit and rewards cards is too large to approximate.
2. Model at least three ticket-size scenarios (low, median, high) against your actual transaction distribution, not a single "average" that can hide a large loss-making segment.
3. Separate float assumptions from fee assumptions so a change to payout speed doesn't silently erase float revenue nobody tracked as a line item.
4. Set a minimum viable transaction size or minimum fee if your break-even ticket size is above what real usage patterns suggest customers will bring.
5. Revisit the model whenever card mix, scheme rates, or payout speed changes — interchange schedules update roughly twice a year and scheme fee changes are common enough to warrant a standing calendar reminder.

None of this replaces standard prioritization discipline — a feature can pass a RICE score or land well on a Kano map and still need this unit-economics gate before it ships. The two are complementary checks, not substitutes for each other.

Where This Connects to the Rest of the Payments Stack

Unit economics rarely lives in isolation. Fraud losses eat directly into the margin computed above, which is why treating fraud as a product problem rather than purely a risk-team concern matters for the PM who owns take rate. And every fee assumption ultimately needs to be traced back to what the customer is actually trying to accomplish — a lens the Jobs to Be Done framework is well suited to, since ticket size and payment frequency are often symptoms of the underlying job, not independent variables.

If you're new to the payments PM role broadly, the complete guide to the fintech PM role covers how unit economics fits alongside compliance, fraud, and reconciliation as core competencies — and how the customer journey for a payment often has friction points that map directly onto where fees are collected.

Modeling the Money Flow, Not Just the Math

The math above is straightforward once the entities and relationships are clear — the harder part is usually keeping straight who pays whom, at what rate, under what conditions, especially as a product adds more payment methods and geographies. A spreadsheet formula is only as good as the data model underneath it.

Key Takeaways

• Interchange is the largest, non-negotiable slice of transaction cost, typically 70-90% of the total merchant discount rate, set by network tables segmented by card type and channel.
• Interchange-plus pricing exposes your real card-mix risk; flat-rate pricing hides it until a reconciliation catches the margin compression.
• Float — the interest-earning window between receiving and disbursing funds — is real revenue that instant-payout features directly cannibalize, and needs its own model line.
• A per-transaction P&L in dollars, not just percentage margin, reveals breakeven ticket size — a healthy-looking percentage can still be a money-losing transaction below that threshold.
• Volume amplifies existing margin; it does not create margin. A feature with negative unit economics gets worse, not better, at scale.
• Unit economics belongs in the feature spec itself, alongside activation and adoption assumptions, not discovered later in a finance review.