Payora — ein schlüsselfertiges Krypto-Zahlungsgateway

01Projektübersicht

Payora ist ein Krypto-Zahlungsgateway, das ein Unternehmen auf seiner eigenen Infrastruktur bereitstellt und vollständig kontrolliert. Im Gegensatz zu herkömmlichen Zahlungsanbietern steht Payora niemals zwischen dem Käufer und dem Verkäufer: Die Gelder gehen direkt an die eigenen Adressen des Händlers, und der Gateway-Server hält keine privaten Schlüssel und kontrolliert niemals das Geld. Daraus ergeben sich die zwei definierten Eigenschaften, die im Produkt selbst festgelegt sind — selbstgehostet (es läuft auf der Infrastruktur des Eigentümers) und nicht verwahrend (deine Schlüssel, deine Gelder).

Die Idee entstand aus einer einfachen Beobachtung: Fast jeder Online-Dienst, der Krypto akzeptieren muss, erfindet dasselbe Zahlungsmodul neu. Einige fügen einen Drittanbieter-Prozessor hinzu und zahlen Gebühren sowohl für Transaktionen als auch für Abhebungen; andere schreiben die Akzeptanz "von Hand", ohne Webhooks, ohne Betragsabgleich und ohne ordnungsgemäße Handhabung von Unterzahlungen. Payora fasst diese wiederholte Arbeit in einem Produkt zusammen: eine einzige API, einen bereitgestellten Zahlungsbildschirm (gehosteter Checkout) und signierte Webhooks die dem Geschäft mitteilen, dass eine Zahlung erfolgt ist.

Wir haben das Produkt von Anfang bis Ende entworfen und gebaut — von der Infrastruktur und Architektur bis zur Landing Page, dem Händler-Dashboard und der Dokumentation. Im Folgenden erläutern wir das Problem, das Payora löst, wie es intern funktioniert und die technischen Entscheidungen, die die Akzeptanz von Krypto vorhersehbar und sicher gemacht haben.

Der Kontext ist ebenfalls wichtig. Payora sollte niemals ein einmaliges Zahlungs-Widget sein, sondern ein gemeinsame Zahlungsplattform für eine ganze Reihe von Projekten: Einmal implementieren, und Sie können Krypto in jedem Ihrer Dienste akzeptieren, indem Sie jeden als separaten Händler registrieren. Das spart Dutzende von Stunden bei jedem neuen Produkt und beseitigt den Zoo inkompatibler Zahlungsmodule, der sich im Laufe der Zeit über die Seiten verteilt. Je mehr Projekte ein Eigentümer betreibt, desto höher ist die Rendite auf ein einzelnes Gateway: ein Ort zum Aktualisieren, ein Sicherheitsmodell, ein Satz von Statusmeldungen für alle.

02Kontext und das Problem

Die Annahme einer Krypto-Zahlung ist "technisch" einfach – der schwierige Teil ist, es zu tun zuverlässig und wiederholbar. Als wir die Aufgabe aufschlüsselten, tauchte eine ganze Reihe von Problemen auf, mit denen jeder konfrontiert ist, der selbstständig Krypto akzeptiert:

• Custodial-Risiko.Drittanbieter halten die Gelder selbst: das bedeutet Gebühren, Limits und das Risiko einer Sperrung oder dass der Dienst zusammen mit dem Geld verschwindet.
• Duplizierter Code.Auf jeder neuen Seite wird das Zahlungsmodul von Grund auf neu geschrieben – Adressgenerierung, Überwachung eingehender Überweisungen, Betragsabgleich, Rechnungsstatus.
• Unzuverlässige Benachrichtigungen.Der Shop muss sofort über eine Zahlung informiert werden und der Quelle vertrauen. Selbstgemachte "Pings" sind leicht zu fälschen, und das manuelle Abfragen der Blockchain bedeutet Last und Verzögerungen.
• Eine Zahlung mit einer Rechnung abgleichen.Wenn jeder an eine einzige Adresse zahlt, wird es zur Kopfschmerz, herauszufinden, wer für was bezahlt hat.
• Unterzahlungen und Überzahlungen.Die Raten schwanken, die Nutzer runden den Betrag, das Netzwerk erhebt eine Gebühr – Sie benötigen Logik für Teilzahlungen und akzeptable Abweichungen.

Die Vorgabe war folgende: Entwickeln Sie ein Gateway, das all diese Routine vom Entwickler des Shops abnimmt, während die Kontrolle über das Geld nicht entzogen wird. Ein Händler sollte in der Lage sein, an einem Abend mit der Annahme von Krypto zu beginnen, nicht in einem Sprint, und dennoch sicher sein, dass die Gelder direkt bei ihm ankommen.

Eine separate Ebene der Aufgabe ist Vertrauen auf der Käuferseite. Der Zahlungsbildschirm muss beruhigend genug aussehen, damit eine Person keine Angst hat, Gelder zu senden: ein klarer Betrag, eine sichtbare Adresse, ein QR-Code und ein Timer, der bis zum Ablauf der Rechnung herunterzählt. Jede Nachlässigkeit hier schadet direkt dem Abschluss der Zahlung, daher haben wir den Checkout nicht als "technischen Bildschirm" betrachtet, sondern als einen vollständigen Teil des Verkaufstrichters.

Schließlich gab es die Infrastruktur-Ebene. Der Dienst verarbeitet Geld, was bedeutet, dass er in einer vorhersehbaren, isolierten Umgebung mit klaren Zugriffssteuerungen, gültigen Zertifikaten und Perimeterschutz leben muss. In der Fintech-Branche wird jedes Detail, das "für später" gelassen wird, zu einem Vorfall, daher haben wir die Anforderungen an die Umgebung von Anfang an integriert, anstatt sie unter Last nachzurüsten.

03Projektziele

Aus dem Brief entstanden konkrete Produkt- und Ingenieurziele, die wir in jeder Phase im Hinterkopf hatten:

• Einfache Integration.Die Verbindung einer Seite ist eine Anfrage zur Erstellung einer Rechnung und ein Webhook-Handler. Kein tausendzeiliger SDK, sondern einfaches, lesbares REST.
• Standardmäßig nicht verwahrend.Private Schlüssel verlassen niemals die Seite des Eigentümers. Der Gateway-Server läuft im Nur-Lese-Modus, wenn es um die Annahme von Geldern geht.
• Ein fertiger Zahlungsbildschirm.So muss der Händler keine Zahlungs-UI entwerfen — Payora bietet einen gehosteten Checkout mit der Rechnung, Adresse, QR und Timer.
• Vertrauenswürdige Benachrichtigungen.Jeder Webhook ist signiert; der Shop überprüft die Signatur und kann nicht von einem gefälschten "bezahlt" hereingelegt werden.
• Vorhersehbarkeit.Klare Rechnungsstatus, transparente Logik für Unterzahlungen und Ablauf, Idempotenz.
• Selbsthosting.Bereitstellung auf Ihrem eigenen Server mit separaten Subdomains für die API, Zahlungen und Admin.

Diese Ziele wurden absichtlich als Einschränkungen und nicht als Wünsche formuliert. Jedes von ihnen schloss ungeeignete architektonische Optionen in der Entwurfsphase aus. Zum Beispiel schloss das nicht-treuhänderische Erfordernis sofort alle Konzepte aus, bei denen der Server Schlüssel hält; das einfache Integrations-Erfordernis wies schwere SDKs zugunsten von transparentem HTTP zurück; und das Vorhersehbarkeits-Erfordernis diktierte ein striktes Statusmodell anstelle von "magischem" Verhalten. Das Ergebnis ist ein eng fokussiertes Produkt – es macht eine Sache, aber macht sie zuverlässig.

04Was wir gebaut haben

Payora bündelt die Akzeptanz von Kryptowährungen in drei klaren Bausteinen, die den gesamten Zahlungszyklus abdecken:

Auf diesem Kern sitzt eine Landingpage mit klarer Positionierung, ein Händler-Dashboard zur Erstellung von Projekten und zur Ansicht von Rechnungen sowie Dokumentation, die ein Entwickler ohne Anrufe integrieren kann. All dies wird als ein einziges Produkt auf einer dedizierten Infrastruktur bereitgestellt.

Entscheidend ist, dass diese drei Blöcke nicht voneinander getrennt sind — sie bilden einen geschlossenen Kreislauf: die API erstellt eine Rechnung, der Checkout zeigt sie dem Käufer, der Webhook gibt das Ergebnis an den Shop zurück. Jedes Element weiß genau so viel, wie es braucht, und dringt nicht in den Verantwortungsbereich anderer ein. Diese Kohäsion trennt ein Gateway von einem Haufen Skripte: der Integrator muss keine Teile zusammenkleben; sie arbeiten mit einem fertigen Ablauf von "Rechnung → Zahlung → Benachrichtigung".

05Lösungsarchitektur

Payora ist auf mehrere Subdomains verteilt — so sind Rollen und Lasten physisch getrennt, und der Zugriff ist einfacher zu sichern:

• payora.money — die Landing-Page: Positionierung, Entwicklerdokumentation, Einstiegspunkte in das Dashboard.
• api.payora.money — die programmgesteuerte Schnittstelle: wo Geschäfte anrufen, um Rechnungen zu erstellen und ihren Status zu überprüfen.
• pay.payora.money — der gehostete Checkout: die Zahlungsseite, die der Käufer sieht.
• admin.payora.money — das Admin-Panel und das Händler-Dashboard: Projekte, Schlüssel, Rechnungsverlauf, Webhook-Einstellungen.

Diese Trennung ist nicht kosmetisch. Sie ermöglicht es uns, dem Zahlungsbildschirm und der API unterschiedliche Caching- und Sicherheitsrichtlinien zu geben, den Administrationsbereich zu isolieren und Teile bei Bedarf unabhängig zu skalieren oder zu extrahieren. Im Hintergrund befindet sich ein Server-Stack auf PHP 8.3, bereitgestellt in einer panelverwalteten Umgebung, hinter Cloudflare (DNS, TLS, Perimeterschutz).

Logisch besteht das System aus vier Blöcken: Anfrageaufnahme (die API und Validierung), Rechnungsbuchhaltung (Zustand, Status, Beträge und Fristen), Blockchain-Überwachung (Erkennung von Überweisungen an Rechnungsadressen), und Benachrichtigung (Erstellung und Versand von signierten Webhooks). Jedes Block besitzt seinen Teil des Zahlungslebenszyklus und kommuniziert mit den anderen über klare Grenzen.

Die Aufteilung pro Subdomain bringt auch einen betrieblichen Vorteil: Die öffentlich verfügbaren Landing- und Checkout-Seiten leben getrennt vom Admin-Bereich, dessen Zugang weiter eingeschränkt werden kann. Wenn ein Block in Zukunft zum Engpass wird — sagen wir, Blockchain-Überwachung, während die Anzahl der Rechnungen wächst — kann er verstärkt oder extrahiert werden, ohne den Rest zu berühren. Die Architektur wurde von Anfang an für Erweiterungen entworfen, nicht nur für einen einmaligen Start.

06Wie ein Zahlungsvorgang abläuft

Aus der Sicht des Integrators passt der gesamte Ablauf in ein paar Schritte, und die meisten davon erfolgen ohne Beteiligung des Shops:

• 1. Rechnungserstellung. Der Shop ruft die API auf: Betrag, Währung, Bestell-ID, Webhook-Adresse. Als Antwort — eine Rechnung mit einzigartigen Details und einem Link zum gehosteten Checkout.
• 2. Zahlung. Der Käufer landet auf dem Zahlungsbildschirm von Payora: Er sieht den Betrag, die Adresse, den QR-Code und den Timer. Er bezahlt von jeder Wallet.
• 3. Übertragungserkennung.Das Gateway überwacht die Rechnungsadresse und registriert die eingehende Überweisung, indem es den Betrag mit dem erwarteten vergleicht und akzeptable Abweichungen zulässt.
• 4. Bestätigung.Nach der erforderlichen Anzahl von Bestätigungen wechselt die Rechnung in den Status "bezahlt".
• 5. Signierter Webhook.Payora sendet dem Shop eine serverseitige Benachrichtigung mit dem Status und einer Signatur; der Shop überprüft die Signatur und führt seine Aktion aus – gibt die Waren frei, lädt ein Guthaben auf, gewährt Zugang.

Ein wichtiges Detail ist Idempotenz und Vertrauen. Der Shop darf niemals auf eine Benutzerumleitung zu einer "Danke für die Zahlung"-Seite vertrauen: die einzige Quelle der Wahrheit über Geld ist der signierte Webhook von Payora. Daher ist die tatsächliche Gutschrift immer an eine verifizierte Benachrichtigung gebunden, nicht an eine Aktion im Browser.

Warum ist das so wichtig? Eine Umleitung ist leicht zu fälschen oder kommt einfach nie an: Der Benutzer kann den Tab direkt nach dem Senden der Mittel schließen, die Verbindung verlieren oder manuell eine "Danke-Seite" öffnen, ohne etwas zu bezahlen. Wenn der Shop Waren bei einer Umleitung gewährt, ist er Missbrauch und Verlusten ausgesetzt. Der Webhook hingegen kommt serverseitig an, ist mit einem Geheimnis signiert und spiegelt den tatsächlichen Zustand der Rechnung wider – weshalb er, und nur er, als der "Freigabe"-Befehl dient. Wir machen dieses Prinzip zu einer Anforderung in der Dokumentation, nicht zu einer Empfehlung.

07Wesentliche Funktionen

Lassen Sie uns ansehen, was Payora nicht nur zu einer "Krypto-Akzeptanz" macht, sondern zu einem produktionsreifen Zahlungsgateway.

Eine REST-API

Die gesamte Integration basiert auf einer kleinen Anzahl von Methoden: eine Rechnung erstellen, ihren Status überprüfen, die Zahlungsdetails abrufen. Die Antworten sind vorhersehbar, Fehler sind maschinenlesbar. Der Entwickler muss sich nicht die Eigenheiten eines bestimmten Netzwerks merken – sie arbeiten mit dem Begriff "Rechnung", und Payora kümmert sich um die Netzwerkdetails.

Gehosteter Checkout

Die fertige Zahlungsseite nimmt eine ganze Schicht Arbeit vom Geschäft ab. Darauf sieht der Käufer den Betrag, die Adresse, einen QR-Code für seine Brieftasche und einen Timer bis zum Ablauf der Rechnung. Es ist sowohl bequemer für den Benutzer als auch sicherer: Das Gateway selbst generiert und zeigt die Details an, und das Geschäft spielt keine Rolle bei der Anzeige der Adresse.

Signierte Webhooks

Jede Benachrichtigung über eine Änderung des Rechnungsstatus ist mit dem Geheimnis des Händlers signiert. Das Geschäft überprüft die Signatur auf seiner Seite und vertraut erst dann dem Inhalt. So kann "bezahlt" nicht gefälscht werden, selbst wenn die Handler-Adresse bekannt ist.

Betrags- und Fristenlogik

Die Kurse schwanken, Benutzer runden, Netzwerke erheben eine Gebühr – daher kann das Gateway mit einer akzeptablen Abweichung des Betrags arbeiten, Teilzahlungen erfassen und Rechnungen korrekt bei Ablauf schließen. Dies nimmt die unangenehmste manuelle Arbeit vom Geschäft.

Status und der Lebenszyklus der Rechnung

Eine Rechnung in Payora durchläuft eine klare Reihe von Zuständen — von "erstellt" und "wartet auf Zahlung" bis "bezahlt", "unterbezahlt" oder "abgelaufen". Der Shop muss nicht raten, was vor sich geht: Der Status ist immer eindeutig, und die Übergänge zwischen den Zuständen sind deterministisch. Dies vereinfacht sowohl die Automatisierung auf der Seite des Shops als auch die Lösung von Streitigkeiten im Support — für jede Rechnung kann man sehen, in welchem Schritt sie sich befindet und warum sie dort gelandet ist.

Idempotenz und zuverlässige Zustellung

Das Netzwerk ist unzuverlässig, Handler stürzen ab, Antworten gehen verloren — daher sind Benachrichtigungen so gestaltet, dass eine wiederholte Zustellung die Logik des Shops nicht beeinträchtigt. Der gleiche Zahlungsfall kann sicher mehrere Male verarbeitet werden, ohne dass etwas doppelt gutgeschrieben wird. Für Geld ist dies entscheidend: Es ist besser, eine Benachrichtigung zweimal zu erhalten und sie korrekt zu deduplizieren, als die einzige zu verlieren und den Kunden ohne seine Waren zu lassen.

08Sicherheit und nicht verwahrendes Design

Das Kernprinzip von Payora ist nicht zum Verwalter zu werden. Das Geld des Käufers geht an Adressen, die vom Unternehmen selbst kontrolliert werden, während der Gateway-Server auf der Akzeptanzseite im "Nur-Beobachtungs"-Modus läuft: Er kann Adressen für Rechnungen berechnen und eingehende Überweisungen verfolgen, hält jedoch keine privaten Schlüssel, die verwendet werden könnten, um diese Mittel auszugeben.

Dies verschiebt das Bedrohungsmodell in eine günstige Richtung. Selbst im schlimmsten Fall eines Serverkompromisses hat der Angreifer keinen Zugriff auf das Geld — es gibt nichts, was man "mitnehmen" könnte. Die Webhook-Signierung schützt Shops vor gefälschten Benachrichtigungen, die Subdomain-Trennung verringert die Angriffsfläche, und der Perimeter wird von Cloudflare abgeschottet. Für das Unternehmen bedeutet dies etwas Einfaches: Die Kontrolle über die Mittel bleibt bei ihnen, nicht bei einem externen Dienst.

Darüber hinaus haben wir das Prinzip der geringsten Privilegien auf der Infrastrukturebene angewendet: ein dedizierter Systemaccount für den gesamten Dienst, Rollentrennung über Subdomains und Geheimnisse, die nur der Händler kennt. Je weniger Rechte und je weniger Daten jede Komponente hat, desto kleiner ist der Explosionsradius eines einzelnen Fehlers oder Lecks — und desto ruhiger ist es, ein Produkt zu betreiben, das mit Geld umgeht.

09TON und USDT: einzigartige Adressen

Payora akzeptiert TON und USDT im TON-Netzwerk — schnelle, gebührenarme Vermögenswerte, die für Online-Zahlungen praktisch sind. Aber eine Währung zu unterstützen, ist nur die halbe Arbeit. Die zweite, subtilere Hälfte ist, wie man eine spezifische Zahlung einer spezifischen Rechnung zuordnen.

Wir haben den Weg der einer einzigartigen Adresse pro Rechnung: Für eine neue Rechnung wird eine separate Empfangsadresse deterministisch abgeleitet. Wenn eine Überweisung dort ankommt, weiß das Gateway genau, zu welchem Auftrag sie gehört — ohne Memos, Zahlungsbemerkungen oder manuelle Zuordnungen, die so leicht verloren gehen können. Die Adressableitung ist so implementiert, dass der Server keine privaten Schlüssel benötigt, um Zahlungen zu akzeptieren: Er berechnet Adressen und überwacht sie, bleibt dabei schreibgeschützt.

Deterministische Ableitung betrifft auch die Wiederherstellbarkeit. Die Adresse jeder Rechnung kann aus den ursprünglichen Parametern neu berechnet werden, was bedeutet, dass das System nicht von einem fragilen "Adresse ↔ Auftrag"-Speicher abhängt: Die Verbindung wird aus der Ableitungslogik selbst wiederhergestellt. Für die Annahme von USDT-on-TON und nativen TON ist dies besonders praktisch — beide Währungen leben im selben Netzwerk, was das Überwachen vereinfacht und die Gebühren im Vergleich zu "schwereren" Ketten senkt.

10Unterzahlungen, Überzahlungen und Fristen

In der Krypto-Welt kommt "genau der Betrag auf der Rechnung" selten an. Der Kurs zwischen dem Vermögenswert und dem Fiat-Preis schwankt, Wallets runden, das Netzwerk behält eine Gebühr ein, und ein Benutzer kann um einen Bruchteil abweichen. Daher wurde das Gateway von Anfang an um die Idee der akzeptablen Abweichung: Eine kleine Differenz zwischen dem erwarteten und dem tatsächlichen Betrag zählt als korrekte Zahlung, und die Rechnung schließt sauber ab.

Explizite Unterzahlungen und Überzahlungen sind komplizierter. Wenn deutlich weniger ankommt, erhält die Rechnung den entsprechenden Status und der Laden entscheidet, was zu tun ist: auf eine Aufstockung warten, Rückerstattung oder teilweise schließen. Wenn mehr ankommt, wird auch dieser Fakt erfasst und dem Laden angezeigt, anstatt stillschweigend verschluckt zu werden. Die Logik ist so aufgebaut, dass kein echter Transfer aus dem Blickfeld gerät und jeder von ihnen eine klare Lösung hat.

Eine separate Angelegenheit ist Fristen. Eine Rechnung hat ein Lebenszeitfenster, während dessen sie bezahlt werden kann; beim Checkout ist dieses Fenster als Timer sichtbar. Sobald es abläuft, wechselt die Rechnung in den Status "abgelaufen", was aus zwei Gründen wichtig ist: Erstens driftet der Kurs zum Zeitpunkt der Zahlung nicht weit von dem festgelegten ab; zweitens erhält der Laden ein klares Signal, dass die Bestellung storniert oder neu erstellt werden kann. Alle diese Übergänge — Unterzahlung, Überzahlung, Ablauf — werden in Status und in den signierten Webhooks widergespiegelt, sodass der Integrator immer ein maschinenlesbares Bild davon hat, was passiert.

11Händler-Dashboard und Admin

Damit das Produkt eigenständig funktioniert, reicht eine API allein nicht aus — Sie benötigen eine Schnittstelle, über die der Händler seine Projekte verwaltet. Im Admin-Bereich (admin.payora.money) erstellt das Unternehmen Projekte, erhält Schlüssel und ein Geheimnis zum Signieren von Webhooks, konfiguriert die Handler-Adresse und Währungen und sieht die Rechnungshistorie mit Status.

Dies deckt alltägliche Szenarien ab, ohne den Gateway-Entwickler einzubeziehen: ein neues Projekt für eine neue Seite erstellen, einen Schlüssel neu ausstellen, überprüfen, ob eine bestimmte Zahlung eingegangen ist, eine strittige Rechnung untersuchen. Im Wesentlichen ist das Dashboard eine "Konsole" über alles, was die API programmatisch tut.

Jedes Händlerprojekt ist isoliert: Es hat eigene Schlüssel, eigenes Signaturgeheimnis, eigenen Währungssatz und eigene Webhook-Adresse. Dank dessen kann ein Eigentümer mehrere völlig unterschiedliche Seiten von einem einzigen Dashboard aus betreiben, ohne ihre Zahlungen zu vermischen oder einem Projekt Zugriff auf die Daten eines anderen zu gewähren. Die Rechnungshistorie mit klaren Status verwandelt das Dashboard in ein Support-Tool: Für jede Zahlung können Sie immer sehen, in welchem Schritt sie sich befindet, welcher Betrag erwartet und eingegangen ist und welcher Webhook gesendet wurde.

12Integrationen: erprobte Lösungen

Payora existiert nicht im Vakuum — es wurde als gemeinsame Zahlungsschicht für ein ganzes Ökosystem von Projekten entwickelt. Einer der ersten echten Integratoren ist der Freelance-Marktplatz 24freelance: Eine Aufladung des Benutzerkontos erfolgt über Payora. Der Shop erstellt eine Rechnung, der Benutzer bezahlt an der gehosteten Kasse, und nach Bestätigung sendet Payora einen signierten Webhook, auf dem das Guthaben automatisch gutgeschrieben wird.

Diese Integration ist ein guter Praxistest der Architektur: Sie zeigte, dass ein neues Projekt schnell mit dem Gateway verbunden werden kann und dass das gewählte Modell (Rechnung → Checkout → signierter Webhook → Gutschrift) auf ein echtes Produkt ohne Umgehungen abgebildet werden kann. Jeder verbundene Dienst wird als separates Händlerprojekt mit eigenen Schlüsseln registriert, was sie voneinander isoliert.

Der Hauptwert der ersten Integration besteht darin, dass sie genau dem Pfad folgte, der in das Produkt eingebaut ist — keine Umwege, keine "vorübergehenden" Hacks. Eine Guthabenaufladung ist ein hervorragendes Testfeld, da die Zuverlässigkeit der Gutschrift hier entscheidend ist: Ein Fehler würde entweder verlorenes Geld für den Benutzer oder eine ungerechtfertigte Guthabengutschrift bedeuten. Die Tatsache, dass der gesamte Ablauf auf einer Bindung an den signierten Webhook lief, bestätigte die zentrale Hypothese: Ein einmal bereitgestelltes Gateway wird tatsächlich zu einer gemeinsamen Zahlungsschicht, mit der neue Projekte als Händler verbunden werden, anstatt jedes Mal von Grund auf neu geschrieben zu werden.

13Technologiestack und Infrastruktur

Für Payora haben wir eine dedizierte, isolierte Umgebung eingerichtet — mit eigenem Systembenutzer, Subdomains und Richtlinien. Es ist sowohl aus Sicherheitsgründen sauberer als auch einfacher zu betreiben.

• Backend — PHP 8.3: die API, Rechnungsbuchhaltung, Erstellen und Senden von Webhooks, Statuslogik.
• Blockchain-Schicht — Arbeiten mit TON und USDT-on-TON: Berechnung von Rechnungsadressen und Überwachung von Überweisungen im Nur-Lese-Modus.
• Infrastruktur — ein separates isoliertes Konto mit api/pay/admin Subdomains, hinter Cloudflare (DNS, TLS, Schutz) und mit gültigen Let's Encrypt-Zertifikaten.
• Sicherheit — Rollentrennung über Subdomains, Signieren von Geheimnissen auf der Händlerseite, keine privaten Schlüssel zur Annahme auf dem Server.

Die Wahl von PHP 8.3 hier ist pragmatisch: eine ausgereifte, schnelle Plattform, auf der es bequem ist, die API, das serverseitige Rendering des Checkouts und den Admin-Bereich in einer vorhersehbaren Umgebung zu hosten. Cloudflare schließt den Perimeter und übernimmt die TLS-Terminierung und den grundlegenden Schutz, während Let's Encrypt gültige Zertifikate über alle Subdomains bereitstellt. Die gesamte Umgebung soll selbstgehostet sein: der Eigentümer implementiert sie auf seiner eigenen Infrastruktur und behält die volle Kontrolle — was direkt aus der nicht verwahrenden Natur des Produkts folgt.

14Design und UX

Ein Fintech-Produkt verkauft Vertrauen, daher haben wir Payoras Schnittstellen ruhig und technisch gestaltet, frei von visuellem Lärm. Die Landingpage erklärt den Wert in wenigen Sekunden: was es ist, für wen es gedacht ist, wie es sich unterscheidet (selbstgehostet, nicht verwahrend) und wie man anfängt. Die Dokumentation und die Einstiegspunkte zum Dashboard sind nur einen Klick entfernt.

Besondere Aufmerksamkeit galt dem Zahlungsbildschirm. Dies ist der Moment, in dem ein Benutzer Geld ausgibt, und jede Unklarheit kostet Konversion. Daher wird beim gehosteten Checkout alles auf das Wesentliche reduziert: der Betrag, die Adresse, der QR-Code, der Timer und ein klarer Status. Je weniger Unordnung auf diesem Bildschirm, desto höher die Rate der bis zum Ende durchgeführten Zahlungen.

Wir haben die Checkout-UX als Teil des technischen Problems betrachtet, nicht als "Styling". Jedes Element auf dem Zahlungsbildschirm löst ein konkretes Vertrauensproblem: Eine sichtbare Adresse und QR-Codes nehmen die Angst vor "wo zahle ich?", der Timer beseitigt die Unsicherheit "wie lange habe ich?" und ein Live-Rechnungsstatus beantwortet die Hauptfrage des Käufers – "Ist mein Geld angekommen?" Zusammen reduziert dies die Anzahl der abgebrochenen Zahlungen und Supportanfragen, was für ein Zahlungsprodukt ebenso wichtig ist wie technische Zuverlässigkeit im Hintergrund.

15Wie wir gearbeitet haben

Wir haben das Projekt in aufeinanderfolgenden Phasen durchgeführt und bei jedem Schritt ein Ergebnis demonstriert:

• Forschung.Wir haben Szenarien zur Akzeptanz von Kryptowährungen, Schmerzpunkte, Sicherheitsanforderungen und das Modell "Rechnung → Zahlung → Benachrichtigung" skizziert.
• Architektur.Wir haben die Subdomain-Aufteilung, das API-Format, das Rechnungsstatus-Schema und den Webhook-Signierungsmechanismus entworfen.
• Kernentwicklung.Wir haben die API, die Rechnungsbuchhaltung, die Adressableitung und die Überwachung von Übertragungen, den gehosteten Checkout und die Webhook-Zustellung erstellt.
• Integration und Einarbeitung.Wir haben das erste echte Projekt (die Aufladung des 24freelance-Guthabens) verbunden und den gesamten Ablauf in der Praxis getestet.
• Start und Infrastruktur.Wir haben die Umgebung hinter Cloudflare mit Subdomains und Zertifikaten bereitgestellt und die Landingpage sowie die Dokumentation erstellt.

Diese Reihenfolge ist nicht zufällig: Zuerst haben wir den Vertrag – das API-Format, das Status-Schema und die Webhook-Signierung – festgelegt und erst dann die Implementierung darum herum aufgebaut. Dadurch konnten wir den Kern und die Integration fast parallel entwickeln: Während die Serverlogik zusammengestellt wurde, war der Vertrag bereits stabil genug, um den ersten Integrator vorzubereiten. Die Demos in jeder Phase ermöglichten es, Unstimmigkeiten frühzeitig zu erkennen und zu beheben, bevor sie im Code "fest" wurden.

16Das Ergebnis

Was wir erhalten haben, ist kein "Krypto-Akzeptanz-Skript", sondern ein eigenständiges Zahlungsgateway, das Sie selbst bereitstellen und mit beliebig vielen Projekten verbinden können.

• Die Akzeptanz von Krypto-Zahlungen ist in einem Abend verbunden — eine Anfrage zur Erstellung einer Rechnung und ein Webhook-Handler.
• Das Unternehmen behält die volle Kontrolle über die Mittel: nicht verwahrend und selbst gehostet.
• Signierte Webhooks und einzigartige Adressen beseitigen ganze Klassen von Fehlern: gefälschte Benachrichtigungen und verlorene Zahlungen.
• Die Architektur ist durch eine echte Integration bewährt und bereit, auf neue Projekte zu skalieren.

Aber das Hauptresultat liegt nicht in einzelnen Zahlen — es liegt im Wandel des Modells. Früher bedeutete jede neue Seite, die der Eigentümer baute, ein neues Zahlungsmodul von Grund auf; jetzt ist es einfach ein weiteres Händlerprojekt in einem gemeinsamen Gateway. Die Zahlungslogik hörte auf, eine einmalige Aufgabe zu sein, und wurde zu einem wiederverwendbaren Vermögenswert, der umso mehr rentiert, je mehr Projekte sich damit verbinden.

17Erkenntnisse

Payora ist ein Beispiel dafür, wie ingenieurtechnische Strenge ein "trendy Thema" in ein funktionierendes Werkzeug verwandelt. Das Wertvollste hier ist nicht, dass das Produkt "Krypto akzeptiert", sondern wie dass es dies tut: ohne Verwahrungsrisiko, mit vertrauenswürdigen Benachrichtigungen und mit vorhersehbarer Rechnungslogik. Es sind genau diese unglamourösen, aber kritischen Details, die ein produktionsreifes Zahlungsgateway von einer weiteren handgefertigten Akzeptanz trennen.

Für uns war dies ein Projekt an der Schnittstelle von Fintech, Blockchain und Infrastruktur — genau die Art von Arbeit, bei der sowohl Produktdenken als auch technische Disziplin wichtig sind. Wenn Sie eine Zahlungsakzeptanz, eine Blockchain-Integration oder einen komplexen Service mit einer klaren API und einem Dashboard benötigen, wissen wir, wie wir das bis zur Markteinführung umsetzen können.

Und noch eine weitere, methodischere Erkenntnis. Die besten Fintech-Lösungen betreffen fast immer das, was Sie nicht auf dem Bildschirm sehen können: das Bedrohungsmodell, die Idempotenz, was als die einzige Quelle der Wahrheit über Geld zählt. Diese Entscheidungen werden einmal, zu Beginn, getroffen und schützen das Produkt dann jahrelang vor ganzen Klassen von Problemen. Genau so gehen wir die Arbeit an — zuerst die richtigen Grenzen und Verträge, und erst dann alles andere.