Was passiert, wenn ein Kunde den falschen Betrag zahlt?

49,60 USDT treffen auf eine Rechnung über 50. Vertippt hat sich niemand, der Transfer ist bestätigt, und eine Rückbuchung gibt es hier nicht. Was jetzt geschieht, stand fest, bevor der Zahler die Seite geöffnet hat: Ein zu hoher Betrag geht vollständig auf Ihr Guthaben und schließt die Rechnung, ein zu niedriger hat zwei mögliche Enden, und welches davon eintritt, entscheidet eine Einstellung am Projekt.

Selten ist beides nicht. Börsen ziehen ihre Gebühr vom Auszahlungsbetrag ab, umgerechnete Beträge tragen Nachkommastellen, und wer eine Bestellung auffüllt, rundet auf etwas Glattes.

Wer offene Posten ausgleicht, kennt die Zahlungsdifferenz und die Grenze, bis zu der sie ausgebucht wird. Dieselbe Idee steckt in der Toleranz für Unterzahlung. Ein zweites Stück kommt hier allerdings dazu, und das kennt keine Buchhaltung: Jeder Ausgang trägt seinen eigenen Namen im Ereignisstrom, und einer dieser Namen wird regelmäßig übersehen.

Das hier ist die Betragsseite einer Rechnung. Wie überhaupt eine entsteht, steht im Leitfaden zur Rechnungsstellung; der vollständige Zustandsautomat mit jedem Übergang steht im Zahlungsablauf.

Was passiert mit dem Betrag über der Rechnungssumme?

Einbehalten wird nichts. Der gesamte eingegangene Betrag geht auf Ihr Guthaben, der Überschuss mit, und die Rechnung schließt als bezahlt.

Die Abwicklungsgebühr folgt derselben Regel wie bei jeder anderen Zahlung: Berechnet wird sie auf das, was angekommen ist, nicht auf das, was Sie gefordert haben. Der Überschuss trägt sie also mit.

Welcher Satz das ist, steht in der Preisliste.

Unterscheiden lassen sich die beiden Fälle erst am Ereignis. Eine Zahlung, die auf der Zahl landet, meldet invoice.paid. Eine, die darüber hinausgeht, meldet invoice.paid_over — und dieser Name ist der ganze Unterschied, den Ihr System in die Hand bekommt.

Den Überschuss zurückzuschicken ist eine Überweisung, die Sie selbst auslösen. Von allein geht nichts hinaus, und die Entscheidung ist kaufmännisch statt technisch: Ein Rundungsrest ist keine Transaktion wert, während der Kunde, der eine Null zu viel getippt hat, sich ohnehin meldet, bevor Sie es tun.

Warum bleibt die Bestellung offen, obwohl die Rechnung bezahlt ist?

Weil der Handler nur eine einzige Zeichenkette kennt.

Angekommen ist das Ereignis. Abonniert wird je Kategorie, einzelne Namen innerhalb einer Kategorie lassen sich nicht auswählen, und ein Endpunkt auf der Kategorie der Rechnungen bekommt deshalb alle acht — invoice.paid_over eingeschlossen.

Der Handler hält event_type gegen invoice.paid, findet etwas anderes und legt es unter „betrifft mich nicht“ ab.

Auffällig ist daran nichts. Im Dashboard steht eine bezahlte Rechnung, auf dem Guthaben liegt die Gutschrift, die Bestellung liegt unbearbeitet, und nirgends hat etwas einen Fehler geworfen. Bemerkt wird es Tage später, wenn ein Kunde nach seiner Ware fragt — und es trifft ausgerechnet die Kunden, die zu viel bezahlt haben.

Verzweigen Sie auf eine Menge statt auf Gleichheit:

// Beide schließen die Rechnung. Nur die zweite trägt einen Überschuss.
if (in_array($event['event_type'], ['invoice.paid', 'invoice.paid_over'], true)) {
    $this->fulfil($event['data']['invoice_id']);
}

Halten Sie die beiden Zahlen danach in Ihrem eigenen Datensatz auseinander. Geforderter und eingegangener Betrag sind zwei Felder, und der Überschuss ist ihre Differenz — nichts, was man später aus einem Ereignisnamen ableiten sollte.

Wie viel zu wenig gilt noch als bezahlt?

Jedes Projekt trägt seine eigene Toleranz für Unterzahlung, und gefragt wird niemand, wenn eine Zahlung darunter landet. Die Obergrenze liegt bei 2 %, verstellt wird der Regler in Zehntelprozent, und ein heute angelegtes Projekt steht schon auf der ersten Stufe: bei 0,1 %.

Steht er auf null, gilt die strenge Regel: Die Zahlung muss den Rechnungsbetrag erreichen oder überschreiten.

Je Rechnung überschreiben lässt sich das nicht — die Anfrage zum Anlegen einer Rechnung kennt kein Feld dafür, also gilt für jede Rechnung, was ihr Projekt sagt.

Innerhalb der Toleranz schließt die Rechnung und meldet invoice.paid, wie jede andere bezahlte auch. Abgerechnet wird der Betrag, der angekommen ist; die Lücke füllt niemand auf.

Ein Detail entscheidet darüber, was sich hinterher noch reparieren lässt. Bewertet wird eine Rechnung nach der Toleranz, die ihr Projekt in dem Moment trug, in dem sie entstand, und diese Kopie bleibt ihr Leben lang an ihr hängen. Wer den Regler verschiebt, ändert die Rechnungen, die er als Nächstes ausstellt, und keine einzige von denen, die schon auf einer Checkout-Seite offen stehen.

Warum kommt überhaupt zu wenig an?

Die Netzwerkgebühr ist der übliche Verdächtige und der falsche. Gas auf Ethereum wird in Ether bezahlt — „Gasgebühren müssen in Ethereums nativer Währung, Ether (ETH), bezahlt werden“ — und das sendende Wallet nimmt es aus seinem eigenen Bestand.

Der Token-Betrag reist unangetastet. Wer 50 USDT aus einem Wallet schickt, das ihm gehört, schickt 50 USDT.

Der Fehlbetrag entsteht fast immer dort, wo aus einem Börsenkonto gezahlt wird. Binance.US schreibt es für die eigenen Auszahlungen hin: Börsengebühr und Netzwerkgebühr „are deducted from your withdrawal amount before it reaches your destination wallet“.

Versteckt ist das nicht einmal: Kraken hält in der eigenen Hilfe fest, dass „die endgültigen Gebühren zum Zeitpunkt der Bestätigung genau angezeigt“ werden.

Gesehen hat Ihr Kunde die Zahl also. Getippt hat er trotzdem den Rechnungsbetrag, abgegangen ist er abzüglich Gebühr, und Ihre Rechnung ist um genau diese Gebühr zu kurz.

Die Toleranz ist ein Prozentsatz, die Ursache ist keiner. Ein fester Abzug reißt bei einer kleinen Rechnung ein Loch und verschwindet bei einer großen, also deckt kein einzelner Prozentsatz beide ab. Bei 0,1 % darf eine Rechnung über 50 USDT um fünf Hundertstel zu kurz kommen — ein Rundungsrest, und nichts, was einer Börsengebühr nahekäme. Die 49,60 vom Anfang liegen 0,8 % daneben: innerhalb einer Toleranz von 2 %, weit außerhalb von 0,1 %. Stellen Sie die Toleranz auf den Rundungsrest ein und behandeln Sie den Börsenfall als das, was er ist — einen Hinweis an den Zahler, auf der Checkout-Seite oder in der Bestellbestätigung.

Zwei Enden für eine Teilzahlung

Welches davon eintritt, entscheidet allow_multiple_payments. Der Wert steht beim Anlegen der Rechnung fest, und die API setzt ihn auf true, solange Sie nichts anderes sagen.

Sind mehrere Zahlungen erlaubt, schließt eine zu kleine gar nichts. Die Rechnung geht auf underpaid_waiting, bleibt für den Rest offen, und der Checkout rechnet für den Zahler: QR-Code und jeder Wallet-Link bauen sich um den noch offenen Betrag herum neu auf, und diesen Betrag liefert der Server, statt ihn im Browser abzuziehen.

In der Telegram-Karte wechselt die Schaltfläche zum Kopieren des Betrags ihre Beschriftung und kopiert den Fehlbetrag statt der ursprünglichen Summe.

Sind sie abgeschaltet, ist nach einer zu kleinen Zahlung Schluss. Die Rechnung schließt underpaid und meldet invoice.underpaid.

Am Ende entscheidet die Uhr. Läuft das Zahlungsfenster ab, während die Rechnung noch unter der Linie steht, endet sie unterbezahlt. Ein bereits erkannter Transfer, der gerade bestätigt wird, hält das allerdings auf: Über Geld hinweg, das unterwegs ist, läuft keine Rechnung ab.

Bringt eine unterbezahlte Rechnung trotzdem Geld?

Sie tut es, und auf einem Auszug liest sich das eigenartig. Jeder Transfer geht auf das Guthaben, sobald er bestätigt ist, und die Gebühr fällt auf den Betrag genau dieses Transfers an. Eine Teilzahlung ist damit Geld bei Ihnen, während die Rechnung noch offen steht.

Eine Rechnung, die als underpaid endet, lässt Sie mit echtem Geld gegen eine Bestellung zurück, die nie geschlossen hat.

Der Ereignisstrom ist dabei leiser als das Geld. invoice.underpaid_waiting läuft einmal los, beim Eintritt in diesen Zustand. Ein zweiter zu kleiner Transfer, der die Rechnung immer noch nicht deckt, bewegt Ihr Guthaben und erzeugt kein neues Ereignis, weil sich der Status nicht geändert hat und ein Webhook am Statuswechsel hängt.

Eine Supportansicht, die auf dem Ereignisstrom steht, zeigt dann eine Ankunft, wo zwei waren. Den laufenden Stand hat die Rechnung.

Übrig bleibt die Entscheidung, die Ihnen niemand abnimmt: trotzdem liefern, teilweise liefern, die Differenz einfordern oder das Geld zurückschicken. Zurückschicken ist eine gewöhnliche Überweisung aus Ihrem Guthaben, genau wie im Fall der Überzahlung.

Wann ist Geld auf dem Guthaben gar keine Zahlung?

Eine Rechnung kann zu kurz kommen. Es kann aber auch Geld ankommen, das nie eine Zahlung auf eine Rechnung war, und auf der Guthabenseite stehen die beiden nebeneinander und sehen sich ähnlich. Sie verhalten sich vollkommen gegensätzlich.

Zu jeder Gutschrift dieser Art ist der Grund vermerkt, und die alltäglichen sind schnell aufgezählt: eine Einzahlung auf eine Adresse, hinter der gerade keine Rechnung steht; ein Zahler, der USDC schickt, wo die Rechnung in USDT ausgestellt ist; ein Transfer gegen eine längst geschlossene Rechnung; und einer, der erst nach dem Zahlungsfenster eintrifft. Das Geld geht in allen Fällen abzüglich der üblichen Abwicklungsgebühr auf Ihr Guthaben, und die Rechnung rührt sich nicht. Sie wird nicht als bezahlt markiert, nicht als unterbezahlt, sie ändert sich überhaupt nicht.

Ein Ereignis gibt es dafür ebenfalls nicht. Nicht ein anderes — gar keines: Eine Gutschrift dieser Art hat nichts im Webhook-Strom, was sie tragen könnte.

Eine Unterzahlung hat einen Status, den Ihre Anbindung lesen kann, und ein Ereignis, das sie abonnieren kann. Das hier hat eine Zeile auf der Guthabenseite, eine E-Mail, einen Hinweis an der Glocke und eine Telegram-Nachricht, wo der Kontakt verknüpft ist — und nichts, worauf Ihr Server hören könnte.

Der Unterschied entscheidet, wo Sie suchen, wenn die Bücher auseinanderlaufen. Eine zu kurze Rechnung ist eine Bestellung, der jemand nachgehen muss. Eine Gutschrift ohne Rechnung ist Geld, auf das keine Bestellung wartet, und davon erfahren Sie nur über das Guthaben. Wie beides in einer Buchhaltung landet, steht beim Abgleich.

Wie probt man das, bevor es ein Kunde tut?

In der Sandbox, mit dem Simulator für Zahlungen, der dieselben Lebenszyklus-Webhooks sendet wie eine echte Zahlung.

Ein signierter Aufruf führt eine Sandbox-Rechnung zu einem Ergebnis:

POST /v1/sandbox/invoices/inv_7Qk2.../simulate-payment
Content-Type: application/json

{ "stage": "overpaid" }

overpaid zahlt 10 % über dem erwarteten Betrag, underpay zahlt 40 % davon, und jede Zahl leitet der Server aus der Rechnung ab — der Client schickt keine.

Über mehrere Aufrufe addieren sich die Stufen: Zweimal underpay bringt 80 % auf eine Rechnung, und zu wenig ist es immer noch.

Drei Durchläufe lohnen sich vor dem ersten echten:

1. overpaid gegen eine Rechnung, die Ihr Auslieferungsweg beobachtet. Die Bestellung muss rausgehen, und Ihr eigener Datensatz muss einen eingegangenen Betrag über dem geforderten zeigen.
2. underpay gegen eine Rechnung, die mehrere Zahlungen erlaubt. Die Bestellung darf nicht rausgehen, und was Ihr Support ansieht, muss den Fehlbetrag zeigen statt der ursprünglichen Summe.
3. underpay gegen eine Rechnung, die mit allow_multiple_payments auf false angelegt wurde. Die Bestellung darf nicht rausgehen, und die Rechnung muss schließen.

Den Zweig mit der Toleranz probt man so nicht: Für eine Zahlung, die nur einen Bruchteil zu kurz kommt, gibt es keine Stufe. Diese eine Einstellung prüfen Sie, indem Sie sie am Projekt nachlesen. Für alles andere genügt eine signierte Anfrage.