Interchange & Platform Economics
If the Card Transaction Lifecycle explained how a transaction moves, and Stakeholders in a Card Program explained who's involved, this page explains who pays whom, and when — the economic engine that makes card programs commercially viable, and how this model differs from the traditional one.
What is interchange?
Interchange is a fee paid by the merchant's acquirer to the cardholder's issuer for each transaction. It's set by the card network (not negotiated transaction-by-transaction) and published as a rate table, typically expressed as a percentage of the transaction value plus a fixed amount, varying by factors including:
- Card-present vs card-not-present (CNP) — CNP transactions (online, phone) typically carry higher interchange due to higher fraud risk
- Debit vs credit — debit interchange is often lower, and in some jurisdictions is subject to regulatory caps (e.g. the Durbin Amendment in the United States caps debit interchange for large issuers, and the EU limits interchange on debit cards to 0.2% and credit cards to 0.3%)
- Merchant Category Code (MCC) — different categories of business (e.g. supermarkets vs travel agencies) often have different rates
- Transaction size — the fixed-fee component matters more for small transactions; the percentage component dominates for large ones
- Network — Visa and Mastercard each publish their own rate tables, which differ
Why interchange exists
Interchange compensates the issuer for:
- Fronting funds between authorization (when the cardholder's funds are reserved) and settlement (when the issuer actually receives payment). Recall from the Card Transaction Lifecycle that this can be a multi-day gap
- Bearing fraud and credit risk on transactions
- Operating the infrastructure that makes card payments possible (authorization systems, customer service, dispute resolution)
- Issuer processor costs for the card authorizations and processing
- Funding any rewards or benefits offered to cardholders
Where interchange revenue goes — the traditional model
When a cardholder makes a $100 purchase, the flow of fees typically looks like this:
- The merchant agrees to a Merchant Discount Rate (MDR) with its acquirer — say, 2.5% — and receives the net amount.
- The acquirer keeps a margin (e.g. 0.15% to 0.5% in an interchange++ model) and passes the rest toward the network and issuer. (The alternative to interchange++ (in which the acquirer transparently marks up the interchange and scheme assessment fees) is a blended fee that covers all three principal payouts.)
- The card network collects an assessment fee (e.g. 0.1% to 0.15%) for operating the network.
- The issuer (or technically the network member, which is often the issuer) receives the interchange portion — say, 1.85% to 2.25% in this example — through the issuer processor, which is the issuer parties' primary revenue from this transaction.
- If any of the issuer parties (e.g. the issuer itself, issuer bank, issuer processor, program manager, and network member) are separate entities, the interchange revenue is then split between them according to a commercial arrangement, often negotiated as a percentage share.
- Similarly, the acquirer side often has multiple parties to payout.
- Often, the various issuer and acquirer parties have to wait not only for net settlement of the transaction itself but also for their respective paymasters (in the case of the issuer side, who is waiting on the network, who is waiting on the acquirer).
This last point is the crux of the traditional model: interchange revenue is a shared pool, divided among multiple parties according to multilateral agreements, and its arrival is gated by the settlement timeline described in the Card Transaction Lifecycle — commonly T+1 to T+3 or longer from the transaction date.
flowchart TB
T1["Merchant pays Acquirer<br/>(Merchant Discount Rate)"]
T2["Acquirer retains its margin,<br/>forwards interchange + assessment to Network"]
T3["Network retains assessment fee,<br/>routes interchange to Issuer"]
T4["Issuer parties split interchange,<br/>per multilateral agreements"]
T5["Each share arrives on the<br/>settlement timeline (T+1 to T+3+)"]
T1 --> T2 --> T3 --> T4 --> T5
The Axys model
Although Axys has no control over acquirer-side fees or the scheme assessment fee, it has largely eliminated the multi-party interchange-sharing model: fees are instead charged directly to the card on the issuer side, achieving T+0 settlement. Each Program sets its own fees.
A single bundled fee, not a revenue share
Rather than interchange flowing through multiple parties who each take a negotiated cut, Axys allows fees to be set at the Program level. What would traditionally be separate line items — the interchange-derived revenue share, network assessment costs, processing costs, and payment-rail and network integration costs — are substituted by a Program-specific fee structure, set directly by the Tenant and Program, combined with T+0 settlement.
The specific rate and split for the fees are commercially negotiated between the Tenant and the Program. It isn't a published figure, much as traditional interchange-sharing percentages are also individually negotiated between issuers, processors, and program managers. What's structurally different is that it's a single unified fee rather than a shared pool, and fees are remitted near-instantly.
T+0 settlement
As covered in the Card Transaction Lifecycle, traditional settlement takes T+1 to T+3 (or longer) from the network. The Axys platform programmatically settles with the Program on a T+0 (same-day) basis, regardless of the underlying network settlement cycle. This materially changes the liquidity and cashflow position of running a card program: you're not waiting multiple days to know your revenue position or to access funds.
Layered markups — your margin, not a shared pool
Your Program and your Tenant can each apply their own fee structure. For example, a foreign-transaction fee charged to cardholders, a monthly account fee, or an FX spread on currency conversion (see Embedded FX & Cross-Border Fees).
This is structurally different from the traditional model's interchange split:
- Traditional model: interchange revenue is a pool, divided among the issuer parties by negotiated percentages — each party's markup is really a shared pot.
- Axys model: you set the fees you want to apply. This is pure margin agreed between the authorized Tenant and each underlying Program.
flowchart TB
A1["Tenant markup (optional) — pure margin"]
A2["Program markup (optional) — pure margin"]
A3["Same-day settlement (T+0)"]
A4["Cardholder pays one unified fee,<br/>debited in a single charge,<br/>either embedded spread or itemized"]
A1 --> A2 --> A3 --> A4
Configurable billing and settlement
Billing cycle (e.g. per-transaction vs periodic invoicing) and settlement currency/asset (fiat or digital-asset settlement) are configurable per Tenant/Program.
Billing cycle and settlement currency/asset configuration are part of Account Management. See API Users, Tenants & Programs.