USDT membership top-up API: dedicated bindings and reconciliation

2026-07-17 · Updated 2026-10-01 · UUGate · 3 min read

Membership top-ups must reliably identify who owns each deposit. Fixed-price purchases use collection orders; ongoing account funding can bind a dedicated address to a stable membership identity.

Choose the network and payment model

USDT is supported on TRON (TRC20) and BSC (BEP20). Select the network customers actually use. Store bindKey, chain, asset, bindingId, and address. Customer deposits and merchant fee-account top-ups are different flows; do not share the platform fee top-up address.

API parameters and integration steps

Create or reuse a binding with POST /openapi/payin/exclusive-bindings. Use your stable member identifier as bindKey and your HTTPS top-up callback as notifyUrl. Query GET /openapi/payin/exclusive-bindings/{bindKey}?chainCode=TRON&tokenSymbol=USDT&recentLimit=10. bindKey is not a platform orderNo.

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",
  "bindKey": "MEMBER_DEMO_001",
  "label": "Demo member",
  "notifyUrl": "https://merchant.example.com/member-topups/notify"
}

Statuses, callbacks, and exceptions

Deposits create collection records. Match bindKey to the member and validate completed, paidAmount, and network before posting each credit. Cumulative stats are not the amount of a new deposit. Investigate recentOrders, query individual platform orders, and run compensation through the same deduplication path.

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: MEMBER_DEMO_001 deposits 10.00 and 5.00 USDT to a TRON binding. Two verified orders credit 15.00 in total. Redelivery of the second callback does not add another 5.00. This contains no real member or transfer; validate the flow in your own system before launch.

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.