USDC collection API: BEP20 and Solana integration and validation

2026-07-11 · Updated 2026-10-01 · UUGate · 4 min read

USDC collection suits digital goods, subscriptions, and membership services whose customers already use BSC or Solana wallets. Identify their supported networks before choosing a payment flow. The same asset name does not make payments interchangeable across networks.

Choose the network and payment model

UUGate supports BSC-USDC (BEP20) and SOL-USDC (SPL). Use chainCode=BSC or SOL respectively. Configure a matching merchant wallet and display the network, address, and amount together. TRON-USDC and planned networks are not currently supported.

API parameters and integration steps

Use POST /openapi/payin/orders for a fixed-price purchase. Persist merchantOrderNo and the returned orderNo, address, cashierUrl, and expireAt before sending the customer to the returned checkout URL. Dedicated bindings are an alternative for ongoing account top-ups.

This request body is illustrative. No request is sent and no real merchant, key, or transaction is included. A complete server-side request also needs the documented UID, API Key, timestamp, nonce, and signature. Send amounts as strings and use precise arithmetic for accounting.

{
  "chainCode": "BSC",
  "tokenSymbol": "USDC",
  "merchantOrderNo": "DEMO_PRODUCT_001",
  "amount": "10.00",
  "notifyUrl": "https://merchant.example.com/payments/notify"
}

Statuses, callbacks, and exceptions

Waiting and confirmation stages are not fulfillment success. Use completed as the success state and GET /openapi/payin/orders/{orderNo} to compensate for unavailable callbacks. Underpayments, wrong assets, wrong networks, and late transfers need investigation; do not promise automatic cross-chain recovery.

If collection creation times out without an orderNo, inspect the original business order in the dashboard. Do not assume merchantOrderNo guarantees automatic idempotent creation retries. If orderNo is available, query that platform order. Callback deduplication and creation retries are separate concerns.

Use the API Key associated with the original order and the unchanged rawBody. Verify HMAC-SHA256(timestamp + "." + nonce + "." + rawBody) against x-callback-signature. Then validate identity, order, asset, network, and amount. Use a database transaction and uniqueness constraint to process once; acknowledge with HTTP 2xx only after reliable persistence. A browser redirect is not payment confirmation.

Illustrative integration from API to fulfillment

Illustration: a digital product costs 10.00 USDC. Create a BSC order and save its reference. After payment, verify the completed callback and write the payment plus one download entitlement in one transaction. A repeated callback grants nothing extra. A timeout triggers an original-order query. This is a design example, not a customer transaction.

Checks before launch

Valid signatures pass; changing the raw callback body causes verification to fail.
Duplicate notifications credit once; interrupted processing can resume.
Queries, callbacks, business entries, and on-chain transactions reconcile.
Wrong networks, amount exceptions, expiry, and unknown results require investigation rather than immediate success.

Integration and technical references

These sources explain underlying standards and implementation. They do not imply endorsement of UUGate. Follow the current UUGate documentation for integration parameters.