Was bei einem Reorg mit einer bestätigten Zahlung geschieht

Eine Blockchain-Reorganisation ersetzt die jüngste Historie einer Kette. Die Blöcke des unterlegenen Zweigs werden verworfen, und eine Transaktion, die nur dort stand, gehört danach nicht mehr zur Kette. Entwickler sagen kurz Reorg, deutschsprachige Berichte schreiben von verworfenen oder verwaisten Blöcken — gemeint ist derselbe Vorgang. Erstattet wurde dabei nichts, und umgekehrt hat niemand etwas: Der Eintrag fehlt, das Geld steht dort, wo der siegreiche Zweig es ausweist, in aller Regel weiterhin im Wallet des Zahlers.

Für einen Händler hängt daran genau eine Entscheidung. Darf die Ware raus, oder kann die Zahlung dahinter noch wegbrechen? Wie Bestätigungen und Finalität überhaupt arbeiten, erklärt der Leitfaden zu Bestätigungen; warum die nötige Tiefe von Netzwerk und Betrag abhängt, führt die gestaffelte Regel aus. Dieser Artikel behandelt den Fall danach.

Was genau verliert eine Zahlung dabei?

Den Eintrag, nicht das Geld. Das Wallet des Zahlers hat eine Transaktion signiert, ein Block hat sie aufgenommen, und anschließend hat das Netzwerk einen Zweig der Historie gewählt, in dem dieser Block nicht vorkommt. Aus Sicht der Kette hat die Zahlung damit nie stattgefunden. Genau diese Verschiebung macht den Vorgang so schwer greifbar: Er sieht aus wie eine Umkehr, ist aber keine. Mit einer Rückbuchung nach Kartenregeln hat er nichts gemeinsam — dort korrigieren Institute einen Betrag, hier entscheidet ein Netzwerk über seine eigene Historie.

Meistens erledigt sich das innerhalb von ein, zwei Blöcken. Dieselbe Transaktion wird erneut aufgenommen, denn sie ist gültig und das Netzwerk hat keinen Grund, sie abzulehnen. Eng wird es nur in einem Fall: Die Zahlung fällt heraus, der Anbieter hatte sie zuvor als bestätigt gemeldet, und Sie haben darauf gehandelt.

Wie oft kommt das wirklich vor?

Flach und regelmäßig, tief und selten. Im März 2026 verwarf das Bitcoin-Netzwerk zwei Blöcke, nachdem zwei Mining-Pools fast gleichzeitig eine gültige Version desselben Blocks gefunden hatten; als der konkurrierende Zweig länger wurde, fielen die beiden Blöcke des anderen heraus.

Ein Fehler war das nicht. Solche Reorganisationen gehören zum Konsensverfahren, und die Pools des unterlegenen Zweigs verlieren dabei ihre Blockprämie.

Unter Proof of Stake ist die Lage ähnlich. Die Ethereum-Dokumentation führt kurzreichweitige Reorgs ausdrücklich als bekannte Erscheinung auf und beschreibt Endgültigkeit als den Punkt, an dem ein Block nicht mehr geändert werden kann.

Wie stark eine Zahlung diesem Risiko ausgesetzt ist, hängt deshalb vom Netzwerk ab. Einige der von Paymos unterstützten Ketten liefern ein eigenes Finalitätssignal, auf das die Bestätigungsregel direkt aufsetzen kann; andere sammeln Sicherheit über die Tiefe.

Wer trägt den Verlust, wenn ein bestätigter Block wegfällt?

Die Plattform, nicht Ihr Guthaben. Fällt der Block einer bereits bestätigten Zahlung aus der Kette, bleibt Ihre Gutschrift unverändert stehen, und der Fehlbetrag wird als Reorg-Verlust auf eigene Konten von Paymos gebucht. Diese Regel steht nicht in einer Broschüre, sondern als Kommentar direkt neben der Buchung im Ledger-Code: Der Händler wird nicht angefasst, seine Gutschrift hat überlebt, sie darf weder zurückgenommen werden noch sich verdoppeln.

Dahinter steht eine Frage der Zuständigkeit. Wie tief eine Zahlung geht, bevor sie bestätigt heißt, entscheidet der Anbieter — nach Netzwerk und Betrag, für Sie unsichtbar.

Läge der Fehlbetrag beim Händler, hinge seine Haftung an einer Risikoabwägung, die er weder getroffen hat noch einsehen kann. Die Frage lohnt sich in jedem Auswahlgespräch: Wessen Konto bewegt sich, wenn früh bestätigt wird und die Kette später anderer Meinung ist? Wer den Fall durchdacht hat, kann das Konto benennen.

Warum wird vor der Finalität des Protokolls bestätigt?

Weil der Checkout sonst unbrauchbar langsam wäre. Auf absolute Finalität zu warten, würde Zahlungen in manchen Netzwerken so lange hinziehen, dass der Zahler die Seite verlässt. Paymos bestätigt deshalb in einer Tiefe, die sich nach Netzwerk und Zahlbetrag richtet — bewusst vor dem Punkt, an dem das Protokoll selbst seine Historie für abgeschlossen erklärt.

Damit ist der seltene Fall eingekauft, dass sich der Block einer bestätigten Zahlung später als verworfen herausstellt.

Diese Abwägung trägt nur mit einer klaren Antwort darauf, wer den Fehlbetrag übernimmt. Die Geschwindigkeit kommt Ihnen und Ihrem Zahler zugute, das Risiko daraus bleibt bei der Plattform. Wie die Tiefe im Einzelnen zustande kommt und warum keine feste Blockzahl in Ihren Shop-Code gehört, steht in der gestaffelten Bestätigungsregel.

Warum wird der Transfer nicht einfach gelöscht?

Weil Löschen der kürzeste Weg zur doppelten Gutschrift ist. Naheliegend wäre es: Die Zahlung hat nicht stattgefunden, also weg mit dem Datensatz. Bei Paymos geschieht das Gegenteil: Der Transfer wird als verdrängt markiert und nie gelöscht.

Sichtbar wird der Nutzen, sobald die Transaktion zurückkommt. Wäre der ursprüngliche Datensatz gelöscht, träfe die erneute Aufnahme als brandneue Zahlung ein, und für einen einzigen Transfer stünde zweimal Geld auf dem Händlerkonto. Weil die Identität dieselbe bleibt, wird die Wiederaufnahme als Rückkehr derselben Zahlung erkannt und nicht als Eingang einer weiteren. Ein zweiter Datensatz für eine Zahlung ist deshalb ausdrücklich verboten — aus genau diesem Grund.

Wann gilt ein Block als endgültig verschwunden?

Erst wenn die Finalität des Protokolls es bestätigt. Ketten wechseln ihre Spitze im laufenden Betrieb: Ein Knoten sieht einen Block an der Spitze, eine Sekunde später einen anderen, ohne dass etwas falsch läuft und ohne dass eine Transaktion verloren geht. Würde jeder solche Wechsel als Reorganisation gelten, kämen laufend Meldungen über verdrängte Zahlungen herein, und binnen einer Woche würde sie niemand mehr lesen. Als verdrängt markiert wird ein Transfer deshalb ausschließlich dann, wenn die Finalität belegt, dass der Block nicht in der abgeschlossenen Kette steht.

Für den Ausnahmefall darunter gibt es keine Automatik. Reicht eine Reorganisation unter die bereits als final geltende Höhe, hält der Cursor dieses Netzwerks an, statt den Widerspruch selbsttätig aufzulösen. Ein Bruch der Protokollzusage ist kein Vorfall, den eine Warteschlange im Vorbeigehen bereinigt.

Was passiert, wenn die Transaktion zurückkommt?

Der Verlust wird aufgelöst, und zwar dort, wo er gebucht wurde. Ein wieder aufgenommener Transfer kehrt unter seiner ursprünglichen Identität zurück; der Reorg-Verlust der Plattform wird gegen dieselben Konten aufgelöst, die ihn getragen haben, und die Gebühr auf diese Zahlung wird erneut als Ertrag erfasst. Aus dem Fehlbetrag wird null.

Ihr Guthaben bewegt sich auch in diese Richtung nicht. Es hat sich beim Herausfallen nicht bewegt, also gibt es bei der Rückkehr nichts nachzuholen. Einmal gutgeschrieben und einmal gutgeschrieben geblieben, quer durch Verdrängung und Wiederaufnahme — das ist der ganze Zweck der Konstruktion.

Woran erkennen Sie den Fall in Ihrer Anbindung?

Auf Zahlungskanälen an einem Webhook. payment_channel.deposit.reorged ist eines der drei Einzahlungsereignisse, neben confirming und confirmed, und wird über dasselbe Abonnement zugestellt wie die beiden anderen.

Auf Rechnungen gibt es kein eigenes Ereignis dieses Namens; dort führt der Weg über den Rechnungsstatus, den Ihre Anbindung ohnehin verarbeitet.

Behandeln Sie das Ereignis als Betriebsmeldung, nicht als Buchungsvorgang. Ihr Guthaben hat sich nicht verändert, für die Buchhaltung ist also nichts zu tun. Was Ihnen die Meldung sagt: Eine bestimmte Bestellung wurde auf einen Beleg hin freigegeben, den es inzwischen nicht mehr gibt. Steht die Ware noch im Lager, ist das eine nützliche Minute; war es ein Download, ist es eine Notiz.

Wie proben Sie den Ernstfall in der Sandbox?

Sie simulieren ihn. Die Sandbox legt auf Anfrage eine Einzahlung an und treibt sie bis zur gewünschten Stufe; reorged ist eine der drei Stufen, neben confirming und confirmed.

Jeder Aufruf sendet zuerst confirming und danach das Ereignis der angeforderten Stufe, Ihr Webhook-Pfad ist also derselbe wie im Echtbetrieb — der vollständige Vertrag der Simulation führt die Stufen einzeln auf.

Eine Grenze hat die Probe. Jeder Aufruf legt eine neue Einzahlung an, und der Simulator nimmt nichts wieder auf. Die Rückkehr derselben Zahlung lässt sich damit nicht nachstellen, wohl aber der Teil, auf den es bei einem Integrationstest ankommt — hält Ihr Handler ein Ereignis aus, mit dem er nicht gerechnet hat? Die meisten Anbindungen sind gegen den glücklichen Fall geschrieben und begegnen dem ersten ungewöhnlichen Ereignis in der Produktion. Dieses hier können Sie an einem Dienstagnachmittag kennenlernen.

Was sollte Ihr Bestellsystem daraus machen?

Weniger, als Sie vermuten. Ihre Seite einer Krypto-Zahlung hat die Form, die sie braucht: offen, dann bestätigt, dann ausgeliefert. Eine Reorganisation fügt diesem Ablauf keinen vierten Zustand hinzu, denn Ihr Guthaben ändert sich nicht und abzustimmen gibt es nichts. Der Fehler wäre, mehr zu bauen, als der Fall hergibt.

Sinnvoll ist genau eine Ergänzung, und nur bei teurer, körperlich versandter Ware. Halten Sie ein kurzes Fenster zwischen Bestätigung und Übergabe an den Versand offen, damit eine Meldung überhaupt irgendwo landen kann. Bei Downloads, Zugängen und digitalen Guthaben ist die richtige technische Antwort, nichts zu tun. Ein eigener Reorg-Pfad in einem Checkout, der Dateien verkauft, ist Arbeit, die sich nie zurückzahlt — und der Verlust, gegen den er schützen soll, ist ohnehin nicht Ihrer.