Polygon Blockchain API: Stablecoin Payments with Low Gas

The name collision is worth two more paragraphs, because half the search results for "polygon api" point at the wrong product. Polygon.io is a US company selling market data feeds: stock quotes, options chains, forex candles. Its API answers questions like "what did AAPL trade at yesterday". It has no blockchain, no tokens and no connection to the network this page covers.

Polygon the blockchain, run by Polygon Labs, is an EVM-compatible proof-of-stake network that settles token transactions. Its API surface, whether raw JSON-RPC or a payments layer like Chaingateway, answers questions like "did the customer's USDC arrive" and executes instructions like "pay out 50 USDT". If you need tickers and OHLC candles, close this tab and search for Polygon.io. If you need to move stablecoins with gas fees measured in fractions of a cent, keep reading.

The most common thing built on Chaingateway's Polygon endpoints is stablecoin payment processing, and the economics explain why. Every ERC-20 transfer needs gas. On Ethereum mainnet, gas for a USDT transfer can cost more than a small payment itself; on Polygon, the same transfer costs pennies at most. Charging someone 2 USDC for a digital product is viable here. On L1 it is not.

The numbers back this up. As of mid-2026, fee trackers put a typical USDT transfer on Polygon PoS between a tenth of a cent and two cents, and it rarely exceeds a few cents even when the network is busy. The same transfer on Ethereum mainnet has ranged from well under a dollar in quiet weeks to several dollars during congestion spikes. The gap moves with gas markets, but it has held at two to three orders of magnitude for years, and for a business model built on small payments that gap is the whole business case.

A typical checkout looks like this: your backend assigns the customer a deposit address and shows a QR code, and the customer sends USDC or USDT from any wallet or exchange. About two seconds later the transfer is in a block. The webhook fires, your server verifies the HMAC signature, and the order flips to paid. No card networks, no chargebacks, no waiting for banking hours.

Chain facts drift, so here are the current ones with dates. As of early July 2026:

Blocks arrive every 2 to 2.3 seconds on average, per PolygonScan's block-time data, and transaction finality sits around 5 seconds. For deposits that means the gap between "customer pressed send" and "safe to credit" is measured in single-digit seconds.

The gas token is POL. The migration from MATIC happened on September 4, 2024, at a 1:1 rate, with balances on the PoS chain converted automatically; Polygon reported the migration 99% complete about a year later. Every transaction on Polygon PoS since then has paid gas in POL.

The testnet is Amoy, anchored to Ethereum's Sepolia. It replaced the older Mumbai testnet, which was retired on April 13, 2024, together with the Goerli network it depended on. Tutorials that still say Mumbai are outdated; the flow they describe usually works on Amoy unchanged.

Every Polygon transaction pays gas in POL, the token that replaced MATIC in September 2024 at a 1:1 rate. The sending address needs a small POL balance for that; receiving tokens costs the recipient nothing. Gas price is set automatically by the API, so integrations rarely tune it by hand.

Balances on the PoS chain migrated from MATIC to POL automatically, so older documentation that still says MATIC means POL today. The usual pattern is a funded hot wallet for payouts, plus consolidation transfers from deposit addresses that you top up with POL as needed. Since a single transfer burns only a tiny fraction of one POL, a modest float covers a lot of traffic.

Every standard ERC-20 contract on Polygon works. USDT, USDC and DAI are supported out of the box, decimals included. If you launched your own token, pass its contract address to the same endpoint and it behaves like any other. NFTs and DeFi tokens follow the same rule. Because the API is identical across chains, code written for Polygon also runs against Ethereum, BSC or Arbitrum once you swap the chain segment in the URL.

Throughput is high enough for gaming and other high-frequency workloads, and costs are low enough that use cases priced out of Ethereum L1 become practical. Large consumer brands have shipped loyalty programs and collectibles on Polygon, which has pulled mainstream users onto the network, and institutional projects keep choosing it for settlement. For your team the entry cost is low: the chain is EVM-compatible, so everything you know about Ethereum carries over unchanged.

Three requests cover the whole payment loop. The exact request schemas are in the API reference; for dry runs against the Polygon testnet (Amoy), add the header X-Network: testnet.

Import an existing wallet:

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"
  }'

The password protects the imported key on the platform; later sends from that address pass the password instead of the raw key.

Send USDT on Polygon (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"
  }'

List past webhook notifications, the fastest way to reconcile deposits against your database:

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

The same three calls translate directly to PHP, Python or Node with any standard HTTP client; there is no Polygon-specific library to install.

Here is the full receiving flow, the way it runs in production rather than in a demo.

Address mapping and attribution

Each customer or order gets its own deposit address, stored in one table: your internal ID, the address, a timestamp. The address in an incoming webhook payload is the lookup key that ties a transfer to an order, and a unique index on that column guarantees no deposit can ever match two orders. If your platform already manages keys, register them once through POST /api/v2/polygon/addresses/import and attach webhooks as described in the webhooks guide.

Verifying and crediting a deposit

When the customer pays, the transfer is in a block within about two seconds and the notification hits your endpoint moments later. Your handler verifies the HMAC signature first, looks up the order by address, and then checks one more thing before crediting: whether it has seen this transaction hash before. Store every processed hash with a unique constraint and let the database refuse duplicates. A delivery your server missed is not gone: it appears under GET /api/v2/polygon/webhooks/notifications/failed, and POST /api/v2/polygon/webhooks/notifications/{id}/retry sends it again, so a timeout on your side never loses a deposit; idempotent processing is what keeps a replayed notification from crediting one twice.

How long to wait before releasing goods

That is a business decision, not a technical one. Finality on Polygon arrives around 5 seconds after inclusion, so even a cautious policy costs little: credit a 3 USDC purchase on the first notification, hold a four-figure deposit until your reconciliation check against GET /api/v2/polygon/webhooks/notifications confirms it. That endpoint doubles as your audit trail; a nightly diff against your own ledger catches anything a two-hour outage might have obscured.

Sweeping deposit addresses

Deposit addresses fill up over time, so schedule a sweep: a job that consolidates balances into your treasury wallet with the same POST /api/v2/polygon/transactions/erc20 call, from set to the deposit address. Each swept address needs a trace of POL for gas, which at Polygon prices is small enough to pre-fund in bulk.

Withdrawals are the flow where mistakes cost money directly, and two habits remove most of the risk.

Validate before you queue. A destination address must decode as a 20-byte 0x value, and when it contains mixed-case letters, the EIP-55 checksum must match. Reject failures at the form, where the user can fix a typo; the API validates again before broadcasting, but the earlier the catch, the cheaper it is.

Write first, send second. Create one database row per payout with a state machine (queued, sent, confirmed), let a worker make exactly one POST /api/v2/polygon/transactions/erc20 call per row, and store the returned transaction hash immediately. Give the user that hash as a PolygonScan link, and they can track their own withdrawal instead of writing to support. If the API call times out, do not fire again on reflex: check the notification list and your own records to confirm nothing went out, then retry deliberately. The hot wallet needs a POL float for gas; on Polygon a small balance covers thousands of transfers, so a monthly top-up is enough.

Amoy is Polygon's Sepolia-anchored testnet, live since early 2024 as the replacement for Mumbai, and every endpoint on this page runs against it when you add one header:

X-Network: testnet

No separate account, no second key, no other change. Test POL comes from the public Amoy faucets, and the addresses and mechanics match mainnet exactly.

Spend the test run on failure paths rather than the happy path. Kill your webhook endpoint, send a deposit, bring the endpoint back, then read the failed-notifications list and replay the delivery through the retry endpoint. Replay a notification you already processed and confirm your idempotency check rejects it. Submit the same payout twice and verify only one leaves. Each rehearsal takes minutes on Amoy and prevents a real incident later; when all three hold, drop the header and the identical code is in production.

Your webhook endpoint feeds your ledger, so harden it like any other money-adjacent input.

Signature first. Set a personal secret in your profile settings, and every notification carries an X-Signature header: a base64-encoded HMAC-SHA256 of the payload's txid, keyed with that secret. Recompute it and compare in constant time before touching the rest of the payload. Anything that fails gets a 4xx response and no processing. Verification examples in Python, Java, PHP and JavaScript are in the webhooks guide.

Chaingateway's IP whitelist guards the other direction: in the account panel you can limit API access to a list of your own server IPs, so a leaked API key is useless from anywhere else. It protects your key, not your webhook receiver — for the receiver, the signature is the authenticity check. Against replayed notifications, which carry valid signatures by definition, your transaction-hash constraint is the defense; a duplicate gets acknowledged and dropped. Serve the endpoint over HTTPS only, and keep secrets out of the URL, because URLs leak into logs on infrastructure you do not operate.

Errors come back as standard HTTP status codes with JSON bodies, so your usual patterns apply unchanged.

A 401 is an authentication problem: the Bearer token is missing, revoked or mistyped. Other 4xx responses are validation failures, a bad checksum or an unknown field, and the body names the offender; retrying the identical request cannot succeed. A 429 means the plan's rate limit is reached; back off with increasing delays, and look at the pricing page if you hit it in normal operation rather than in bursts.

For 5xx responses, retry reads freely. Retry sends only after you have confirmed, via the notification list and your own payout rows, that the first attempt was not broadcast. Keep the full response body in your logs next to the request that caused it; that pairing shortens every debugging session and support exchange. Per-endpoint status codes and error schemas are in the API reference.

The core pattern is payment acceptance: a deposit address per order, a webhook per incoming transfer, settlement in seconds. Merchants use it for checkout, and platforms use it for user balances, watching deposits and processing withdrawals across thousands of addresses through the same endpoints.

The low gas costs open patterns that are dead on arrival elsewhere: micro-payouts to content creators, airdrops and vesting schedules executed as plain ERC-20 transfers, recurring subscription billing in stablecoins, and cross-border payments where the fee is cents instead of a percentage.