Gestaltung eines agilen Bezahlsystems: Delegierte Befugnisse, veraltete Kostenvoranschläge, Wiederholungsversuche

Früher war das Entwerfen eines Bezahlsystems ein einfaches Thema in Vorstellungsgesprächen, da es überall Referenzlösungen gab und ein geeigneter Kandidat diese in zwanzig Minuten nachbilden konnte. Die aktuelle Variante setzt einen Software-Agenten zwischen Käufer und Verkäufer ein, wodurch fast jede Annahme, die in den vorherigen Lösungen zugrunde lag, nicht mehr gilt. Es gibt keinen kanonischen Artikel, den man auswendig lernen könnte – und genau das ist der Grund, warum diese Frage immer wieder gestellt wird.

Warum es entstanden ist

Drei Entwicklungen trafen innerhalb kurzer Zeit ein.

Zunächst ein offener Standard: Das Agentic Commerce Protocol, das gemeinsam von OpenAI und Stripe entwickelt wurde, legt fest, wie Käufer, ihre Agenten, Verkäufer sowie Zahlungsdienstleister miteinander kommunizieren. Im Zentrum steht ein gemeinsamer Zahlungstoken – der Agent kann einen Kauf abschließen, ohne jemals die Kartendaten zu sehen, während der Verkäufer weiterhin die Rolle des offiziellen Händlers behält.

Zweitens: ein konkurrenzfähiges Design. Googles Agent Payments Protocol betrachtet Autorisierungen als signierte Anweisungen, die in Form von JWTs mit selektiver Offenlegung übertragen werden. Eine Anweisung belegt, dass der Benutzer den Kauf genehmigt hat, und eine weitere die Genehmigung der Zahlung – wobei jede davon entweder offen sein kann, um Einschränkungen im Voraus festzuhalten, oder geschlossen sein kann und an einen endgültigen Warenkorb gebunden ist.

Drittens: Die Sicherheitsforschung schreitet schnell voran. Eine systematische Untersuchung von AP2 listet 48 verschiedene Bedrohungen auf, die in fünf Kategorien eingeteilt sind; acht davon werden als hochgradig gefährlich eingestuft, wobei alle in einem Live-Testumfeld getestet wurden und nicht nur beschrieben wurden. Für einen Interviewer ist das ideales Material, da die Fehlermuster real und konkret sind und es keine Tricks braucht, um der Frage Tiefe zu verleihen.

Die Anfrage in ihrer ursprünglichen Form

Die Formulierungen variieren, doch die Anforderungen bleiben stets in dieser Größenordnung:

1. Ein Käufer bittet einen Assistenten, etwas zu kaufen, wobei möglicherweise Einschränkungen wie ein Höchstpreis oder ein Liefertermin festgelegt werden.
2. Der Agent prüft mehrere Verkäufer, bewertet die Optionen und entscheidet sich schließlich für einen.
3. Die Zahlung wird abgewickelt, ohne dass der Agent jemals die Rohdaten der Karte berührt.
4. Der Käufer kann überprüfen, was genehmigt wurde, und Streitigkeiten können später geklärt werden.
5. Es kommt niemals zu einer Doppelbestellung oder zu einer Aktion, die über das hinausgeht, was der Käufer tatsächlich zugestimmt hat.

Die fünfte Anforderung verdient eine zweite Lektüre, denn alles Schwierige findet sich dort. Diese fünf Zeilen erzeugen alle schwierigen Unteraufgaben, und ein Kandidat, der mit dieser Vergleichstabelle beginnt anstatt mit Diagrammen, hat sich bereits von den meisten Mitbewerbern abgesetzt. Das Üben mit Fragen zur tatsächlichen Zahlungsinfrastruktur ist ein schneller Weg, um das erforderliche Vokabular zu beherrschen, da Bücher, Idempotenz und Abwicklung hier in agenter Form vorkommen.

Problem eins: Delegierte Befugnis

Der Käufer ist zum Zeitpunkt des Kaufs abwesend, daher muss etwas seine Zustimmung ersetzen.

Die schwache Lösung behält eine Zahlungsmethode im System, damit der Agent nach einer Zustimmung des Benutzers abziehen kann. Dies funktioniert nicht, weil eine Zustimmung um 10:00 Uhr für einen Kaffemühler unter 80 Pfund nicht ausreicht, um das zu decken, was der Agent um 10:04 Uhr auswählt. Ein Modell, eine Kette von Werkzeugen und möglicherweise eine manipulierte Produktbeschreibung fallen alle in diese Lücke.

Die Standards handhaben dies auf drei Arten:

• Eine Genehmigung wird zu einem unterschriebenen Objekt mit definiertem Umfang, anstatt nur ein Zertifikat zu besitzen.
• Dieses Objekt trennt Absicht von Ausführung: Ein offenes Mandat enthält Beschränkungen wie einen Preisobergrenzen und eine Kategorie, während ein geschlossenes Mandat an einen bestimmten Endwagen gebunden ist.
• Zahlungszertifikate werden durch einen Token ersetzt, der nur für einen Händler und eine Transaktion gültig ist, sodass ein gestohlener Token nur einmal für ein einzelnes Produkt verwendet werden kann.

Punkte, die ausgesprochen werden sollten: Begrenzen Sie jede Zuschusszahlung hinsichtlich Betrag, Händler, Kategorie und Ablaufdatum; verlangen Sie die endgültige Form vor jeder Geldüberweisung, damit das unterschriebene Dokument und der gekaufte Artikel identisch sind; betrachten Sie außerdem den Auftrag als das eigentliche Autorisierungsprotokoll und nicht als eine Hülle, die die Kartennutzung erleichtert.

Problem zwei: bindende Angaben – oder warum sorgfältige Agenten auf veraltete Daten zurückgreifen

Fast niemand bringt dieses Thema von selbst zur Sprache, und es lässt sich messen.

Ein sorgfältiger Einkaufsagent liest viele Angebote durch, bevor er sich entscheidet. Das gewinnende Angebot wurde zu Beginn des Vergleichs gelesen, was bedeutet, dass je sorgfältiger der Agent vorgeht, desto veralteter ist seine beste Datenquelle.

Eine Simulation fügte dazu eine Abbildung hinzu. Der Agent befragt nacheinander jeden Verkäufer, verbringt dabei drei bis acht Sekunden pro Anfrage, überlegt anschließend fünf bis fünfzehn Sekunden lang über alles nach und trifft schließlich eine Entscheidung. Preise und Bestände ändern sich nach einem Poisson-Prozess, wodurch bestimmt wird, wie wahrscheinlich es ist, dass das ausgewählte Angebot zum Zeitpunkt der Entscheidung bereits geändert wurde.

Bemerkenswert ist das Muster: Der Wechsel von einem Verkäufer auf zwanzig verdoppelt die Wahrscheinlichkeit einer veralteten Entscheidung um etwa das Fünffache bei jeder Wechselrate – somit untergräbt genau das Verhalten, das Käufer erwarten, die eigenen Eingaben des Agents. Bei recht aggressivem dynamischem Preissystem endet ein Drittel der sorgfältigen Vergleiche mit einem Angebot, das bereits geändert wurde.

Die Konsequenzen für die Gestaltung sind konkret:

• Kostenangebote sind von dem Server ausgegebene Objekte, die jeweils eine ID sowie eine kurze Gültigkeitsdauer haben.
• Die endgültige Autorisierung ist an ein Hash des abgeschlossenen Warenkorbs gebunden, genau wie es eine abgeschlossene Bestellung bietet.
• Zur Abwicklung überprüft der Verkäufer erneut Preis und Lagerbestand und lehnt bei Abweichungen ab, anstatt stillschweigend zu liefern.
• Falls die Änderung die von ihnen festgelegten Grenzen überschreitet, sendet der Verkäufer eine neue Kostenvoranschau und eine Nachricht an den Käufer.

Kandidaten vergessen oft den letzten Punkt: Es ist das richtige Verhalten, eine veraltete Bestellung abzulehnen, und ohne einen Mechanismus für neue Kostenvoranschauen wird ein Preisfehler lediglich zu einem Zuverlässigkeitsfehler.

Problem drei: Wiederholungsversuche und der wertlose Idempotenzschlüssel des Agents

Idempotenzschlüssel werden in jeder Antwort erwähnt, doch in der üblichen Konfiguration verbirgt sich ein Haken.

Normalerweise erstellt der Kunde einen Schlüssel und sendet denselben beim erneuten Versuch. Agenten untergraben das. Wenn eine Antwort verschwindet, sendet ein Agent oft nicht die gleiche Anfrage erneut; er plant neu, was zu einer neuen Anfrage mit einem neuen Schlüssel führt, und der Server behandelt diese als neuen Versuch.

Dieses Verhalten wurde direkt modelliert anstatt angenommen, wobei 5 % der Antworten nach der bereits erfolgten Abrechnung bei bis zu drei Versuchen verloren gehen:

• Wenn der Agent bei jedem Versuch einen neuen Schlüssel erstellt, werden 4,98 % der Bestellungen zweimal abgebucht, was im Durchschnitt 1,052 Abrechnungen pro Bestellung ergibt.
• Wenn der Schlüssel auf dem Server aus der Warenkorbverknüpfung abgeleitet wird, sinken die Duplikate auf 0,00 % und jede Bestellung wird genau einmal abgebucht.

Der simulierten Wert von 4,98 % entspricht der exakten Wahrscheinlichkeit von 5,00 %, was sinnvoll ist, da ein Duplikat genau dann auftritt, wenn die erste Antwort fehlt.

Fazit: Erstellen Sie den Idempotenzschlüssel aus einem von dem Käufer genehmigten Element, nicht aus etwas, was der Aufrufer selbst erfunden hat. Der Hash, der die abgeschlossene Anweisung mit dem Warenkorb verbindet, dient bereits diesem Zweck, sodass keine zusätzliche Arbeit erforderlich ist.

Problem vier: Wer ist der offizielle Händler?

Es handelt sich um eine geschäftliche Frage, die als Systemfrage getarnt ist, und sie bestimmt das Datenmodell.

• Mit einem gemeinsamen Token bleibt der Verkäufer der offizielle Händler, wodurch die Agenturplattform keinerlei Haftung für Abrechnungen, Steuern und Rückerstattungen trägt.
• Falls die Plattform hingegen kauft und weiterverkauft, wird es für den Agenten einfacher – allerdings entstehen dadurch ganze Bereiche mit regulatorischen Vorgaben.
• Formulieren Sie die Annahme frühzeitig, innerhalb von zwei Minuten, da daraus Rückerstattungen, Steuern und Streitigkeiten folgen.

Problem fünf: Prüfbarkeit als Anforderung

Eine der fünf Bedrohungsgruppen in der AP2-Analyse bezieht sich ausschließlich auf Rechenschaftspflicht – also auf die Aufbewahrung von Beweisen und Auditableität. Viele übergehen dieses Aspekt, obwohl es darüber entscheidet, ob ein Streitpunkt nach sechs Monaten gelöst werden kann.

Für jede Transaktion soll unveränderlich gespeichert werden:

• Sowohl die offene als auch die geschlossene Version der unterschriebenen Weisung.
• Der genaue Cart-Hash, der genehmigt wurde, zusammen mit dem Inhalt des Carts.
• Die Quoten-ID sowie das Datum der Erstellung und des Ablaufs.
• Die Version des Agenten und des Modells, die tätig war, sowie die Delegation, unter der sie handelte.
• Jeder Ablehnungsfall und sein Grund, denn Ablehnungen belegen, dass die Kontrollmechanismen funktionierten.

Ein Referenzpfad

Eine klare Antwort verfolgt einen Kauf von Anfang bis Ende:

1. Der Käufer gibt ein mit Grenzen versehenes Ziel an, und die Plattform erteilt eine offene Weisung, die durch Betrag, Kategorie und Ablaufdatum begrenzt ist.
2. Der Agent sammelt Angebote von potenziellen Verkäufern ein, und jeder Verkäufer antwortet mit einem Kostenvoranschlag, der eine ID sowie einen Ablauftermin enthält.
3. Der Agent wählt eines aus und bittet um eine endgültige Bestellliste, die vom Verkäufer unterschrieben wird.
4. Die Plattform erstellt ein abgeschlossenes Mandat, das mit dem Hash dieser Bestellliste verknüpft ist, und überprüft es gegen die Grenzen des offenen Mandats.
5. Für diesen Verkäufer wird ausschließlich ein Zahlungstoken für genau diese Summe ausgestellt.
6. Der Verkäufer überprüft erneut Preis und Lagerbestand und führt anschließend die Transaktion durch, wobei eine Idempotenzschlüssel aus dem Hash der Bestellliste verwendet wird.
7. Sämtliche Dokumente aus den Schritten eins bis sechs werden vor dem Versenden einer Antwort im Prüfungsdatenspeicher gespeichert.
8. Falls es beim Schritt sechs zu einer Unstimmigkeit kommt, wird zum Schritt zwei zurückgekehrt – oder falls die Änderung die Grenzen des Käufers überschreitet, an diesen zurückgegeben.

Jeder der acht Schritte existiert, weil sonst ein bestimmter Fehler ungeschützt bliebe, und genau das Beziehen jedes Schritts auf seinen entsprechenden Fehler ist es, was ein Interviewer tatsächlich bewertet.

Bewertung einer Übungsanwort

Auszeichnung verdienen Antworten, die:

• das Delegierungsmodell innerhalb von zwei Minuten darlegen und sich danach daran halten;
• die offene Zusage von der festen Verpflichtung unterscheiden und erklären, warum beide notwendig sind;
• ohne Aufforderung das Problem der Veraltetheit ansprechen, idealerweise mit einer ungefähren Zahl;
• die Idempotenz aus dem genehmigten Zustand ableiten, nicht aus den von der Aufrufstelle bereitgestellten Daten;
• die Audit-Trail als Anforderung betrachten und nicht nur als bloßes Protokollieren.

Auszeichnung geht verloren bei Antworten, die:

• den Agenten als schnellen Menschen darstellen, obwohl die größten Schwierigkeiten aus den Unterschieden zu einem Menschen resultieren;
• dem Agenten irgendeine Art von wiederverwendbaren Zugangsdaten geben;
• Man geht davon aus, dass ein Neversuch einfach der erneute Versand derselben Anfrage ist;
• Es wird ein Ablehnungsfall konzipiert, bei dem es keinen weiteren Schritt gibt;
• Fragen bezüglich der Verantwortung und des zuständigen Anbieters werden auf den letzten Platz verschoben, obwohl sie das Datenschema bestimmen.

Warum sich die Vorbereitung auf diese Anfrage lohnt

Die polnische Sprache ist nicht mehr ein nützliches Kriterium bei der Einstellung, seit es kostenlose, überzeugende Antworten auf alle klassischen Fragen gibt. Der agierende Zahlungsabwicklungsprozess ist ein aktuelles Beispiel, bei dem es keinen solchen Shortcut gibt. Die Protokolle sind erst seit wenigen Monaten vorhanden, die Bedrohungsforschung ist noch jünger, und es gibt bisher keine Einigung über die Abwägungen.

Dadurch belohnt die Anfrage nicht länger die in den Übungsbänken für das Fähigkeitsniveau vermittelten Methoden: das Schlussfolgern aus wirklich verstandenen Einschränkungen. Eine gute Beherrschung dieser Fähigkeit bereitet zudem auf jede Frage vor, die sie ersetzen könnte, da der grundlegende Ansatz unverändert bleibt. Man sollte sich fragen, was sich ändert, sobald das, was auf der anderen Seite der API steht, kein Mensch mehr ist.