Zahlungsablauf

Zwei Produkte für den Geldeingang

Eine Rechnung und ein Zahlungskanal nehmen beide Geld an. Welches der beiden Sie einsetzen, verändert den Zuschnitt Ihrer Integration:

	Rechnung	Zahlungskanal
Was es ist	Eine einzelne Zahlungsanforderung	Die dauerhafte Einzahlungsadresse eines einzelnen Kunden
Betrag	Bei der Erstellung festgelegt	Keiner — gutgeschrieben wird jede Einzahlung ab dem Mindestbetrag des Tokens
Frist	Ja	Keine
Adresse	Eine eigene Adresse je Rechnung	Je Netzwerk eine feste Adresse, die nie neu vergeben wird
Endzustand	paid, paid_over, underpaid, expired, cancelled	Keiner — ein Kanal nimmt Zahlungen an, bis Sie ihn sperren
Passt zu	Checkout, Bestellungen, einmalige Zahlungen	Guthaben aufladen, laufende Einzahlungen, Kunden mit Abrechnung außerhalb von Paymos

Der Rest dieser Seite beschreibt den Lebenszyklus einer Rechnung. Für den Kanalzweig siehe Zahlungskanal erstellen: Ein Kanal hat keinen eigenen Lebenszyklus; den hat jede eingehende Einzahlung, und er ist deutlich kürzer — confirming → confirmed, mit reorged dazwischen, wenn die Chain sich reorganisiert.

Lebenszyklus

Eine Rechnung endet in genau einem Endzustand: paid, paid_over, underpaid, expired oder cancelled. Die meisten Übergänge lösen ein Webhook-Ereignis aus — welche, steht in der Statustabelle weiter unten. Ab confirming sendet jeder. Die beiden Zustände vor der Zahlung senden keines: Der Start in awaiting_client bleibt still, und der gewöhnliche Wechsel nach awaiting_payment, wenn der Checkout das Token bestätigt, ebenso. Die eine Ausnahme läuft rückwärts — entfernt eine tiefe Reorganisation jeden gezählten Transfer, fällt die Rechnung auf awaiting_payment zurück, und dieser Rückfall sendet invoice.awaiting_payment.

Zwei Wege der Erstellung

Beide Wege beginnen gleich. Die Rechnung entsteht in awaiting_client, noch ohne Adresse dahinter. Unterschiedlich ist, was Sie senden und wie viel der Kunde noch entscheidet. Die Adresse wird in dem Moment vergeben — und die Rechnung wechselt zu awaiting_payment —, in dem der Checkout das Token bestätigt.

Direkter Krypto-Weg — Sie senden amount + currency + network. Der amount ist der zu zahlende Krypto-Betrag, Token und Chain stehen bereits bei der Erstellung fest. Der Kunde hat nichts mehr zu entscheiden, deshalb bestätigt der Checkout dieses Paar und die Adresse wird sofort vergeben.

Fiat-Weg — Sie senden amount + currency (ohne network). Der amount ist ein Fiat-Betrag. Der Kunde wählt im gehosteten Checkout Token und Netzwerk; in diesem Moment fixiert Paymos den Wechselkurs, vergibt eine Adresse, und die Rechnung wechselt zu awaiting_payment. Den fixierten Kurs lesen Sie an der Rechnung über payment.exchange_rate zurück, zusammen mit dem exakten Token-Betrag payment.expected.

Die vollständige Liste der Fiat-Codes und Token steht unter Unterstützte Währungen, der Anfragekörper unter Rechnung erstellen.

Status

Status	Beschreibung	Webhook-Ereignis
awaiting_client	Startstatus jeder Rechnung — keine Adresse, bis der Checkout das Token bestätigt	—
awaiting_payment	Adresse vergeben, wartet auf den Transfer	— auf dem Hinweg; invoice.awaiting_payment nur beim Rückfall nach einer Reorganisation
confirming	Zahlung erkannt, wartet auf Bestätigungen	invoice.confirming
underpaid_waiting	Teilzahlung eingegangen, wartet auf den Rest	invoice.underpaid_waiting
paid	Zahlung vollständig bestätigt	invoice.paid
paid_over	Eingegangener Betrag übersteigt den erwarteten (vollständig gutgeschrieben)	invoice.paid_over
underpaid	Mit unzureichender Zahlung geschlossen	invoice.underpaid
expired	Frist ohne Zahlung abgelaufen	invoice.expired
cancelled	Vom Händler storniert (nur aus awaiting_client)	invoice.cancelled

Stornierung

Eine Rechnung lässt sich nur in awaiting_client stornieren — bevor der Checkout das Token bestätigt. Danach ist die Adresse aktiv und dem Kunden wurde ein fester Betrag auf einer bestimmten Chain genannt, damit ist eine Stornierung ausgeschlossen.

Fristen und Ablauf

Einstellung	Standard
Zeitfenster für die Token-Auswahl (Fiat-Weg)	Konfigurierbar
Ablauf der Rechnung (nach Vergabe der Adresse)	Konfigurierbar
Schwelle für Unterzahlung	Je Projekt konfigurierbar
Umgang mit Überzahlung	Vollständig gutgeschrieben

Sendet der Kunde vor Ablauf der Rechnung weniger als den geforderten Betrag, hängt der resultierende Status von allow_multiple_payments ab:

• —allow_multiple_payments: true — der Status wird underpaid_waiting, weitere Zahlungen werden bis zum Ablauf der Frist angenommen
• —allow_multiple_payments: false — eine einzelne unzureichende Zahlung schließt die Rechnung sofort mit underpaid

Läuft die Frist im Zustand underpaid_waiting ab, ergibt sich der Endstatus aus dem insgesamt eingegangenen Betrag und der Regel für Unterzahlung. Sendet der Kunde mehr als erwartet, wird der volle Betrag gutgeschrieben und der Status wird paid_over.