Dedicated vs shared addresses for USDT / USDC payments

2026-06-16 · Updated 2026-10-01 · UUGate · 3 min read

One-off purchases and ongoing membership funding need different mappings. Choose a model based on the business identity, amount matching, and signing authority rather than address persistence alone.

Choose the network and payment model

Shared fixed-amount orders map merchant orders to platform orders and follow expiry and amount-allocation rules. An active order with the same amount may produce 40105. Dedicated bindings map bindKey, network, asset, and address for ongoing deposits.

API parameters and integration steps

Start shared collection with POST /openapi/payin/orders and dedicated funding with POST /openapi/payin/exclusive-bindings. Supported combinations remain TRC20-USDT, BEP20-USDT, BEP20-USDC, and SPL-USDC; changing the wallet model does not add networks.

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": "TRON",
  "tokenSymbol": "USDT",
  "merchantOrderNo": "DEMO_PRODUCT_001",
  "amount": "10.00",
  "notifyUrl": "https://merchant.example.com/payments/notify"
}

Statuses, callbacks, and exceptions

A business binding is separate from signing authority. Platform-generated custodial wallets can pay out subject to permissions. Imported watch-only addresses support monitoring but cannot be signed by the platform. Dedicated collection does not make every imported address custodial.

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 10.00 USDT product gets a fixed-amount checkout order. A long-term MEMBER_DEMO_001 account stores a dedicated binding whose later deposits create records. Both flows end in verified, once-only accounting, but their ownership lookup must remain distinct.

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.