Changelog

Wenn die Zahlungsbestätigung für das vom Kunden gewählte Token und Netzwerk keine Zahlung eröffnen kann, kommt jetzt ein einziger 503: payment_method_unavailable. Er ersetzt no_available_address, address_lease_failed, bridge_unavailable und collection_disabled.

Die Lage war bei allen dreien dieselbe: Dieses Token kann in diesem Netzwerk derzeit keine Zahlung annehmen, und ein erneuter Versuch oder eine andere Wahl führt meist zum Ziel. Darüber hinaus beschrieben die drei Namen unsere eigene Technik — und gingen so in den Browser eines Käufers auf Ihrer Zahlungsseite. Die Meldungen taten dasselbe; sie lauten jetzt für jede Ursache gleich.

Nichts spaltet sich auf: Es gab keinen Fall, in dem die alten drei Ihnen unterschiedliche Schritte nahegelegt hätten. Die Gründe werden weiterhin auf unserer Seite festgehalten, wo der Support sie braucht.

Wenn Ihre Integration auf eine der drei alten Zeichenketten verzweigt, stellen Sie sie jetzt um. Sie werden nicht mehr gesendet, und es gibt keinen Übergangszeitraum, in dem alte und neue zugleich kommen. Der type-Link im Fehlerumschlag folgt dem neuen Namen; ein gespeicherter Link auf einen alten Anker führt ins Leere.

Die vollständige Liste steht unter Fehlercodes.

Der 503, den eine Auszahlung zurückgibt, wenn das Zielnetzwerk nicht auszahlen kann, heißt jetzt withdrawal_network_unavailable. Vorher war es hot_wallet_insufficient_liquidity.

An der Auslösung ändert sich nichts: derselbe Endpunkt, derselbe 503, dieselbe Lage — dieses Token lässt sich in diesem Netzwerk gerade nicht abwickeln, mit einem anderen Netzwerk oder später klappt es meist. Geändert haben sich Name und Meldung, die unsere Seite der Auszahlung beschrieben statt Ihrer.

Wenn Ihre Integration auf die alte Zeichenkette verzweigt, stellen Sie jetzt um. Der alte Code wird nicht mehr gesendet, und es gibt keine Übergangszeit, in der beide kommen. Der type-Link in der Fehlerhülle folgt dem neuen Namen — ein gespeicherter Link auf den alten Anker läuft ins Leere.

Die vollständige Liste steht unter Fehlercodes.

Gerundet wird nichts. Im Ledger steht weiterhin der genaue Betrag; kurz ist ab jetzt nur die Anzeige, und die volle Genauigkeit erscheint, sobald Sie mit der Maus über die Zahl fahren.

Zu sehen ist das zuerst in einer Spalte mit Guthaben. Die Beträge fluchten untereinander, statt in jeder Zeile auf eine andere Zahl von Nachkommastellen zu laufen.

Festgelegt wird die Anzeige je Asset. Ein dollargedeckter Stablecoin kommt mit wenigen Nachkommastellen aus; ein goldgedecktes Asset wie XAUT bekommt mehr davon, damit die letzte sichtbare Stelle überall ungefähr gleich viel wert bleibt.

Am Monatsende steht selten eine einzelne Auszahlung an. Ein einzelner Empfänger und eine ganze Liste laufen im Dashboard jetzt durch denselben Dialog: auswählen, an einer Stelle prüfen, abschicken. Auch die Freigabe einer Adressliste passiert genau dort, statt Adresse für Adresse an anderer Stelle.

In der Liste steht das Empfängerlabel, und eine bereits ausgeführte Auszahlung lässt sich von dort wiederholen. Der monatliche Transfer an denselben Partner heißt damit nicht, eine längst freigegebene Adresse noch einmal abzutippen.

Wie viele Empfänger noch in den Lauf passen, sehen Sie vor dem Abschicken. Die Zahl steht neben dem Feld, und die bereits laufenden Auszahlungen sind vom Limit des Kontos schon abgezogen. So kommt die Grenze vor dem Senden an — und nicht als Ablehnung danach.

Zwei Stellen schreibt man von Hand leicht falsch: die Signatur und den Cursor. Beide liegen jetzt in der Bibliothek — Zahlungskanäle, ihre Webhooks und der Einzahlungs-Feed stecken in allen acht offiziellen SDKs: .NET, Go, Java, PHP, Python, Ruby, Rust und TypeScript.

Der Cursor ist der Teil, der unbemerkt schiefgeht. Der mitgelieferte Reader führt ihn weiter, statt bei einer leeren Seite anzuhalten; ein Prozess, der neu startet, setzt an derselben Stelle an und sieht jede abgeschlossene Einzahlung genau einmal.

Signieren, Wiederholungen und typisierte Fehler bleiben ebenfalls im SDK. In jeder README steht der vollständige Ablauf, nicht nur die Liste der Methoden.

Ein Transfer unter dem Minimum wird nicht gutgeschrieben und nicht automatisch zurückgesendet. Deshalb steht die Grenze jetzt in der Token-Liste eines Zahlungskanals: Jeder Eintrag trägt seinen eigenen minimum_deposit statt eines nackten Symbols.

Das Minimum gehört Token und Netzwerk gemeinsam — dasselbe Symbol trägt auf einem anderen Netzwerk eine andere Grenze. Geliefert wird der Wert bei jedem Lesen frisch; nehmen Sie ihn also aus der Antwort, die Sie gerade rendern, statt ihn irgendwo fest zu hinterlegen. Sein Platz in der Oberfläche ist die Zeile neben der Adresse, bevor jemand etwas sendet.

Dazu eine Vereinfachung in den Projekteinstellungen: Freigegeben werden jetzt Token-Symbole, nicht Paare aus Netzwerk und Symbol. Ein neues Netzwerk heißt damit nicht, jeden Token darauf noch einmal einzeln zu erlauben.

Bei der Anlage eines Projekts steht jetzt eine Frage statt drei Schaltern: Wie wird bezahlt? Fünf Antworten sind möglich — Ihr Backend ruft die API, die Zahlung läuft in einem Telegram-Bot, ein Shop-Plugin übernimmt den Checkout, eine Kassenkraft kassiert vor Ort am POS-Terminal, oder ein einbettbares Snippet sitzt auf Ihrer eigenen Seite.

Danach zeigt das Projekt nur noch, was zu dieser Antwort passt. Ein Bot-Projekt trägt sein Branding dorthin, wo seine Links stehen, und sein Schnellstart endet in Telegram; einem Plugin-Projekt wird kein Snippet mehr angeboten, das es nie einbauen wird.

Geändert wird die Antwort später nicht. Wer einen anderen Weg braucht, legt dafür ein zweites Projekt an.

Der Verkauf vor Ort ist unter beiden Adressen erreichbar: /pos antwortet mit einem 308 auf /terminal. Ein Lesezeichen, das an der Kasse liegt, funktioniert also weiter.

Manche Zahler zahlen nicht einmal, sondern immer wieder. Für sie gibt es jetzt den Zahlungskanal: eine dauerhafte Einzahlungsidentität für genau einen Zahler, mit je einer bleibenden Adresse pro unterstütztem Netzwerk. Kein Betrag, keine Frist, kein Endzustand — was eingeht, wird zu einer Einzahlung und landet auf Ihrem Guthaben.

Geführt wird ein Kanal über die Kennung, die Sie ohnehin halten: Ihre eigene external_id. Projekt und externe ID zusammen bilden den Idempotenzschlüssel, weshalb der Aufruf ruhig in jedem Checkout stehen darf — eine Wiederholung liefert denselben Kanal, keinen zweiten.

Einzahlungen werden getrennt gelesen, über einen Feed: nur bestätigte, älteste zuerst, mit einem Cursor, der ausschließlich vorwärts läuft. Wer ihn mitführt, sieht jede abgeschlossene Zahlung genau einmal. Eine leere Seite ist dabei nicht das Ende des Feeds — auch sie gibt einen Cursor zurück, und gelesen wird ab genau dieser Stelle weiter. Sperren und Entsperren gehören dazu, und in der Sandbox lässt sich eine Einzahlung simulieren.

Der erste Kanal entsteht unter Zahlungskanal erstellen.

Deutsch und Spanisch sind ab heute live. Türkisch und vereinfachtes Chinesisch laufen seit dem 20. Juli, Englisch und Russisch schon länger — damit ist der Satz aus sechs Sprachen vollständig.

Ein Zahler in Hamburg sieht die Zahlungsseite auf Deutsch, einer in Valencia auf Spanisch. Welche Sprache erscheint, entscheidet zuerst die URL, dann das Cookie, dann Accept-Language; ohne Treffer bleibt es bei Englisch. Wer trotzdem in der falschen Sprache landet, stellt sie direkt auf der Zahlungsseite um, ohne dass der Vorgang von vorn beginnt.

Ein Projekt kann jetzt als Telegram-Bot angelegt werden. Bei einem solchen Projekt gibt die Rechnung keine Seitenadresse zurück, sondern einen Deep Link: Er öffnet einen Chat, und dort entscheidet der Zahler, welchen Token er sendet und über welches Netzwerk.

Der Einzahlungsschritt zeigt drei Dinge nebeneinander — den erzeugten QR-Code, die Adresse mit einem Button zum Kopieren und wie lange sie gilt. Kein Browser-Tab, kein Konto, keine App außer der, in der Ihr Kunde ohnehin schreibt.

Auch die Statuswechsel laufen in denselben Chat. Wer bezahlt und Telegram schließt, findet dort später, wie die Rechnung ausgegangen ist.

Wie ein Bot-Projekt eingerichtet wird, steht unter Telegram-Checkout.

Empfehlen Sie einen Händler weiter und verdienen Sie an der Paymos-Abwicklungsgebühr mit, die er erzeugt. Vier Stufen reichen von 20 % bis 40 % und steigen bei 5 und 20 aktiven Händlern; die oberste Stufe wird auf Anfrage vergeben, nicht über eine Schwelle.

Der Anteil wird auf jede Rechnung gutgeschrieben, die der empfohlene Händler abrechnet, und zwar im Moment der Abrechnung — nicht monatlich, nicht nach einem Auszahlungsplan, nicht erst ab einem Mindestbetrag. Es gibt keine Obergrenze für das Volumen und keine für die gesamte Provision. Ein Stufenwechsel gilt für das gesamte Portfolio, nicht nur für Händler, die danach empfohlen wurden.

Die Provision wird aus der Paymos-Gebühr herausgelöst, statt obendrauf geschlagen zu werden. Was ein empfohlener Händler zahlt, zahlt jeder Händler.

Ihr Link und Ihre aktuelle Stufe stehen unter Partnerprogramm.

Die Seite „Analysen“ beantwortet drei Fragen: Wie viel kam herein, welcher Anteil der Rechnungen wurde bezahlt, und wie lange brauchten die Zahler dafür?

Die Conversion wird nur über die abgeschlossene Kohorte berechnet — über Rechnungen, deren Ergebnis bereits feststeht. Eine vor zwanzig Minuten erstellte Rechnung ist nicht gescheitert; sie als unbezahlt zu zählen würde die Quote grundlos drücken und jede frische Stunde wie einen Vorfall aussehen lassen.

Die Zeit bis zur Zahlung ist eine Verteilung, kein Mittelwert: 0–5 Minuten, 5–10, 10–15, 15–20 und 20 oder mehr. Das Volumen schlüsselt sich nach Token, Netzwerk und Projekt auf — je die führenden fünf, nicht die vollständige Liste. Die Rechnungsaktivität ist nach Wochentag und Stunde gebündelt, in der Zeitzone Ihrer Wahl.

Öffnen unter Analysen.

Privilegierte Aktionen werden mit Akteur, Aktion, Ziel, Ergebnis und Zeitpunkt festgehalten. Auf Händlerseite wie auf Betriebsseite, in einem gemeinsamen Protokoll.

Jeder Eintrag benennt die Aktion ausdrücklich — merchant.add_whitelisted_address, operator.engage_freeze — und hält fest, wer der Akteur in diesem Moment war, samt seiner Rolle. Eine Beförderung im nächsten Monat schreibt nicht um, was ein Betrachter im März getan hat.

Geschwärzt wird beim Schreiben, nicht beim Lesen. Geheimnisse, Token, Hashes und Signaturen werden entfernt, bevor der Eintrag gespeichert wird. So kann das Prüfprotokoll nie zu der Stelle werden, aus der später Zugangsdaten austreten.

Ein Händler sieht die Historie seines eigenen Kontos, einschließlich der Sicherheitsaktivität mit Gerät und IP. Das vollständige Plattformprotokoll bleibt dem Betrieb vorbehalten — es enthält Aktionen anderer Händler, und es gibt keine Variante, es sicher offenzulegen.

Konto- und Geldereignisse erreichen den Händler jetzt auf zwei Kanälen. Jede Meldung existiert als E-Mail und als Telegram-Nachricht, aus demselben Ereignis — Telegram zu verbinden fügt also einen Zustellweg hinzu, ohne das Postfach stillzulegen.

Geldbewegungen sind abgedeckt — eine Auszahlung gestartet, eine Auszahlung bestätigt — dazu Änderungen im Team, aufgegebene Webhook-Zustellungen und der Sicherheitssatz: 2FA ein- oder ausgeschaltet, ein Passkey hinzugefügt oder entfernt, eine Anmeldemethode verknüpft, eine Auszahlungsadresse freigegeben oder aus der Freigabeliste entfernt, ein API-Geheimnis gewechselt, ein API-Schlüssel widerrufen.

Die Routinekategorien können Sie abschalten. Die Sicherheitsmeldungen nicht, und es gibt keine Einstellung, die sie verbirgt: Die Meldung, dass sich Ihre Auszahlungsadresse geändert hat, ist eine unerwünschte E-Mail weit eher wert als umgekehrt. SMS ist hier kein Kanal.

Jeder Endpunkt, der scheitert, antwortet in derselben Form: RFC 9457 Problem Details, ausgeliefert als application/problem+json.

Verzweigen sollten Sie auf code — eine stabile Zeichenkette, deren Bedeutung sich nach der Veröffentlichung nie ändert. title und detail sind für Menschen geschrieben und können zwischen Releases umformuliert, ergänzt oder übersetzt werden; eine Anbindung, die detail parst, ist eine Anbindung, die an einer Textkorrektur zerbricht. Validierungsfehler an einem einzelnen Feld tragen field; scheitern mehrere Felder gleichzeitig, trägt stattdessen ein Array errors[] die Aufschlüsselung je Feld.

type verweist direkt auf die Dokumentationszeile zu genau diesem Code — aus einer unbekannten Zeichenkette im Log wird ein Klick. Die vollständige Liste liegt unter /docs/errors/codes.

external_order_id ist der Idempotenzschlüssel. Senden Sie ihn beim Erstellen einer Rechnung, und ein wiederholter Aufruf gibt zurück, was bereits existiert, statt eine zweite anzulegen.

Es gibt keinen Idempotency-Key-Header, den Sie erzeugen und aufbewahren müssten, denn maßgeblich ist die Kennung, die Sie ohnehin schon halten: die Bestellnummer, die Warenkorb-ID, die Referenz der Auszahlung. Eine neue Rechnung antwortet mit 201 Created; die Wiederholung derselben Kennung antwortet mit 200 OK und der ursprünglichen Rechnung. Bei Auszahlungen gilt dasselbe, und dort zahlt sich die Eigenschaft aus: Ein wiederholter Auszahlungsaufruf gibt die erste Auszahlung zurück, statt zweimal Geld zu senden.

Die Eindeutigkeit gilt je Projekt für Rechnungen und je Händler für Auszahlungen. Ein Netzwerk-Timeout auf Ihrer Seite ist damit etwas zum Wiederholen, nichts zum Untersuchen.

Jeder API-Zugangsdatensatz führt seine eigene Freigabeliste: bis zu 50 Einträge, IPv4 oder IPv6, einzelne Adressen oder CIDR-Bereiche. Eine leere Liste bedeutet, dass die Zugangsdaten nicht auf IPs beschränkt sind.

Beim Auszahlungsschlüssel bleibt der leere Fall nicht bestehen. Frisch erzeugte Auszahlungs-Zugangsdaten bleiben inaktiv, bis mindestens eine Adresse hinterlegt ist — ein Schlüssel, der am Tag seiner Erstellung gestohlen wird, hat keinen Ort, von dem aus er aufgerufen werden könnte. Zahlungsschlüssel kennen keine IP-Prüfung: Sie erstellen Rechnungen, sie bewegen kein Geld.

Die Freigabeliste zu bearbeiten verlangt eine erneute Authentifizierung und landet im Prüfprotokoll, mit der vollständigen gesetzten Liste statt einer Differenz. Wer die Firewall vor einem geldbewegenden Zugangsdatensatz weiter öffnet, hinterlässt damit einen Eintrag, der festhält, wer sie geöffnet hat.

Zugangsdaten gibt es in zwei Ausführungen. Ein Zahlungsschlüssel (pk_) erstellt Rechnungen und liest deren Status; ein Auszahlungsschlüssel (rk_) erstellt und storniert Auszahlungen und liest Guthaben.

Die Prüfung des Geltungsbereichs sitzt zentral, nicht je Route. Die Zugriffsebene wird bei jeder Anfrage aus dem Schlüsseltyp abgeleitet. Ein Zahlungsschlüssel, der in ein Client-Bundle durchsickert, kann also kein Geld bewegen, auf welchen Pfad er auch gerichtet wird — die Anfrage wird abgewiesen, bevor ein Handler sie sieht, und nicht von einer Route, die ans Prüfen gedacht hat.

API-Geheimnisse tragen das Präfix sk_, Signaturgeheimnisse für Webhooks whsec_. Auch die Umgebung steckt im Präfix. Damit sind pk_live_… und pk_test_… in einer Konfigurationsdatei sichtbar verschiedene Dinge und nicht zwei ähnliche Zeichenketten, bei denen jemand genau hinsehen muss.

Verwalten unter Entwickler → API-Schlüssel.

TOTP lässt sich für jedes Konto einschalten: ein sechsstelliger Code aus einer Authenticator-App, der alle dreißig Sekunden wechselt.

Die Anmeldung ist dabei die kleinere Hälfte. Die größere ist die erneute Authentifizierung — eine kurze Liste von Operationen verlangt einen frischen Code im Moment der Ausführung, statt eine Sitzung zu akzeptieren, die 2FA vor einer Stunde bestanden hat. Eine Auszahlungsadresse hinzufügen, eine entfernen, die IP-Freigabeliste eines API-Schlüssels bearbeiten und 2FA abschalten sind jeweils ein eigener Geltungsbereich: Ein Code, der für einen davon abgefangen wurde, autorisiert keinen anderen.

Ein- und Ausschalten löst eine Sicherheitsmeldung per E-Mail und Telegram aus, unabhängig von den Benachrichtigungseinstellungen. Einrichten unter Konto → Sicherheit.

Melden Sie sich mit einem Passkey an — Face ID, Touch ID, Windows Hello oder ein Hardware-Schlüssel. WebAuthn und FIDO2, ohne Passwort an irgendeiner Stelle des Ablaufs, denn hier gab es nie eines, das sich abphishen ließe.

Ein Passkey ist ein Schlüsselpaar. Die private Hälfte bleibt auf dem Gerät und erreicht uns nie; der Server hält die öffentliche Hälfte und prüft eine Signatur über eine Challenge, die genau einmal gilt. Auf unserer Seite gibt es nichts, das zu stehlen sich lohnt, und auf Ihrer nichts, das man in eine überzeugend gefälschte Anmeldeseite tippen könnte.

Mehrere Geräte lassen sich in einem Konto hinterlegen, und das Hinzufügen wie das Entfernen lösen jeweils eine Sicherheitsmeldung aus, die sich nicht abschalten lässt. Magic Link, Google und Telegram funktionieren weiterhin — ein Passkey ist ein zusätzlicher Weg hinein, kein Ersatz für die anderen.

Einrichten unter Konto → Sicherheit.

Der Paymos-Bot führt einen Support-Verlauf. Öffnen Sie „Anfragen“, schreiben Sie eine Nachricht, und sie erreicht den Support auf der Plattformseite.

Es ist ein Gespräch, keine Ticket-Warteschlange. Antworten landen im selben Chat, die letzten Nachrichten bleiben sichtbar, und eine zweite Nachricht, die vor der Antwort abgeschickt wird, wird nicht zugestellt — der Bot sagt das klar, statt sie in einen Rückstand zu schlucken, den niemand liest.

Ein verknüpftes Paymos-Konto ist keine Voraussetzung. Für einen Zahler ist „nicht verknüpft“ der Normalfall: Wer mitten in einer Zahlung feststeckt, kann auch ohne Konto nach einer Rechnung fragen. Die Verknüpfung zählt nur für die Teile des Bots, die den Zustand des Kontos zeigen.

Plugins sind für WooCommerce, WHMCS, OpenCart, PrestaShop, Magento 2, Shopware 6, CS-Cart und Easy Digital Downloads erschienen.

Die Verbindung ist ein Klick, kein Kopieren und Einfügen. Der Shop öffnet einen Paymos-Tab, der Händler gibt die Anfrage für das Projekt frei, das er ohnehin gewählt hat, und das Plugin erhält die Zugangsdaten dieses Projekts direkt. Nichts Sensibles wird in ein Einstellungsformular getippt, und die gespeicherten Werte gehen nie an den Browser zurück — ein durchgesickertes Release-Archiv ist für jeden Händler dasselbe und enthält überhaupt keine Schlüssel.

Der Bestellstatus kommt aus dem signierten Webhook, nie daraus, dass der Kunde auf einer Rückkehrseite landet. Ein geschlossener Browser-Tab darf keine bezahlte Bestellung verlieren können. Der Callback ist die Quelle der Wahrheit, die Rückkehr-URL eine Höflichkeit.

Installationsanleitungen für alle acht liegen unter /docs.

Plasma nimmt USDT an. Es ist das dreizehnte Mainnet-Netzwerk — dort steht die Liste heute.

USDT ist dort das einzige Asset. Ein Asset erscheint im Checkout auf einem Netzwerk, weil es dort aktiviert wurde, nicht weil die Chain es technisch tragen könnte: Die Registry entscheidet, je Netzwerk und je Token, und nichts wird daraus abgeleitet, dass zufällig ein Vertrag existiert.

Dreizehn Netzwerke und fünf Assets liegen nun hinter einem einzigen Aufruf zur Rechnungserstellung. Wer heute anbindet, schreibt dieselbe Anfrage wie jemand, der im Januar angebunden hat: Die Netzwerkliste steht in den Daten, nicht in der Version der API.

Offizielle Clients sind für TypeScript, Python, PHP, Go, .NET, Java, Ruby und Rust erschienen.

Jeder deckt den vollständigen Vertrag ab, keinen Ausschnitt: Rechnungen, Auszahlungen, Guthaben, Serverzeit, Cursor-Paginierung, das Fehlerformat, Wiederholungen, das Signieren der Anfrage und die Prüfung der Webhooks. Am meisten lohnt eine Bibliothek beim Signieren. Die kanonische Zeichenkette, das Zeitstempel-Fenster und der base64-kodierte HMAC lassen sich von Hand allesamt knapp danebentreffen — und ein knapper Fehler kommt als 401 zurück, ohne weiteren Hinweis.

Die Webhook-Prüfung ist eine zweite Signatur mit eigenen Regeln. Jeder Prüfer nimmt deshalb die rohen Bytes der Anfrage, bevor irgendein JSON geparst wird. Reicht man ihm einen neu serialisierten Rumpf, scheitert die Prüfung — zu Recht.

Repositorys, Release-Tags und Laufzeitanforderungen stehen unter /docs/server-sdks.

XAUT wird auf Ethereum angenommen. Es ist hier das erste Asset, das kein Stablecoin ist, und sollte auch nicht als eines gelesen werden.

Ein XAUT steht für eine Feinunze Gold auf einem Barren nach London Good Delivery. Ein XAUT-Guthaben folgt damit dem Metall, nicht dem Dollar. Für einen Händler, der lieber Gold hält als eine Dollarforderung, ist genau das der Punkt. Es ist zugleich der Preis dafür: ein Guthaben, das sich in beide Richtungen bewegt — wofür ein an den Dollar gebundener Token gerade nicht gedacht ist.

Mechanisch ist daran nichts Besonderes. Nur Ethereum, dieselbe betragsabhängige Bestätigungsregel, dasselbe Guthaben je Asset, dieselbe Freigabeliste auf dem Weg hinaus. Angenommen werden jetzt vier Stablecoins und ein goldgedecktes Asset.

Sui nimmt Zahlungen an, und USDC ist dort das einzige Asset.

Sui ist kein EVM und kein Fork von etwas, das schon auf der Liste steht. Adressen sind 32 Bytes, geschrieben als 0x plus 64 Hex-Zeichen — doppelt so lang wie eine EVM-Adresse, was allein schon reicht, um beide in den Aufzeichnungen des Händlers auseinanderzuhalten. Auch das Coin-Modell hat mit einem ERC20-Guthaben nichts zu tun, weshalb die Erkennung von Einzahlungen einen eigenen Weg geht statt eines geliehenen.

Davon sieht der Händler nichts. Aktivieren Sie Sui in einem Projekt, und es steht im Checkout neben den übrigen; Rechnung, Webhook und Guthaben verhalten sich genau wie in jedem anderen Netzwerk.

Zwei weitere Stablecoins werden angenommen: USD1 auf Ethereum und Solana, DAI auf Ethereum.

Es sind nicht dieselben Instrumente. USD1 ist durch Fiat gedeckt, wie USDT und USDC. DAI ist on-chain durch Krypto besichert statt durch eine Bankeinlage — ein anderes Deckungsmodell hinter derselben Dollareinheit, und es lohnt sich zu wissen, in welchem von beiden ein Guthaben geführt wird.

Umgerechnet wird beim Eingang nichts. Eine DAI-Rechnung schreibt ein DAI-Guthaben gut und zahlt DAI aus, ohne internen Umweg über USDT und ohne Spread dazwischen. Damit umfasst der angenommene Satz vier Stablecoins.

Die Bestätigungsregel liest jetzt zwei Werte: das Netzwerk und den Dollarwert der Rechnung. Eine Rechnung über 40 $ und eine über 40.000 $ warten auf derselben Chain nicht mehr gleich viele Blöcke.

Ethereum verlangt 2 Bestätigungen bis 100 $, 6 bis 1.000 $, 12 bis 10.000 $ und 32 darüber — am flachen Ende rund 24 Sekunden, am tiefen etwa sechs Minuten. Tron geht über 2, dann 6 und deckelt bei 19, dem Solidification-Standard von 19 seiner 27 Super Representatives. Die Werte von Arbitrum wirken mit 40 / 120 / 240 / 800 nur deshalb extrem, weil ein Block dort weniger als eine Sekunde dauert; nach der Uhr gemessen liegen die Fristen bei denen von Base und Optimism.

Chains mit nativer Finalität überspringen die Bänder. BSC und Polygon bestätigen bei Netzwerkfinalität, Solana auf dem Commitment finalized, TON nach einem einzigen Block — jeder Masterchain-Block dort ist bereits endgültig.

Die Anzahl der Bestätigungen ist Konfiguration und ändert sich nur, wenn wir sie ändern. Die daraus abgeleiteten Zeiten nicht: Bei Auslastung kommen Blöcke langsamer. Lesen Sie jede Zeitangabe hier als Näherung, nie als zugesicherte Abwicklungsdauer.

Solana ist live. USDT, USDC und USD1 werden dort abgerechnet.

Solana zählt Bestätigungen nicht wie eine EVM-Chain, und die Plattform tut auch nicht so. Einzahlungen werden auf dem Commitment finalized gescannt und in dem Moment bestätigt, in dem sie dort auftauchen — eine Stufe, keine Betragsbänder. Was finalized auf Solana bedeutet, bedeutet hier eine bestätigte Zahlung.

Einzahlungsadressen sind base58-kodierte ed25519-Public-Keys statt 0x-Zeichenketten; eine Solana-Adresse lässt sich in den Aufzeichnungen des Händlers also nicht mit einer EVM-Adresse verwechseln. Das Guthaben wird weiterhin je Asset zusammengeführt: USDC über Solana und USDC über Base ergeben eine Zahl.

Avalanche nimmt ab heute Zahlungen an. USDT und USDC werden beide auf der C-Chain abgerechnet.

Adressen und Transaktions-Hashes haben EVM-Form — wer bereits Ethereum oder Base abgleicht, muss nichts Neues parsen. Über Betragsstufen läuft die Bestätigung hier nicht: Die Snowman-Finalität klärt die Frage für jede Zahlungsgröße auf einmal, eine Einzahlung wird also gutgeschrieben, sobald die Chain sie als final meldet — dieselbe einstufige Behandlung wie bei BSC und Polygon, nicht die gestaffelten Blockzahlen, die Ethereum und die Rollups abwarten.

Auszahlungen nach Avalanche gehen ausschließlich an Adressen, die bereits auf der Freigabeliste des Händlers stehen. Gebühr und Mindestbetrag des Weges sehen Sie, bevor Sie die Auszahlung bestätigen.

Die Plattform läuft jetzt über mehrere Instanzen. Block-Pipelines, Einsammel-Worker, Webhook-Zusteller und Outbox-Prozessoren stimmen sich über Advisory Locks in PostgreSQL ab — für jede Arbeitslast ist zu jedem Zeitpunkt genau eine Instanz federführend.

Fällt die federführende Instanz aus, übernimmt eine andere den Lock im nächsten Abfragezyklus. Kein Split-Brain, keine doppelte Verarbeitung, keine manuelle Umschaltung. Die Worker sind bewusst idempotent geschrieben — wird derselbe Blockbereich wegen einer Übergabe zweimal verarbeitet, ist das Ergebnis dasselbe wie bei einmaliger Verarbeitung.

Die Datenbank ist die einzige Quelle der Wahrheit für veränderlichen Zustand. Zwischenspeicher im Arbeitsspeicher sind nur für unveränderliche Nachschlagewerte erlaubt (Nachkommastellen von Token, Netzwerkkonstanten). Alles, was sich ändern kann, lebt in PostgreSQL.

Gebührenregeln werden jetzt je Projekt konfiguriert, nicht nur je Händler. Die Plattformgebühr auf jeder Rechnung wird bei der Erstellung berechnet und an die Rechnung geheftet — was der Kunde im Checkout sieht, wird auch on-chain abgerechnet.

Zwei Stellschrauben je Projekt: die Plattformgebühr (Prozentsatz zu Lasten des Händlers) und der Kundenaufschlag (Anteil der Plattformgebühr, der auf den angezeigten Betrag aufgeschlagen und dem Zahler berechnet wird). Stehen beide auf null, trägt der Händler alles; steht der Aufschlag auf 100 %, zahlt der Kunde die volle Gebühr.

Gebühren werden auf der Rechnung selbst gespeichert und nicht später aus dem Einzahlungsbetrag neu berechnet. Nachrechnen ist eine Klasse von Buchhaltungsfehlern, die wir uns nicht leisten.

Auszahlungen, die auf der Chain hängenbleiben — zu wenig Gas, Nonce-Konflikt, Verdrängung aus dem Mempool — werden jetzt von einem eigenen Watchdog erkannt und automatisch durchgedrückt.

Auf EVM-Chains nutzt der Watchdog Replace-by-Fee: Wurde eine Transaktion nach einer konfigurierten Frist nicht aufgenommen, wird sie mit höherem Gaspreis und derselben Nonce erneut gesendet. Die ursprüngliche wird im Mempool verdrängt, ohne dass sich die Identität des Vorgangs ändert.

Sendefehler ordnet die Plattform in handhabbare Kategorien ein: Revert (der Handler entscheidet), Nonce-Konflikt (erneut senden mit frischer Nonce), zu niedrig bepreist (RBF-Anhebung), unzureichende Mittel (Betrieb alarmieren). Jede Einordnung ist im Auszahlungsstatus sichtbar — niemand muss raten, was schiefging.

Laden Sie Kolleginnen und Kollegen in ein Händlerkonto ein, ohne die Hauptzugangsdaten herauszugeben. Jedes Mitglied erhält eine Rolle, die sich zu einem fein abgestuften Satz von Berechtigungen auffächert — durchgesetzt auf Ebene der Autorisierungs-Pipeline, nicht nur in der Oberfläche versteckt.

Auszahlungen und die Verwaltung der Freigabeliste sind standardmäßig dem Inhaber vorbehalten. Administratoren können Rechnungen, Webhooks, Projekte und die Teamzugehörigkeit verwalten, aber ohne ausdrückliche Freigabe kein Geld bewegen.

Verwalten unter Einstellungen.

Eine vollständige Sandbox-Umgebung läuft parallel zur Produktion. Dasselbe Dashboard, dieselbe API-Oberfläche, getrennte Datenbank, getrennte Signaturschlüssel, getrennte Webhook-Endpunkte — nichts überschreitet die Grenze.

In der Sandbox können Sie eine Zahlung simulieren, ohne das Mainnet überhaupt zu berühren. Rufen Sie den Simulationsendpunkt mit einem Zustandswert auf (paid, overpaid, underpay, cancel), und die Plattform errechnet den passenden Einzahlungsbetrag und feuert exakt die Lebenszyklus-Ereignisse, die auch in der Produktion feuern würden. Webhooks, Signaturen, Wiederholungspläne — alles identisch.

Der Punkt dabei: Was in der Sandbox die Integrationstests besteht, geht so in Produktion. Keine Überraschungen der Sorte „die Testumgebung ist eben anders“. Umschalten über den Umgebungsschalter in der Kopfleiste.

Die gehostete Zahlungsseite trägt jetzt die Marke des Händlers. Logo, Checkout-Stil, Akzent, Hintergrund, Fläche, Eckenradius — einmal je Projekt festgelegt und auf jede Rechnung angewendet, die dieses Projekt ausstellt.

Der Widget-Baukasten baut auf denselben Markeneinstellungen auf: Die konfigurierte Farbpalette und das Logo fließen in das einbettbare Widget, sodass eine Website mit dem JavaScript-Schnipsel zum gehosteten Checkout passt, auf den sie verweist.

Branding konfigurieren Sie unter Checkout-Formular. Der Widget-Baukasten liegt unter Low-Code.

Die Webhook-Zustellung nutzt jetzt ein Outbox-Verfahren. Domain-Ereignisse werden in derselben Datenbanktransaktion in die Outbox geschrieben, die den Geschäftszustand ändert — ein Ereignis ist also dauerhaft erfasst, oder die Zustandsänderung hat nie stattgefunden. Ein eigener Worker holt die Ereignisse ab und stellt sie zu.

Jeder Inhalt wird mit HMAC-SHA256 signiert. Die Signatur wird über die rohen Bytes des Rumpfs plus einen Zeitstempel-Header gebildet, sodass der Schutz gegen Wiedereinspielung eingebaut ist — Empfänger weisen Signaturen ab, die älter als das konfigurierte Fenster sind. Das Geheimnis lässt sich je Endpunkt aus dem Dashboard wechseln.

Die Zustellung erfolgt mindestens einmal. Der Wiederholungsplan läuft nach 1 Minute, 2, 4, 8, 16, 32 Minuten, dann 1, 2, 4, 8 Stunden — insgesamt elf Versuche über rund 16 Stunden. Empfänger müssen anhand der Ereignis-ID idempotent sein; sie steht im Inhalt und im Header X-Webhook-Id.

Ein Terminal im POS-Stil gehört jetzt zur Plattform. Rechnungserstellung mit einem Klick und erzeugtem QR-Code — die Kasse hält dem Kunden ein Smartphone hin, der Kunde scannt, die Zahlung landet im Händlerguthaben.

Die Terminalseite ist für Tablets und Smartphones gestaltet, nicht für den Desktop. Großes Eingabefeld für den Betrag, deutlicher Button zum Kassieren, Statuswechsel auf bestätigt in Echtzeit, sobald die Einzahlung final ist. Ein Projekt bekommt eine Terminal-URL, und die öffnet sich auf so vielen Smartphones oder Tablets, wie die Theke braucht — nichts zu koppeln, keine Einrichtung je Gerät.

Die URL Ihres Projekts steht unter Terminal.

Die öffentliche REST-API ist in Produktion. JSON rein, JSON raus, OpenAPI-Spezifikation.

Zugangsdaten sind nach Händler, Umgebung und Schlüsselart eingegrenzt, ein Payment- und ein Payout-Schlüssel sind also verschiedene Zugangsdaten mit verschiedener Reichweite — ein Payment-Schlüssel, der in ein Client-Bundle rutscht, legt Rechnungen an und sonst nichts. Ratenbegrenzungen zählen je Händler in Zählern über feste Zeitfenster, gestützt auf PostgreSQL: ein Budget, gleich über welchen Schlüssel der Aufruf kam, und kein Zustand im Edge-Cache, den man synchron halten müsste.

Die Auth-Pipeline ist dieselbe, die das Dashboard schützt: Jeder Endpunkt trägt ein Berechtigungsattribut, das Eigentum wird gegen den Bereich der Zugangsdaten geprüft, die Umgebung wird zuerst geprüft. Die Plattform weigert sich, mit einem Produktionsschlüssel Sandbox-Daten zu lesen. Punkt.

Zugangsdaten verwalten Sie unter Entwickler → API-Schlüssel. Die vollständige Dokumentation liegt unter /docs.

Der Widget-Baukasten ist im Dashboard. Bauen Sie ein Zahlungs-Widget visuell — Farben, Logo, unterstützte Netzwerke, Standardbetrag, Weiterleitungsverhalten — und sehen Sie die Vorschau live mitlaufen.

Der Zustand ist in die URL kodiert, sodass ein konfiguriertes Widget als einzelner Link teilbar ist. Exportmöglichkeiten: ein JavaScript-Schnipsel zum Einsetzen auf jeder Website oder ein Iframe mit festen Maßen für engere Layout-Kontrolle. Das Widget spricht mit einem stabilen öffentlichen Endpunkt, sodass eine ausgerollte Anbindung nicht bricht, wenn wir intern etwas ändern.

Öffnen Sie den Baukasten unter Low-Code.

Jedes Command und jede Query läuft jetzt durch eine typisierte Pipeline: Logging → Validierung → Autorisierung → Wiederholung → Transaktion → Handler. Jeder Schritt ist generisch über den Anfragetyp — ein Verhalten zu ergänzen ist eine DI-Registrierung, kein Umbau.

Die Autorisierung wird beim Start kompiliert, nicht je Anfrage per Reflection aufgelöst. Jedes Command trägt ein einzelnes Attribut, das auf einen Berechtigungsbereich, eine Eigentumsprüfung und einen Umgebungsschutz abbildet. Durch die kompilierten Tabellen wird die Autorisierung je Anfrage zu einem Dictionary-Zugriff statt zu einem Durchlauf über Attribute.

Die Validierung läuft zuerst, weil das Abweisen fehlerhafter Eingaben, bevor sie die Datenbank berühren, der günstigste mögliche Fehlschlag ist. Die Transaktion ist das letzte Verhalten vor dem Handler — Handler öffnen keine Transaktionen selbst, sie bekommen eine übergeben.

Die gehostete Zahlungsseite ist heute erschienen. Kunden landen auf einer einzigen URL, wählen das Netzwerk, aus dem sie zahlen möchten, sehen Adresse und QR-Code, und die Seite aktualisiert sich live, sobald die Einzahlung eintrifft.

Wie es unter der Haube funktioniert: Die Zahlungsseite ist ein eigener Blazor-Host mit eigenem SignalR-Kanal. Sobald der Kunde ein Netzwerk wählt, wird eine Adresse aus dem netzwerkspezifischen Pool der Plattform geliehen, und die Seite abonniert Statusaktualisierungen für genau diese Rechnung. Kein Polling, kein Neuladen, kein manueller Status-Button.

Eine Rechnung deckt jedes Netzwerk ab, das im Projekt aktiv ist — einmal ausstellen und den Kunden auf Tron, BSC oder Polygon begleichen lassen, je nachdem, was er gerade hält. Erst die Wahl erzeugt die Adresse: davor gibt es keine, danach genau eine, und der geschuldete Betrag steht gegen diese Wahl fest.

Erreichbar unter /invoice/{invoice-id}.

Das Händler-Dashboard ist in Produktion. Gebaut auf Blazor Server mit serverseitigem Rendering und einem interaktiven SignalR-Kanal — Aktualisierungen landen in der Oberfläche ohne Polling und ohne separate Frontend-Codebasis.

Was im ersten Schnitt ausgeliefert wird:

• Übersicht — Tagesvolumen, Erfolgsquote, offene Ereignisse, jüngste Einzahlungen (Übersicht →)
• Rechnungen — durchsuchbare Historie mit Statusfiltern, Aufschlüsselung je Netzwerk, Zeitleiste der Einzahlungen (Rechnungen →)
• Guthaben — Live-Guthaben je Token über alle aktivierten Netzwerke, mit Auszahlungshistorie direkt daneben (Guthaben →)
• Projekte — Einstellungen je Projekt, aktivierte Netzwerke und Token, Branding (Projekte →)
• API-Schlüssel — Zugangsdaten, Webhook-Endpunkte, Ereignisprotokoll (API-Schlüssel →)

Der Umgebungsschalter in der Kopfleiste wechselt zwischen Produktion und Sandbox, ohne dass Sie Ihre Position verlieren.

Eine Rechnung kann nur abgeschlossen werden, wenn die Chain über den Ablaufzeitpunkt der Rechnung hinaus fortgeschritten ist. Das wird auf Domainebene erzwungen — nicht als Prüfung, die über die Handler verstreut ist, sondern als Invariante, die bei Verletzung laut scheitert.

Warum das zählt: Bei bestätigungsbasierter Finalität kann eine Einzahlung aus Sicht der Chain „vor“ dem Ablauf landen, von der Pipeline aber „nach“ dem Ablauf beobachtet werden — eine Wettlaufsituation, die naiv behandelt zu Doppelbelastung oder stillem Mittelverlust führt. Die Plattform verfolgt sowohl den zuletzt verarbeiteten als auch den zuletzt finalisierten Block, und der Abschluss wartet auf beide.

Regressionstests hämmern bei jedem Commit auf diese Invariante ein. Einen stillen Fehler an dieser Stelle dürfen wir nicht ausliefern.

Mittel, die auf den Adressen einzelner Rechnungen eingehen, werden jetzt ohne Zutun des Händlers automatisch in Hot Wallets gebündelt. Das Einsammeln läuft als Hintergrundprozess und ist eine Plattformaufgabe — das Händlerguthaben wird in dem Moment gutgeschrieben, in dem die Einzahlung bestätigt ist, nicht wenn sie eingesammelt wird.

Auf EVM-Chains läuft das Einsammeln zweistufig: zuerst eine Gas-Überweisung, dann der Token-Transfer. Beides zahlt die Plattform. Auf Tron übernimmt die Plattform die Netzwerkgebühr aus dem eigenen Guthaben, sodass der Händler nie eine Gas-Position sieht. Fehlgeschlagene Läufe werden mit Backoff wiederholt; der Watchdog fängt alles Hängengebliebene ab und meldet es dem Betrieb.

Ergebnis: Der Händler bekommt ein Guthaben, kein Wallet zu pflegen.

Das Kurs-Subsystem ist in Produktion. Umrechnungen von Krypto in Fiat und von Krypto in Krypto lösen jetzt gegen Live-Marktpreise auf statt gegen veraltete Nachschlagewerte.

Primärquelle ist CoinGecko, angebunden über einen Round-Robin-HTTP-Pool mit Backoff je Endpunkt bei Ratenbegrenzung. Kurse werden mit kurzer Lebensdauer im Speicher zwischengehalten — lang genug, um die Latenz beim Kursabruf im Checkout aufzufangen, kurz genug, um echte Bewegungen abzubilden. Ein Händler, der in EUR abrechnet, bekommt den USDT-Betrag in dem Moment aufgelöst, in dem der Zahler Token und Netzwerk wählt; dieser Kurs hängt danach an der Rechnung fest — der Markt läuft weiter, der geschuldete Betrag nicht.

Veraltete Kurse fallen auf den zuletzt bekannten Wert zurück; bleibt die Quelle über das Zeitfenster hinaus nicht erreichbar, scheitern kursabhängige Operationen laut, statt gegen eine Schätzung zu bepreisen.

USDC wird jetzt auf allen sechs unterstützten EVM-Chains angenommen: Ethereum, BSC, Polygon, Arbitrum, Optimism und Base. Die Token-Registry führt die kanonische Vertragsadresse je Netzwerk — natives USDC lässt sich nicht mit einer gebrückten Variante verwechseln.

Händler können USDC je Projekt in den Projekteinstellungen aktivieren. Jedes Projekt führt seine eigene Liste akzeptierter Token; Preisregeln gelten je Token, nicht je Projekt.

TON ist zur Netzwerkliste dazugekommen. Mit Tron, sechs EVM-Chains und TON rechnet die Plattform nun über acht Netzwerke aus einer einzigen API ab.

Die Architektur von TON hat mit EVM nichts gemein. Smart-Contract-Wallets werden je Adresse ausgerollt, Jettons leben in eigenen Vertragspaaren (Master plus Wallet je Nutzer), und die Finalität läuft über Validator-Sets, die im Sekundentakt rotieren. Unsere Pipeline bringt eigene TON-RPC-Clients, die Ableitung von Jetton-Wallets und einen TON-spezifischen Transfer-Parser mit.

TON-Transaktionen nutzen einen Ed25519-kompatiblen Signaturweg statt des secp256k1-Verfahrens der ECDSA-Netzwerke — bei denselben Kontrollen für Zieladressen und Prüfprotokoll wie auf allen anderen Paymos-Wegen.

Drei L2-Rollups sind zur Netzwerkliste dazugekommen: Arbitrum One, Optimism und Base. Alle drei teilen sich die EVM-Pipeline und erben deren Vorfilter und Reorg-Behandlung.

Gas ist auf Rollups deutlich günstiger als auf L1 Ethereum, was die USDC-Abwicklung auf Base oder Arbitrum zu einer echten Option für kleinteiligen Handel macht. Die Bestätigungsschwellen sind je Chain abgestimmt — Base und Optimism werden auf Sequencer-Finalität abgerechnet, sobald die konfigurierte Bestätigungstiefe erreicht ist.

Aktivieren Sie sie je Projekt unter Projekte.

Drei EVM-Netzwerke gingen gemeinsam an den Start: Ethereum Mainnet, BNB Smart Chain und Polygon PoS. Eine einzige Block-Pipeline treibt alle drei — die Finalitätsstrategie wird je Netzwerk eingesteckt.

Die Erkennung von Einzahlungen läuft über eth_getLogs in einem gleitenden Fenster, mit einem Bloom-Filter-Vorfilter gegen die kanonische Token-Registry, sodass wir nur Logs für Token abrufen, die uns tatsächlich interessieren. Die Reorg-Behandlung läuft an den Parent-Hashes zurück, markiert die verwaisten Blöcke und spielt ab dem neuen Fork-Punkt erneut ein.

Jede Chain hat ihren eigenen RPC-Pool mit Round-Robin-Lastverteilung und Backoff je Endpunkt bei Ratenbegrenzung. Eine neue EVM-Chain aufzunehmen ist eine Konfigurationsänderung, keine Codeänderung.

Der erste Stablecoin ist live: USDT auf Tron. Rechnungen in TRC20 USDT werden angenommen, gegen die Block-Finalität bestätigt und dem Händlerguthaben gutgeschrieben — die Gebühren für das Einsammeln zahlt die Plattform, nicht der abgerechnete Betrag des Händlers.

Die Nachkommastellen des Tokens werden beim Laden der kanonischen Registry direkt aus dem Vertrag gelesen. Die Betragsrechnung läuft gegen die native Einheit des Tokens, nie gegen Anzeigetexte, sodass Rundungsfehler nicht aus der Oberfläche zurück in die Bücher wandern.

Das erste Netzwerk ist in Produktion. USDT-TRC20 läuft durchgängig über Paymos — Rechnungserstellung, Erkennung der Einzahlung, Verfolgung der Bestätigungen, Gutschrift auf das Guthaben.

Wie tief eine Zahlung bestätigt werden muss, hängt neben dem Netzwerk auch vom Betrag ab — eine kleine Zahlung ist früher durch als eine große. Die Block-Pipeline liest aus einem selbst verwalteten RPC-Pool mit automatischer Umschaltung. Die Erkennung von Einzahlungen arbeitet mit einem Parser, der zuerst die Calldata liest, statt jede Log-Ausgabe zu durchsuchen — günstiger und verlässlicher.

Tron kam zuerst. Die tiefste Stufe wartet auf die Solidification durch 19 der 27 Super Representatives; eine Zahlung über 1.000 $ ist damit nach rund einer Minute endgültig.

Auszahlungen gehen jetzt ausschließlich an vom Händler kontrollierte Adressen, die vorab freigegeben wurden. Eine leere Freigabeliste deaktiviert ausgehende Überweisungen, statt auf ein unbeschränktes Ziel zurückzufallen.

Sensible Änderungen an der Freigabeliste erfordern eine erneute Authentifizierung und werden im Prüfprotokoll festgehalten. Auszahlungsanfragen bleiben idempotent, sodass dieselbe Anfrage auch bei Wiederholung keine zweite Auszahlung erzeugt.

Der Betrieb kann außerdem alle ausgehenden Überweisungen stoppen oder ein einzelnes Paar aus Asset und Netzwerk einfrieren, während ein Vorfall untersucht wird.

Ein Hauptbuch mit doppelter Buchführung erfasst jetzt jede Bewegung auf der Plattform. Einzahlungen, Gebühren, Gutschriften, Erstattungen, Stornierungen — jede einzelne wird gegen die Gegenseite ausgeglichen, bevor die Transaktion festgeschrieben wird.

Soll gleich Haben. Die Prüfung läuft in derselben Datenbanktransaktion, die die Buchungen schreibt, sodass eine unausgeglichene Buchung gar nicht erst landen kann. Eine Abweichung zwischen Händlerguthaben und der Realität auf der Chain ist eine Fehlerklasse, die wir uns nicht leisten.

Das Hauptbuch ist append-only. Korrekturen werden als neue Transaktionen mit Verweis auf das Original gebucht — die Historie bleibt vollständig und wiederholbar.

Die Kern-Domainschicht steht. Reichhaltige Modelle mit privaten Settern, Factory-Methoden, die jede Eingabe prüfen, und Value Objects für alles Monetäre.

Money ist ein Value Object, das an ein Token gebunden ist, kein nacktes Decimal. Arithmetik über Token-Grenzen hinweg scheitert bereits an der Absicht und fällt zur Laufzeit laut aus — USDT zu TRX zu addieren ist nichts, das kompiliert oder läuft.

Geschäftsoperationen geben Outcome<T, Error> zurück, statt Ausnahmen zu werfen. Ausnahmen bleiben echten Fehlern vorbehalten. Erwartete Fehlschläge reisen als Werte durch die Pipeline.

Die Entwicklung von Paymos hat heute begonnen. Der Stack ist .NET 10 mit Blazor Server für die Host-Schicht, PostgreSQL mit EF Core 9 für die Persistenz und MediatR für die Command- und Query-Pipeline.

Der Code ist in vier Schichten aufgeteilt — Domain, Application, Infrastructure und Host — mit strikter Abhängigkeitsumkehr. Die Domain hängt von nichts ab. Die Infrastruktur passt sich an Ports an, die in Application definiert sind. Der Host verdrahtet alles miteinander.

Test-first ist die Regel, nicht die Ausnahme. Die CI führt bei jedem Push die vollständige Suite aus.