Warum Capture einfach ist, aber Finalisierung schwer (Warum Capture Einfach Ist Aber Finalisierung Schwer)

Ein Schritt, sechs Schritte

Wenn Sie „Zahlung erhalten“ sagen, meinen Sie meist eines: Das Provider-Gateway hat eine Anfrage an den PSP gesendet, und der PSP sagte „Ich habe das Geld genommen“. Das ist ein Aufruf, eine Antwort, eine Prüfung. Sagen Sie aber „Bestellung abgeschlossen“, meinen Sie etwas viel Größeres: Bestand wurde reduziert, ein Ledger-Eintrag wurde geöffnet, die Bestellung wurde bestätigt, der Kunde wurde benachrichtigt, der Warenkorb wurde bereinigt, und eventuelle Treuepunkte wurden verarbeitet.

Capture:       Checkout Orchestrator → Provider-Gateway → PSP → "captured"

Finalisierung: Bestand reduzieren + Ledger-Eintrag + Bestellbestätigung + Benachrichtigung + Aufräumen
               (sechs unabhängige Schritte, jeder kann für sich fehlschlagen)

Dieser Teil behandelt die prägendste Frage dieser Serie: Warum ist Capture einfach, und warum ist Finalisierung schwer?

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Capture
Die Bestätigung des PSP, einen zuvor autorisierten oder direkt angeforderten Betrag tatsächlich eingezogen zu haben; eine einzelne externe Systemtatsache.

📦 Finalisierung
Die Summe aller internen Schritte, die nach dem Capture nötig sind, damit die Arbeit tatsächlich erledigt ist: Bestand, Finanzen, Bestätigung, Benachrichtigung, Aufräumen.

📦 Saga
Ein Workflow-Muster, das mehrere Schritte end-to-end verwaltet, jeder mit eigener Fehler- und Kompensationslogik.

📦 Kompensationsschritt
Eine umgekehrte Operation, die die Wirkung vorheriger Schritte ausgleicht, wenn ein Saga-Schritt sich nicht einfach zurücknehmen lässt.

📦 Schritt-Marker
Ein dauerhafter Datensatz, der einen Saga-Schritt als abgeschlossen markiert, damit ein erneuter Lauf ihn nicht wiederholt.

Captures Einfachheit kommt davon, dass es nur von einem Teilnehmer (dem PSP) und einer Antwort abhängt. Finalisierungs Schwierigkeit kommt davon, dass sie von vielen Teilnehmern abhängt, die jeder für sich fehlschlagen können.

Warum Capture einfach ist

Capture hat ein Erfolgskriterium in einem Satz: Hat der PSP „eingezogen“ gesagt oder nicht. Diese Tatsache kommt synchron oder per Webhook an, ihre Signatur wird geprüft, und der zugehörige Payment-Datensatz wechselt zu Captured. Es gibt kein Schreiben in mehrere Datenbanken, kein sequenzielles Aufrufen mehrerer abhängiger Services — nur die Ja/Nein-Antwort eines externen Systems.

Provider-Gateway --Anfrage--> PSP
Provider-Gateway <--"captured"-- PSP
                        ↓
                Payment.Status = Captured
                (ein Schreibvorgang, eine Entscheidung)

Warum Finalisierung eine Saga ist

Ist Capture fertig, ist die Arbeit nicht erledigt — der wirklich komplexe Teil beginnt jetzt. Damit die Bestellung als „tatsächlich fertig“ gilt, müssen alle folgenden Schritte zuverlässig laufen, in irgendeiner Reihenfolge, bis jeder einzelne abgeschlossen ist:

Finalisierungs-Saga
  1. Bestandsreservierung in eine endgültige Reduzierung umwandeln
  2. Umsatzeintrag in Finanzen/Ledger öffnen
  3. Bestellpositionen als bestätigt markieren
  4. Kunden benachrichtigen
  5. Warenkorb/aktive Intent bereinigen
  6. (Falls vorhanden) Treuepunkte oder Kampagneneffekte verarbeiten

Jeder dieser sechs Schritte hat seinen eigenen Fehlermodus: Der Bestands-Service kann vorübergehend nicht erreichbar sein, der Finanz-Service kann eine Validierung ablehnen, der Benachrichtigungs-Service kann ein Timeout haben. Bei Capture gab es ein Ja/Nein; bei Finalisierung gibt es sechs unabhängige Ja/Neins, und keines garantiert die anderen.

Teilweise Finalisierung: der gefährlichste Zwischenzustand

Das schwierigste Szenario ist, wenn die Hälfte der Saga lief und die andere Hälfte nicht. Zum Beispiel wurde der Bestand reduziert, aber der Finanzeintrag konnte nicht geöffnet werden; der Prozess ist abgestürzt, und der neu startende Worker muss genau wissen, welche Schritte bereits fertig waren.

Finalisierungs-Saga läuft
  ✓ Bestand reduziert
  ✓ Bestellung bestätigt
  ✗ Finanzeintrag — Worker ist hier abgestürzt
  ? Benachrichtigung — nie versucht

Worker startet neu: Welche Schritte soll er WIEDERHOLEN, welche ÜBERSPRINGEN?

Ohne Schritt-Marker können Sie diese Frage nicht beantworten. Jeder Schritt muss seinen eigenen Abschluss dauerhaft festhalten; sonst läuft ein neu startender Worker entweder die gesamte Saga erneut und reduziert den Bestand zweimal, oder er tut nichts, und die Bestellung bleibt für immer stecken.

Warum diese Unterscheidung unterschätzt wird

Die meisten Teams meinen mit „Payment-Integration“ nur Capture und planen es als eine Woche Arbeit. Die Finalisierungs-Saga wird meist als „Details“ behandelt und geht ohne richtiges Design in Produktion. In Wirklichkeit ist Capture — wie Teil eins und zwei zeigten — das Sprechen mit einem einzelnen externen System; Finalisierung erfordert, dass Ihr eigenes System gegen seine eigenen Fehler resilient ist. Letzteres verlangt eine deutlich größere Engineering-Investition.

Die am häufigsten verwechselten Zuordnungen

❌ Payment-Integration = Capture implementieren
✓ Payment-Integration = Capture + die gesamte Finalisierungs-Saga

❌ Wenn Capture erfolgreich war, ist die Arbeit erledigt
✓ Capture ist der Start-Trigger der Finalisierungs-Saga, nicht ihr Ende

❌ Die Reihenfolge der Saga-Schritte spielt keine Rolle, es ist „dieselbe Transaktion“
✓ Jeder Schritt kann unabhängig fehlschlagen; jeder braucht eigene Retry- und Kompensationslogik

❌ Stürzt der Worker ab, ist ein kompletter Neustart der Saga sicher
✓ Ohne Schritt-Marker wiederholt ein Neustart bereits abgeschlossene Schritte und erzeugt doppelte Nebenwirkungen

Checkliste zum Testen Ihrer Finalisierungs-Saga

1. Schreiben Sie jeden Schritt Ihrer Finalisierungs-Saga einzeln auf: Wie viele Schritte gibt es, und welche rufen unabhängige Services auf?
2. Testen Sie, ob jeder Schritt für sich idempotent ist: Ändert sich das Ergebnis, wenn Sie denselben Schritt zweimal ausführen?
3. Töten Sie den Worker absichtlich mitten in der Saga (Chaos-Test). Welche Schritte überspringt er beim Neustart, welche wiederholt er?
4. Hat jeder Schritt einen Kompensations- oder Retry-Plan für seinen Fehlerfall, oder wurde er unter der Annahme geschrieben, „dieser Schritt gelingt immer“?
5. Wenn Capture erfolgreich ist, die Finalisierungs-Saga aber nie startet — nach wie vielen Minuten merken Sie es?

Wenn Sie zwei dieser fünf Tests nicht bestehen, wurde Ihre Finalisierungs-Saga wahrscheinlich für den Happy Path geschrieben, nicht für den Fehlerpfad.

Was aus diesem Teil bleiben sollte

1. Capture ist die Ja/Nein-Antwort eines einzigen externen Systems (des PSP); daher seine Einfachheit.
2. Finalisierung ist eine Saga, die den Abschluss mehrerer unabhängiger Schritte erfordert; daher ihre Schwierigkeit.
3. Teilweise Finalisierung — manche Schritte fertig, manche nicht — ist der gefährlichste Zwischenzustand und ohne Schritt-Marker nicht sicher wiederherzustellen.
4. Wenn „Payment-Integration“ nur Capture umfasst, fehlt der riskanteste Teil des Projekts im Plan.

Capture ist der Moment, in dem der PSP Ihnen zustimmt. Finalisierung ist der Moment, in dem Ihr eigenes System sich selbst zustimmt — und das ist meist die schwerere Seite.