USDC payment integration guide

Supported mainnet token identities

These contracts or mints are project defaults, not live channel status. Order creation also requires an enabled network and asset plus a valid merchant wallet. Always pay payment.address from the API, never the token contract or mint.

Supported mainnet token identities

Network	Currency	Contract / Mint	Token decimals
ERC20	USDC	0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48Copy	6
BEP20	USDC	0x8ac76a51cc950d9822d68b83fe1ad97b32cd580dCopy	18
POLYGON	USDC	0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359Copy	6
SOLANA	USDC	EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1vCopy	6
BASE	USDC	0x833589fcd6edb6e08f4c7c32d4f71b54bda02913Copy	6

Merchant setup

1. Configure a receiving wallet for the network and an enabled Webhook URL and secret. Keep the API Key and HMAC secret on your server.
2. Check availability of the network / currency combination. Platform administrators maintain RPC, network and asset configuration; merchants do not need to deploy scanners.
3. Display payment.amount, payment.address, currency, network and expiry from the response. QR data is not an image.
4. Verify, deduplicate and durably accept events before returning HTTP 2xx; fulfill your business order idempotently.

Network and asset notes

Ethereum, Polygon, Solana and Base use native USDC. BNB Smart Chain uses Binance-Peg USDC with 18 token decimals. TRC20 does not support USDC. USDbC, USDC.e and other contracts cannot replace the listed identities.

• ERC20 in this API means Ethereum mainnet, not every network using the ERC20 token standard.
• The same 0x address may exist on different EVM networks. Customers must choose the order network and token version.
• Ethereum USDC uses the native Circle contract. Other bridged versions cannot replace the listed identity.

Signed request and response examples

Examples use 25.00 to demonstrate the format. Real amounts come from your business order and must meet the configured asset minimum. Addresses, orders and hashes are examples, not actual payments. The copied cURL / Java program sends a request: configure your own API Key and Webhook secret before running it.

# Run against your account only when ready; this sends an API request.
: "${BOLTUTIL_API_KEY:?Set your complete API Key}"
: "${BOLTUTIL_WEBHOOK_SECRET:?Set your Webhook secret}"
timestamp=$(python3 -c 'import time; print(int(time.time()*1000))')
body='{"amount":"25.00","currency":"USDC","network":"ERC20","externalOrderId":"INV-20260209-99281"}'
signature=$(printf '%s.%s' "$timestamp" "$body" | openssl dgst -sha256 -hmac "$BOLTUTIL_WEBHOOK_SECRET" | awk '{print $NF}')

curl --request POST "https://api.boltutil.com/api/v1/order/create" \
  --header 'Content-Type: application/json' \
  --header "X-Bolt-Key: $BOLTUTIL_API_KEY" \
  --header "X-Bolt-Timestamp: $timestamp" \
  --header "X-Bolt-Signature: $signature" \
  --data-binary "$body"

Confirmation and callback handling

Detection is not confirmation. Use system status and verified callbacks: PAID still awaits confirmation. CONFIRMED / COMPLETED may also follow manual acceptance; check paidAmount, shortfallAmount and settlementType. COMPLETED does not prove that your business has fulfilled the order.

Integration questions