Polygon Blockchain API: Stablecoin-Zahlungen mit niedrigem Gas

Der Namenskonflikt ist zwei weitere Absätze wert, weil die Hälfte der Suchergebnisse für „polygon api“ auf das falsche Produkt zeigt. Polygon.io ist ein US-Unternehmen, das Marktdaten-Feeds verkauft: Aktienkurse, Options-Ketten, Forex-Kerzen. Seine API beantwortet Fragen wie „was hat AAPL gestern gehandelt“. Es hat keine Blockchain, keine Token und keine Verbindung zu dem hier behandelten Netzwerk.

Polygon die Blockchain, betrieben von Polygon Labs, ist ein EVM-kompatibles Proof-of-Stake-Netzwerk, das Token-Transaktionen abwickelt. Seine API-Oberfläche, ob rohes JSON-RPC oder eine Payments-Schicht wie Chaingateway, beantwortet Fragen wie „ist das USDC des Kunden angekommen“ und führt Anweisungen aus wie „zahle 50 USDT aus“. Brauchen Sie Ticker und OHLC-Kerzen, schließen Sie diesen Tab und suchen Sie nach Polygon.io. Müssen Sie Stablecoins mit Gas-Gebühren in Bruchteilen eines Cents bewegen, lesen Sie weiter.

Das Häufigste, was auf Chaingateways Polygon-Endpoints gebaut wird, ist Stablecoin-Zahlungsverarbeitung, und die Ökonomie erklärt warum. Jeder ERC-20-Transfer braucht Gas. Auf Ethereum Mainnet kann Gas für einen USDT-Transfer mehr kosten als eine kleine Zahlung selbst; auf Polygon kostet derselbe Transfer höchstens Cent-Beträge. Jemandem 2 USDC für ein digitales Produkt zu berechnen, ist hier tragfähig. Auf L1 ist es das nicht.

Die Zahlen bestätigen das. Stand Mitte 2026 setzen Gebühren-Tracker einen typischen USDT-Transfer auf Polygon PoS zwischen einem Zehntel Cent und zwei Cent an, und er übersteigt selten ein paar Cent, selbst wenn das Netzwerk beschäftigt ist. Derselbe Transfer auf Ethereum Mainnet reichte von deutlich unter einem Dollar in ruhigen Wochen bis zu mehreren Dollar während Überlastungsspitzen. Die Lücke bewegt sich mit den Gas-Märkten, hat sich aber über Jahre bei zwei bis drei Größenordnungen gehalten, und für ein Geschäftsmodell auf Basis kleiner Zahlungen ist diese Lücke der gesamte Business Case.

Ein typischer Checkout sieht so aus: Ihr Backend weist dem Kunden eine Deposit-Adresse zu und zeigt einen QR-Code, und der Kunde sendet USDC oder USDT aus jeder Wallet oder Börse. Etwa zwei Sekunden später ist der Transfer in einem Block. Der Webhook feuert, Ihr Server verifiziert die HMAC-Signatur, und die Bestellung kippt auf bezahlt. Keine Kartennetzwerke, keine Chargebacks, kein Warten auf Bankzeiten.

Chain-Fakten driften, hier also die aktuellen mit Datumsangabe. Stand Anfang Juli 2026:

Blöcke kommen im Schnitt alle 2 bis 2,3 Sekunden, laut PolygonScans Blockzeit-Daten, und Transaktions-Finalität liegt bei etwa 5 Sekunden. Für Deposits bedeutet das: Die Lücke zwischen „Kunde hat gesendet gedrückt“ und „sicher gutzuschreiben“ liegt im einstelligen Sekundenbereich.

Das Gas-Token ist POL. Die Migration von MATIC fand am 4. September 2024 statt, zum Kurs 1:1, mit automatisch konvertierten Guthaben auf der PoS-Chain; Polygon meldete die Migration etwa ein Jahr später zu 99 % abgeschlossen. Jede Transaktion auf Polygon PoS bezahlt seither Gas in POL.

Das Testnet ist Amoy, verankert an Ethereums Sepolia. Es ersetzte das ältere Mumbai-Testnet, das am 13. April 2024 zusammen mit dem Goerli-Netzwerk, von dem es abhing, stillgelegt wurde. Tutorials, die noch Mumbai sagen, sind veraltet; der beschriebene Flow funktioniert meist unverändert auf Amoy.

Jede Polygon-Transaktion zahlt Gas in POL, dem Token, das MATIC im September 2024 zum Kurs 1:1 ersetzte. Die sendende Adresse braucht dafür ein kleines POL-Guthaben; Token empfangen kostet den Empfänger nichts. Der Gas-Preis wird automatisch von der API gesetzt, sodass Integrationen ihn selten von Hand feintunen.

Guthaben auf der PoS-Chain wurden automatisch von MATIC zu POL migriert, sodass ältere Dokumentation, die noch MATIC sagt, heute POL meint. Das übliche Muster ist eine gefüllte Hot Wallet für Auszahlungen, plus Konsolidierungs-Transfers von Deposit-Adressen, die Sie nach Bedarf mit POL auffüllen. Da ein einzelner Transfer nur einen winzigen Bruchteil eines POL verbrennt, deckt ein moderater Puffer viel Traffic.

Jeder Standard-ERC-20-Contract auf Polygon funktioniert. USDT, USDC und DAI werden sofort unterstützt, Dezimalstellen inklusive. Haben Sie Ihr eigenes Token gelauncht, übergeben Sie seine Contract-Adresse an denselben Endpoint, und es verhält sich wie jedes andere. NFTs und DeFi-Token folgen derselben Regel. Weil die API über Chains hinweg identisch ist, läuft für Polygon geschriebener Code auch gegen Ethereum, BSC oder Arbitrum, sobald Sie das Chain-Segment in der URL tauschen.

Der Durchsatz ist hoch genug für Gaming und andere hochfrequente Workloads, und die Kosten sind niedrig genug, dass Use-Cases, die auf Ethereum L1 unerschwinglich sind, praktikabel werden. Große Consumer-Marken haben Loyalty-Programme und Sammlerstücke auf Polygon ausgeliefert, was Mainstream-Nutzer auf das Netzwerk gezogen hat, und institutionelle Projekte entscheiden sich weiterhin dafür für die Abwicklung. Für Ihr Team sind die Einstiegskosten niedrig: Die Chain ist EVM-kompatibel, sodass alles, was Sie über Ethereum wissen, unverändert übertragbar ist.

Drei Requests decken den gesamten Zahlungs-Loop ab. Die exakten Request-Schemas stehen in der API-Referenz; für Trockenläufe gegen das Polygon-Testnet (Amoy) fügen Sie den Header X-Network: testnet hinzu.

Eine bestehende Wallet importieren:

curl -X POST https://app.chaingateway.io/api/v2/polygon/addresses/import \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xYourAddress",
    "privatekey": "0xYourPrivateKey",
    "password": "YourWalletPassword"
  }'

Das Passwort schützt den importierten Key auf der Plattform; spätere Sends von dieser Adresse übergeben das Passwort statt des rohen Keys.

USDT auf Polygon senden (Contract 0xc2132D05D31c914a87C6611C10748AEb04B58e8F):

curl -X POST https://app.chaingateway.io/api/v2/polygon/transactions/erc20 \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contractaddress": "0xc2132D05D31c914a87C6611C10748AEb04B58e8F",
    "from": "0xYourSenderAddress",
    "to": "0xRecipientAddress",
    "amount": 5,
    "password": "YourWalletPassword"
  }'

Vergangene Webhook-Benachrichtigungen auflisten, der schnellste Weg, Deposits gegen Ihre Datenbank abzugleichen:

curl https://app.chaingateway.io/api/v2/polygon/webhooks/notifications \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY"

Dieselben drei Aufrufe übersetzen sich direkt nach PHP, Python oder Node mit jedem Standard-HTTP-Client; es gibt keine Polygon-spezifische Bibliothek zu installieren.

Hier ist der vollständige Empfangs-Flow, so wie er in Produktion läuft statt in einer Demo.

Adress-Zuordnung und Attribution

Jeder Kunde oder jede Bestellung bekommt eine eigene Deposit-Adresse, gespeichert in einer Tabelle: Ihre interne ID, die Adresse, ein Zeitstempel. Die Adresse in einem eingehenden Webhook-Payload ist der Lookup-Key, der einen Transfer mit einer Bestellung verknüpft, und ein Unique-Index auf dieser Spalte garantiert, dass kein Deposit je zwei Bestellungen zugeordnet werden kann. Verwaltet Ihre Plattform bereits Keys, registrieren Sie sie einmal über POST /api/v2/polygon/addresses/import und hängen Sie Webhooks wie im Webhooks-Guide beschrieben an.

Einen Deposit verifizieren und gutschreiben

Zahlt der Kunde, ist der Transfer innerhalb etwa zwei Sekunden in einem Block, und die Benachrichtigung trifft Ihren Endpoint Augenblicke später. Ihr Handler verifiziert zuerst die HMAC-Signatur, sucht die Bestellung nach Adresse, und prüft dann noch eine Sache, bevor er gutschreibt: ob er diesen Transaktions-Hash schon gesehen hat. Speichern Sie jeden verarbeiteten Hash mit einer Unique-Constraint, und lassen Sie die Datenbank Duplikate ablehnen. Eine Zustellung, die Ihr Server verpasst hat, ist nicht verloren: Sie erscheint unter GET /api/v2/polygon/webhooks/notifications/failed, und POST /api/v2/polygon/webhooks/notifications/{id}/retry sendet sie erneut, sodass ein Timeout auf Ihrer Seite nie einen Deposit verliert; idempotente Verarbeitung hält eine wiederholte Benachrichtigung davon ab, ihn doppelt gutzuschreiben.

Wie lange vor der Freigabe warten

Das ist eine Geschäftsentscheidung, keine technische. Finalität auf Polygon kommt etwa 5 Sekunden nach Inklusion, sodass selbst eine vorsichtige Policy wenig kostet: Schreiben Sie einen 3-USDC-Kauf bei der ersten Benachrichtigung gut, halten Sie einen vierstelligen Deposit, bis Ihr Reconciliation-Check gegen GET /api/v2/polygon/webhooks/notifications ihn bestätigt. Dieser Endpoint dient auch als Audit-Trail; ein nächtlicher Diff gegen Ihr eigenes Ledger fängt alles, was ein zweistündiger Ausfall verschleiert haben könnte.

Deposit-Adressen fegen

Deposit-Adressen füllen sich mit der Zeit, planen Sie also einen Sweep: einen Job, der Guthaben mit demselben POST /api/v2/polygon/transactions/erc20-Aufruf in Ihre Treasury-Wallet konsolidiert, from auf die Deposit-Adresse gesetzt. Jede gefegte Adresse braucht eine Spur POL für Gas, was bei Polygon-Preisen klein genug ist, um im Voraus in großen Mengen zu füllen.

Abhebungen sind der Flow, bei dem Fehler direkt Geld kosten, und zwei Gewohnheiten beseitigen den Großteil des Risikos.

Validieren Sie vor dem Einreihen. Eine Zieladresse muss als 20-Byte-0x-Wert dekodieren, und enthält sie Mixed-Case-Buchstaben, muss die EIP-55-Checksum stimmen. Weisen Sie Fehlschläge im Formular ab, wo der Nutzer einen Tippfehler korrigieren kann; die API validiert vor dem Broadcast erneut, aber je früher der Fang, desto günstiger.

Erst schreiben, dann senden. Erstellen Sie eine Datenbankzeile pro Auszahlung mit einer Zustandsmaschine (queued, sent, confirmed), lassen Sie einen Worker genau einen POST /api/v2/polygon/transactions/erc20-Aufruf pro Zeile machen, und speichern Sie den zurückgegebenen Transaktions-Hash sofort. Geben Sie dem Nutzer diesen Hash als PolygonScan-Link, und er kann seine eigene Abhebung verfolgen, statt an den Support zu schreiben. Timeoutet der API-Aufruf, feuern Sie nicht reflexartig erneut: Prüfen Sie die Notification-Liste und Ihre eigenen Aufzeichnungen, um zu bestätigen, dass nichts rausging, dann wiederholen Sie gezielt. Die Hot Wallet braucht einen POL-Puffer für Gas; auf Polygon deckt ein kleines Guthaben Tausende Transfers, sodass eine monatliche Aufladung reicht.

Amoy ist Polygons Sepolia-verankertes Testnet, live seit Anfang 2024 als Mumbai-Ersatz, und jeder Endpoint auf dieser Seite läuft dagegen, wenn Sie einen Header hinzufügen:

X-Network: testnet

Kein separates Konto, kein zweiter Key, keine sonstige Änderung. Test-POL kommt von den öffentlichen Amoy-Faucets, und Adressen und Mechanik entsprechen exakt Mainnet.

Verbringen Sie den Testlauf mit Fehlerpfaden statt dem Happy Path. Töten Sie Ihren Webhook-Endpoint, senden Sie einen Deposit, bringen Sie den Endpoint zurück, lesen Sie dann die Failed-Notifications-Liste und wiederholen Sie die Zustellung über den Retry-Endpoint. Spielen Sie eine bereits verarbeitete Benachrichtigung erneut ab und bestätigen Sie, dass Ihre Idempotenz-Prüfung sie ablehnt. Reichen Sie dieselbe Auszahlung zweimal ein und verifizieren Sie, dass nur eine rausgeht. Jede Probe dauert Minuten auf Amoy und verhindert später einen echten Vorfall; halten alle drei stand, löschen Sie den Header, und derselbe Code ist in Produktion.

Ihr Webhook-Endpoint füttert Ihr Ledger, härten Sie ihn also wie jeden anderen geldnahen Input.

Signatur zuerst. Setzen Sie ein persönliches Secret in Ihren Profileinstellungen, und jede Benachrichtigung trägt einen X-Signature-Header: ein base64-kodiertes HMAC-SHA256 der txid des Payloads, geschlüsselt mit diesem Secret. Berechnen Sie ihn neu und vergleichen Sie zeitkonstant, bevor Sie den Rest des Payloads anfassen. Alles, was scheitert, bekommt eine 4xx-Antwort und keine Verarbeitung. Verifizierungsbeispiele in Python, Java, PHP und JavaScript stehen im Webhooks-Guide.

Chaingateways IP-Whitelist bewacht die andere Richtung: Im Konto-Panel können Sie den API-Zugriff auf eine Liste Ihrer eigenen Server-IPs beschränken, sodass ein geleakter API-Key nirgendwo sonst nützlich ist. Sie schützt Ihren Key, nicht Ihren Webhook-Empfänger – für den Empfänger ist die Signatur die Echtheitsprüfung. Gegen wiederholte Benachrichtigungen, die per Definition gültige Signaturen tragen, ist Ihre Transaktions-Hash-Constraint die Verteidigung; ein Duplikat wird bestätigt und verworfen. Bedienen Sie den Endpoint nur über HTTPS, und halten Sie Secrets aus der URL heraus, weil URLs in Logs auf Infrastruktur landen, die Sie nicht betreiben.

Fehler kommen als standardmäßige HTTP-Statuscodes mit JSON-Bodies zurück, sodass Ihre üblichen Muster unverändert gelten.

Ein 401 ist ein Authentifizierungsproblem: Der Bearer-Token fehlt, wurde widerrufen oder falsch getippt. Andere 4xx-Antworten sind Validierungsfehler, eine falsche Checksum oder ein unbekanntes Feld, und der Body benennt den Übeltäter; den identischen Request zu wiederholen kann nicht gelingen. Ein 429 bedeutet, dass das Rate-Limit des Plans erreicht ist; drosseln Sie mit steigenden Verzögerungen, und schauen Sie auf die Preisseite, wenn Sie es im Normalbetrieb statt in Spitzen erreichen.

Bei 5xx-Antworten dürfen Sie Reads frei wiederholen. Sends wiederholen Sie nur, nachdem Sie über die Notification-Liste und Ihre eigenen Auszahlungszeilen bestätigt haben, dass der erste Versuch nicht broadcastet wurde. Behalten Sie den vollständigen Response-Body neben dem verursachenden Request in Ihren Logs; diese Paarung verkürzt jede Debugging-Sitzung und jeden Support-Austausch. Statuscodes und Fehlerschemas pro Endpoint stehen in der API-Referenz.

Das Kernmuster ist Zahlungsannahme: eine Deposit-Adresse pro Bestellung, ein Webhook pro eingehendem Transfer, Abwicklung in Sekunden. Händler nutzen es für Checkout, und Plattformen nutzen es für Nutzerguthaben, beobachten Deposits und verarbeiten Abhebungen über Tausende Adressen mit denselben Endpoints.

Die niedrigen Gas-Kosten eröffnen Muster, die anderswo unwirtschaftlich sind: Micro-Auszahlungen an Content-Creator, Airdrops und Vesting-Pläne als schlichte ERC-20-Transfers, wiederkehrende Abo-Abrechnung in Stablecoins, und grenzüberschreitende Zahlungen, bei denen die Gebühr Cent-Beträge statt Prozentpunkte sind.