Payment orchestration: who is accountable for a routing decision?
Payment Orchestration: Wer verantwortet eine Weiterleitungsentscheidung?
Payment orchestration sells a simple promise: connect once, route anywhere, and stop being hostage to a single provider. It delivers on that. It also inserts a new party into the chain, and the questions that party raises are the ones nobody asks in the sales meeting.
What an orchestrator does
A merchant of any size ends up with several payment providers: one for cards in one region, another for a local method, a third for a specific currency. Each has its own integration, its own reconciliation format, its own failure modes.
An orchestration layer abstracts that. The merchant integrates once with the orchestrator, which holds the connections and routes each transaction. Add smart routing — send this transaction to whichever provider is likeliest to authorise it — and there is measurable revenue in it. Authorisation rate differences of a few percentage points between providers are real and material at scale.
The dependency that replaces the dependency
The pitch is escaping provider lock-in. Note what it actually does: it moves the lock-in one layer up.
The orchestrator now holds the integration, the routing logic, the tokenised card data in many cases, and the operational knowledge of how the merchant’s payments work. Leaving it is at least as hard as leaving a PSP was, and often harder, because the merchant no longer maintains direct relationships with the providers underneath.
This is not a criticism of the model so much as an accurate description of it. Abstraction layers always concentrate dependency; the question is whether what you get back is worth it. Frequently it is. But a merchant choosing orchestration to reduce dependency should understand it is choosing which dependency, not whether.
Who is responsible when it routes wrong
Here the picture gets genuinely murky, and it is the reason we are writing about this.
Routing decisions affect outcomes that carry regulatory weight. Whether a transaction is authenticated, which acquirer’s fraud ratio it lands in, which jurisdiction’s rules apply to the settlement, whether a merchant’s volume is split in a way that keeps each account below a monitoring threshold — all of these are consequences of routing logic that sits with a party that is usually not a regulated payment institution and often not a licensed entity at all.
Consider volume splitting specifically. An orchestrator that routes to keep each underlying account’s dispute ratio comfortable is doing something that looks like optimisation from the merchant’s side and looks like evasion from the network’s. The rules on monitoring programmes assume a merchant has a merchant account. They are less clear about a merchant that effectively has six, allocated dynamically by a third party.
What we would ask an orchestrator
Does the routing logic ever have the effect of keeping an account below a monitoring threshold, and is that effect deliberate? Are the underlying acquirers told how volume is being allocated? When a merchant is terminated by one provider, is that fact propagated to the others, or does the orchestrator simply route around it?
That last question is the one that matters most. If an orchestrator responds to a termination by shifting volume elsewhere, it has converted a risk decision by a licensed institution into a routing event — and the next acquirer inherits a merchant whose history it cannot see.
Our view
Orchestration is a legitimate and useful category, and most orchestrators are running an honest business solving a real integration problem. But a layer that makes routing decisions with regulatory consequences, while sitting outside the regulatory perimeter, is exactly the kind of gap that gets noticed only after something goes wrong.
We would rather report on it now.
Sources: card network rules on merchant monitoring programmes and payment facilitator obligations; published orchestration provider documentation; PSD2 provisions on the regulatory status of technical service providers. This article contains opinion, marked as such, and makes no allegation about any specific provider.
Payment Orchestration verkauft ein einfaches Versprechen: einmal anbinden, beliebig weiterleiten, nicht mehr einem Anbieter ausgeliefert sein. Das hält es. Es schiebt aber auch eine neue Partei in die Kette — und die Fragen, die diese Partei aufwirft, stellt im Verkaufsgespräch niemand.
Was ein Orchestrator tut
Ein Händler ab einer gewissen Größe hat mehrere Zahlungsdienstleister: einen für Karten in einer Region, einen für ein lokales Verfahren, einen dritten für eine bestimmte Währung. Jeder mit eigener Anbindung, eigenem Abstimmungsformat, eigenen Fehlerbildern.
Eine Orchestrierungsschicht abstrahiert das. Der Händler bindet einmal an, der Orchestrator hält die Verbindungen und leitet jede Transaktion weiter. Kommt intelligentes Routing dazu — schicke diese Transaktion zu dem Anbieter, der sie am ehesten autorisiert —, steckt darin messbarer Umsatz. Unterschiede in der Autorisierungsquote von einigen Prozentpunkten zwischen Anbietern sind real und in der Menge erheblich.
Die Abhängigkeit, die die Abhängigkeit ersetzt
Das Argument lautet: raus aus der Bindung an einen Anbieter. Tatsächlich verschiebt es die Bindung eine Ebene nach oben.
Der Orchestrator hält nun die Anbindung, die Routing-Logik, in vielen Fällen die tokenisierten Kartendaten und das Betriebswissen darüber, wie die Zahlungen des Händlers funktionieren. Ihn zu verlassen ist mindestens so schwer, wie es das Verlassen eines Zahlungsdienstleisters war, oft schwerer — weil der Händler zu den darunterliegenden Anbietern keine eigenen Beziehungen mehr pflegt.
Das ist weniger Kritik am Modell als seine zutreffende Beschreibung. Abstraktionsschichten konzentrieren immer Abhängigkeit; die Frage ist, ob der Gegenwert stimmt. Häufig stimmt er. Wer sich aber für Orchestrierung entscheidet, um Abhängigkeit zu verringern, sollte wissen, dass er wählt, welche — nicht ob.
Wer haftet, wenn falsch geleitet wird
Hier wird das Bild wirklich unklar, und deshalb schreiben wir darüber.
Routing-Entscheidungen wirken auf Ergebnisse mit regulatorischem Gewicht. Ob eine Transaktion authentifiziert wird, in wessen Betrugsquote sie fällt, welches Recht auf die Abwicklung anwendbar ist, ob das Volumen eines Händlers so aufgeteilt wird, dass jedes Konto unter einer Überwachungsschwelle bleibt — all das folgt aus einer Logik bei einer Partei, die meist kein zugelassenes Zahlungsinstitut und oft überhaupt nicht erlaubnispflichtig ist.
Nehmen wir die Volumenaufteilung. Ein Orchestrator, der so leitet, dass die Streitquote jedes darunterliegenden Kontos bequem bleibt, tut etwas, das von der Händlerseite wie Optimierung aussieht und von der Netzwerkseite wie Umgehung. Die Regeln zu Überwachungsprogrammen gehen davon aus, dass ein Händler ein Händlerkonto hat. Zu einem Händler, der faktisch sechs hat, dynamisch zugeteilt von einem Dritten, sagen sie weniger.
Was wir einen Orchestrator fragen würden
Hat die Routing-Logik jemals den Effekt, ein Konto unter einer Überwachungsschwelle zu halten — und ist dieser Effekt beabsichtigt? Erfahren die darunterliegenden Acquirer, wie das Volumen verteilt wird? Wird die Kündigung durch einen Anbieter an die anderen weitergegeben, oder leitet der Orchestrator einfach daran vorbei?
Die letzte Frage wiegt am schwersten. Reagiert ein Orchestrator auf eine Kündigung damit, das Volumen zu verschieben, hat er die Risikoentscheidung eines zugelassenen Instituts in ein Routing-Ereignis verwandelt — und der nächste Acquirer erbt einen Händler, dessen Vorgeschichte er nicht sehen kann.
Unsere Einschätzung
Orchestrierung ist eine legitime und nützliche Kategorie, und die meisten Anbieter betreiben ein ehrliches Geschäft und lösen ein echtes Anbindungsproblem. Aber eine Schicht, die Weiterleitungsentscheidungen mit regulatorischen Folgen trifft und dabei außerhalb des regulierten Bereichs sitzt, ist genau die Art Lücke, die erst auffällt, wenn etwas schiefgeht.
Wir berichten lieber vorher darüber.
Quellen: Regelwerke der Kartennetzwerke zu Überwachungsprogrammen und Pflichten von Payment Facilitators; veröffentlichte Dokumentation von Orchestrierungsanbietern; PSD2-Vorgaben zum regulatorischen Status technischer Dienstleister. Dieser Beitrag enthält Meinung, als solche gekennzeichnet, und erhebt keinen Vorwurf gegen einen bestimmten Anbieter.