Ein Payment-API-Schlüssel funktioniert wie eine Geldkarte ohne PIN. Wer ihn verwendet, kann Rechnungen erstellen, Ihre Zahlungsdaten einsehen und, wenn Sie Auszahlungen nutzen, Geld von Ihrem Guthaben abziehen. Die Sicherheit einer Payment-API beruht deshalb auf drei Gewohnheiten: Den Schlüssel auf den eigenen Servern behalten, die API nur Anfragen von den Adressen dieser Server akzeptieren lassen und jeden Webhook bestätigen, indem Sie die Zahlung vor dem Handeln erneut abrufen.
Dieser Leitfaden richtet sich an Engineering-Leitungen und Zahlungsverantwortliche bei Zahlungsdienstleistern (PSPs), E-Geld-Instituten (EMIs), Banken und Händlern, die eine Krypto-Zahlungs-API anbinden, die in Euro abrechnet. Er zeigt, wie Sie einen Schlüssel über IP-Adresse und CIDR-Bereich einschränken, wo der Schlüssel liegen sollte, wie Sie Webhooks prüfen und welche Kontrollen rund um Auszahlungen gelten sollten. Die Beispiele verwenden die ItisPay-API und das Dashboard (Demodaten).
Wichtige Momente
Kurz gesagt
- Ein API-Schlüssel ist ein Inhabernachweis (Bearer-Credential). GitGuardian zählte 2025 in öffentlichen GitHub-Commits 28,65 Millionen neue fest codierte Geheimnisse. Planen Sie daher damit, dass ein Schlüssel abfließt, und nicht nur damit, ihn sicher zu halten.
- Eine IP-Allowlist macht einen geleakten Schlüssel außerhalb Ihres Netzwerks nutzlos. Listen Sie die kleinsten IPv4- oder IPv6-Bereiche auf, die Ihre tatsächlichen ausgehenden Adressen abdecken; eine leere Liste erlaubt jede Adresse.
- Ein Webhook ist eine Benachrichtigung, kein Beleg. Rufen Sie die Rechnung über ihre ID mit Ihrem Schlüssel erneut ab, bevor Sie Waren versenden oder ein Konto gutschreiben.
- Auszahlungen brauchen menschliche Kontrollen auf Ihrer Seite: Zwei-Schritt-Anmeldung, gespeicherte Empfänger-IBANs und Wallets sowie eine zweite Freigabe oberhalb eines festgelegten Betrags.
Warum ist ein geleakter Payment-API-Schlüssel so gefährlich?#
Ein geleakter Payment-API-Schlüssel ist gefährlich, weil der Schlüssel die gesamte Identität Ihrer Integration darstellt. Die ItisPay-API authentifiziert, wie die meisten Payment-APIs, jede Anfrage mit einem einzigen Header, Api-key, und dieselbe Authentifizierung gilt für Rechnungen, Auszahlungen auf eine IBAN oder ein Wallet sowie Krypto-Abhebungen an eine externe Adresse. Deshalb verlangt die Dokumentation, dass der Schlüssel „nicht im clientseitigen Code oder in öffentlichen Repositories offengelegt wird.“
In der Praxis gelangen Schlüssel über gewöhnliche Wege nach außen: Code, Logs und Chats. Laut GitGuardians State of Secrets Sprawl 2026 (März 2026) wurden 2025 in öffentlichen GitHub-Commits 28,65 Millionen neue fest codierte Geheimnisse hinzugefügt, 34 % mehr als ein Jahr zuvor. Als GitGuardian 2022 geleakte Geheimnisse erneut prüfte, waren im Januar 2026 mehr als 64 % noch gültig. Teams veröffentlichen Schlüssel und vergessen dann, sie zu ersetzen.
Die OWASP API Security Top 10 (2023) stufen „Broken Authentication“ auf Platz zwei ein und warnen, dass der Authentifizierungsmechanismus ein leichtes Ziel für Angreifer ist, da er allen ausgesetzt ist. Der Data Breach Investigations Report 2025 von Verizon nennt den Missbrauch von Zugangsdaten mit 22 % den häufigsten initialen Angriffsvektor. Ein geheimer Zeichenstring allein ist eine dünne Verteidigung, weshalb dieser Leitfaden weitere Schichten ergänzt, die auch dann halten, wenn der String bereits herausgekommen ist.
Wie schützt eine IP-Allowlist einen API-Schlüssel?#
Eine IP-Allowlist, manchmal auch IP-Whitelist genannt, schützt den Schlüssel, indem sie ihn an Orte bindet und nicht nur an eine Zeichenfolge. Die API akzeptiert den Schlüssel nur, wenn die Anfrage von einer von Ihnen eingetragenen Adresse kommt; eine Kopie des Schlüssels auf dem Laptop eines Entwicklers, in einem CI-Log oder auf einer Paste-Seite funktioniert nicht.
Im ItisPay-Dashboard finden Sie die Einstellung unter Projects, dann Settings, dann Security, im Feld „API Allowed IPs“. Das Feld nimmt eine durch Kommas getrennte Liste aus einzelnen Adressen und CIDR-Blöcken entgegen. Der Hilfetext lautet: „Leer lassen, um alle IPs zuzulassen. IPv4 und IPv6 werden unterstützt.“ Dieselbe Liste lässt sich beim Anlegen eines Projekts über die API im Feld api_allowed_ips setzen; ein ungültiger Eintrag wie 256.256.256.256 wird mit einem Validierungsfehler abgelehnt, statt gespeichert zu werden.
Der leere Standardwert ist wichtig. Ein neues Projekt akzeptiert seinen Schlüssel von überall, bis jemand das Feld ausfüllt. Setzen Sie diesen Schritt deshalb auf die Go-live-Liste und nicht auf die Liste der Dinge, die man später aufräumt. Die Demowerte im Screenshot, 203.0.113.10 und 198.51.100.0/24, stammen aus Bereichen, die RFC 5737 für Dokumentationszwecke reserviert; Ihre Liste enthält Ihre eigenen öffentlichen Adressen. Jedes Projekt hat seinen eigenen 64-stelligen Schlüssel und eine eigene Liste, sodass die Produktion auf zwei oder drei Server beschränkt bleiben kann, während ein Testprojekt einen breiteren Satz an Adressen akzeptiert.
Wie schreibt man CIDR-Bereiche für IPv4 und IPv6?#
Schreiben Sie den kleinsten Bereich, der jede Adresse abdeckt, die Ihre Server tatsächlich zur Kommunikation mit der API nutzen. Die meisten Probleme mit Allowlists entstehen durch einen Bereich, der viel zu weit gefasst ist, oder durch einen ausgehenden Pfad, den jemand vergessen hat.
Ein Präfix lesen#
Ein CIDR-Block besteht aus einer Adresse, gefolgt von einem Schrägstrich und einer Präfixlänge. RFC 4632 definiert die Präfixlänge als Anzahl der signifikanten Bits: 192.168.99.0/24 fixiert die ersten 24 Bits und lässt 8 frei, was 256 Adressen ergibt. Jedes Bit, das Sie vom Präfix abziehen, verdoppelt den Block. Ein /32 ist eine IPv4-Adresse, ein /29 sind 8, ein /24 sind 256 und ein /16 sind 65 536.
IPv6 funktioniert genauso mit 128 Bits. Ein /128 ist eine Adresse. RFC 4291 legt den Anteil der Interface-ID bei den meisten IPv6-Adressen auf 64 Bits fest. Daher ist das Netz eines Servers normalerweise ein /64, und der Host kann seine Adresse innerhalb davon ändern, etwa wenn das Betriebssystem temporäre Adressen erzeugt. Wenn sich die IPv6-Adresse Ihres Hosts ändert und dieses /64 ausschließlich Ihnen gehört, tragen Sie das /64 ein und nicht ein einzelnes /128. Der Dokumentationsbereich für IPv6-Beispiele ist 2001:db8::/32 (RFC 3849). Kopieren Sie ihn daher niemals in eine echte Allowlist.
Ihre tatsächliche ausgehende Adresse finden#
Entscheidend ist die Adresse, die die API sieht, nicht die, die Ihr Server über sich selbst meldet. Hinter einem Cloud-NAT-Gateway oder einer Unternehmens-Firewall teilen sich viele Rechner eine oder zwei öffentliche Adressen. Serverless-Funktionen verlassen das Netz oft über einen gemeinsamen Pool, sofern Sie sie nicht über einen festen Ausgang (Egress) leiten. Prüfen Sie aus jeder Umgebung heraus mit einem Dienst für „Wie lautet meine IP“, oder lesen Sie die Quelladresse in Ihren Firewall-Logs, und tragen Sie dann genau diese Adresse ein.
| Konfiguration | Einzutragen | Bewertung |
|---|---|---|
| Ein Server mit statischer öffentlicher IPv4-Adresse | Diese Adresse als /32 oder ohne Suffix | Funktioniert |
| Mehrere Server hinter einem Cloud-NAT-Gateway | Die öffentlichen Adressen des NAT-Gateways | Funktioniert |
| IPv6-Host mit wechselnden Adressen | Das /64-Netz des Hosts, sofern niemand anderes es nutzt | Hängt ab |
| Büronetz für manuelle Tests | Die feste Adresse des Büros, sofern der Anbieter sie garantiert | Hängt ab |
| Serverless-Funktionen ohne feste ausgehende Adresse | Zuerst über ein NAT mit statischer Adresse leiten | Nicht praktikabel |
| Der gesamte regionale Adressbereich eines Cloud-Anbieters | Nichts; er umfasst auch andere Kunden | Nicht praktikabel |
Bevor Sie eine Änderung speichern, fügen Sie zuerst die neue Adresse hinzu, deployen, prüfen, ob der Traffic fließt, und entfernen erst dann die alte. Eine Liste zu speichern, die Ihre aktiven Server auslässt, blockiert Ihren eigenen Checkout.
Wo sollte der API-Schlüssel liegen und wer sieht ihn?#
Der Schlüssel gehört auf Ihre Server, in einen Secret Store, und nirgendwo sonst. Liefern Sie ihn niemals in einer Browserseite oder einer mobilen App aus, denn dort kann ihn jeder auslesen. Halten Sie ihn auch aus URLs heraus: Das OWASP REST Security Cheat Sheet warnt, dass ein Schlüssel in einer URL in Webserver-Logs erfasst werden kann. Ihre Checkout-Seite spricht mit Ihrem Back End; das Back End spricht mit der Payment API.
Laden Sie den Schlüssel beim Start aus einem Secret Manager oder aus Umgebungsvariablen, nicht aus einer Konfigurationsdatei im Repository. Hosten Sie Code auf GitHub, aktivieren Sie den Push-Schutz: Laut GitHubs Dokumentation gilt: Wenn er „ein potenzielles Secret bei einem Push-Versuch erkennt, blockiert er den Push.“
Verwenden Sie je Umgebung einen eigenen Schlüssel. Jedes ItisPay-Projekt hat seinen eigenen Schlüssel und seine eigene Allowlist; getrennte Projekte für Produktion und Staging bedeuten, dass ein geleakter Staging-Schlüssel keine Live-Zahlungen berühren kann. Begrenzen Sie, wer den Produktionsschlüssel sehen darf. Die Leitlinien der EBA von 2019 zur IKT-Sicherheit setzen die Regel eines „Need-to-know“-Zugriffs mit „minimalen Zugriffsrechten“, technische Nutzer eingeschlossen; seit 2025 übernimmt DORA diese Pflicht für die meisten Zahlungsinstitute.
Legen Sie dann fest, wie Sie den Schlüssel ersetzen würden, bevor Sie es müssen. Das OWASP Cryptographic Storage Cheat Sheet empfiehlt, Schlüssel nach einem festgelegten Zeitraum und immer dann zu rotieren, wenn eine Kompromittierung vermutet wird, und sicherzustellen, dass „der Code und die Prozesse zur Rotation eines Schlüssels vorhanden sind, bevor sie benötigt werden.“
Wie sollten Sie Webhooks einer Payment API verifizieren?#
Behandeln Sie einen Webhook als Hinweis darauf, dass sich etwas geändert hat, niemals als Nachweis, dass Sie bezahlt wurden. Wer Ihre Callback-URL kennt, kann ihr eine gefälschte Nachricht „completed“ schicken. Das sichere Muster ist, die Rechnung mit Ihrem eigenen Schlüssel bei der API zurückzulesen und auf Basis dessen zu handeln, was die API zurückgibt.
Wenn Sie eine ItisPay-Rechnung erstellen, legt das Feld callback_url die Adresse für Statusaktualisierungen fest. Kommt ein Webhook an, übernehmen Sie daraus die Rechnungs-ID, rufen die Rechnung per GET über diese ID ab und liefern aus oder schreiben gut, nur wenn die Antwort den erwarteten Status und den von Ihnen kalkulierten Betrag zeigt. Die Dokumentation beschreibt diesen Endpunkt als Rückgabe von Zahlungsstatus und Blockchain-Details „zur Anzeige für Nutzer oder zur Verifizierung.“
Einige Regeln halten den Handler sauber:
- Akzeptieren Sie Webhooks nur über HTTPS und lehnen Sie einfaches HTTP ab.
- Machen Sie den Handler idempotent. Speichern Sie jede verarbeitete Rechnungs-ID und jeden Status und überspringen Sie Wiederholungen, da Anbieter Benachrichtigungen erneut senden.
- Antworten Sie zügig und erledigen Sie die Arbeit in einer Warteschlange, damit eine langsame Datenbank keine Wiederholungen auslöst.
- Signiert ein Anbieter seine Webhooks mit HMAC, einem in RFC 2104 definierten Hash mit Schlüssel, berechnen Sie die Signatur neu und vergleichen Sie sie mit einer Funktion mit konstanter Laufzeit. Das OWASP Webhook Security Cheat Sheet formuliert es deutlich: „Verwenden Sie niemals ==: Es gibt Timing-Informationen preis und kann den Endpunkt in ein Signing-Orakel verwandeln.“ Lehnen Sie Nachrichten ab, deren signierter Zeitstempel zu alt ist.
Testen Sie vor dem Go-live. ItisPay bietet einen Endpunkt, der eine Statusänderung für eine echte Testrechnung simuliert, und einen weiteren, der den letzten Webhook für eine Rechnungs- oder Bestell-ID erneut sendet. So können Sie Wiederholungen und Duplikate ohne echtes Geld prüfen.
Wie sichern Sie Auszahlungen und den Dashboard-Zugriff ab?#
Bei Auszahlungen wird ein gestohlener Schlüssel zu verlorenem Geld, also setzen Sie menschliche Kontrollen davor. Über den Auszahlungs-Endpunkt von ItisPay geht eine Fiat-Auszahlung an eine IBAN des Begünstigten und eine Krypto-Auszahlung an eine Wallet-Adresse, beide aus Ihrem verfügbaren Guthaben. Die API führt aus, was die Anfrage verlangt; zu entscheiden, ob eine Anfrage legitim ist, ist Ihre Aufgabe.
Kontrollen, die auf Ihrer Seite wirken:
- Zweistufige Anmeldung für alle mit Dashboard- oder Auszahlungszugriff. Das EU-Zahlungsrecht nutzt diese Idee bereits für Zahlungsnutzer: Die PSD2-Regeln zur starken Kundenauthentifizierung verlangen mindestens zwei unabhängige Elemente aus Wissen, Besitz und Inhärenz. Wenden Sie denselben Standard auf Ihre eigenen Mitarbeiter an.
- Gespeicherte Begünstigte. Führen Sie eine eigene Liste genehmigter IBANs und Wallet-Adressen und lassen Sie Ihren Auszahlungsdienst nur an Einträge auf dieser Liste senden. Ein neuer Begünstigter durchläuft eine separate Genehmigung, idealerweise mit einer Abkühlphase.
- Ein zweiter Freigeber oberhalb eines Schwellenwerts. Eine Person bereitet vor, eine andere genehmigt. Legen Sie den Schwellenwert nach Ihrer eigenen Risikobereitschaft fest.
- Ein separater Auszahlungsdienst. Betreiben Sie Auszahlungen über einen Dienst mit eigener fester Adresse auf der Allowlist, getrennt von den Checkout-Servern, die Rechnungen erstellen.
| Kontrolle | Was sie verhindert | Bewertung |
|---|---|---|
| IP-Allowlist für den Schlüssel | Nutzung eines geleakten Schlüssels von außerhalb Ihres Netzwerks | Funktioniert |
| Schlüssel nur auf dem Server | Diebstahl des Schlüssels aus Browsern, Apps und Repositories | Funktioniert |
| Erneutes Abrufen der Rechnung nach einem Webhook | Gefälschte „bezahlt“-Meldungen | Funktioniert |
| Gespeicherte Empfänger und zweite Freigabe | Auszahlungen an die IBAN oder Wallet eines Angreifers | Funktioniert |
| Jede dieser Maßnahmen allein gegen einen gehackten Server auf der Liste | Diebstahl durch jemanden, der bereits im System ist | Nein |
Was erwarten DORA und PCI DSS beim API-Zugang?#
Wenn Sie ein regulierter Finanzdienstleister in der EU sind, sind diese Kontrollen keine optionalen Zusatzmaßnahmen. Der Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) gilt laut EBA seit dem 17. Januar 2025. Artikel 9 verlangt von Unternehmen, „Richtlinien umzusetzen, die den physischen oder logischen Zugang“ zu IKT-Anlagen begrenzen, und „Richtlinien und Protokolle für starke Authentifizierungsmechanismen umzusetzen“. Ein Schlüssel mit IP-Allowlist, der nur auf dem Server liegt und einen Rotationsplan hat, ist genau die Art von Nachweis, die ein Prüfer sehen will.
PCI DSS deckt Kartendaten ab, nicht Krypto-Rechnungen. Wenn dasselbe Team auch Kartenzahlungen abwickelt, verlangt Anforderung 8.4.2 Multi-Faktor-Authentifizierung für jeden Zugriff auf die Umgebung mit Karteninhaberdaten, und die erst später wirksam werdenden Anforderungen der Version 4.0 wurden am 31. März 2025 verbindlich.
Wo stoßen Sicherheitskontrollen für Zahlungs-APIs an ihre Grenzen?#
Diese Kontrollen verengen die Zugangswege. Allein machen sie eine Integration nicht sicher. Auch bei Webhook-Absendern bezeichnet das OWASP-Webhook-Cheat-Sheet die IP-Allowlist als „nur eine zusätzliche Schicht“, weil „eine gemeinsam genutzte Egress-IP kein Identitätsnachweis ist“.
Wo es nicht hilft
- Ein gehackter Server auf der Allowlist. Der Angreifer sendet Anfragen von einer vertrauenswürdigen Adresse mit dem echten Schlüssel.
- Gemeinsam genutzte Ausgangsadressen. Wenn andere Mandanten die Cloud über dieselbe NAT-Adresse verlassen, kann die Allowlist sie nicht von Ihnen unterscheiden.
- Ein gestohlenes Dashboard-Passwort ohne zweistufige Anmeldung. Der Angreifer umgeht die API vollständig.
- Personenbezogene Daten in Rechnungsfeldern. Der öffentliche Rechnungsendpunkt von ItisPay liefert für offene Rechnungen ohne Schlüssel vollständige Angaben. Halten Sie daher Kundennamen und E-Mail-Adressen aus dem Bestellnamen heraus.
Wie richten Sie eine sichere Integration an einem Nachmittag ein?#
Den technischen Teil einer sicheren Integration können Sie an einem Nachmittag abschließen, wenn Sie einer festen Reihenfolge folgen. Die folgenden Schritte verwenden ItisPay; dieselbe Reihenfolge funktioniert mit jedem Anbieter.
- Legen Sie ein Testprojekt und ein separates Produktionsprojekt an, jeweils mit eigenem Schlüssel.
- Speichern Sie beide Schlüssel in Ihrem Secret Manager und laden Sie sie nur auf dem Server.
- Ermitteln Sie die öffentliche ausgehende Adresse jeder Umgebung und tragen Sie sie unter API Allowed IPs ein.
- Erstellen Sie eine Rechnung aus dem Backend: POST an https://api.itispay.com/api/v1/invoices mit dem Api-key-Header, einer eindeutigen order_id, fiat_amount mit fiat_currency EUR, der Kryptowährung in currency und Ihrer callback_url.
- Bauen Sie den Webhook-Handler: nur HTTPS, idempotent, und rufen Sie die Rechnung vor jeder Aktion anhand der ID erneut ab.
- Führen Sie die Webhook-Simulation für jeden Status durch, den Sie verarbeiten, und danach den Resend-Endpunkt, um Duplikate zu testen.
- Aktivieren Sie Auszahlungen zuletzt, mit gespeicherten Empfängern und einer zweiten Freigabe.
Für einen schnellen Einstieg schreibt der Ask-AI-Assistent im Dashboard auf Anfrage Beispielcode, etwa einen Rechnungsaufruf in Node.js mit bereits eingetragenem Api-key-Header. Behandeln Sie ihn als Entwurf: Prüfen Sie die Feldnamen vor dem Go-live anhand der API-Referenz, denn maßgeblich ist die Referenz und nicht ein generiertes Beispiel. ItisPay veröffentlicht außerdem einen offiziellen TypeScript-Client auf npm, @itispay/typescript-client.
Wenn Sie dies in ein umfassenderes Payment-Orchestration-Setup einbinden, geben Sie jedem Anbieter einen eigenen Schlüssel, eine eigene Allowlist und einen eigenen Webhook-Handler. Derselbe Datensatz, der anhand der ID erneut abgerufen wird, speist auch den Abgleich von Krypto-Zahlungen für Ihr Finanzteam.
Wenn Sie Stablecoin-Zahlungen annehmen und Euro empfangen möchten, ohne den Stack selbst aufzubauen, stellt ItisPay die API, Rechnungsstellung, Webhooks und den Abgleich bereit sowie die erste Ebene der API-Sicherheit: Schlüssel, die Sie auf Ihre eigenen IP-Adressen beschränken können. Lizenzierung, KYC und die Abwicklung auf Ihre IBAN laufen über unseren EU-lizenzierten Partner, einen Anbieter von Kryptowerte-Dienstleistungen (CASP) und Zahlungsinstitut. Die meisten Teams kommen in weniger als einer Woche von KYB bis zur ersten Transaktion.
Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Rechts- oder aufsichtsrechtliche Beratung dar.
