The uplift number on the orchestration slide is real, published by Visa, and about something you already own

A payments lead I have worked with for years sent me a vendor deck last month with a single number on the third slide: a 4 per cent uplift in authorisations. It is a good number. It is also, I told them confidently, the reason to buy the platform, and that was bad advice built on a figure I had never traced to its source.

So what is payment orchestration, once you take the uplift claim out of the answer? I went looking for the source of that four per cent, which took me most of an afternoon, because the number on the slide is real, published by Visa, and about something you can switch on without buying anything at all.

The same network publishes four different uplift numbers

Visa is unusually open about its tokenisation results, which is what makes the exercise possible at all. It is also why the exercise is uncomfortable. I would rather the numbers were hidden, and that is a poor instinct that I notice in myself every time this comes up.

One Visa page reports “a 30 percent reduction in fraud online vs. PAN (16-digit card number) and a four percent uplift in authorization”, footnoted to VisaNet data from October to December 2022. The same page, a paragraph later, says Visa “is seeing a more than three percent authorization rate lift with tokens for Card-not-Present (CNP) transactions”, this time footnoted to January to March 2022. Then it says token CNP transactions “have seen a 4.6 percent lift in authorization rates globally, compared to PAN”. The Visa Token Service factsheet reports 3 per cent.

Four numbers, four footnotes, four different windows and populations. I find it hard to read past that without wincing. The 4.6 per cent figure comes from Visa Risk Datamart covering merchants “with over 1,000 CNP token transactions per month per country”, and it carries the sentence that every business case skips: “Merchant’s individual results may vary.”

Each figure carries its own period, its own data set and its own cut, and every one of them is footnoted properly. That is more than most vendors manage, and it makes me slightly annoyed that the care goes into the footnote and not into the slide. It does mean that anyone quoting the figure as though there were one figure has stopped reading at the number, and I had done exactly that in a room full of people who trusted me to have read further.

And none of it is about orchestration

Every one of those figures measures network tokens against raw card numbers. A network token is issued by the scheme. It survives card reissue. Your acquirer or gateway can enable it for card on file traffic without any orchestration layer existing anywhere in the stack, which is the single most useful sentence in this article and the reason that deck annoyed me.

Visa says tokens now operate in 198 countries, with the Token Service factsheet putting the figure at 189 markets, 8,500 issuers enabled as of July 2022, and more than four billion tokens issued between October 2014 and that month. The fraud side is reported twice as well, at 30 per cent lower online fraud in one place and 28 per cent by payment volume in the other. That is infrastructure rather than a product category, and buying an orchestrator to obtain it is like buying a car to get the radio.

The abandonment figure gets quoted the same loose way. Visa says payment issues can cause up to 44 per cent of digital abandonment, and the footnote points at an EMARKETER forecast rather than at VisaNet, so it describes a market rather than your checkout. I had assumed it was Visa’s own measurement for years, and it is not.

Which leaves the real question, and I asked it badly for two years by starting from the vendor category instead of from the job: what does the layer actually do that nothing underneath it does?

The definition, without the marketing

Payment orchestration is a routing and abstraction layer sitting between your checkout and several payment providers. One integration on your side, many acquirers and methods on the far side, plus a rules engine that decides which transaction goes where, retry logic when something is declined, a vault so card credentials are not trapped inside one provider, and reconciliation across all of them.

The honest case for it is not uplift. I would put it differently to a board: the decision of where to send a transaction has consequences you cannot see from inside a single provider, and in Europe one of those consequences is regulatory rather than commercial. That is a smaller claim than the deck makes and a much easier one to defend.

Where the numbers are actually hard: the exemption regime

The European rules on strong customer authentication are the opposite of vendor material. They specify thresholds to the euro and consequences to the quarter, and they sit in Commission Delegated Regulation (EU) 2018/389, which is free to read.

Article 16 lets a provider skip authentication for small remote payments where “the amount of the remote electronic payment transaction does not exceed EUR 30” and the cumulative amount since the last authentication “does not exceed EUR 100”, or where the count since the last authentication “does not exceed five consecutive individual remote electronic payment transactions”.

Article 18 is the interesting one, and I would put its Annex on the wall next to the VAMP footnote, because it is the rare piece of payments regulation that hands you a price list instead of a principle: a 500 euro ceiling requires a reference fraud rate of 0.01 per cent for remote card payments, a 250 euro ceiling requires 0.06 per cent, and a 100 euro ceiling requires 0.13 per cent. The lower your fraud, the larger the payments you may wave through. That is the whole trade.

The conditions are specific too. The real time analysis must find none of six things: abnormal spending or behaviour, unusual device or software information, malware in the authentication session, a known fraud scenario, an abnormal payer location, or a high risk payee location.

Put a shop against that table and the bands stop being abstract. I use this arithmetic in every conversation about routing now. Take an average basket of 74 euros and a measured card fraud rate of 0.04 per cent. That shop clears the 250 euro band, which asks for 0.06, and misses the 500 euro band, which asks for 0.01, by a factor of four. Almost all of its baskets sit under 100 euros anyway, where the tolerance is 0.13 and it has three times the headroom it needs. The 500 band is not a target for that shop. It is a distraction, and I have watched two teams build routing rules aimed at it.

Now move the same shop to a 240 euro basket without changing anything else. The applicable reference rate drops from 0.13 to 0.06, its 0.04 goes from three times covered to comfortable but close, and one bad month of card testing puts it over. We use the gap between the current rate and the applicable reference rate as the number to watch, not the rate itself.

The part that turns routing into a compliance decision

Article 20 is where this stops being a pricing exercise, and it is the passage I would read before signing anything. A provider whose monitored fraud rate goes over the reference rate must report it to the regulator immediately with a description of the remedy; if the rate stays above for two consecutive quarters the provider must stop using the exemption in that threshold band altogether; it may not resume until a full quarter back at or below the reference rate; and it must notify the authority and produce evidence before resuming.

There is an audit attached. The methodology, the model and the reported fraud rates are audited at least annually, and in the first year of using the exemption and at least every three years after that the audit must be done by an independent, qualified external auditor with expertise in IT security and payments.

Article 19 closes the last gap by requiring the overall fraud rate to cover both authenticated transactions and every transaction exempted under Articles 13 to 18, so a provider cannot improve the ratio by shuffling traffic between buckets.

The Annex has a second column that almost nobody quotes, because it covers remote credit transfers rather than cards, and the numbers there are tighter by an order of magnitude: 0.005 per cent at the 500 euro ceiling, 0.01 at 250 and 0.015 at 100. A shop moving customers towards bank transfers to save on interchange is moving them into a band where the fraud tolerance is roughly ten times stricter, which is not a trade-off I have seen anyone put on a slide.

Read together, those articles say something a routing dashboard does not. Sending traffic to the provider with the best exemption performance is not merely cheaper, it protects the exemption itself, and losing it costs you conversion on every basket in the band for at least two quarters after the numbers go wrong.

The numbers worth memorising

The list is short enough to carry in your head. That is unusual for anything in this area, and I still find it the most useful page of the regulation. EUR 30 per transaction and EUR 100 cumulative under Article 16. Or 5 consecutive transactions as the alternative test. EUR 500, EUR 250 and EUR 100 as the 3 risk bands. Their prices in card fraud are 0.01, 0.06 and 0.13 per cent. For remote credit transfers the same bands cost 0.005, 0.01 and 0.015 per cent. 2 consecutive quarters over the line loses the exemption. 1 clean quarter earns it back. 1 external audit in the first year and another at least every 3 years after that.

Everything else here is context around those 11 numbers, and the 11 are the part a routing rule can actually be written against.

What that means for the buying decision

Enable network tokens through whatever you already have. Hold the vendor to the footnote rather than the headline when they quote an uplift, and ask which of the four numbers it is. That work needs no new platform and no new contract.

I would consider orchestration in three situations and no others: when you genuinely run more than one acquirer, when your exemption performance differs measurably between them, or when your card credentials being locked inside one provider is the thing stopping you from moving. Those are the cases where the layer does something the layer underneath cannot.

My guess is that most shops under a few million in annual volume fail all three tests, and I suspect the vendors know the shape of that distribution far better than the market does. It is a guess either way. Nobody publishes the numbers, and I do not know of a survey that asks the question in a form you could act on.

Questions we get

Five that come up whenever a deck like that one goes round.

Is multi acquirer routing worth it below a certain size? The mechanical answer is that a second acquirer only pays for itself once the volume you can move covers a second integration and a second reconciliation, and the compliance answer above changes that calculation in Europe because exemption performance differs between providers and it is not a number you can see from inside either of them. Below a million or so a year the second integration usually wins the argument on cost and loses it on nothing.

What smart routing rules actually matter? I would keep the list to four. The ones tied to a threshold in the regulation rather than to a basis point in a price sheet. Amount bands against the 30, 100, 250 and 500 euro lines, transaction risk signals that map onto the six conditions in Article 18, and card type. Everything else is fine tuning that will not survive contact with a fraud rate breach.

What is the real orchestration platform cost? I cannot tell you, and I dislike writing that in a piece about buying decisions. No vendor I checked publishes a price, both pages route you to a sales contact, and any number I put here would be invented rather than reported.

How does a network token migration work between platforms? Tokens are issued by the scheme rather than by the platform, which is the whole argument for portability, but who holds the relationship and what happens on exit is contract detail. I have not found a description general enough to quote, so ask for the exit clause in writing before the pilot rather than after it.

What does a sound sca exemption strategy look like? Measure your fraud rate the way Article 19 defines it, across authenticated and exempted traffic together, then pick the threshold band you can actually hold rather than the highest one you qualify for this quarter. Falling out of a band costs two quarters minimum.

A short digression about the word platform

Orchestration, gateway, acquirer, processor, vault and PSP describe overlapping things, and the same company will call itself three of them on three different pages depending on who is reading. I still find that harder to forgive than any pricing question, because it is the reason merchants buy a second copy of something they already own. Anyway, back to the regulation.

What is not settled here

Whether orchestration adds authorisation uplift beyond what tokenisation adds. The schemes do not measure it, the vendors measure it on their own customer bases, and no independent figure exists that I would put in front of a board.

What the platforms cost. Two vendor pages checked, no pricing on either, so the honest answer is a shrug and a request for a quote.

Who owns the token vault in practice when a merchant leaves. The mechanics depend on the contract, and two descriptions are not enough to generalise from. It is the question I keep thinking about, because it is the one that decides whether the layer you bought for portability is itself portable.