Rechnung in Kryptowährung: der vollständige Ablauf

Eine Rechnung in Kryptowährung verbindet eine Bestellung mit einer überwachten Zahlung auf der Blockchain. Sie bindet die Bestellkennung des Händlers an einen erwarteten Betrag, eine Frist, gültige Kombinationen aus Asset und Netzwerk, den Zahlungsstatus und den entstehenden Transaktionsdatensatz. Sie ist der Zahlungsdatensatz hinter jeder Zahlungsoberfläche von Paymos.

Eine Wallet-Adresse allein leistet das nicht. Sie benennt keine Bestellung, entscheidet nicht, wann eine Zahlung endgültig ist, und sagt dem System des Händlers nicht, wann die Auslieferung sicher ist. Die Rechnung liefert genau diesen kaufmännischen Zusammenhang. Zum größeren Bild lesen Sie, wie Krypto-Zahlungen funktionieren.

Welche Angaben braucht eine Krypto-Rechnung?

Eine produktive Rechnung beantwortet drei Fragen. Was schuldet der Kunde, wo kann er zahlen, und wie ordnet der Händler den Transfer einer Bestellung zu? Speichern Sie mindestens die Bestellkennung des Händlers, den geforderten Betrag, die Preiswährung, die Frist, das gewählte Asset und Netzwerk, die Einzahlungsadresse, den Rechnungsstatus und die Referenz der Blockchain-Transaktion.

Halten Sie Asset und Netzwerk in jeder Beschriftung für Kunden zusammen. „USDT“ allein ist unvollständig, denn USDT auf Tron und USDT auf Ethereum sind getrennte Assets on-chain. Die Zahlungsanweisung sollte außerdem einen QR-Code oder eine kopierbare Adresse, den exakten Token-Betrag und einen aktuellen Status zeigen. Der Datensatz des Händlers sollte sowohl die eigene Bestellnummer als auch die Rechnungskennung des Anbieters festhalten, damit Support und Abgleich beide Seiten der Transaktion verfolgen können.

Wie verhindert die Rechnungserstellung Duplikate?

Die Rechnungserstellung muss auf Ebene der kaufmännischen Bestellung idempotent sein. Nach einer Zeitüberschreitung weiß der Händler nicht, ob die erste Anfrage durchkam, und ein Neuversuch ohne stabile Kennung kann zwei zahlbare Rechnungen für eine Bestellung erzeugen.

Paymos nutzt dafür die vom Aufrufer gesetzte external_order_id. Wird dieselbe externe Bestellkennung erneut verwendet, kommt die bestehende Rechnung zurück, statt dass eine zweite entsteht. Paymos verwendet für die Rechnungserstellung keinen Header Idempotency-Key, deshalb sollte die Anbindung die Bestellkennung vor dem ersten API-Aufruf erzeugen und speichern.

Speichern Sie die zurückgegebene Paymos-Rechnungskennung zusammen mit der ursprünglichen Bestellung. Geht die Antwort verloren, wiederholen Sie die Anfrage mit derselben external_order_id und arbeiten dann mit der bestehenden Rechnung weiter. Das ist sicherer, als nach jedem Übertragungsfehler eine neue Kennung zu erzeugen.

Wie erhält der Kunde die Zahlungsdetails?

Der Kunde braucht einen eindeutigen Zahlungsweg, bevor sein Wallet die Zahlung sendet. Paymos zeigt ihn über den gehosteten Checkout, ein eingebettetes Iframe, einen Zahlungslink, das Low-Code SDK, ein CMS-Plugin oder eine eigene Oberfläche auf Basis der REST-API. Der Weg sollte das gewählte Asset, das Netzwerk, den Betrag, die Adresse, den QR-Code und den aktuellen Status anzeigen.

Der gehostete Checkout übernimmt die Zahlungsoberfläche. Bestellung und Auslieferung bleiben beim Händler. Ein CMS-Plugin verbindet dasselbe Rechnungsmodell mit einem unterstützten Shop- oder Abrechnungssystem. Die REST-API passt zu Teams, die eine eigene Oberfläche brauchen, macht sie damit aber auch für Validierung, Fehlerbehandlung, signierte Anfragen, Statusanzeige und Abgleich verantwortlich. Wählen Sie die Oberfläche mit dem geringsten Eigenbau, die Ihre Anforderung an das Produkterlebnis noch erfüllt.

Wie sieht der Lebenszyklus einer Paymos-Rechnung aus?

Die Art der Anbindung ändert sich, der Regelkreis bleibt gleich:

1. Erstellen Sie die Rechnung mit einer stabilen external_order_id.
2. Zeigen Sie einen verfügbaren Weg aus Asset und Netzwerk — über Checkout, Link, Plugin, Widget oder eigene Oberfläche.
3. Lassen Sie das Wallet des Zahlers die Zahlung senden und die eingehende Netzwerkgebühr tragen.
4. Warten Sie, während Paymos die Bestätigungsregel für dieses Netzwerk und diesen Betrag anwendet.
5. Wenden Sie die Toleranz für Unterzahlung des Projekts auf den tatsächlich eingegangenen Betrag an.
6. Prüfen Sie die Zustellung des signierten Webhooks und speichern Sie sie dauerhaft, bevor die Auslieferung startet.
7. Gleichen Sie Bestellkennung, Paymos-Rechnungskennung, eingegangenen Betrag und Transaktionsreferenz ab.

Diese Reihenfolge zeigt, wo Duplikatschutz, Finalität, Unterzahlung und Auslieferungskontrolle über alle unterstützten Anbindungen hinweg hingehören. Die genaue Gestalt der Anfrage hängt von der gewählten Oberfläche ab. Teams mit eigenem Weg ergänzen sie um den Leitfaden zu Zahlungen über die REST-API.

Wann darf nach einer erkannten Zahlung ausgeliefert werden?

Erkennung ist noch keine Finalität. Ein Anbieter kann eine Transaktion beobachten, bevor das Netzwerk genug Sicherheit gibt, dass sie in der maßgeblichen Historie bleibt. Die Rechnung sollte erst dann in einen auslieferungsbereiten Zustand wechseln, wenn die zutreffende Bestätigungsregel erfüllt ist.

Paymos legt die Bestätigungsregel nach Netzwerk und Zahlungsbetrag fest. Kleinere Zahlungen können weniger Bestätigungen benötigen, größere warten auf eine strengere Schwelle. Es gibt keine einheitliche Bestätigungsdauer für jede Rechnung. Auch der Zustand des Netzwerks verändert die tatsächlich verstrichene Zeit.

Liefern Sie ausschließlich aus dem endgültigen Zustand „bezahlt“ heraus aus. Verlassen Sie sich nie auf einen Wallet-Screenshot, einen vom Kunden genannten Transaktions-Hash oder ein frühes Ereignis „gesehen“. Der Leitfaden zu Bestätigungen erklärt, warum die erforderliche Tiefe schwankt.

Wie funktioniert die Toleranz für Unterzahlung?

Unterzahlung folgt einem Prozentsatz auf Projektebene. Sie hängt nicht von einer Einzelfallentscheidung im Support ab. Der Regler läuft von 0 % bis 2 % in Schritten von einem Zehntel, und ein neues Projekt startet bei 0,1 % — genug für einen Rundungsrest, nie genug für einen Rabatt. Wer 0 % einstellt, prüft streng: Die Zahlung muss die Rechnung erreichen oder übertreffen. Liegt der eingegangene Betrag innerhalb der eingestellten Toleranz, wird die Rechnung abgeschlossen und der Händler erhält den gezahlten Betrag. Der fehlende Teil wird nicht ergänzt.

Bleibt eine Rechnung mit einer einzelnen Zahlung unter der Schwelle, gilt sie als unterbezahlt. Erlaubt die Rechnung mehrere Zahlungen, kann sie offen bleiben, während der Zahler den Rest sendet. Die Anbindung sollte diesen Zustand anzeigen, statt die Bestellung stillschweigend als bezahlt zu markieren.

Leiten Sie die Toleranz aus der Ökonomie der Bestellung ab. Ein kleiner Prozentsatz kann Rundungen im Wallet auffangen, ohne Handarbeit zu erzeugen; eine großzügige Toleranz kann einen Preisfehler dagegen in einen akzeptierten Rabatt auf jeder Rechnung verwandeln.

Wie werden signierte Rechnungs-Webhooks verarbeitet?

Webhooks bringen den Rechnungszustand in das System des Händlers. Paymos signiert sie mit HMAC-SHA256 im Header X-Webhook-Signature im Format t={timestamp},v1={hmac_hex}. Der empfangende Dienst sollte Zeitstempel und Signatur mit einem laufzeitunabhängigen Vergleich prüfen, bevor er das Ereignis als vertrauenswürdige Daten auswertet.

Die Zustellung wird wiederholt, deshalb müssen Handler idempotent sein. Ein Zustellzyklus von Paymos umfasst insgesamt 11 Versuche — einen ersten Versuch und zehn Wiederholungen — über rund 16 Stunden. Fehlgeschlagene oder unzustellbare Ereignisse lassen sich von Hand nachsenden.

Antworten Sie erst dann mit Erfolg, wenn das Ereignis dauerhaft gespeichert ist. Verarbeiten Sie die Auslieferung anschließend aus diesem Datensatz. Scheitert nachgelagerte Arbeit, wiederholen Sie sie intern, statt den Absender um ein Ereignis zu bitten, dessen Empfang bereits gespeichert war.

X-Webhook-Signature: t=1785326400,v1=2b4f...
Content-Type: application/json

Was gehört in den Abgleich?

Der Abgleich sollte eine vollständige Spur ergeben. Verbinden Sie kaufmännische Bestellung, Datensatz des Anbieters und Blockchain-Transaktion. Speichern Sie die externe Bestellkennung, die Paymos-Rechnungskennung, den geforderten und den eingegangenen Betrag, Asset, Netzwerk, Transaktionsreferenz, den endgültigen Zustand und die relevanten Zeitstempel. Bewahren Sie auch den vom Händler definierten Schlüssel auf, der doppelte Verarbeitung verhindert.

Gleichen Sie aus dem Zustand des Anbieters ab, nicht aus einem vom Kunden genannten Transaktions-Hash. Ein Transfer kann das falsche Asset, das falsche Netzwerk, die falsche Adresse oder einen zu geringen Betrag nutzen und im Block-Explorer trotzdem plausibel aussehen. Der Rechnungszustand bewertet den Transfer gegen die Zahlungsanfrage.

Der Support sollte den Datensatz über drei Kennungen finden. Bestellnummer, Rechnungskennung und Transaktionsreferenz sollten alle zur selben Spur führen. Das senkt Fehler bei Erstattungen und gibt dem Händler einen belastbaren Nachweis, wenn ein Kunde die Auslieferung bestreitet.

Welchen Weg zur Krypto-Rechnung sollten Sie wählen?

Nutzen Sie einen Zahlungslink für gelegentliche Rechnungen von Hand. Er passt zur Abrechnung über Vertrieb oder Support. Nutzen Sie den gehosteten Checkout oder die eingebettete Variante, wenn eine Website eine vollständige Zahlungsseite braucht, ohne jede Wallet-Interaktion selbst zu verantworten. Nutzen Sie ein offizielles CMS-Plugin, wenn der Shop auf einer der von Paymos unterstützten Plattformen läuft.

Wählen Sie die REST-API für einen wirklich eigenen Ablauf. Paymos trennt die Zugangsdaten von Sandbox und Produktion, behält aber dieselbe API-Oberfläche, sodass Teams Rechnungsergebnisse und die Verarbeitung von Webhooks testen können, bevor echte Mittel fließen. Payment- und Payout-Zugangsdaten bleiben ebenfalls getrennt.

Halten Sie für jeden Weg denselben Regelkreis ein: mit stabiler externer Bestellkennung erstellen, exakte Zahlungsdetails zeigen, den endgültigen Zustand „bezahlt“ abwarten, signierte Webhooks prüfen und vor der Auslieferung abgleichen.