Interchange++ (IC++)

Interchange++ (IC++) is a pricing model in which the acquirer passes interchange and scheme fees through at cost and adds its own markup as a separate line. Because the three layers of cost appear apart, each one can be recalculated against its own source: the scheme's rate tables, the scheme's fee schedule and your contract.

Last reviewed 28 September 2026

How IC++ is calculated

Under IC++ the charge for each transaction is the sum of three parts: the interchange rate for its category, the scheme fees that apply to it, and the acquirer markup set in your contract. The first two should match the schemes' own published figures, and the third should match your rate card.

Two other models are common. Blended pricing charges one rate that covers everything, so no layer is visible. Interchange plus (IC+) passes interchange through but folds scheme fees into the acquirer's margin. IC++ gives the most detail of the three, which is why buyers with enough volume to negotiate usually ask for it. The detail only helps if someone checks it: interchange in the UK and EEA is capped at 0.2% for consumer debit and 0.3% for consumer credit, while scheme fees and markup are not (Ryft, 2026).

Where IC++ goes wrong on a bill

IC++ goes wrong when a pass-through line carries more than the cost it claims to pass through. The usual cases are scheme fees rolled into one line with an uplift, interchange billed above the scheme rate, markup calculated on the wrong base, and exceptions in a schedule that move some card types back to a blended rate.

Being on IC++ does not stop two acquirers billing the same thing differently. A large merchant told the Reserve Bank of Australia that different acquirers charged it different scheme fees "for like-for-like transactions despite having an interchange++ plan" (RBA summary of submissions, 2025). A statement that labels a line "scheme fees" tells you what the acquirer calls it, and the schedule tells you what it should be.

How to check IC++

Split the statement into its three layers and check each against its own source. Interchange is checked against the scheme rate tables, scheme fees against the scheme fee schedule and notices, and markup against your contract and its addenda. Anything left over that belongs to no layer needs an explanation from the acquirer.

Recalculate at transaction level where the data allows, because category and region errors disappear in totals. Check the base the markup is charged on: a percentage of transaction value gives a different answer from a percentage of the total including interchange. Read the schedules for exceptions, such as commercial cards or certain regions priced on a blended rate. FeeVerify builds one rule per fee from the contract and the scheme schedules, then recalculates every transaction against all three layers at once.

Worked example

A PSP on IC++ processes 100,000 transactions worth £4,000,000 in a month. Interchange and markup match their sources. The line labelled scheme fees comes to 20% more than the schedule gives for the same transactions, because the acquirer applied a handling uplift the contract does not mention. The figures are synthetic.

LayerSourceExpectedBilledVariance
InterchangeScheme rate tables£9,200£9,200£0
Scheme feesScheme fee schedule£4,400£5,280£880
Markup at 0.25% of valueYour contract£10,000£10,000£0

The £880 variance appears only once the scheme fee line is recalculated from the schedule. The statement looks like correct IC++, since each layer is shown apart, and the error sits inside the one line nobody recalculated. Synthetic figures for illustration.

Start with one month of your own data.

A pilot begins with the agreements that protect both sides, then your contracts and one month of settlement data, scoped with a payments specialist on the first call. The 30-day diagnostic re-costs every transaction against them and shows each variance with its clause, before any recurring fee.