Eine Blockchain API für Krypto-Zahlungen, sieben Chains
Nehmen Sie Krypto-Zahlungen auf Bitcoin, Ethereum, TRON, Solana, BNB Smart Chain, Polygon und Arbitrum an und senden Sie sie. Eine REST-API für Wallets, Token-Transfers und Deposit-Webhooks.
Chaingateway ist eine REST-API für Blockchain-Zahlungen. Sie generieren Wallet-Adressen und senden Token mit einfachen HTTPS-Aufrufen, und wenn ein Deposit eine Ihrer Adressen erreicht, benachrichtigt ein Webhook Ihren Server in Echtzeit. Dieselbe API deckt Bitcoin, Ethereum, TRON, Solana, BNB Smart Chain, Polygon und Arbitrum ab.
Diese Abdeckung zählt mehr als jedes einzelne Feature. Die meisten Blockchain-APIs handhaben ein Netzwerk; Teams, die eine zweite Chain hinzufügen, landen meist bei einer zweiten Codebasis, weil jedes Netzwerk sein eigenes RPC-Format und seine eigenen Client-Bibliotheken hat. Chaingateway beseitigt diese Spaltung. Die Route für einen ERC-20-Transfer auf Ethereum ist POST /api/v2/ethereum/transactions/erc20; auf Polygon ist es POST /api/v2/polygon/transactions/erc20. Ein Pfadsegment ändern, und Ihr bestehender Code läuft auf der nächsten Chain.
Es gibt keine Node zu synchronisieren und kein SDK zu installieren. Die Authentifizierung ist ein Bearer-Token im Authorization-Header. Ein zusätzlicher Header, X-Network: testnet, richtet jeden Aufruf auf das Testnetzwerk statt Mainnet. Ein kostenloser 7-Tage-Test startet ohne KYC.
Was die API abdeckt
Wallets und Adressen
Erstellen Sie passwortgeschützte Wallets für Ethereum, BSC, Polygon und TRON, oder bringen Sie bestehende Keys über Import-Endpoints wie POST /api/v2/ethereum/addresses/import mit. Private Keys werden mit einem Passwort verschlüsselt gespeichert, das nur Sie kennen – Chaingateway speichert weder Keys noch Passwörter im Klartext, sodass Gelder ohne Ihre Credentials liegen bleiben. Solana-Adressen kommen von POST /api/v2/solana/addresses. Für Zahlungsprodukte ist das übliche Muster eine Adresse pro Kunde oder pro Rechnung, was Zuordnung trivial hält: Was auch immer auf Adresse X ankommt, gehört Kunde X, ohne Abgleich nach Betrag oder Memo.
Native und Token-Transaktionen
Senden Sie ETH, BNB, POL, TRX oder BTC mit einem einzigen Aufruf, und bewegen Sie ERC-20, BEP-20, TRC-20 und SPL-Token über dieselbe Schnittstelle. Gas, Gas-Preis und Nonce sind optionale Request-Felder – lassen Sie sie weg, füllt die API sie aus, sodass Sie einen Empfänger und einen Betrag übergeben statt rohe Transaktionen zusammenzubauen. Beträge sind Token-Einheiten, keine Basiseinheiten: 100 bedeutet 100 Token der jeweils übergebenen Contract-Adresse. TRON geht weiter als die anderen Chains: Freeze- und Delegate-Endpoints decken Staking ab (mit Unfreeze und Undelegate zum Umkehren), und TRC-10 steht neben TRC-20.
Dekodierte Blockchain-Daten
Antworten kommen als lesbares JSON zurück, nicht als Hex. Eine dekodierte TRON-Transaktion enthält Sender, Empfänger, den Betrag in Token-Einheiten, die Blocknummer und die aktuelle Bestätigungsanzahl. Das ist, was eine Blockchain-Data-API zurückgeben sollte: Werte, die Ihre Anwendung ohne ABI-Parser speichern und anzeigen kann.
Webhooks für eingehende Zahlungen
Abonnieren Sie On-Chain-Events und erhalten Sie eine Benachrichtigung, sobald ein Deposit on-chain abgewickelt ist. Setzen Sie ein persönliches Secret in Ihrem Profil, und jede Benachrichtigung trägt einen X-Signature-Header, den Ihr Server verifizieren kann. Fehlgeschlagene Zustellungen werden von der API aufgelistet und lassen sich mit einem einzigen Aufruf erneut senden.
Was auf welcher Chain funktioniert
Die Tabelle verdichtet die aktuelle API-Referenz in eine Ansicht: welche Chains Adress-Routen haben, welche Token-Standards Sie senden können, und wo Deposit-Webhooks dokumentiert sind.
| Chain | Adressen | Token-Transfers | Deposit-Webhooks |
|---|---|---|---|
| Bitcoin | POST /api/v2/bitcoin/wallets/{wallet}/addresses | — (kein Token-Standard) | GET /api/v2/bitcoin/webhooks/notifications |
| Ethereum | POST /api/v2/ethereum/addresses/import | ERC-20: POST /api/v2/ethereum/transactions/erc20 | GET /api/v2/ethereum/webhooks/notifications |
| TRON | POST /api/v2/tron/addresses/import | TRC-20 und TRC-10: POST /api/v2/tron/transactions/trc20 und .../trc10 | GET /api/v2/tron/webhooks/notifications |
| Solana | POST /api/v2/solana/addresses | SPL: POST /api/v2/solana/transactions/SPL | — |
| BNB Smart Chain | POST /api/v2/bsc/addresses/import | BEP-20: POST /api/v2/bsc/transactions/bep20 | GET /api/v2/bsc/webhooks/notifications |
| Polygon | POST /api/v2/polygon/addresses/import | ERC-20: POST /api/v2/polygon/transactions/erc20 | GET /api/v2/polygon/webhooks/notifications |
| Arbitrum | POST /api/v2/arbitrum/addresses/import | ERC-20: POST /api/v2/arbitrum/transactions/erc20 | GET /api/v2/arbitrum/webhooks/notifications |
Zwei Fußnoten, um die Tabelle richtig zu lesen. Erstens: TRON ist die tiefste Integration auf der Plattform. Über die obigen Routen hinaus dokumentiert die Referenz Staking (POST /api/v2/tron/freeze und /delegate), Chain-Parameter und ein Self-Signing-Paar – /transactions/trc20/build, um eine Transaktion zu konstruieren, und /transactions/broadcast, um eine lokal signierte einzureichen. Besteht Ihr Compliance-Team darauf, dass Private Keys Ihre Server nie verlassen, ist dieses Build-and-Broadcast-Muster Ihr Weg.
Zweitens: Ein Strich bedeutet, dass die aktuelle Referenz für diese Zelle keine v2-Route dokumentiert, nicht dass das Netzwerk zweite Wahl ist. Bitcoin hat keinen Token-Standard, daher die leere Token-Zelle – natives BTC läuft stattdessen über sein eigenes Wallet-Modell: eine passwortverschlüsselte Wallet mit POST /api/v2/bitcoin/wallets erstellen, Deposit-Adressen darunter ableiten und mit POST /api/v2/bitcoin/transactions senden. Solanas Referenz deckt Adresserstellung, SOL- und SPL-Transfers sowie Guthaben- und Block-Abfragen ab, aber noch keine Webhooks. Für alles, was hier nicht aufgeführt ist, hat die API-Referenz den aktuellen Stand.
Ein Blockchain-API-Beispiel: der erste Aufruf in vier Sprachen
Holen Sie sich einen API-Key (nächster Abschnitt), bestätigen Sie dann, dass er funktioniert. GET /api/account gibt Ihre Kontodaten zurück und beweist, dass der Key gültig ist.
curl https://app.chaingateway.io/api/account \
-H "Authorization: Bearer YOUR_API_KEY"Das ist die gesamte Authentifizierungsprüfung – Konto erstellen, und derselbe Aufruf beweist, dass Ihr eigener Key funktioniert.
Wie Sie einen Blockchain-API-Key bekommen
Registrieren Sie sich unter app.chaingateway.io/register. Der 7-Tage-Test startet ohne KYC.
Kopieren Sie den API-Key aus Ihrem Dashboard.
Senden Sie ihn mit jedem Request als Authorization: Bearer YOURAPIKEY, und halten Sie ihn ausschließlich server-seitig. Client-seitiger Code würde ihn jedem offenlegen, der die Browser-Konsole öffnet. Das Konto-Panel kann den Key zusätzlich auf die IP-Adressen Ihrer Server beschränken, sodass ein geleakter Key nirgendwo sonst nützlich ist. Weitere Härtungsschritte stehen in unseren Sicherheitstipps für die Blockchain-API.
Deposits empfangen: der Webhook-Flow
Eine Zahlungsintegration sieht meist so aus:
Erstellen oder importieren Sie eine Deposit-Adresse für jeden Kunden.
Der Kunde sendet Coins oder Token an diese Adresse.
Sobald der Transfer abgewickelt ist, sendet Chaingateway eine Benachrichtigung per POST an Ihre Callback-URL – mit einem X-Signature-Header, wenn Sie ein persönliches Secret gesetzt haben.
Ihr Server verifiziert die Signatur und schreibt das Kundenkonto gut.
Webhook-Sicherheit in der Praxis
Ein Webhook-Endpoint ist eine Tür in Ihr Backend, und diese bestimmte Tür schreibt Geld gut. Chaingateway gibt Ihnen drei Mechanismen, um sie zu sichern; ein Produktions-Handler sollte alle drei nutzen. Das gilt für die sechs Chains mit Deposit-Webhooks – Solana-Deposit-Erkennung nutzt stattdessen Polling, weiter unten behandelt.
1. Signatur verifizieren
Setzen Sie ein persönliches Secret in Ihren Profileinstellungen – ab dann trägt jede Benachrichtigung einen X-Signature-Header, gebaut als base64 eines HMAC-SHA256 über das txid-Feld des Payloads, geschlüsselt mit diesem Secret. Berechnen Sie ihn aus der erhaltenen txid neu, vergleichen Sie ihn mit dem Header-Wert, bevor Sie irgendetwas gutschreiben, und nutzen Sie einen zeitkonstanten Vergleich – die meisten Standardbibliotheken liefern einen. Weisen Sie Fehlschläge mit einem 401 zurück. Das schließt den offensichtlichen Angriff: Wer auch immer Ihre Callback-URL entdeckt, kann fabrizierte Deposits daran posten, und ohne Signaturprüfung würde Ihr Shop Waren für Zahlungen versenden, die nie stattfanden.
2. Für Wiederholungszustellung entwerfen
Eine Benachrichtigung kann Sie mehr als einmal erreichen – Sie können fehlgeschlagene über die API erneut senden, und nichts garantiert dazwischen exactly-once-Zustellung. Knüpfen Sie Ihre Gutschrift-Logik an den Transaktions-Hash statt an die Anzahl erhaltener Callbacks – ein INSERT ... ON CONFLICT DO NOTHING auf der Hash-Spalte kostet eine Zeile und schaltet die gesamte Klasse von Doppelgutschrift-Bugs ab. Antworten Sie mit einem 2xx, sobald die Benachrichtigung persistiert ist, und erledigen Sie langsame Verarbeitung danach; ein Handler, der schwere Arbeit inline erledigt, läuft in Timeouts und macht aus einem Deposit einen Support-Fall.
3. Die Recovery-Routen nutzen
War Ihr Endpoint down oder antwortete mit einem Fehler, landet die Zustellung auf der Failed-Liste: GET /api/v2/{chain}/webhooks/notifications/failed zeigt, was nicht durchkam, und POST /api/v2/{chain}/webhooks/notifications/{id}/retry sendet jede auf Ihr Kommando erneut. Für alles Übrige – ein Datenbank-Failover, ein schlechtes Deploy, ein abgelaufenes TLS-Zertifikat – gibt GET /api/v2/{chain}/webhooks/notifications die vollständige Zustellungshistorie zurück, sodass ein nächtlicher Reconciliation-Job sie mit Ihrem Ledger vergleichen und Lücken reparieren kann. Payload-Details und Verifizierungscode stehen im Webhook-Guide.
Auf Testnet testen, denselben Code ausliefern
Jede Route akzeptiert einen zusätzlichen Header, X-Network: testnet, und läuft gegen das Testnetzwerk statt Mainnet. Endpoints, Request-Bodies und Response-Formen bleiben identisch; die Coins sind wertlos. Genau diese Eigenschaft ist der Sinn. Ihre Integrationstests können den ganzen Tag Adressen erstellen, Token bewegen und Webhooks empfangen, ohne echte Gelder anzufassen.
Ein praktisches Setup sieht so aus. Legen Sie den Header hinter eine Umgebungsvariable, sodass Staging ihn sendet und Produktion nicht – kein Code-Unterschied zwischen beiden. Geben Sie Staging eine eigene Callback-URL, sonst landen Test-Deposits in Ihrem Produktions-Webhook-Handler und verwirren das Ledger. Test-Coins kommen kostenlos von den öffentlichen Faucets, die jedes Ökosystem betreibt; die Supported-Networks-Seite in den Docs nennt das Testnetzwerk pro Chain – Sepolia für Ethereum, Nile für TRON, Amoy für Polygon, testnet3 für Bitcoin.
Wenn der Flow Ende-zu-Ende funktioniert – Adresse erstellt, Deposit erkannt, Webhook verifiziert, Guthaben gutgeschrieben –, löschen Sie den Header. Sonst ändert sich nichts. Diese Symmetrie ist beabsichtigt, und deshalb ist Live-Gehen eine Konfigurationsänderung statt eines zweiten Integrationsprojekts.
Drei Integrationen, durchgespielt
Feature-Listen sagen wenig über den Integrationsaufwand aus, hier also drei Builds, die wir häufig sehen, jeweils auf ihre beweglichen Teile reduziert.
Deposits für einen Online-Shop
Ein Shop will USDT am Checkout annehmen. Wählt ein Kunde Krypto, weist Ihr Backend eine Adresse für diese Bestellung zu und zeigt sie neben dem Betrag an. Von dort erledigt der Webhook die Arbeit. Die Benachrichtigung kommt, sobald der Transfer on-chain abgewickelt ist; markieren Sie die Bestellung als „Zahlung erkannt“ und zeigen Sie das dem Kunden, weil schnelles Feedback das ist, was Krypto-Checkout vertrauenswürdig wirken lässt. Verlangt Ihre Policy mehr Tiefe bei größeren Beträgen, prüfen Sie die Transaktion mit GET /api/v2/{chain}/transactions/{txid}, bis Ihr Schwellenwert erreicht ist, markieren Sie die Bestellung dann als bezahlt und starten Sie die Erfüllung.
Zwei Randfälle entscheiden, ob dieser Build produktionsreif ist. Unterzahlung: Kunden senden manchmal etwas weniger als die Rechnung, meist weil ihre Wallet die Netzwerkgebühr vom eingegebenen Betrag abgezogen hat. Entscheiden Sie die Toleranz im Voraus – einen kleinen Fehlbetrag absorbieren oder die Bestellung halten und die Differenz nachfordern. Überzahlung ist seltener und einfacher: gutschreiben oder zurückerstatten, aber in jedem Fall loggen. Beide Fälle ergeben sich daraus, den gemeldeten Betrag mit dem Rechnungsbetrag zu vergleichen, statt jeden Callback als „bezahlt“ zu behandeln.
Batch-Auszahlungen
Eine Affiliate-Plattform zahlt jeden Monat Hunderte Partner in Stablecoins aus, auf Polygon, weil dort die Gebühren im Verhältnis zu den Auszahlungsbeträgen klein bleiben. Der Build ist eine Queue und eine Loop:
import requests
payouts = load_pending_payouts() # [{"address": ..., "amount": ...}, ...]
for p in payouts:
r = requests.post(
"https://app.chaingateway.io/api/v2/polygon/transactions/erc20",
headers={"Authorization": "Bearer YOUR_API_KEY"},
json={
"contractaddress": "0xTokenContract...",
"from": "0xTreasuryWallet...",
"to": p["address"],
"amount": p["amount"],
"password": "treasury-wallet-password",
},
)
record_result(p, r.json()) # vor der nächsten Iteration persistieren
Die Queue zählt mehr als die Loop. Persistieren Sie den Zustand jeder Auszahlung, bevor Sie sie senden, speichern Sie die API-Antwort sofort, und wiederholen Sie einen Send nie nur, weil der HTTP-Aufruf getimeoutet hat – die Transaktion könnte trotzdem durchgegangen sein. Prüfen Sie Ihre gespeicherten Ergebnisse und GET /api/v2/polygon/transactions, das jede über die API erstellte Transaktion listet, und senden Sie nur erneut, was nachweislich nie passierte. Diese eine Regel trennt Auszahlungssysteme, die Audits überstehen, von solchen, die in Tabellenkalkulations-Archäologie enden.
On-Chain-Abrechnung für ein SaaS
Ein B2B-Tool rechnet Kunden monatlich in Stablecoins ab, weil Kartenprozessoren seine Merchant-Kategorie ständig ablehnen. Der Build nutzt das Shop-Muster wieder, mit einem Twist: eine frische Deposit-Adresse pro Rechnung, nicht pro Kunde. Adresse-pro-Rechnung macht Abgleich trivial – jeder Betrag, der auf der Adresse von Rechnung 4711 ankommt, gehört zu Rechnung 4711 – und es beseitigt das Raten beim Abgleich von Zahlungen nach Betrag, wenn zwei Rechnungen zufällig dieselbe Summe ergeben. Der Webhook markiert Rechnungen als bezahlt; ein geplanter Job lässt veraltete verfallen und sendet Erinnerungen. Nichts an diesem Flow braucht eine Wallet-UI, eine Browser-Extension oder Krypto-Wissen auf Kundenseite jenseits der Fähigkeit, einen Transfer zu senden.
Unterstützte Blockchains
Jede Chain hat ihre eigene Seite mit Endpoints und Code-Beispielen:
- Bitcoin API – die ursprüngliche Chain. Native BTC-Transfers aus passwortverschlüsselten Wallets, plus Deposit-Webhooks für eingehende Zahlungen.
- Ethereum API – die am weitesten verbreitete Smart-Contract-Plattform, mit ERC-20-Token-Transfers und ERC-721-NFT-Unterstützung.
- TRON API – TRC-10- und TRC-20-Transaktionen, Staking via Freeze und Delegate, und Self-Signing-Build/Broadcast-Routen. Schätzen Sie Transferkosten vorab mit dem TRON-Fee-Calculator.
- Solana API – Adresserstellung und SPL-Token-Transaktionen auf einer High-Throughput-Chain.
- BNB Smart Chain API – BEP-20-Transfers mit demselben Routenmuster, das Sie auf Ethereum nutzen.
- Polygon API – ERC-20-Transfers auf Ethereums Scaling-Chain, zu einem Bruchteil der Mainnet-Gas-Kosten. Das ist die Polygon-Blockchain-API, nicht der Polygon.io-Aktiendaten-Dienst.
- Arbitrum API – Ethereum-L2 für hohen Durchsatz, mit demselben Endpoint-Layout wie Mainnet.
Von JSON-RPC zu REST migrieren
Eine Blockchain-API ersetzt rohe JSON-RPC-Aufrufe durch einen authentifizierten REST-Request pro Aktion. Wo JSON-RPC mehrere Round-Trips pro Transfer braucht, plus manuelles ABI-Encoding, Nonce-Tracking und Signieren, kollabiert ein Aufruf wie POST /api/v2/{chain}/transactions/erc20 (bep20 auf BNB Smart Chain) all das zu einem einzigen Request.
Viele Teams kommen hierher mit einer bereits laufenden Integration: web3.js gegen einen bezahlten RPC-Endpoint, oder ein selbst gebauter JSON-RPC-Client aus einer früheren Ära der Codebasis. Die Migration ist weniger dramatisch, als es klingt, weil die API ganze Code-Kategorien absorbiert statt Aufruf für Aufruf zu ersetzen.
Nehmen Sie den kanonischen EVM-Sendepfad. Über JSON-RPC ist ein Token-Transfer eine Sequenz: eth_getTransactionCount für den Nonce, eth_gasPrice oder ein Fee-History-Aufruf für die Bepreisung, eth_estimateGas gegen ABI-kodierte Calldata, lokales Signieren, dann eth_sendRawTransaction zum Broadcasten. Jeder Schritt hat Fehlermodi, die Ihr Code aktuell handhabt – oder still nicht. Alle fünf kollabieren zu einem authentifizierten POST an /api/v2/{chain}/transactions/erc20, und die Nonce-Buchhaltung, die übliche Quelle von „stuck transaction“-Tickets, verlässt Ihre Codebasis vollständig.
Event-Erkennung ändert die Form mehr als die Logik. Wo Sie eth_getLogs mit einem Block-Cursor gepollt oder eine WebSocket-Subscription durch jeden Reconnect-Bug offen gehalten haben, registrieren Sie jetzt einen Webhook und löschen den Poller. Ihre nachgelagerte Logik – Transfer parsen, Kunde matchen, Guthaben gutschreiben – bleibt, wie sie ist; nur die Eingabeseite kippt von Pull zu Push.
Was sich nicht überträgt: Consensus-Tooling, eigene Indexer, alles, was rohen Block-Zugriff braucht. Behalten Sie für diese Aufgaben einen RPC-Endpoint; beide koexistieren reibungslos. Zahlungen sind meist die erste Workload, die es wert ist, migriert zu werden, weil sie das meiste operative Risiko pro Codezeile tragen. Der ausführlichere Vergleich, inklusive der Fälle, in denen eine Node gewinnt, steht in Blockchain API vs. Blockchain Node.
Wenn ein Request fehlschlägt
Fehlerbehandlung für eine Payments-API verdient mehr als einen generischen Catch-Block, weil ein fehlgeschlagener Request und eine fehlgeschlagene Transaktion unterschiedliche Ereignisse sind.
Die HTTP-Ebene folgt REST-Konventionen. Ein 401 bedeutet, dass der Bearer-Token fehlt, falsch oder abgelaufen ist – korrigieren Sie das Credential, versuchen Sie es nicht erneut. Andere Antworten im 4xx-Bereich sagen, dass der Request selbst fehlerhaft ist: eine fehlerhafte Adresse, ein fehlendes Feld, ein Validierungsfehler. Loggen Sie den Response-Body, der das spezifische Problem benennt, und behandeln Sie diese als zu behebende Bugs statt als vorübergehende Zustände zum Wiederholen. Der 5xx-Bereich und Netzwerk-Timeouts bilden die vorübergehende Klasse, wo ein Retry mit exponentiellem Backoff der richtige Reflex ist.
Mit einer Ausnahme, und es ist die Ausnahme, die zählt. Wiederholen Sie nie blind einen Request, der Gelder bewegt. Ein Timeout sagt Ihnen, dass Sie die Antwort nicht erhalten haben – nicht dass die Transaktion fehlschlug. Die sichere Abfolge: Prüfen Sie, ob der Transfer rausging, mit Ihren gespeicherten Ergebnissen und GET /api/v2/{chain}/transactions (der Liste der von Ihrem Key erstellten Transaktionen), und senden Sie nur erneut, wenn Sie zeigen können, dass es nie passierte. Idempotency-Keys auf Ihrer Seite, an Ihre eigenen Auszahlungs- oder Bestell-IDs gebunden, machen diese Prüfung günstig.
Bauen Sie Observability von Tag eins ein. Loggen Sie Request-Response-Paare für jeden geldbewegenden Aufruf, und alarmieren Sie bei 4xx-Raten statt nur bei 5xx – ein plötzlicher Schub an Validierungsfehlern bedeutet meist, dass ein Deploy Ihr Request-Format kaputt gemacht hat. Das in Minuten statt Tagen zu erwischen, ist der Unterschied zwischen einem Vorfall und einer Fußnote.
Eigene Nodes betreiben oder eine API nutzen?
Nodes selbst zu betreiben gibt Ihnen volle Kontrolle und keine Abhängigkeit von Dritten. Es bedeutet auch eine Maschine pro Chain, Speicher- und Bandbreitenbudgets, Sync-Monitoring und Versions-Upgrades – multipliziert mit sieben, wenn Sie die oben beschriebene Abdeckung wollen. Unser Vergleich von Blockchain API vs. Blockchain Node geht diesen Trade-off durch. Die Kurzfassung: Betreiben Sie eine Node, wenn Sie Kontrolle auf Consensus-Ebene brauchen, nutzen Sie die API, wenn Zahlungen diese Woche funktionieren müssen.
Häufig gestellte Fragen
Bereit, Krypto-Zahlungen anzunehmen?
Erstellen Sie ein Konto unter app.chaingateway.io/register, wählen Sie eine Chain aus den sieben oben und senden Sie einen Testnet-Transfer. Die vollständige Endpoint-Referenz steht in den Docs, und Pläne und Rate Limits haben ihre eigene Seite.