Warum Payment-Intent-Architektur den Gateway-Charge-Call schlägt

Klassische Gateways exponieren Zahlungen als Funktionsaufruf: Charge senden, Erfolg oder Fehler erhalten. Diese Abstraktion hält genau so lange, bis die Realität dazwischenfunkt — ein Timeout, bei dem Sie nicht wissen, ob die Bank abgebucht hat, ein Retry beim zweiten Acquirer, ein Teil-Capture, ein Refund auf einen Capture, der selbst partiell war. Ein Boolean kann diese Geschichte nicht tragen.

Ein Intent modelliert die Zahlung stattdessen als langlebige State Machine: initiiert, in Verarbeitung, wartet auf 3-D Secure, autorisiert, teilweise erfasst, erfasst, erstattet — jede legale Transition definiert, alles andere abgelehnt. Code kann eine nicht autorisierte Zahlung nicht „versehentlich“ erstatten — die Transition existiert schlicht nicht.

Der unterschätzteste Zustand ist der ehrliche: needs-reconciliation. Läuft eine Bank in den Timeout, lautet der wahre Status „unbekannt“ — und etwas anderes vorzugeben, ist das Rezept für Doppelbelastungen. Ein Intent kann dort parken, während ein Sweep die Bank fragt, was wirklich geschah — und erst dann weitergehen. Ein Charge-Call hat keinen Parkplatz; er muss in eine Richtung lügen.

Intents machen auch Multi-Acquirer-Routing natürlich. Versuch eins wird abgelehnt; die Cascade zündet Versuch zwei unter demselben Intent — gleicher Idempotenz-Scope, gleicher Audit-Trail, garantiert eine Abbuchung. Bei Charge-Call-Gateways ist jeder Retry eine brandneue Zahlung — und sie zu einer Kundengeschichte zu vernähen, wird Ihr Problem.

Schließlich emittiert ein Intent bei jeder Transition Events — eine append-only Historie, die Sie hash-verketten, auditieren und wieder abspielen können. Das ist nicht nur Compliance-Hygiene; es ist das Substrat, auf dem Webhooks, Ledger und Dispute-Beweise aufbauen. Das Gateway gab Ihnen eine Antwort. Der Intent gibt Ihnen eine Akte.