Sicherheit

Paymos ist ein verwahrender Zahlungsanbieter — wir halten die Schlüssel, die Ihre Mittel on-chain bewegen. Damit steht für jeden Händler eine berechtigte Frage im Raum: Was hindert Paymos daran, mein Geld zu nehmen, und was passiert, wenn etwas schiefgeht?

Diese Seite beantwortet beides — zuerst als kurze Liste von Zusagen, dann in klarer Sprache mit der Begründung dahinter. Sie beschreibt die Garantien, die die Plattform Ihnen gibt, und was jede davon Ihnen bringt, nicht einen internen Bauplan. Wo ein Detail Teil der öffentlichen API ist (wie Sie eine Anfrage signieren, wie Sie einen Webhook prüfen), dokumentieren wir es genau, weil Sie es für die Anbindung brauchen.

---

Warum Ihre Mittel sicher sind

Kontrollierte Ziele und isolierte Signatur

• Isolierte Signatur-Infrastruktur. Paymos betreibt Verwahrung und Signaturweg abseits der öffentlichen Weboberfläche. Das ist verwaltete Verwahrung, keine direkte Schlüsselkontrolle durch den Händler.
• Verpflichtende Freigabeliste. Mittel können ausschließlich an Ziele gehen, die Sie vorab freigegeben haben. Selbst eine vollständige Kompromittierung Ihrer API-Zugangsdaten kann keine neue Auszahlungsadresse erfinden.
• Standardmäßig beim Inhaber. Die Möglichkeit auszuzahlen und die Freigabeliste zu bearbeiten liegt beim Kontoinhaber, sofern Sie sie nicht ausdrücklich delegieren — und jede Erteilung wird protokolliert.
• Sie zahlen nach Ihrem Takt aus. Ihr Guthaben gehört Ihnen in dem Moment, in dem eine Zahlung Finalität erreicht. Wir sperren keine Mittel. Zahlen Sie stündlich aus, täglich oder nie: Zwischen der Anforderung und der gesendeten Transaktion liegt kein Sammelfenster und keine Warteschlange, und wie lange sie danach unterwegs ist, bestimmt die Chain selbst.
• Getrennte Guthaben. Das Guthaben jedes Händlers wird eigenständig geführt. Wir bündeln keine Händlermittel und verleihen oder verpfänden sie nicht weiter.

Ihr Geld verschwindet nicht stillschweigend

• Wir schreiben ab einer Tiefe gut, die wir je Netzwerk und Betrag wählen — tief genug, dass eine Reorganisation selten ist, nie tief genug, um sie auszuschließen.
• Keine Rückholung. Sobald wir Ihnen melden, dass eine Zahlung bestätigt ist, machen wir das nie rückgängig. Fällt eine bestätigte Zahlung später einer Reorganisation zum Opfer, trägt Paymos den Verlust — nicht Sie.
• Auszahlungen können nicht doppelt gehen. Jede Auszahlung trägt Ihren eigenen Idempotenzschlüssel.
• Gestaffelte Sperren können ein einzelnes Asset automatisch anhalten, wenn die Realität on-chain vom Hauptbuch abweicht.
• Die Liquidität wird vorab geprüft, sodass eine Auszahlung sofort scheitert, statt hängenzubleiben.
• Manipulationssichere Aufzeichnungen: Jede privilegierte Aktion wird protokolliert, wobei Geheimnisse und Signaturen vor dem Schreiben aus dem Eintrag entfernt werden.

Der Rest dieser Seite erklärt jeden Punkt in klaren Worten. Wenn Sie die Begriffe HMAC oder SSRF schon gesehen haben und sich fragten, was sie bedeuten — lesen Sie weiter.

---

Bedrohungsmodell

Wir entwerfen gegen:

• Mittel im Ruhezustand — Schlüssel, die Guthaben on-chain bewegen könnten
• Mittel in Bewegung — Freigabe von Auszahlungen und Manipulation des Ziels
• API-Zugriff — Diebstahl von Zugangsdaten, Wiedereinspielung von Anfragen, Ausweitung des Geltungsbereichs
• Webhook-Zustellung — gefälschte Inhalte und die Nutzung unserer Infrastruktur als SSRF-Sprungbrett in Ihre
• Betriebsrisiko — versehentlich zerstörerische Aktionen, Wettläufe über mehrere Server, Lücken im Prüfprotokoll

Ausdrücklich außerhalb des Rahmens: die Wallet-Sicherheit Ihrer Kunden (sie halten ihre eigenen Schlüssel), das Risiko auf Empfängerseite nach der Signatur einer Auszahlung (On-Chain-Transaktionen sind final), Dienste Dritter, die Sie neben Paymos betreiben, und Social Engineering gegen Ihr Team.

---

Signatur von Auszahlungen und Kontrolle der Ziele

Das Problem. Mittel auf einer Blockchain werden von Signaturschlüsseln kontrolliert. Ein gestohlener Zugang, ein geändertes Ziel oder ein kompromittierter Signatur-Host kann deshalb zum Geldverlust führen, wenn die umgebenden Kontrollen nicht im Zweifel sperren.

Was Paymos tut. Ausgehende Transaktionen werden auf isolierter Infrastruktur signiert. Eine Auszahlung kann nur an eine Adresse gehen, die bereits in der Freigabeliste des Händlers steht; eine leere Liste deaktiviert Auszahlungen vollständig. Die Liste zu ändern ist ein eigener Vorgang und wird protokolliert. Ist für den Zugang ein zweiter Faktor hinterlegt, verlangt diese Änderung zusätzlich eine erneute Authentifizierung. Ohne zweiten Faktor gibt es nichts abzufragen — diese Schicht beginnt an dem Tag, an dem Sie sie einrichten.

Der Betrieb kann jeden ausgehenden Transfer stoppen oder ein einzelnes Paar aus Asset und Netzwerk einfrieren, während ein Vorfall untersucht wird. Jede Auszahlung trägt außerdem einen Idempotenzschlüssel, sodass die Wiederholung derselben Anfrage keine zweite Auszahlung erzeugt.

Es bleibt verwahrende Infrastruktur: Paymos betreibt den Signaturweg. Kontrolle der Ziele, Sperren, Prüfprotokolle und der Abgleich mit dem Hauptbuch senken das Risiko rund um die Verwahrung; sie machen daraus keine nicht-verwahrende oder schwellenbasierte Verwahrung.

Jede Rechnung erhält ihre eigene eindeutige Einzahlungsadresse, sodass der Abgleich eindeutig ist. Zahlungen und Auszahlungen in der Sandbox berühren keine echten Mittel, sodass Sie die Anbindung testen können, ohne Transfers in der Produktion auszulösen.

---

HMAC — woran die API erkennt, dass eine Anfrage wirklich von Ihnen kommt

HMAC steht für Hash-based Message Authentication Code. Furchteinflößender Name, einfache Idee.

Das Problem. Ihr Server sendet uns „erstelle eine Auszahlung über 1.000 $“. Wir haben zwei Fragen: Sind Sie das wirklich oder ein Betrüger? Und wurde die Anfrage unterwegs verändert — Betrag oder Adresse getauscht? Legten Sie einfach ein Passwort in die Anfrage, würde jeder, der den Verkehr mitschneidet, es stehlen und in Ihrem Namen Anfragen senden.

Was HMAC leistet. Sie und wir teilen ein Geheimnis (Ihr API Secret). Für jede Anfrage berechnen Sie einen „Fingerabdruck“ (eine Signatur) — einen Hash über den Inhalt der Anfrage zusammen mit dem Geheimnis. Sie senden die Anfrage und den Fingerabdruck, aber nicht das Geheimnis. Wir berechnen denselben Fingerabdruck mit unserer Kopie des Geheimnisses. Stimmen beide überein, sind Sie es wirklich und nichts wurde verändert — ändern Sie ein einziges Zeichen, und der Fingerabdruck passt nicht mehr.

Analogie. Ein Wachssiegel auf einem Brief. Das Geheimnis ist Ihr eigener Siegelstempel. Jeder sieht das Siegel, aber ohne den Stempel lässt es sich nicht fälschen. Und wird der Brief geöffnet und umgeschrieben, passt das Siegel nicht mehr zum Inhalt.

Der entscheidende Punkt: Das Geheimnis selbst wandert nie über das Netz. Selbst wer Ihren gesamten Verkehr aufzeichnet, kann daraus weder das Geheimnis gewinnen noch eine neue Anfrage bauen — er hält nur Signaturen für Anfragen, die Sie ohnehin schon gesendet haben. (SHA-256 ist die konkrete „Mühle“, die jede Eingabe zu einem Fingerabdruck fester Länge mahlt, der sich nicht zurückrechnen lässt.)

Das genaue Format (für Ihre Anbindung)

Jede authentifizierte Anfrage trägt zwei Header:

Authorization: HMAC-SHA256 {api_key_id}:{base64(signature)}
X-Request-Timestamp: {unix_seconds}

Die Signatur ist HMAC-SHA256 über eine kanonische Zeichenkette:

{timestamp}\n{METHOD}\n{path}\n{query}\n{sha256_hex_lower(body)}

Ein leerer Körper trägt an dieser Stelle eine leere Zeichenkette bei — er wird nicht gehasht; Query-Parameter werden genau so signiert, wie sie in der URL stehen. Alle Einzelheiten stehen auf der Seite Authentifizierung.

Schutz vor Wiedereinspielung

Könnte ein Angreifer eine alte Anfrage erneut senden, die er mitgeschnitten hat — „erstelle Auszahlung“ hundertmal wiederholen? Der Zeitstempel ist Teil der Signatur, und wir weisen jede Anfrage ab, deren X-Request-Timestamp mehr als ±5 Minuten von der Serverzeit abweicht (Abweisung mit 401). Eine mitgeschnittene Anfrage lebt fünf Minuten, dann ist sie tot. Zusammen mit der Idempotenz (unten) sendet auch eine innerhalb dieses Fensters wiederholte „erstelle Auszahlung“ kein zweites Mal Mittel.

Analogie. Eine Eintrittskarte mit fünf Minuten Einlassfenster — die von gestern funktioniert nicht.

Zeitkonstanter Vergleich

Wenn wir zwei Signaturen vergleichen, bricht ein naiver Vergleich beim ersten falschen Zeichen ab — und die Antwortzeit würde verraten, wie viele Zeichen bereits stimmen, sodass ein Angreifer Byte für Byte raten könnte. Wir vergleichen zeitkonstant: Ein „Nein“ dauert exakt gleich lang, egal wie viel Sie erraten haben.

Analogie. Ein Zahlenschloss, das gleich schnell „Nein“ sagt, ob Sie eine Ziffer richtig hatten oder fünf. Sie merken nicht, dass Sie „wärmer“ werden.

Schlüsselarten und Wechsel

Zwei Schlüsselarten, jede auf einen festen Geltungsbereich festgelegt, bei jedem Aufruf serverseitig durchgesetzt:

• Payment-Schlüssel — alles auf der Eingangsseite: Rechnungen erstellen und lesen, Zahlungskanäle verwalten und deren Einzahlungen lesen. Kann keine Guthaben lesen und keine Auszahlungen erstellen.
• Payout-Schlüssel — Auszahlungen erstellen, lesen und stornieren sowie Guthaben lesen. Kann keine Rechnungen erstellen und keinen Zahlungskanal erreichen.

Geheimnisse wechseln ohne Ausfall: Sie erzeugen ein neues Geheimnis, während das vorherige bis previous_secret_expires_at gültig bleibt — genau 24 Stunden nach dem Wechsel. Das Fenster steht fest und lässt sich nicht als Parameter setzen. Solange es offen ist, werden beide Geheimnisse akzeptiert, danach nur noch das neue.

---

Webhook-Sicherheit — dasselbe HMAC, andersherum

Das HMAC oben schützt Ihre Anfragen an uns. Ein Webhook ist unser Klopfen an Ihrer Tür („Rechnung bezahlt“). Derselbe Kniff, umgekehrt: Wir signieren jeden Webhook mit dem Geheimnis Ihres Endpunkts, und Sie prüfen die Signatur, bevor Sie ihm vertrauen. Sonst könnte jeder, der Ihre Webhook-URL erfährt, ein falsches „bezahlt“-Ereignis senden und Sie zur Auslieferung verleiten.

X-Webhook-Signature: t={unix_seconds},v1={hex_hmac}

Der signierte Inhalt ist {timestamp}.{request_body}. Das Verfahren entspricht dem von Stripe, sodass Bibliotheken zur Prüfung von Stripe-Webhooks hier fast unverändert funktionieren; während eines Geheimniswechsels senden wir beide Signaturen im selben Header. Siehe Webhooks prüfen.

SSRF-Schutz

SSRF steht für Server-Side Request Forgery. Sie hinterlegen eine Webhook-URL, und unsere Server rufen sie auf. Ein cleverer Angreifer richtet die URL nicht nach außen, sondern in unser Netz — auf eine Cloud-Metadaten-Adresse oder ein internes Panel —, sodass unser Server sie stellvertretend abruft und Paymos zum Stellvertreter für Dinge wird, die nur unser Netz sieht.

Das verhindern wir: Ein Webhook-Ziel wird geprüft, ob es auf eine öffentliche Adresse auflöst — Loopback, private, interne und Cloud-Metadaten-Bereiche werden abgewiesen —, und die Verbindung wird an die geprüfte Adresse gebunden, sodass kein Zeitfenster für DNS-Rebinding entsteht. Weiterleitungen werden abgelehnt. Ein Ziel, das die Prüfung nicht besteht, wird sofort verworfen, sodass Sondieren kein Zustellbudget verbraucht.

Analogie. Ein Kurier, der nur an echte externe Adressen liefert, sich weigert, etwas „in den Serverraum dieses Hauses“ zu tragen, die Adresse vor dem Losfahren prüft und einen Zettel „liefere es doch bitte dorthin“ ignoriert.

Regeln der Zustellung

Webhook-URLs müssen HTTPS nutzen (wird beim Speichern des Endpunkts erzwungen). Die Zustellung erfolgt mindestens einmal — entdoppeln Sie auf Ihrer Seite über die Ereignis-ID (so machen es auch Stripe, GitHub und PayPal). Fehlgeschlagene Zustellungen werden über 11 Versuche und rund 16 Stunden mit exponentiellem Backoff wiederholt — der vollständige Zeitplan steht unter Zustellung und Wiederholungen —, danach als fehlgeschlagen markiert und aus dem Dashboard erneut sendbar. Jeder Versuch hat seine eigene Zeitgrenze.

---

Schutz von Auszahlungen — mehrere Schlösser hintereinander

Geld hinauszubewegen ist der Punkt, an dem ein verwahrender Anbieter steht oder fällt, deshalb hat er die meisten Schichten:

• Freigabeliste (verpflichtend). Eine Auszahlung geht ausschließlich an Adressen, die Sie vorab freigegeben haben. Ist die Liste für eine Netzwerkfamilie leer, lässt sich gar keine Auszahlung anlegen — es gibt keine Abkürzung nach dem Muster „die erste Auszahlung setzt die Adresse“. Selbst mit gestohlenen Schlüsseln können Mittel nur auf Ihre eigenen Wallets gehen, womit sich der Diebstahl nicht mehr lohnt. Analogie: ein Konto, das nur an eine vorab registrierte Empfängerliste überweisen kann — ein Dieb mit Ihrem Passwort kann keinen neuen Empfänger eintragen.
• Nur der Inhaber. Auszahlungen anzulegen und die Freigabeliste zu bearbeiten gehört dem Kontoinhaber, nicht einer gewöhnlichen Administratorrolle. Sie müssen es einem Nicht-Inhaber ausdrücklich erteilen, und diese Erteilung ist nachvollziehbar.
• Zwei-Faktor (2FA). Ein sechsstelliger Code aus einer Authenticator-App, der alle 30 Sekunden wechselt; ein hinterlegter Passkey zählt ebenso als zweiter Faktor. Er ist nicht voreingestellt, sondern wird von Ihnen eingerichtet — und genau damit schaltet sich die erneute Authentifizierung scharf: Die Freigabeliste zu ändern, die IP-Liste eines API-Schlüssels zu bearbeiten oder den zweiten Faktor abzuschalten verlangt dann im Moment der Ausführung einen frischen Code.
• Sperren (Schutzschalter). Wir können alles auf einmal sperren, ein einzelnes Token in einem einzelnen Netzwerk oder einen einzelnen Händler. Eine Sperre je Asset kann automatisch greifen, wenn die Guthaben on-chain über ein sicheres Maß hinaus vom Hauptbuch abweichen.
• Vorab-Prüfung der Liquidität. Eine Auszahlung wird vor der Annahme gegen die verfügbaren Mittel geprüft (einschließlich Gebühren), sodass sie sofort mit einer klaren Fehlermeldung scheitert, statt hängenzubleiben.
• Idempotenz. Ihre Bestellkennung ist der Idempotenzschlüssel — senden Sie sie zweimal, bekommen Sie dieselbe eine Auszahlung zurück, nie einen zweiten Transfer. Analogie: ein Garderobenschein; geben Sie denselben Schein zweimal ab, bekommen Sie denselben einen Mantel.
• Wettlaufsichere Erstellung. Gleichzeitige Auszahlungsanfragen desselben Kontos werden serverseitig serialisiert, sodass zwei parallele Aufrufe nicht an derselben Guthabenprüfung vorbeischlüpfen können.

---

Autorisierung und Abgrenzung

• Jede Anfrage wird serverseitig geprüft, bevor sie irgendetwas tut: Die Umgebung muss passen (Sandbox oder Produktion), die Art des Aufrufers muss zulässig sein, der Geltungsbereich der Zugangsdaten muss die Operation abdecken, und die Ressource muss dem Aufrufer gehören. Diese Prüfungen sind die eigentliche Grenze — Bedienelemente in der Oberfläche sind nur Hinweise.
• 404 statt 403. Existiert eine Ressource nicht oder existiert sie, gehört aber nicht Ihnen, bekommen Sie 404. So kann ein Angreifer nicht unterscheiden zwischen „diese ID ist echt, aber nicht Ihre“ und „diese ID gibt es nicht“. Analogie: ein Portier, der „diese Person gibt es nicht“ sagt, ob sie nun nicht existiert oder dort wohnt und Sie nur nicht hinaufdürfen.
• Ihre Identität kommt aus Ihren Zugangsdaten, nie aus dem Anfragekörper. Die Kennung eines anderen in eine Anfrage zu schreiben bewirkt nichts — Sie können nicht im Namen eines anderen Händlers handeln, indem Sie eine ID fälschen.
• Feingranulare Berechtigungen. Der Zugriff wird über fein abgestufte, rollenbasierte Berechtigungen gesteuert (etwa auszahlen, Guthaben sehen, Webhooks verwalten), jede einzeln erteilbar. Die serverseitige Prüfung ist die Grenze; das Dashboard spiegelt sie nur.

---

Anfragegrenzen

Jeder Händler hat eigene Anfragegrenzen. Überschreiten Sie eine, erhalten Sie 429 Too Many Requests mit einem Retry-After-Header, sodass eine einzelne fehlerhafte Anbindung nur den eigenen Durchsatz beeinträchtigt, nicht die Plattform oder andere Händler.

---

Finalität on-chain — warum Ihr Geld nicht verschwindet

Auf einer Blockchain „erscheint“ eine Transaktion schnell in einem Block, aber die Chain kann die jüngste Historie noch umschreiben (eine Reorganisation) — und was bestätigt aussah, kann verschwinden. Wie feuchte Tinte: geschrieben, aber noch verwischbar.

Finalität heißt, so lange zu warten, bis die Transaktion tief genug begraben ist, dass sie sich nicht mehr umkehren lässt. Die Tinte ist getrocknet. Wir warten die für das jeweilige Netzwerk angemessene Finalität ab, bevor wir Ihr Guthaben bewegen. Auf Chains, bei denen Finalität eine Frage der Bestätigungstiefe ist, skaliert diese Tiefe mit dem Betrag — kleine Beträge sind schnell durch, große warten länger; Chains mit nativer sofortiger Finalität rechnen ab, sobald der Block final ist. Diese Schwellen sind auf die Netzwerkbedingungen abgestimmt, nicht fest.

Die zentrale Zusage: Fällt eine bereits bestätigte Zahlung später einer Reorganisation zum Opfer (sehr selten), trägt Paymos den Verlust, nicht Sie. Sobald ein Bestätigungs-Webhook feuert, können Sie sofort handeln. Als Zugabe gibt es keine Rückbuchungen (anders als bei Karten, die ein Käufer noch Monate nach dem Verkauf umkehren kann), und verspätete Zahlungen sind konstruktionsbedingt unmöglich — eine Zahlung, die nach Ablauf einer Rechnung bestätigt wird, schreibt dieser abgelaufenen Rechnung nichts gut.

---

Datenschutz

In der Übertragung: Der gesamte Verkehr läuft über TLS 1.2+, HSTS ist in der Produktion aktiv, und unverschlüsselte Anfragen werden auf HTTPS umgeleitet.

Im Ruhezustand: Sitzungs-Cookies sind HttpOnly, Secure, SameSite=Strict; Anmeldelinks sind einmalig nutzbar, laufen schnell ab und sind im Ruhezustand verschlüsselt.

Schutz vor Fälschung: Zustandsverändernde Aktionen im Dashboard tragen ein Anti-Forgery-Token, das zusammen mit SameSite=Strict-Cookies Cross-Site Request Forgery abschwächt.

Prüfprotokoll: Jede privilegierte Aktion hält fest, wer sie ausgeführt hat, was lief, wie es ausging und wann. Sensible Werte — Geheimnisse, Passwörter, Token, Hashes, Signaturen — werden vor dem Speichern des Eintrags geschwärzt, erzwungen beim Schreiben.

---

Betriebliche Belastbarkeit

• Sicherheit über mehrere Server. Der Betrieb auf mehreren Servern verarbeitet eine Zahlung, Auszahlung oder einen Webhook nie doppelt — gleichzeitige Arbeit am selben Vorgang wird so abgestimmt, dass sie genau einmal geschieht. Durch automatisierte Tests belegt, nicht angenommen.
• Datenschutzfreundliche Fehlermeldungen. Absturzberichte werden von personenbezogenen Daten und Anfrageinhalten bereinigt, bevor sie unsere Systeme verlassen.
• Selbstheilende Infrastruktur. Automatische Gesundheitsprüfungen nehmen eine fehlerhafte Instanz aus dem Verkehr.
• Sichere Schemaänderungen. Datenbankmigrationen laufen einmal, in Reihenfolge, und nur vorwärts — wir führen keine zerstörerischen Rückabwicklungen gegen Produktionsdaten aus.

---

Regeltreue und Umgang mit Daten

Kein KYC zum Start. Sie können sich registrieren und testen, ohne Nachweise zu Identität, Adresse oder wirtschaftlich Berechtigten einzureichen, und Paymos erhebt solche Nachweise auch nicht von Ihren Kunden. Paymos prüft Ihr Geschäft nicht, kontrolliert keine Lizenzen, bewertet keine Händlerkategorien und führt keine Sanktionsprüfung Ihrer Kunden durch; diese Pflichten bleiben beim Händler. Wir können später KYC/KYB anfordern, wenn Aktivitäten eine manuelle Prüfung erfordern, Kontogrenzen überschritten werden oder eine zuständige Behörde es verlangt, wie in unserer AML/KYC-Richtlinie beschrieben.

Daten auf Kundenseite. Von Ihren Kunden erhebt Paymos im Checkout konstruktionsbedingt keine personenbezogenen Daten — keine E-Mail-Adresse, Telefonnummer, keinen Namen, keine Kartendaten. Der Ablauf ist: Rechnung → Zahlungsseite → Wallet zahlt → fertig. Wir sehen Wallet-Adressen und Beträge, keine Identitäten, sodass Ihr Risiko nach DSGVO oder CCPA über Paymos praktisch bei null liegt.

Daten auf Händlerseite. Für Ihr Konto halten wir Firmenname, Kontakt-E-Mail, Land und Projekt-Metadaten (Webhook-URLs, Kennungen der API-Schlüssel). Ein Löschverlangen nach DSGVO löst eine Löschmarkierung für 30 Tage und danach die endgültige Entfernung aus; im Prüfprotokoll bleibt nur ein Hash des gelöschten Eintrags.

Speicherort der Daten. Die primären Daten liegen in der EU. Enterprise-Verträge können eine bestimmte Region festlegen — sprechen Sie uns an.

---

Was wir nicht tun

• Wir behaupten nichts, was wir nicht gebaut haben. Diese Seite beschreibt das System, wie es ausgerollt ist. Vorhaben aus der Roadmap stehen erst hier, wenn sie ausgeliefert sind.
• Wir verwahren nicht länger als nötig. Mittel erreichen Ihr Guthaben, sobald eine Zahlung bestätigt ist; wann Sie auszahlen, entscheiden Sie.
• Wir bündeln keine Händlerguthaben. Jedes Guthaben wird getrennt geführt. Die Zahlungsunfähigkeit oder ein Streitfall eines Händlers kann die Mittel eines anderen nicht berühren. Genau das Bündeln in einen gemeinsamen Topf hat Börsen wie FTX versenkt.
• Wir versprechen keine Sicherheit auf Empfängerseite. Sobald eine Auszahlung signiert ist, ist die Transaktion on-chain und final. Die Freigabeliste verhindert Tippfehler und Schlüsseldiebstahl — sie kann nicht prüfen, ob ein von Ihnen freigegebenes Ziel sich anständig verhält.

---

Eine Schwachstelle melden

Senden Sie Meldungen an [email protected].

• Eingangsbestätigung: innerhalb von zwei Werktagen nach einer vollständigen Meldung
• Geltungsbereich: die Produktion unter paymos.io und *.paymos.io, die produktive REST-API sowie die von Paymos veröffentlichten SDKs und CMS-Plugins
• Außerhalb des Geltungsbereichs: Denial of Service über Anfragegrenzen, Social Engineering, Dienste Dritter (Ihr CDN, Ihr Hosting-Anbieter und Ähnliches)
• Bug-Bounty: derzeit kein öffentliches Programm; die vertrauliche Meldung wesentlicher Funde wird im Einzelfall vergütet, auf Wunsch mit Nennung.

Bitte testen Sie nicht gegen Konten anderer Händler, führen Sie keine zerstörerischen Tests gegen die Produktion durch und veröffentlichen Sie nichts, bevor wir Gelegenheit zur Behebung hatten. Wir sagen zu, eine vollständige Meldung innerhalb von zwei Werktagen zu bestätigen, Sie über die Behebung auf dem Laufenden zu halten, Sie mit Ihrer Erlaubnis zu nennen, wenn sie ausgeliefert wird, und gegen gutgläubige Forschung im Geltungsbereich rechtlich nicht vorzugehen.