Warum ein Krypto Zahlungsanbieter doppelt bucht

Guthaben und Rechnung bewegen sich zu verschiedenen Zeitpunkten. Deshalb liegen Händlerguthaben bei Paymos als eigene Konten in einem Hauptbuch mit doppelter Buchführung, statt als Zahl, die ein Dienst fortschreibt. Jede Bewegung wird gegen ihre Gegenseite gebucht, und was einmal gebucht ist, bleibt stehen.

Im Normalfall fällt das nicht auf. Auffällig wird es, sobald ein Zahler eine Rechnung mit drei Überweisungen begleicht, Geld eine Stunde nach Ablauf des Zahlungsfensters eintrifft oder eine Auszahlung erstellt, reserviert und wieder storniert wird, ohne dass eine Transaktion die Kette erreicht. Jedes Mal bewegt sich Geld, während die Bestellung dahinter stehen bleibt. Eine fortgeschriebene Zahl hat für diese Differenz keine Spalte.

Sechs solcher Ereignisse stehen am Ende dieses Textes nebeneinander: was das Guthaben tut und was die Rechnung im selben Moment tut.

Was kann ein Hauptbuch, was eine fortgeschriebene Zahl nicht kann?

Es hält die Bewegung fest, nicht den Stand.

Ein einfaches System speichert einen Betrag und überschreibt ihn. Ein doppeltes speichert die Veränderung: welches Konto abgibt, welches empfängt, in einer Transaktion, die aufgehen muss, bevor sie festgeschrieben wird. Der Saldo wird damit zu einer Größe, die man aus der Historie herleitet. Zahlungsteams weit außerhalb von Krypto bauen auf derselben Eigenschaft — das Engineering-Journal von Modern Treasury beschreibt ein Hauptbuch als unveränderliches, nur anhängendes Protokoll, aus dem sich jeder frühere Zustand wiederherstellen lässt.

Bei Paymos liegt jedes Händlerguthaben als eigenes Konto je Asset in diesem Hauptbuch. Die Buchungen darauf sind unveränderlich, tragen mindestens zwei Seiten und gleichen sich je Token aus; eine Buchung, die nicht aufgeht, wird abgewiesen, statt gespeichert und später korrigiert zu werden.

Warum steht auf einer Rechnung mehr als eine Gutschrift?

Drei Überweisungen auf eine Rechnung ergeben drei Gutschriften und drei Gebührenbuchungen. Die Gebühr fällt auf jeden Transfer einzeln, bemessen an dem Betrag, der gerade eingegangen ist, und sie fällt in dem Moment, in dem dieser Transfer bestätigt ist. Der Satz dafür stand fest, als die Rechnung erstellt wurde, und gilt weiter, was auch immer die Preisliste danach getan hat.

Ein Eingang ist damit schon drei Zahlen: was kam, was die Gebühr nahm, was blieb. Gerundet wird nur in eine Richtung. Die Gebühr wird auf die kleinste Einheit des Tokens abgeschnitten, der Rest gehört dem Händler, und der tatsächliche Satz liegt deshalb bei jeder Größe auf oder unter dem veröffentlichten. Für einen Betrag, bei dem die Gebühr in dieser Genauigkeit wegfällt, wird gar nichts berechnet.

Wer sein eigenes Konto liest, stolpert genau hier. Gutschriften stehen nicht eins zu eins neben Rechnungen. Sie stehen neben Transfers, und wer die Gebühr trägt, ist noch einmal eine eigene Einstellung.

Was passiert, wenn der Betrag nicht stimmt?

Bei einer Überzahlung geht der Überschuss vollständig aufs Guthaben. Zurückgehalten wird nichts, und von allein fließt auch nichts zurück; die Rechnung schließt als bezahlt, gemeldet wird aber invoice.paid_over statt invoice.paid. Ein Bestellsystem hält die beiden Fälle damit auseinander, ohne Beträge nachzurechnen.

Nach unten entscheidet die Toleranz des Projekts. Sie ist ein Regler von 0 % bis 2 % in Schritten von 0,1 %, und ein neues Projekt startet bei 0,1 %. Was innerhalb dieser Spanne fehlt, schließt die Rechnung trotzdem, und der Händler behält den eingegangenen Betrag, weil zum Füllen der Lücke nichts erfunden wird. Auf 0 gezogen, verlangt die Rechnung wieder den exakten Betrag.

Darunter trennt sich der Fall nach Rechnungsart. Eine Rechnung mit einer einzigen Zahlung gilt als unterbezahlt. Eine Rechnung mit mehreren Zahlungen bleibt offen, während der Zahler den Rest schickt, und genau diese Lage kann eine einzelne Zahl nicht ausdrücken: echtes Geld gutgeschrieben, Bestellung unfertig.

Wohin geht Geld, das keine Rechnung bezahlt?

Auf das Guthaben des Händlers, abzüglich der üblichen Abwicklungsgebühr, mit dem Grund daneben.

Transfers erreichen Rechnungsadressen zu ungünstigen Zeitpunkten. Eine Stunde nach Schließen des Zahlungsfensters. Gegen eine Rechnung, die am selben Morgen storniert wurde. In USDC, obwohl die Rechnung in USDT ausgestellt war. Oder auf eine Adresse, an der gerade gar keine Rechnung hängt. Gutgeschrieben wird in jedem dieser Fälle.

Stehen bleibt die Rechnung. Sie wird nicht als bezahlt markiert, und ein Webhook läuft nicht los, weil eine Gutschrift dieser Art kein eigenes Ereignis hat. Eine Anbindung, die nur am Ereignisstrom hängt, erfährt davon nie.

Sichtbar wird der Vorgang auf der Guthabenseite, in einem eigenen Block mit Grund, Betrag, Gebühr und der Rechnung, sofern es eine gab, dazu Absenderadresse und Transaktions-Hash; fehlen sie, steht dort „Absender unbekannt“. Dieselbe Meldung geht per E-Mail, über die Glocke im Dashboard und bei verknüpftem Kontakt über Telegram. Ob davon etwas zurückgeht, ist eine kaufmännische Entscheidung des Händlers, denn eine Erstattung ist eine gewöhnliche Überweisung, die jemand auslösen muss.

Warum ist eine Auszahlung zuerst reserviert?

Zwischen dem Auftrag und der Transaktion ist das Geld weder verfügbar noch weg.

Eine Auszahlung hebt den Betrag samt Netzwerkgebühr für die gewählte Strecke aus dem verfügbaren Guthaben heraus und legt beides in die Reservierung. Deshalb führt die Guthabenseite zwei Zahlen getrennt, und nur das verfügbare Guthaben finanziert die nächste Auszahlung. Einbehalten wird dabei nichts: Es gibt keine Sicherheitsreserve und keinen rollierenden Einbehalt, und was dort liegt, sind die eigenen Auszahlungen des Händlers auf dem Weg nach draußen.

Eine Auszahlung kennt sieben Zustände, drei davon endgültig, und is_final reist in jedem Payload mit, damit niemand diese Liste von Hand pflegen muss. Einen der nicht endgültigen Zustände erkennt man besser auf den ersten Blick: Eine Auszahlung, die das Netzwerk noch nicht bestätigt hat, steht als „Unbestätigt“ da, und ihr Betrag liegt weiter in der Reservierung.

Endet sie, ohne dass die Transaktion rausgeht, kommt die gesamte Reservierung zurück, die Netzwerkgebühr eingeschlossen. Für eine Auszahlung, die nicht hinausgegangen ist, wird nichts berechnet. Stornieren geht nur ganz am Anfang, bevor die Ausführung beginnt; danach wird der Auftrag abgewiesen.

Wessen Konto trägt einen Verlust, den die Kette verursacht?

Der Fehlbetrag geht auf Konten der Plattform. Wie tief eine Zahlung bestätigt sein muss, hängt von Netzwerk und Betrag ab; das ist eine bewusste Abwägung gegen das Warten auf absolute Finalität, und sie lässt ein schmales Fenster offen, in dem ein bereits gutgeschriebener Transfer noch aus der Kette fallen kann. Passiert das, bleibt die Gutschrift des Händlers unverändert stehen.

Für die Buchführung steckt darin ein enger, aber harter Punkt. Wer beide Seiten jeder Buchung hält, kann das Konto benennen, das den Treffer genommen hat. Wer je Händler nur eine Zahl hält, hat genau eine Stelle, an der er ihn nehmen kann, und dort steht der Händler. Was ein Reorg mit einer ausgelieferten Bestellung macht, führt der Artikel dazu aus; warum die Wartezeit je Netzwerk verschieden ausfällt, steht im Leitfaden zu Bestätigungen.

Reichen Webhooks als Grundlage für die Bücher?

Allein nicht, denn ein Ereignisstrom beschreibt Übergänge, und ein Übergang ist noch keine Buchung.

Sechzehn Ereignistypen decken Rechnungen, Auszahlungen und Einzahlungen auf Zahlungskanälen ab, und jedes meldet, dass eine Ressource ihren Zustand gewechselt hat. Als schnelle Nachricht darüber, dass etwas passiert ist, taugt der Strom zuverlässig. Wie hartnäckig er dabei zustellt, steht im Zustellvertrag.

Vollständigkeit ist eine andere Frage. Eine Gutschrift, die keine Rechnung bezahlt, erzeugt überhaupt kein Ereignis, und eine gescheiterte Auszahlung löst zwar den Webhook aus, aber weder E-Mail noch Hinweis im Dashboard. Wer ein Guthaben aus Webhooks aufaddiert, verliert beide Fälle unbemerkt.

Der Einzahlungsstrom der Zahlungskanäle ist anders gebaut. Er veröffentlicht in Reihenfolge hinter einem Cursor, der immer weiterrückt, sodass ein Leser mit gespeicherter Position keine abgerechnete Zahlung überspringen kann; selbst eine leere Seite gibt einen Cursor zurück statt eines Endes. Lange hält diese Position allerdings nicht: Ein Cursor läuft 24 Stunden nach der Ausgabe ab, und wer länger nicht abruft, bekommt pagination_cursor_invalid und beginnt über confirmed_from von vorn. Nehmen Sie ein Ereignis als Aufforderung, nachzulesen, und lassen Sie Strom und Guthaben die Quellen sein, denen Ihre Bücher glauben.

Was sollte Ihr eigenes System speichern?

Transfers, mit der Rechnung als Merkmal statt als Schlüssel.

Diese eine Änderung fängt fast alles oben Beschriebene auf. Drei Gutschriften zu einer Rechnung sind dann keine Anomalie mehr, und eine Gutschrift ohne Rechnung hat einen Platz, statt in einem Support-Thread zu liegen. Eine aufgelöste Reservierung liest sich als Buchung, die eine andere aufhebt, und nicht als Subtraktion, die jemand rekonstruieren muss.

Zwei kleinere Gewohnheiten kommen dazu. Verzweigen Sie über is_final, wo der Zustand einer Auszahlung zählt. Und schlüsseln Sie Guthaben nach Asset, weil sie hier so gehalten werden: Ein USDT-Guthaben deckt jedes Netzwerk ab, über das USDT eingegangen ist, und über welches Netzwerk es wieder hinausgeht, entscheidet sich erst bei der Auszahlung.

Der Test dafür kostet zehn Minuten. Suchen Sie die eine Zahlung der letzten Woche, zu der jemand im Support geschrieben hat, und sehen Sie nach, ob Ihr eigener Datensatz sie ohne Kommentarfeld erklärt. Tut er es nicht, liegt es fast immer am Schlüssel und fast nie am Anbieter.