Know the IC++ cost of every transaction, as it happens
Interchange and every scheme fee calculated in under 50 ms, at authorization, capture, refund and chargeback — each one traced to the rule and rate that produced it.
txn_103838897746976156_6003583
Interchange
IRD EW · 1.150000%
Scheme fees
2 applied
- PreAuth HN2EA1126€0.000200
- Acquirer authorization2EA1166Q€0.009300
True cost
at authorization
Per status
A transaction's cost changes as it moves. So does the price.
An authorization does not cost what a capture costs, and a refund is not a negative purchase. Recivr prices each status event as it arrives, applying fixed fees at the status the scheme actually bills them rather than smearing them across the lifecycle.
- Downgrades and misqualification surface on the transaction that caused them
- Partial captures and reversals reprice against what actually cleared
- New fee events are caught immediately, not found on an invoice
- 1
Authorized
Pre-auth and authorization fees, priced the moment the request lands.
- 2
Captured
Clearing, settlement and ad valorem fees, plus the interchange that finally applies.
- 3
Reversed
Partial and full reversals repriced against what was actually cleared.
- 4
Refunded
Credit interchange and refund-side scheme fees, not a mirrored debit.
- 5
Chargeback
Dispute fees and the interchange consequences of the lifecycle stage.
Interchange resolution
The rate that will actually apply, not the one you hoped for
Interchange is resolved from the card product and funding source, the issuer and merchant geography, the MCC, the entry mode, the authentication result and the clearing timing — the same inputs the scheme uses, evaluated against the qualification criteria that decide the rate.
- Regional, intra-country, intra-regional and interregional rate sets
- Interchange designators carried through onto the transaction
- Rate versions with effective dates, so history stays truthful
Interchange per day
Interchange
€175.6k
on €23.97M volume
Effective rate
0.733%
73.3 bps
Per transaction
€0.4525
388,025 txns
Commercial cards are 3% of volume but 5% of interchange — they price at 1.050% against 0.721% for everything else.
The API
Send the payload you already produce.
One endpoint, a JSON body built from fields your switch already carries, and a response that names every fee, its rate basis and where the rule came from.
- Totals in currency and in basis points
- So the number is usable by a pricing team and a finance team without translation.
- Settlement currency and FX
- Fees and settlement resolved on one rate, returned on every status.
- Deterministic and replayable
- The same input and rule version always produces the same output — including for historical periods.
200 OK · 25 ms
{
"transaction_id": "103838897746976156_6003583",
"status": "CAPTURED",
"region": "INTRA_NON_EEA",
"interchange": {
"amount": 1.150000,
"ird": "EW",
"rate": "1.150000%",
"source": "MC Europe Manual, eff. 2026-04-10"
},
"scheme_fees": {
"per_transaction": [
{ "code": "2EA1126", "name": "PreAuth HN", "amount": 0.000200 },
{ "code": "2EA1166Q", "name": "Acquirer authorization", "amount": 0.009300 },
{ "code": "2GC1521PA", "name": "Acquirer volume · DMC", "amount": 0.020000 },
{ "code": "2GC1901", "name": "Card not present GH", "amount": 0.025000 },
{ "code": "2LY7106", "name": "Non-local currency", "amount": 0.100000 }
],
"fixed_periodic": { "lines": 16, "amount": 0.068164 }
},
"totals": {
"interchange": 1.150000,
"scheme_fees": 0.222664,
"true_cost": 1.372664,
"bps_of_volume": 137.27
},
"settlement": { "currency": "EUR", "fx_rate": 1.0 }
}Integration
Plug and play, either direction.
Recivr sits beside the transaction path. Nothing about how you process has to change.
Card transaction
An authorization, capture, refund or chargeback arrives.
Gateway or switch
Sends the payload it already has. The transaction path is unchanged.
Recivr fee engine
Resolves interchange and every applicable scheme fee, and responds in under 50 ms.
Analytics, reconciliation, monitoring
The same priced events feed the surfaces you review later.
A gateway or processor integrates Recivr once. Every acquirer on that platform inherits real-time IC++ costing without writing a line of code.
Either way, Recivr never needs a PAN — it prices from the transaction attributes that determine cost.
What the engine handles
The awkward parts of scheme pricing, handled as first-class cases
Every fee shape
Ad valorem rates, fixed per-transaction fees, tiered volume bands, minimums and caps — applied on the basis the scheme actually bills.
ICA and BID level fees
Fees billed at portfolio level are attributed back to the volume that drove them, not divided by a flat divisor.
Tier families
A tiered fee behaves as one fee across its variants, so a transaction cannot be charged twice for crossing a boundary.
Effective dating
Rules carry the dates the schemes gave them. Historical transactions keep the rate that priced them.
Entity configuration
Per-entity currencies, FX bases and fee eligibility, so a group with several licences prices each one correctly.
Anomaly surfacing
When a transaction cannot be priced cleanly it is surfaced with the reason, rather than silently defaulted.
Who it's for
Principal licence holders and the platforms that serve them
Acquirers
With a principal Visa and/or Mastercard licence, settling interchange and scheme fees directly, pricing merchants on IC++.
Gateways and processors
Embedding cost intelligence once so every acquirer on the platform inherits it as a switchable feature.
FAQ
Fee engine questions
What does a fee calculation response contain?
The interchange amount and the rate that produced it, each scheme fee that applied with its identifier and rate basis, the assessments, the totals in transaction and settlement currency, and the FX rate used. Every line carries a trace back to the rule, the rate and the source document that set it.
Which fee types does the engine handle?
Ad valorem rates, fixed per-transaction fees, tiered volume fees, blended rates, minimum and maximum caps, and fees billed at ICA or BID level that have to be attributed back to the volume that drove them. Fixed fees are applied at the status the scheme actually bills them at, not smeared across every event.
How do you handle interchange downgrades and misqualification?
The engine evaluates the qualification criteria on the transaction itself — entry mode, authentication, data quality, clearing timing — and prices the rate that will actually apply. When a transaction fails to qualify for the rate it was expected to earn, it surfaces on that transaction rather than as an unexplained shortfall on the invoice.
What happens when the schemes change their rules?
The April and October releases and the interim bulletins are mapped into the engine with effective dates and a reference to the source document. Rates change on the date the scheme says they change, and you can see which rule version priced any historical transaction.
Do you need cardholder data?
No. Recivr prices from the transaction attributes that determine cost — BIN range metadata, card product and funding source, routing geography, MCC, entry mode, authentication result, amount and currency. No PAN, no cardholder identity, nothing that expands your PCI scope.
The rest of the platform
One engine, several surfaces.
Every product below runs off the same priced transaction events.
Pricing management
Set how each merchant is priced by region, card type, amount and currency, and see the margin on every transaction.
Merchant analytics
Scheme cost in basis points by merchant, MCC, card product and region, so under-priced merchants stand out.
Invoice reconciliation
Visa and Mastercard invoices matched line by line against calculated fees, with every difference traced to its rule.
Interchange reconciliation
The schemes' own clearing reports reconciled against your transactions, with a daily deviation in basis points.
Rule change monitoring
Visa and Mastercard releases and bulletins mapped in with effective dates, so you see what each change costs before it is billed.
Find the margin in your own book
Send us a day of traffic and a clearing file. We'll return the true IC++ cost of every transaction in it, and show you where the margin is being lost.