Falsches Netzwerk, falsches Token: Wo ist das Geld des Kunden?

Hat ein Kunde bei Paymos im falschen Netzwerk oder mit dem falschen Token bezahlt, ist das Geld nicht verloren. Der Fehler endet auf einem von drei Wegen. Kommt dasselbe Token aus einem anderen Netzwerk, das die Rechnung annimmt, bezahlt es die Rechnung eins zu eins, und niemand muss eingreifen. Ein anderes Token, das Paymos in diesem Netzwerk annimmt, geht von selbst auf Ihr Guthaben, ohne Supportanfrage und ohne Gebühr fürs Zurückholen; abgezogen wird nur die übliche Abwicklungsgebühr, während die Rechnung ihre Frist absitzt und abläuft. Von selbst kommt nur zweierlei nicht an: ein Transfer in einem Token oder Netzwerk, das die Rechnung nicht annimmt, und ein Betrag unter dem Mindestbetrag des Netzwerks.

Welchen der drei Fälle Sie vor sich haben, bestimmt, was Sie dem Kunden antworten und was Ihr Bestellsystem als Nächstes tut. Was Paymos macht, wenn der Betrag nicht stimmt, steht im Beitrag zu Über- und Unterzahlung. Hier geht es um Geld, das die Adresse einer Rechnung erreicht und die Rechnung trotzdem nicht bezahlt: was Paymos damit tut, wie Sie davon erfahren und was bei Ihrem Server ankommt.

Was macht Paymos, wenn ein Kunde aus einem anderen Netzwerk zahlt?

Paymos rechnet die Zahlung eins zu eins auf die Rechnung an, und zwar in fast jedem Netzwerk, in dem es dieses Token annimmt.

Dass so etwas überhaupt passiert, liegt an der Adresse. Eine Adresse, die mit 0x beginnt, ist in jedem Netzwerk auf Basis der Ethereum Virtual Machine (EVM) dieselbe Zeichenkette. Das Hilfe-Center von MetaMask sagt es ohne Umschweife: Dieselbe geheime Wiederherstellungsphrase erzeugt in allen EVM-kompatiblen Netzwerken dieselbe Adresse. Zeigt der Checkout eine Adresse auf Polygon und wählt der Kunde im Auszahlungsformular seiner Börse BNB Smart Chain, landet der Transfer an derselben Adresse, nur in einem anderen Netzwerk.

Ein solcher Transfer wird auf die Rechnung verbucht, als hätte der Kunde das richtige Netzwerk gewählt. Die Rechnung schließt, Ihr Endpunkt bekommt dieselben Ereignisse wie sonst, und die Bestellung geht raus wie immer. Weder Sie noch der Kunde müssen etwas tun. Worin sich die Netzwerke unterscheiden, zeigt ein eigener Vergleich.

Nimmt Paymos das Token in diesem Netzwerk an und zählt die Zahlung trotzdem nicht für die Rechnung, geht das Geld außerhalb der Rechnung auf Ihr Guthaben, sofern es den Mindestbetrag des Netzwerks erreicht. Die Rechnung läuft dann zu ihrer Frist ab. Deckt dieser Transfer allein oder zusammen mit früheren Zahlungen den Rechnungsbetrag, bekommt Ihr Endpunkt danach invoice.paid_late. Der Status der Rechnung ändert sich nicht, paid_late_at hält fest, wann der Betrag erreicht war, und ob die Bestellung rausgeht, entscheiden Sie.

Tron, TON und Solana haben je ein eigenes Adressformat, und ein Wallet in einem anderen Netzwerk lehnt eine solche Adresse als Ziel ab. Die Verwechslungen beim Netzwerk, die bis zu einer Rechnung durchkommen, passieren deshalb zwischen EVM-Netzwerken.

Mit dem falschen Token bezahlt: Was passiert mit dem Geld?

Es geht auf Ihr Guthaben, sofern Paymos dieses Token in dem Netzwerk annimmt, über das es kam. Eine Supportanfrage brauchen Sie dafür nicht, und eine Gebühr fürs Zurückholen gibt es nicht. Abgezogen wird nur die übliche Abwicklungsgebühr, dieselbe wie bei jeder abgewickelten Zahlung; den Satz finden Sie in der Preisliste.

Schickt ein Kunde USDC auf eine Rechnung in USDT, kommt USDC an: der gesendete Betrag abzüglich dieser Gebühr. Umgerechnet wird nichts, und kein Kurs rückt den Betrag auf die Rechnungssumme zurecht. Bezahlt ist die Rechnung damit nicht, und auch später zählt ein anderes Token nie zum Rechnungsbetrag, also folgt kein invoice.paid_late. Die Gutschrift ist als Zahlung mit falschem Token gekennzeichnet, und die Bestellung dahinter wartet, bis Sie entscheiden.

Es zählt immer das Paar: dieses Token in diesem Netzwerk. In jedem Netzwerk ist ein Token ein eigener Smart Contract, und jeder Emittent führt seine eigene Liste von Netzwerken, Circle für USDC, Tether für USDT. Welche Paare Paymos annimmt, steht auf /tokens/usdt und /tokens/usdc. Warum ein Unternehmen den einen Dollar-Stablecoin dem anderen vorziehen könnte, klärt ein Vergleich für sich.

Warum wurde die Bestellung storniert, obwohl das Geld auf dem Guthaben liegt?

Weil die Rechnung abgelaufen ist und Ihr Server auf den Ablauf reagiert hat. Das ist die einzige Stelle, die Sie in Ihrer Anbindung anfassen müssen.

Eine Gutschrift außerhalb einer Rechnung hat keinen eigenen Webhook: Keines der neun Rechnungsereignisse im Ereigniskatalog beschreibt eine Gutschrift. Die Rechnung, an der das Geld vorbeiging, läuft trotzdem ab, und Paymos schickt dafür invoice.expired. Die Dokumentation beschreibt das Ereignis als „Die Rechnung ist ohne qualifizierende Zahlung abgelaufen“. Das stimmt, nur sagt es kein Wort über das Geld, das schon auf Ihrem Guthaben liegt.

Sehen Sie sich deshalb heute den Handler für abgelaufene Rechnungen an. Ware zurück ins Lager buchen, einen Platz freigeben, die Bestellung stornieren, dem Kunden mailen, seine Zahlung sei nie gekommen: Jeder dieser Schritte läuft jetzt gegen eine Bestellung, die jemand bezahlt hat.

// invoice.expired heißt: Die Rechnung wurde nicht bezahlt.
// Es heißt nicht, dass niemand Geld an ihre Adresse geschickt hat.
if ($event['event_type'] === 'invoice.expired') {
    $this->holdForReview($event['data']['invoice_id']); // nicht stornieren, nichts zurück ins Lager
}

Eine abgelaufene Bestellung festzuhalten, bis ein Mensch draufgesehen hat, ist auch bei ganz gewöhnlich abgelaufenen Rechnungen der sicherere Standard. Es ist das Argument aus der Idempotenz, nur von der anderen Seite.

Zu einer festgehaltenen Bestellung kann später ein zweites Signal kommen. Deckt Geld im Token der Rechnung, verspätet oder aus einem anderen Netzwerk, den Betrag doch noch, kommt für dieselbe Rechnung invoice.paid_late. Der Status bleibt expired, das Ereignis ändert von sich aus also nichts. Es ist eine Notiz zur festgehaltenen Bestellung und der Anlass, sie noch einmal anzusehen. Ein anderes Token löst es nie aus.

Wie erfahren Sie von der Gutschrift?

Die Nachricht geht zusammen mit der Gutschrift raus: per E-Mail, an der Glocke im Dashboard und über Telegram, wenn der Kontakt verknüpft ist, auf demselben Weg wie eine Nachricht zu einer Auszahlung. Sie nennt den Nettobetrag, der auf Ihrem Guthaben angekommen ist, die Gebühr in einer eigenen Zeile, Token, Netzwerk und Grund, dazu einen Link ins Dashboard.

Auf der Seite Guthaben stehen diese Gutschriften im Tab Buchungen, in einer Tabelle mit Ihren Auszahlungen; der Filter nach Typ trennt beides. Jede Zeile zeigt, ob das Geld zu einer Rechnung oder ohne Rechnung kam und um welchen Fall es geht: falsches Token, falsches Netzwerk, Zahlung nach Fristablauf, eine schon geschlossene Rechnung oder eine Adresse ohne Rechnung. Der Betrag mit Pluszeichen ist das, was auf Ihrem Guthaben angekommen ist. Ein Klick klappt die Zeile auf: Eingegangen, Gebühr, Gutgeschrieben, die Rechnung, zu der die Adresse gehörte, oder Keine Rechnung, dann Absender, Transaktion und eine kurze Erklärung. Wurde der Transfer hinter der Gutschrift nie beobachtet, steht dort Absender unbekannt und Transaktion unbekannt, und was später auftaucht, landet in derselben Zeile.

Für die Gutschriften selbst gibt es weder Webhook noch API-Aufruf. Ihre Anbindung erfährt von ihnen nur über das Dashboard und die E-Mail, und das einzige Ereignis, das dieses Geld auslösen kann, ist das oben beschriebene invoice.paid_late.

Was tun mit der Bestellung und dem Geld?

Das entscheiden Sie, und alles, was Sie dafür brauchen, liegt schon vor Ihnen. Die Rechnung bleibt expired, egal wie Sie sich entscheiden, auch nach einem invoice.paid_late. Zur Wahl steht, was aus der Bestellung wird.

Liefern heißt, die Bestellung in Ihrem eigenen System von Hand abzuschließen. Als Zahlungsnachweis dient dabei die Zeile der Gutschrift, nicht der Status der Rechnung. Übertragen Sie deren Angaben in die Bestellung, dorthin, wo Ihr Team beim nächsten Abgleich nachsieht.

Erstatten heißt, selbst eine Überweisung aus Ihrem Guthaben zu schicken, mit Betrag, Token und Netzwerk Ihrer Wahl. Von allein geht nichts zurück, und dem Zahler verspricht das Produkt nirgends eine Erstattung. Was Sie brauchen, steht in der Zeile: der angekommene Betrag, die abgezogene Gebühr und, sofern bekannt, Absenderadresse und Transaktions-Hash.

Zwei Dinge sollten Sie klären, bevor Sie dem Kunden etwas zusagen. Auf dem Guthaben liegt, was angekommen ist, abzüglich der Gebühr; wer den vollen gesendeten Betrag zurückschickt, legt die Differenz aus eigener Tasche drauf. Und wo der Absender unbekannt ist, gibt es keine Adresse, an die etwas zurückgehen könnte.

Wann kommt das Geld nicht von selbst an?

In drei Fällen, und in keinem davon wird automatisch etwas gutgeschrieben.

Ein Token, das Paymos in diesem Netzwerk nicht annimmt, etwa USDC auf Tron oder TON oder USDT auf Base. Ein solcher Transfer wird nicht gutgeschrieben. Welche Paare angenommen werden, steht auf /tokens/usdt, /tokens/usdc und /chains.

Ein Netzwerk, das die Rechnung nicht annimmt. Bei einer Adresse mit 0x am Anfang steckt hier der Fehler, der wirklich vorkommt. Dieselbe Adresse gibt es in jedem EVM-Netzwerk, und ERC-7828, ein vorgeschlagener Standard aus Ethereums eigenem Verfahren, rechnet mit Hunderten und irgendwann Tausenden von L2-Netzwerken, die das Adressformat des Ethereum-Mainnets teilen. Das sind weit mehr Netzwerke, als Paymos annimmt. Eine Zahlung, die in einem davon abgeschickt wurde, bleibt an dieser Adresse in diesem Netzwerk.

Ein Betrag unter dem Mindestbetrag des Netzwerks. Der Paymos-Checkout lässt Token und Netzwerk gar nicht erst auswählen, wenn ihr Minimum über dem Rechnungsbetrag liegt. Wer den vollen Betrag im angezeigten Netzwerk zahlt, stößt also nie darauf. Eine kleine Teilzahlung kann es, ebenso ein Umweg über ein Netzwerk mit höherem Minimum. Ein Betrag unter dem Minimum wird nicht gutgeschrieben, und dann ist der Support am Zug.

Was sollte ein Kunde tun, der schon gesendet hat?

Dem Händler schreiben und vier Angaben mitschicken: Bestellnummer, Token, Netzwerk und Transaktions-Hash. Einen bestätigten Transfer macht auf Kundenseite nichts mehr rückgängig. Eine Blockchain-Zahlung kennt keine Rückbuchung, um die man bitten könnte, und das Wallet, aus dem das Geld kam, holt es nicht zurück.

Der Händler ist die richtige Adresse, weil jeder der drei Ausgänge bei ihm endet. Hat die Zahlung die Rechnung geschlossen, geht die Bestellung ohnehin raus. Wurde sie außerhalb der Rechnung gutgeschrieben, liegt das Geld auf seinem Guthaben, und er entscheidet. Kam sie nicht von selbst an, fragt der Support als Erstes nach dem Hash. Über die Zahlungsseite erreicht der Kunde auch den Paymos-Support, dessen Mitarbeiter bei Bedarf den Händler dazuholen; gebraucht werden dieselben vier Angaben.

Am wichtigsten davon ist der Hash. Mit ihm ist die Zahlung in einem Schritt gefunden, ohne dass jemand Beträge und Uhrzeiten nebeneinanderlegen muss.

Worin unterscheidet sich das von einer Über- oder Unterzahlung?

Darin, ob überhaupt eine Rechnung im Spiel ist.

Überzahlung und Unterzahlung führt Paymos als Zustände einer Rechnung. Zu jedem gehört ein Status, den Ihre Anbindung liest, und ein Ereignis, das sie abonniert: invoice.paid_over, invoice.underpaid, invoice.underpaid_waiting. Hinter jedem steht eine Bestellung, die existiert und auf etwas wartet. Beide Fälle behandelt der Beitrag zum Betrag; wie eine Rechnung überhaupt entsteht, erklärt der Leitfaden zur Rechnungsstellung.

Eine Gutschrift außerhalb einer Rechnung ist Geld, hinter dem keine Rechnung steht. Sie hat keinen Status und kein eigenes Ereignis, und die Bestellung, zu der sie zu gehören scheint, kann abgelaufen sein, schon vor Wochen geschlossen oder nie existiert haben.

Wer beides verwechselt, macht immer denselben Fehler. Jemand im Team sieht die Gutschrift, hält sie für eine Teilzahlung auf die Rechnung und liefert gegen diese Rechnung, die dann nie schließt, sodass beim nächsten Abgleich eine Gutschrift und eine Bestellung nebeneinanderstehen, die niemand miteinander verbunden hat. Auseinanderhalten lässt sich beides mit einer Frage: Welche Rechnung wartet auf dieses Geld? Bei einer Unterzahlung gibt es darauf eine Antwort, bei einer Gutschrift außerhalb einer Rechnung nicht.