USDT 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
TRC20	USDT	TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6tCopy	6
ERC20	USDT	0xdAC17F958D2ee523a2206206994597C13D831ec7Copy	6
BEP20	USDT	0x55d398326f99059fF775485246999027B3197955Copy	18
POLYGON	USDT	0xc2132D05D31c914a87C6611C10748AEb04B58e8FCopy	6
SOLANA	USDT	Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYBCopy	6
BASE	USDT	0xfde4c96c8593536e31f229ea8f37b2ada2699bb2Copy	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

USDT is supported on six networks. The configured BNB Smart Chain token uses 18 decimals; the other five use 6. Token decimals are separate from order amount precision. Base uses the configured bridged USDT: BoltUtil does not bridge funds. Select the order network and the exact listed token version; a shared symbol or wallet address does not make networks or tokens interchangeable.

• TRC20 is the API code for TRON. Only USDT is supported; do not send currency=USDC.
• USDT has 6 token decimals. This does not require displaying six decimals for every order; use the returned payable amount.
• Confirmation follows system configuration and scanning results, without a guaranteed number of seconds.

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":"USDT","network":"TRC20","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