Krypto Payment Gateway API: 12 Punkte, die Sie vor der Integration prüfen sollten
Jede Krypto-Payment-API kann eine Rechnung erstellen. Die Unterschiede zeigen sich bei Wiederholungen, Teilzahlungen und fehlgeschlagenen Webhooks. Eine 12-Punkte-Checkliste für Entwickler – und wie die mistKET-API jeden Punkt löst.
Jede Krypto Payment Gateway API verspricht dasselbe: Rechnung erstellen, Zahlung erhalten, Callback bekommen. Die Unterschiede zeigen sich erst später – wenn zwei Anfragen gleichzeitig eintreffen, wenn ein Kunde etwas weniger als den Rechnungsbetrag sendet, wenn Ihr Server eine Stunde lang ausfällt oder wenn ein Angreifer eine abgefangene Anfrage erneut abspielt. Wer die API sorgfältig auswählt, spart weit mehr Zeit als jemand, der sie nur schnell integriert.
Dies ist eine Checkliste für Entwickler und CTOs, die Krypto-Payment-APIs vergleichen, bevor sie eine Zeile Code schreiben. Zu jedem Punkt sehen Sie, worauf Sie achten sollten, warum es wichtig ist und wie die mistKET-API damit umgeht. Wenn Sie sich bereits entschieden haben und den Code Schritt für Schritt sehen möchten, springen Sie direkt zu unserem Leitfaden zur Krypto-Payment-API-Integration.
Die minimale Ausstattung an Endpunkten
Eine brauchbare Krypto-Payment-API bietet mehr als „Zahlung erstellen“. Achten Sie mindestens auf Folgendes:
| Funktion | Wozu Sie sie brauchen | mistKET-Endpunkt |
|---|---|---|
| Rechnung erstellen | Eine Zahlungsanforderung pro Bestellung, mit Ablaufzeit | POST /invoices |
| Rechnung abrufen | Abgleich, wenn ein Webhook verpasst wurde | GET /invoices/{uuid} |
| Rechnungen auflisten und filtern | Backoffice-Ansichten und nächtlicher Abgleich | GET /invoices |
| Rechnung stornieren | Lagerbestand freigeben, wenn eine Bestellung abgebrochen wird | POST /invoices/{uuid}/cancel |
| Unterstützte Assets | Nur Netzwerke anzeigen, die gerade bezahlbar sind | GET /assets |
| Kursabfrage | Den Krypto-Betrag anzeigen, bevor eine Rechnung erstellt wird | GET /rate |
| Health-Check | Monitoring und sauberes Fallback-Verhalten | GET /health |
Wenn ein Anbieter Rechnungen weder abrufen noch auflisten kann, sind Sie gezwungen, Webhooks blind zu vertrauen – eine schlechte Ausgangslage, sobald die erste Zustellung fehlschlägt.
1. Authentifizierung: Ist jede Anfrage signiert?
Ein API-Key, der einfach in einem Header mitgeschickt wird, ist die schwächste Variante: Wer ihn abfängt oder wem er in die Hände fällt, kann Rechnungen erstellen und stornieren. Bevorzugen Sie eine API, bei der jede Anfrage mit einem Secret signiert wird, das nie über die Leitung geht. mistKET-Anfragen enthalten X-Api-Key, X-Api-Timestamp und eine HMAC-SHA256-Signatur aus Zeitstempel und Raw Body. Das Secret wird im Händlerpanel nur ein einziges Mal angezeigt.
2. Schutz vor Replay-Angriffen
Eine Signatur allein verhindert nicht, dass jemand eine abgefangene Anfrage erneut sendet. Achten Sie auf ein Zeitstempel-Fenster und Nonce-Unterstützung. mistKET lehnt Zeitstempel ab, die mehr als ±300 Sekunden von der Serverzeit abweichen, und akzeptiert bei zustandsändernden Anfragen dieselbe Signatur kein zweites Mal. Signaturversion 2 ergänzt eine Nonce pro Anfrage und signiert zusätzlich Methode und Pfad, sodass eine Signatur nicht an einem anderen Endpunkt wiederverwendet werden kann.
3. Idempotenz bei der Rechnungserstellung
Netzwerke laufen in Timeouts. Wenn Ihr Checkout einen „Rechnung erstellen“-Aufruf wiederholt, dürfen am Ende nicht zwei Rechnungen für eine Bestellung existieren. Eine gute API bietet dafür einen Idempotenzschlüssel. Bei mistKET übernimmt Ihre eigene order_id diese Rolle: Ein erneuter Aufruf mit derselben Bestell-ID liefert die bestehende Rechnung mit "idempotent": true zurück, statt eine neue anzulegen.
4. Ein Statusmodell, das echte Zahlungen abdeckt
„Bezahlt / nicht bezahlt“ reicht nicht. Kunden senden etwas zu wenig, weil eine Börse eine Gebühr abgezogen hat, oder zu viel, oder sie zahlen nach Ablauf. Prüfen Sie, ob die API diese Fälle explizit abbildet. mistKET-Rechnungen durchlaufen die Status new, pending, underpaid, paid, confirmed, overpaid, expired und cancelled, mit Feldern wie paid_amount, remaining_amount, can_pay_remaining und under_review, sodass Ihr Code nie raten muss.
paid, dass die Überweisung erkannt wurde und auf Bestätigungen wartet; liefern Sie Bestellungen erst bei confirmed oder overpaid aus.5. Sichtbare Bestätigungen
Die API sollte Ihnen sagen, wie viele Blockbestätigungen eine Zahlung hat und wie viele erforderlich sind, dazu den Transaktions-Hash und einen Explorer-Link. So werden aus Support-Tickets zu Zahlungen schnelle Nachschlagevorgänge. mistKET liefert für jede Rechnung confirmations, required_confirmations und ein transactions[]-Array mit Hash, Betrag, Status und Explorer-URL.
6. Kursfixierung und Preiswährungen
Sie kalkulieren in Fiat, der Kunde zahlt in Krypto. Fragen Sie, welche Fiatwährungen akzeptiert werden und wie lange der angebotene Kurs gilt. mistKET akzeptiert Preise in USD, EUR, TRY, RUB, GBP und AED (oder direkt im Krypto-Symbol), fixiert den Kurs für die Laufzeit der Rechnung und lässt Sie diese Laufzeit pro Rechnung zwischen 5 und 1.440 Minuten festlegen.
7. Netzwerkauswahl
Können Sie das Netzwerk im API-Aufruf festlegen oder den Kunden auf der gehosteten Seite wählen lassen? Beides ist nützlich: Ein festes Netzwerk passt zu Bots und automatisierten Abläufen, die Wahl durch den Kunden verringert Zahlungen über das falsche Netzwerk. mistKET unterstützt beides über pay_currency + network oder asset_id, und GET /assets meldet available: false, wenn ein Netzwerk keine freie Adresse hat. USDT auf TRON (TRC-20) ist heute aktiviert; weitere Assets und Netzwerke werden pro Händler auf Anfrage freigeschaltet. Warum TRON der übliche Standard ist, lesen Sie in USDT TRC20 vs. ERC20.
8. Signierte, wiederholte und nachvollziehbare Webhooks
An Webhooks scheitern die meisten Integrationen. Prüfen Sie vier Dinge: Die Nutzlast ist signiert, es gibt einen Zeitstempel, um veraltete Zustellungen abzulehnen, fehlgeschlagene Zustellungen werden über Stunden (nicht Sekunden) wiederholt, und jede Zustellung hat eine ID zur Deduplizierung. mistKET signiert Webhooks mit einem separaten Webhook-Secret, sendet die Header X-Mistket-Delivery und X-Mistket-Event und wiederholt Antworten außerhalb von 2xx nach 10 s, 30 s, 2 min, 10 min, 30 min, 1 h, 2 h und 3 h; der Zustellverlauf ist im Dashboard sichtbar. Unser Artikel über Krypto-Zahlungs-Webhooks behandelt das Design des Handlers im Detail.
9. Dokumentierte Fehler und Rate Limits
Sie sollten vorab wissen, wie eine falsche Signatur, eine gesperrte IP oder ein Validierungsfehler aussieht. mistKET liefert einen einheitlichen { "success": false, "error": … }-Body mit Details pro Feld bei Validierungsfehlern, verwendet Standardcodes (401, 403, 404, 422, 429, 503) und dokumentiert sein Limit: 120 Anfragen pro Minute und API-Key.
10. Kontrollen auf Netzwerkebene
Mit einer IP-Allowlist ist ein geleakter Key überall außer auf Ihren Servern nutzlos. In mistKET legen Sie sie im Dashboard fest; Anfragen von anderen Adressen erhalten 403. Zusammen mit signierten Anfragen und kurzen Zeitstempel-Fenstern schließt das die häufigsten Angriffswege.
11. Kein SDK-Lock-in
SDKs sind bequem, bis sie Ihrer Sprachversion hinterherhinken. Eine API auf Basis von schlichtem HTTPS und JSON, bei der das Signieren ein einziger HMAC-Aufruf ist, funktioniert aus PHP, Node.js, Python, Go oder einem Shell-Skript heraus. mistKET veröffentlicht in seiner API-Dokumentation Clients zum Kopieren für PHP, Node.js und Python, aber keiner davon ist Pflicht.
12. Ein manueller Weg für Nicht-Entwickler
Auch API-first-Unternehmen müssen gelegentlich einem einzelnen Kunden eine Rechnung stellen. Prüfen Sie, ob sich Rechnungen auch in einem Panel erstellen und als Link teilen lassen, damit Vertrieb und Support nicht die Entwickler bemühen müssen. Bei mistKET stehen dieselben Rechnungen im Händlerpanel zur Verfügung, und jede gehostete Checkout-Seite funktioniert als Zahlungslink.
GET /invoices/{uuid} aufrufen und vergleichen. So prüfen Sie Signierung, Webhook-Handler und Abgleich in einem einzigen Durchgang.Warnsignale bei der Bewertung einer Krypto-Payment-API
- Unsignierte Webhooks oder Webhooks, die nur durch eine geheime URL „gesichert“ sind.
- Keine Möglichkeit, eine Rechnung abzurufen, nachdem sie erstellt wurde.
- Kein Status für Unter- oder Überzahlung – Sonderfälle landen im Support-Chat.
- Wiederholungen nur über wenige Minuten oder kein Zustellprotokoll.
- Undokumentierte Rate Limits und Fehlerformate.
- Unklare Preise pro Transaktion – vergleichen Sie mit unserem Leitfaden zu den Gebühren von Krypto-Payment-Gateways.
So erhalten Sie API-Zugang zu mistKET
Händler werden vom mistKET-Team aufgenommen: Schreiben Sie @mistnetwork auf Telegram mit Ihrer Website, Ihrer Geschäftsart und dem erwarteten Volumen. Nach der Freigabe erstellen Sie API-Key, Secret und Webhook-Einstellungen im Händlerpanel. Eine typische Integration dauert einen Nachmittag.
Werfen Sie vor dem Start einen Blick auf den Entwicklerbereich, die Preise und die vollständige API-Referenz.
