Cost per Authorisation: The Unit-Economics Model Every Payments Architect Should Own

The rate card is the wrong place to look

Interchange and scheme fees are priced outside your institution. What you can still engineer is the cost of carrying each transaction through your own platform.

This article argues that payments unit economics is a cost-stack discipline, not a pricing one. An illustrative model (built on hypothetical inputs) shows how three variables move cost per authorisation: volume, licence structure and capacity steps. The inputs describe no real institution or vendor; they are chosen to show structure, not to benchmark.

The unit is the first decision

"Cost per transaction" hides at least three denominators, and they move differently as a business grows. State which one the model uses before comparing anything.

Use cost per authorisation as the headline unit for a platform decision, because peak authorisation load sizes the infrastructure, and report the stack against the other two as well. Then split each unit by the mix that changes its cost: debit against credit, card-present against card-not-present, domestic against cross-border. A blended average hides the segments where margin is actually made or lost.

Externally set lines belong in scenarios, not constants

Three lines sit outside your control, and only one of them is stable. Model each as a scenario input with a base, an adverse and a favourable case.

• EU interchange is fixed in structure. Consumer card caps are 0.2% of transaction value for debit and 0.3% for credit, with transition options for domestic debit. Revenue per transaction is therefore bounded, and the competition moves to cost and to the products around the card.
• Scheme and processing fees are a live regulatory variable in the UK. The PSR's final report of 6 March 2025 found that Mastercard and Visa raised core scheme and processing fees to acquirers by at least 25% since 2017, costing UK businesses at least £170 million extra a year (PSR). Its proposed remedies cover fee information, pricing governance, regulatory financial reporting and publication.
• UK–EEA cross-border interchange may be capped. The BRC's outlook expects a consultation on a formal cap in late 2026 or 2027, and reports that the High Court confirmed the PSR's powers to impose caps in early 2026 (BRC).

Scheme fees are charged to acquirers, but a processor with pass-through clauses carries part of the forecasting risk. The practical rule: a TCO model that holds these lines flat is a forecast with the main uncertainty removed.

Platform cost per authorisation: an illustrative model

Every figure in this section comes from a model with hypothetical inputs. They describe no real institution or vendor, and the absolute values are not benchmarks. The shapes are the point.

In the model, cost per authorisation falls from 9–12 cents at 100 million authorisations a year to 1.8–1.9 cents at 2 billion. The fall is interrupted each time capacity has to step up, and licence structure matters mainly at lower volumes.

Capacity steps add 4–18% to cost per authorisation, depending on licence structure and volume, and the first step, at 320 million a year, hurts most. The per-transaction licence is cheapest below roughly 940 million authorisations; above that the hybrid is, but the two stay within 1% of each other. The capacity-band licence runs 5–18% above the cheapest option between 800 million and 3 billion, because its own price bands compound the infrastructure steps.

At 100 million authorisations a year, people, change, infrastructure and security take 79% of cost per authorisation and exceptions, decisioning and connectivity take 5%. At 2 billion, the fixed and stepped costs fall to 57% while the variable costs rise to 29%, because they scale linearly with volume. In this model, the next saving at high volume comes less from diluting fixed cost than from the cost of each exception and each risk decision.

The same model shows what a shock does. Starting from 800 million authorisations a year:

A 30% volume drop costs 13–21% more per authorisation, and the capacity-band licence is the most exposed because its price does not move until volume crosses a band. The volume rows assume one infrastructure block is released as volume falls; if capacity cannot be shed, the penalty is larger. A doubled exception rate hurts more than the volume loss under the per-transaction and hybrid licences, while a fivefold rise in decisioning cost adds under 7%. In this model, a risk model that cut the exception rate by a third would roughly pay for itself even at five times the decisioning cost.

Costs of failure and of change

The lines that hurt most in a TCO model are the ones nobody budgets as unit costs: failure, regulation and cryptographic change.

• Exceptions and disputes. In the model they cost 0.45 cents per authorisation, 25% of the hybrid stack at 2 billion authorisations. They do not dilute with scale; they follow process design and straight-through rates.
• Fraud liability. The PSD3/PSR final texts were published on 23 April 2026, with Official Journal publication expected in the second half of 2026. The PSR applies 21 months after entry into force, which that source reads as realistic application in 2028 (Dudkowiak). Providers may have to refund customers in impersonation-fraud cases where the conditions are met.
• Post-quantum migration. The G7 Cyber Expert Group's January 2026 roadmap targets 2030–2032 for migrating critical financial systems. ISO 8583 caps authentication data fields at about 256 bytes, and an ML-DSA signature of 2,420 bytes does not fit (PostQuantum.com).
• AI inference. Per-decision model cost is a new variable line. In the model above, even a fivefold rise adds under 7% to cost per authorisation, so the question is whether the model lowers exceptions and fraud losses by more than it costs.

How to build a TCO model that survives scrutiny

A TCO model fails in review when its assumptions are hidden, not when its arithmetic is wrong. Five habits keep it defensible.

• Load the full cost. Licence and hardware are the visible part. Add people, non-production environments, DR, certification and mandatory scheme releases, security and compliance, and the cost of exit or migration.
• Write down the conditions under which the result holds. IBM's own comparison deck, from 2009, says a new application usually costs less on a mainframe if it is an incremental workload on an existing mainframe, can use a specialty processor and needs disaster recovery (IBM).
• Use your own volume curve. McKinsey's card processing benchmark, published in May 2014 on 2004–2012 data, found average cost per transaction falling about 4% a year while volumes grew 9% a year (McKinsey). That implies total processing cost still rose roughly 5% a year.
• Run the shocks. Test volume down 30%, a doubled exception rate, a different mix and the fee scenarios from earlier. Shocks hit options unevenly: in the model above, a 30% volume drop costs 13–21% more per authorisation depending on the licence.

Five questions for the next architecture or vendor review

1. Which unit is this number: authorisation, cleared item or active card, and what mix sits behind it?
2. Where is the next capacity step, what does it cost, and can capacity be released if volume falls?
3. Which licence terms flex with volume in both directions, and where are the bands and minimums?
4. Which lines are fixed, stepped and variable, and which variable ones, such as exceptions and decisioning, are we actively reducing?
5. What do scheme fees, the interchange regime, PSD3/PSR liability and post-quantum migration do to this model in an adverse scenario?

The model here leaves out card and payment mix, one-off migration and ramp-up costs, step changes in staffing and foreign exchange. Its inputs are hypothetical; the structure is the useful part. Replace the inputs with your own volumes, contract terms and cost lines before using it to decide anything.

Sources

• PSR: market review of card scheme and processing fees, remedies consultation
• Regulation Tomorrow: PSR proposed regulatory financial reporting direction, May 2026
• BRC: PSR card fees reviews, latest update and next steps
• Pinsent Masons: EU interchange fee caps
• Dudkowiak: PSD3 and PSR final texts agreed
• Finologee: road to PSD3/PSR, webinar takeaways
• PostQuantum.com: payments and the race to quantum safety
• Encryption Consulting: PQC for financial services
• McKinsey on Payments, issue 19: finding new cost efficiencies in European card processing
• IBM: The Rule of Three (2009)