The vendor layer: how many companies stand between a customer and a payment
Die Anbieterschicht: wie viele Unternehmen zwischen einem Kunden und einer Zahlung stehen
Ask a merchant who processes its payments and the answer is usually one company. Trace an actual transaction and the count is rarely below six. Most of the parties in that chain have no contract with the merchant, no relationship with the customer, and no obligation to either — and several of them can stop the payment entirely.
Counting the parties
Follow a single card payment from a checkout page to a merchant’s bank account.
The checkout or gateway collects the card details, usually in a hosted field so that the data never touches the merchant’s servers. The fraud engine scores the transaction, frequently a separate vendor called synchronously. An orchestration layer, if present, decides which provider receives it. The payment service provider formats and submits the authorisation. The acquirer holds the licence and submits into the network. The card network routes to the issuer, which authorises or declines. Then tokenisation, 3-D Secure and network token services sit alongside, each potentially a distinct provider. Settlement, reconciliation and payout may involve further parties again.
Six is a floor. Nine or ten is common for a merchant of any size operating internationally. Each is a distinct company with its own uptime, its own release schedule, its own incident process and its own commercial interests.
Why the stack grew
It is worth being clear that this did not happen through carelessness. Each layer was added because it solved something.
Hosted checkout fields removed card data from merchant systems and shrank PCI scope dramatically. Specialist fraud engines outperform anything a merchant would build. Orchestration removed the need to integrate every provider separately. Tokenisation improved both security and authorisation rates. Every one of these was the right decision at the moment it was taken.
What was never taken was a decision about the total. Each layer was evaluated on its own merits, against the alternative of not having it. Nobody evaluated the ninth vendor against the cumulative fragility of having nine.
What the merchant loses
Diagnosis. When authorisation rates drop two points, the cause could be an issuer’s risk model, a fraud rule, a routing change, a token migration, or a formatting regression in an authorisation message. Each vendor can see its own segment and reports that its segment is healthy. Nobody holds the end-to-end view, and the merchant — who is the only party with an interest in the whole — usually has the least data.
Attribution of failure. A failed payment produces a decline code that travels back up the chain, frequently generalised at each hop. What the merchant sees is often several categories collapsed into one. The information needed to fix the problem was present at the issuer and was discarded before it arrived.
Compound availability. Nine services at 99.9 per cent availability, all required synchronously, deliver about 99.1 per cent — roughly eight hours a year of unavailability rather than one. That arithmetic is unforgiving and is almost never done, because each vendor reports its own figure and each figure looks fine.
Negotiating position. A merchant integrated into nine vendors cannot credibly threaten to leave any of them quickly. Switching cost is the sum of integration effort, data migration and risk, and it rises with every layer. Pricing conversations reflect that.
The dependency nobody mapped
The more serious issue is that the vendors are not independent of each other.
Several run on the same cloud provider, in the same region. Several use the same underlying fraud data consortium, the same identity verification supplier, the same telecoms provider for one-time passcodes. A merchant that has carefully selected two providers for redundancy may have selected two companies whose services terminate in the same availability zone.
This is exactly the concentration risk that the European designation of critical technology providers is aimed at, and the designation criteria are worth borrowing regardless of whether any given vendor is in scope: what is the systemic impact of a failure, how concentrated is reliance, and how substitutable is the service under the conditions where substitution would be needed.
Very few merchants can answer the second question about their own stack, because it requires knowing their vendors’ vendors, and that information is not routinely disclosed.
What to do about it
Four things, none of which requires dismantling anything.
Draw the map. List every party in the authorisation path, mark which are synchronous, and compute compound availability from the published figures. The number is usually worse than expected, and having it changes conversations.
Ask each vendor who they depend on. Cloud provider, region, and any third party in their own critical path. A vendor that cannot answer has not asked itself, which is the more useful finding.
Preserve one path that bypasses the stack. A direct integration to a single acquirer, tested quarterly, is cheap insurance. The value is not that it is good — it is that it works when the sophisticated path does not.
Own the end-to-end data. Log every transaction with the identity of each party that touched it and the raw response each returned. This is the only way to answer a diagnostic question without depending on the answers of the parties being investigated.
The general lesson is not that specialisation is wrong. It is that a chain assembled one justified decision at a time has properties nobody chose, and those properties only become visible when someone counts.
Fragt man einen Händler, wer seine Zahlungen abwickelt, lautet die Antwort meist: ein Unternehmen. Verfolgt man eine tatsächliche Zahlung, liegt die Zahl selten unter sechs. Die meisten Beteiligten dieser Kette haben keinen Vertrag mit dem Händler, keine Beziehung zum Kunden und keine Pflicht gegenüber beiden — und mehrere von ihnen können die Zahlung vollständig stoppen.
Die Beteiligten zählen
Verfolgen wir eine einzelne Kartenzahlung von der Kassenseite bis zum Bankkonto des Händlers.
Die Kasse oder das Gateway nimmt die Kartendaten auf, meist in einem eingebetteten Fremdfeld, damit die Daten nie die Server des Händlers berühren. Die Betrugsmaschine bewertet die Zahlung, häufig ein eigener, synchron aufgerufener Anbieter. Eine Orchestrierungsschicht, sofern vorhanden, entscheidet, wer sie erhält. Der Zahlungsdienstleister formatiert und übermittelt die Autorisierung. Der Acquirer hält die Lizenz und reicht ins Netzwerk ein. Das Kartennetzwerk leitet an den Kartenherausgeber, der autorisiert oder ablehnt. Daneben stehen Tokenisierung, 3-D Secure und Netzwerk-Token-Dienste, jeder womöglich ein eigener Anbieter. Abrechnung, Abstimmung und Auszahlung können weitere Parteien einbeziehen.
Sechs ist die Untergrenze. Neun oder zehn ist für einen international tätigen Händler jeder Größe üblich. Jeder ist ein eigenes Unternehmen mit eigener Verfügbarkeit, eigenem Veröffentlichungsplan, eigenem Störungsprozess und eigenen wirtschaftlichen Interessen.
Warum der Stapel gewachsen ist
Es gehört klargestellt, dass das nicht aus Unachtsamkeit geschah. Jede Schicht kam hinzu, weil sie etwas löste.
Eingebettete Kassenfelder haben Kartendaten aus den Händlersystemen entfernt und den PCI-Geltungsbereich drastisch verkleinert. Spezialisierte Betrugsmaschinen schlagen alles, was ein Händler selbst bauen würde. Orchestrierung hat die Notwendigkeit beseitigt, jeden Anbieter einzeln anzubinden. Tokenisierung hat Sicherheit und Autorisierungsquoten zugleich verbessert. Jede dieser Entscheidungen war im Moment ihrer Entstehung richtig.
Nie getroffen wurde eine Entscheidung über die Summe. Jede Schicht wurde für sich bewertet, gegen die Alternative, sie nicht zu haben. Niemand hat den neunten Anbieter gegen die kumulierte Zerbrechlichkeit von neun Anbietern bewertet.
Was der Händler verliert
Diagnose. Fällt die Autorisierungsquote um zwei Punkte, kann die Ursache das Risikomodell eines Kartenherausgebers sein, eine Betrugsregel, eine Leitungsänderung, eine Token-Migration oder ein Formatierungsfehler in einer Autorisierungsnachricht. Jeder Anbieter sieht seinen Abschnitt und meldet, dieser sei gesund. Niemand hat den Blick von Ende zu Ende — und der Händler, die einzige Partei mit Interesse am Ganzen, hat meist die wenigsten Daten.
Zuordnung von Fehlern. Eine gescheiterte Zahlung erzeugt einen Ablehnungscode, der die Kette zurückwandert und auf jeder Stufe häufig verallgemeinert wird. Was der Händler sieht, sind oft mehrere Kategorien, zu einer zusammengefaltet. Die Information, die zur Behebung nötig wäre, lag beim Kartenherausgeber vor und wurde vor der Ankunft verworfen.
Verkettete Verfügbarkeit. Neun Dienste mit 99,9 Prozent Verfügbarkeit, alle synchron nötig, ergeben rund 99,1 Prozent — also etwa acht Stunden Ausfall im Jahr statt einer. Diese Arithmetik ist unbarmherzig und wird fast nie durchgeführt, weil jeder Anbieter seinen eigenen Wert meldet und jeder Wert gut aussieht.
Verhandlungsposition. Wer in neun Anbieter integriert ist, kann keinem davon glaubhaft mit einem schnellen Wechsel drohen. Die Wechselkosten sind die Summe aus Integrationsaufwand, Datenmigration und Risiko, und sie steigen mit jeder Schicht. Preisgespräche spiegeln das.
Die Abhängigkeit, die niemand kartiert hat
Das ernstere Problem ist, dass die Anbieter nicht voneinander unabhängig sind.
Mehrere laufen beim selben Cloud-Anbieter, in derselben Region. Mehrere nutzen dasselbe Betrugsdatenkonsortium, denselben Identitätsprüfer, denselben Telekommunikationsanbieter für Einmalcodes. Ein Händler, der sorgfältig zwei Anbieter für Redundanz ausgewählt hat, hat womöglich zwei Unternehmen ausgewählt, deren Dienste in derselben Verfügbarkeitszone enden.
Genau das ist das Konzentrationsrisiko, auf das die europäische Benennung kritischer Technologieanbieter zielt — und die Benennungskriterien lohnen die Übernahme, unabhängig davon, ob ein bestimmter Anbieter erfasst ist: Welche systemische Wirkung hat ein Ausfall, wie konzentriert ist die Abhängigkeit, und wie ersetzbar ist der Dienst unter den Bedingungen, unter denen Ersatz nötig würde.
Sehr wenige Händler können die zweite Frage über den eigenen Stapel beantworten, denn dazu müsste man die Anbieter der eigenen Anbieter kennen — und diese Information wird nicht routinemäßig offengelegt.
Was zu tun ist
Vier Dinge, von denen keines einen Abriss verlangt.
Die Karte zeichnen. Jede Partei im Autorisierungspfad auflisten, markieren, welche synchron ist, und aus den veröffentlichten Werten die verkettete Verfügbarkeit berechnen. Die Zahl fällt meist schlechter aus als erwartet, und sie zu haben verändert Gespräche.
Jeden Anbieter fragen, wovon er abhängt. Cloud-Anbieter, Region und jede dritte Partei in seinem eigenen kritischen Pfad. Ein Anbieter, der nicht antworten kann, hat sich die Frage nicht gestellt — was der nützlichere Befund ist.
Einen Pfad bewahren, der den Stapel umgeht. Eine direkte Anbindung an einen einzelnen Acquirer, vierteljährlich getestet, ist billige Versicherung. Ihr Wert liegt nicht darin, gut zu sein — sondern darin, zu funktionieren, wenn der ausgefeilte Weg es nicht tut.
Die Daten von Ende zu Ende selbst halten. Jede Zahlung mit der Identität jeder beteiligten Partei und deren Rohantwort protokollieren. Nur so lässt sich eine Diagnosefrage beantworten, ohne auf die Antworten der untersuchten Parteien angewiesen zu sein.
Die allgemeine Lehre ist nicht, dass Spezialisierung falsch wäre. Sie lautet: Eine Kette, die aus lauter begründeten Einzelentscheidungen zusammengesetzt wurde, hat Eigenschaften, die niemand gewählt hat — und diese Eigenschaften werden erst sichtbar, wenn jemand zählt.
