Interchange++ vs Blended Pricing: A UK Guide

A UK consumer debit card payment carries 0.2% interchange. A French-issued debit card paying the same UK merchant online carries 1.15%. On blended pricing you never see that difference, because your provider averages it into one rate. On interchange++ you see it on every line, sometimes two months after the payment.

That is the real choice between the two models. The question is less "which is cheaper" and more "who carries the variance, and can your systems handle the data". The pages that rank for this query explain the definitions well and stop there. None of them shows what the fee data looks like when it arrives, which is the part I end up debugging. This guide covers both.

What Is Interchange++ Pricing?

Interchange++ (IC++, interchange plus plus) splits the cost of a card payment into three parts and passes each through separately:

The first "plus" is scheme fees. The second is the acquirer's margin. The acquirer only negotiates the last one. Interchange and scheme fees are passed through at cost, whatever they turn out to be.

Interchange depends on the card: consumer or commercial, debit or credit, premium or standard, domestic or cross-border, card present or not, and whether the transaction qualified for a lower tier (tokenised, authenticated, enhanced data). I covered one of those levers, the token discount, in the network tokenisation guide.

Interchange++ vs Blended Pricing: What's the Difference?

Blended pricing (Adyen calls it "blended rates", Stripe calls it standard pricing) charges one rate per card category and absorbs the underlying costs. Stripe's UK list price, checked on 10 October 2026:

Stripe offers IC+ only on custom pricing, "for businesses with large payments volume or unique business models". Adyen goes the other way. Its UK price list is IC++ by default for cards: £0.11 per transaction plus interchange, scheme fees and a 0.60% markup on Visa and Mastercard.

The trade-off, stated plainly:

Blended pricing is insurance. Your PSP sets the rate high enough to cover its worst-case card mix, and you pay that premium on every cheap transaction. If your customers mostly pay with UK consumer debit cards, you are overpaying on most of your volume. If they pay with premium corporate cards from outside the UK, blended may be subsidising you.

How Much Is Interchange in the UK and EU in 2026?

Interchange is the only part of the stack with hard legal caps, and they explain most of the gap between the two models.

The Payment Systems Regulator put the extra cost to UK businesses at £150 million to £200 million a year in its December 2023 interim report, and found Visa and Mastercard carry nine in ten of those online transactions.

On blended pricing, that dispute is invisible. On IC++, a cap would cut your costs the day it applies, with no renegotiation. That is a point in IC++'s favour that the vendor comparisons rarely mention.

How Do Stripe, Adyen and Checkout.com Report IC++ Fees?

This is the gap in the existing guides. Every provider exposes IC++ fees differently, and none of them puts interchange on the payment object at authorisation.

Stripe

On standard pricing, the balance transaction carries fee (a positive integer in minor units) and fee_details[]:

{
  "amount": 5000,
  "fee": 95,
  "net": 4905,
  "fee_details": [
    { "amount": 95, "currency": "gbp", "description": "Stripe processing fees",
      "type": "stripe_fee", "application": null }
  ]
}

The type enum is application_fee, payment_method_passthrough_fee, stripe_fee, tax and withheld_tax. There is no interchange or scheme_fee value. For IC+ merchants, the split lives in the Dashboard's Payments fees report, where each row has fee_category (stripe_fee or network_cost) and fee_name. Stripe's own fees are volume_fee and per_auth_fee. Network costs are interchange, card_scheme, non_transactional_card_scheme and discount. Per-auth fees also apply to declines, voids and card validations, which matters if you run a lot of $0 checks.

The programmatic route is the Reporting API's fees reports (all_fees.incurred_at.itemized.2 and siblings), with data available 96 hours after a fee hits your balance. Connect platforms passing network costs through get their own monthly report types, connect_card_payments_fees.transaction_level.1, with bin, card_brand, card_funding and the scheme and interchange columns per charge. One trap: Stripe's docs give the interchange column as interchange_or_discount_fee in the schema table but show separate interchange_fee and discount_fee in the sample. Parse by header, not by position.

Adyen

Adyen's Settlement details report has separate fee columns: Commission (NC), Markup (NC), Scheme Fees (NC), Interchange (NC), Payment Fees (NC). The rule is mechanical. If the acquirer provides interchange-level data, Commission is empty and Markup, Scheme Fees and Interchange are filled. On blended rates, only Commission is filled. Your parser can tell which model a row was priced on from which columns are populated.

The Payment accounting report goes further with an ICSF details column: a JSON array with one object per fee, keyed t (ic or sf), n (name), ipc (interchange programme code), fc (total), fq (fixed), bps (variable), min, max and ccy. That is the closest any of the big three gets to the scheme's own line items in machine-readable form.

Adyen is also the only one with a pre-payment estimate: BinLookup POST /getCostEstimate returns costEstimateAmount (interchange plus scheme fee) for a card BIN before you charge it, available for merchants in the UK, EU and Australia. It is an estimate, but it is enough to route or surcharge-check expensive cards.

Checkout.com

Checkout.com's GET /financial-actions returns a breakdown[] per action, each with a breakdown_type and a fee_detail:

{
  "breakdown_type": "Scheme Fixed Fee",
  "fee_detail": "Visa Fixed Acquirer Network Fee",
  "processing_currency": "GBP",
  "processing_currency_amount": 0.15816820,
  "holding_currency": "USD",
  "holding_currency_amount": 0.19526938,
  "fx_rate_applied": 1.24
}

The type names split cleanly by model: Interchange Fixed Fee, Interchange Variable Fee, Scheme Fixed Fee, Scheme Variable Fee and Premium Variable Fee for IC++, and Blended Fixed Fee and Blended Variable Fee for blended. Every fee has a matching tax type. Note the eight decimal places. Amounts are fractional pennies, so store them as decimals or in a smaller unit than your payment amounts. If your ledger only holds integer minor units, as I recommended in the ISO 4217 minor units guide, keep a separate fee table at higher precision and round once per payout.

Which One Is Easiest to Build Against?

My view: Checkout.com is the easiest to automate on IC++, because the breakdown is an API resource rather than a file. Adyen gives the richest data but makes you parse CSVs with JSON inside them. Stripe on blended pricing is the simplest of all, which is rather the point of blended pricing.

Why Do Interchange++ Fees Change After the Payment?

Interchange is assessed at clearing, not authorisation, and some scheme fees are billed monthly with no transaction attached. Every provider admits this somewhere:

• Stripe: "Card networks can bill fees for a given payment up to two months after it was processed." Its pricing policy reserves the right to adjust network costs retroactively.
• Adyen: per-transaction fees are netted from each payout, but authorisation scheme fees on unsettled transactions and non-transactional scheme fees "are only accounted for at the end of the month" on the invoice.
• Braintree: its transaction-level fee report shows estimated interchange fields (est_interchange_rate, est_interchange_total_amount) on IC+, says estimates are often adjusted through reclassification, and states the report "should not be used for reconciliation" on IC+.
• Checkout.com: the OpenAPI spec describes fee_detail as granularity for "predicted scheme fees", and corrections arrive as Adjustment rows.

The engineering consequence: on IC++, the cost of a payment is not a field you read once. It is a running total that changes for up to two months. If your unit economics dashboard reads fee at payment time, it is wrong for every IC++ transaction until the month closes. On blended, it is right immediately. My reconciliation guide covers the payout side; IC++ adds the invoice as a third source you have to match.

When Is Interchange++ Cheaper Than Blended in the UK?

A worked example with public list prices, on a £50 online payment. Scheme fees are left as S because no provider publishes them as a flat rate.

On UK debit, scheme fees would have to exceed 44p on a £50 payment for blended to win. They do not come close for a standard domestic transaction. On EEA credit the margin narrows to 29p, and premium and commercial cards narrow it further, because their interchange sits outside the caps.

These are list prices. Nobody on IC++ at volume pays Adyen's list markup, and nobody at volume on Stripe pays 1.5% + 20p either. The shape still holds: IC++ wins on capped domestic consumer cards and loses ground as the mix moves to premium, commercial and cross-border.

Opinion: Most UK Teams Should Move to IC++ Earlier Than They Do

The usual advice is "blended until you hit volume". I think the threshold is lower than that advice implies for a UK business with a domestic, debit-heavy mix. The overpayment on capped UK debit is large in relative terms, and it compounds on every transaction.

What actually holds teams back is the data work, and that is getting easier. The PSR's July 2026 policy statement PS26/1 includes Specific Direction 22, which requires the card schemes to give acquirers clearer fee information, including information to help reconcile fees with the transactions that generated them, from the end of July 2027. My prediction: by 2028, at least one of the big three PSPs will put interchange and scheme fees on the payment or balance object itself, rather than in reports, because the scheme-side data will finally be clean enough to do it. Teams that build their fee pipeline now will be ready to consume it. Teams that stay blended will keep paying a premium for not having to.

The exception is a business whose customers pay with premium or corporate cards, or mostly from outside the UK. Blended may be quietly subsidising you. Run the numbers on your actual mix before switching.

What This Means for UK Engineering Teams

1. Pull your card mix before the pricing call. Group the last three months by card_funding (debit or credit), issuer country and card product. The domestic consumer debit share decides most of the answer. 2. Model fees as a ledger, not a field. Store each fee line with its source (payout, report, invoice), its type and a link to the payment. Expect adjustments for up to two months. 3. Hold fee amounts at higher precision. Checkout.com returns eight decimal places. Round once, at payout or invoice level. 4. Parse by column name and by population. Adyen's populated columns tell you the pricing model per row. Stripe's sample and schema disagree on column names. 5. Use the estimate where it exists. Adyen's getCostEstimate lets you flag expensive cards before you charge them, for surcharging rules or routing. 6. Track the PSR cross-border cap. If it lands, EEA card costs on IC++ drop automatically. On blended, you will need to renegotiate to see any of it. 7. Separate unit economics from reconciliation. Use the estimate for real-time margin and the final invoice for the books. Do not try to make one number serve both.

Pricing models look like a commercial decision. On IC++ they become a data model decision too, and that part lands on engineering. I'm Tom Wang, and I'd rather build the fee ledger once than explain a 2% margin gap every month.