Wallets and pay-ins
Exclusive wallets for deposits — recommended
Recommended for member deposits: no amount to enter in advance, no payment countdown, and credit based on the amount received. Learn the dashboard, API binding, queries and callbacks.
Watch the video03:28 · English audio and captions
Watch in full screen or choose a chapter to jump to an operation. Use addresses and order details from your own dashboard when sending or receiving funds.
Step-by-step guide
Follow these steps in your own dashboard. Select an image to enlarge it.
Why we recommend this mode: assign a dedicated receiving address to each member. Members can deposit repeatedly without entering an expected amount or working within a fixed pay-in order deadline. This avoids mismatches caused by a different amount or an expired order. It suits member balance top-ups and repeat customer deposits. Shared wallets remain an option for fixed-price orders. Exclusive wallets still require the correct network and asset, an active binding and blockchain confirmations.
Step 1 · Click to enlarge Create a wallet in the dashboard: open Wallets → Create wallet, choose the asset, then select Exclusive wallet. Supported pairs are TRC20-USDT, BEP20-USDT, BEP20-USDC and SPL-USDC. Match the member's sending network. Do not give members the fee top-up address from the header.
Step 2 · Click to enlarge Bind the member: enter a stable, unique identifier such as MEMBER_10001 in Binding info. This maps to bindKey, not the merchant UID. For automatic member credits, enter your server's publicly reachable HTTPS callback URL as notifyUrl. Leave it blank to use merchant defaults. Check the address quota, create the wallet, and find it in the list after success.
Step 3 · Click to enlarge Find an existing wallet: filter Mode by Exclusive wallet, then check the asset, binding and enabled status. Dashboard-created and API-created wallets belong to the same merchant and appear in the same list. Reuse the binding for the same member, network and asset; never assign one binding to different members.
Step 4 · Click to enlarge Share payment information: select the collection icon in the wallet row to open its checkout directly. No amount or payment countdown is required. Share the complete address or checkout link with the intended member and specify the matching network and asset. Keep the wallet enabled for repeat deposits. Before disabling it, tell the member to stop sending funds to that address.
Step 5 · Click to enlarge Integrate and debug: select Create Exclusive Wallet in the official API debugger. Provide chainCode, tokenSymbol and bindKey, plus label and notifyUrl if needed. POST /openapi/payin/exclusive-bindings does not take amount, expireMinutes or merchantOrderNo. It creates the member binding; actual deposits generate exclusive pay-in orders after detection. The debugger and dashboard refer to the same exclusive wallet mode.
Step 6 · Click to enlarge Authenticate the request on your server using Merchant UID and API Key. Include x-api-key, x-merchant-uid, x-timestamp, x-nonce and x-signature. The HMAC-SHA256 signing payload has seven lines: UID, millisecond timestamp, nonce, uppercase HTTP method, path without the query, canonical query and canonical body. Prefer the official SDK or debugger-generated code. Use a fresh timestamp and nonce each time. Check the binding and callback URL before submitting: Create Production Exclusive Wallet creates a real binding.
Step 7 · Click to enlarge Save the response: retain bindingId, addressId, address, bindKey, chainCode, tokenSymbol and status. The status should be active. Repeating the same merchant + network + asset + bindKey returns the existing binding, supporting get-or-create behavior. It does not replace the original label or notifyUrl. No cashierUrl is returned. Display the returned address on your own deposit page, or copy the checkout link from the dashboard.
Query the binding and deposits with GET /openapi/payin/exclusive-bindings/{bindKey}?chainCode=TRON&tokenSymbol=USDT&recentLimit=10. URL-encode bindKey in the path. GET has no body, but its query participates in signing. The response includes stats, recentOrders and recentTransactions. recentLimit accepts 1–20 and covers recent records only, not a full ledger. Query an individual order with GET /openapi/payin/orders/{orderNo}.
Credit members automatically: after processing a deposit, the platform sends a callback to the wallet's notifyUrl, or the merchant default if none is set. Verify the original rawBody using the API Key associated with that order. Check the merchant, network, asset, bindKey and status=completed, then credit paidAmount, the amount actually received. Use merchant + orderNo as a unique key and commit deduplication and the balance increase in one database transaction. Return HTTP 2xx after success. Acknowledge duplicates without crediting again. Never deduplicate only by bindKey, or a member's next deposit could be ignored.
Step 10 · Click to enlarge Reconcile in the dashboard: open Payins and filter Address / Label / bindKey by the member or wallet address. Check the exclusive order, amount, status and transaction hash, then reconcile with Wallet Ledger and your member credit records. The Callback button resends a notification; it does not open a read-only history. Ensure your receiver handles duplicates before resending.
Step 11 · Click to enlarge Test and troubleshoot: first verify binding reuse, queries and callback signatures, then validate real deposits according to your own acceptance process. For a missing member credit, check network, asset, binding, address, blockchain confirmations, order status, callback configuration and server logs. A redirect or QR code alone does not prove payment. For signature failures, check canonicalization, time and nonce. For a missing binding, check merchant, network, asset and bindKey. Also check account status, address quota and fee balance if an operation is blocked.
Reuse each member's binding for the same network and asset. Credit only after verifying a completed callback and the amount actually received. If a deposit is missing, check the original transaction and order before retrying or manually adjusting the member's balance.
Member deposit flow
Member signs in and selects a network and asset
→ Server obtains that member’s stable bindKey
→ Create or query the exclusive binding and reuse its address
→ Member chooses an amount and sends it to that address
→ Platform detects and confirms the deposit, then generates an exclusive order
→ Verify the completed callback and credit paidAmount exactly once per order
→ Reconcile dashboard orders and ledgers with your member credit recordsNode.js: create or reuse a binding (creates a real wallet)
import { UUGateClient } from 'uugate-openapi-sdk';
const client = new UUGateClient({
baseUrl: 'https://api.uugate.com',
merchantUid: process.env.UUGATE_MERCHANT_UID,
apiKey: process.env.UUGATE_API_KEY,
});
const binding = await client.createExclusiveBinding({
chainCode: 'TRON',
tokenSymbol: 'USDT',
bindKey: 'MEMBER_10001',
label: 'MEMBER_10001',
notifyUrl: 'https://merchant.example.com/uugate/notify',
});Node.js: query a binding and recent deposits (reuse client above)
const bindKey = 'MEMBER_10001';
const detail = await client.request('GET',
'/openapi/payin/exclusive-bindings/' + encodeURIComponent(bindKey), {
query: { chainCode: 'TRON', tokenSymbol: 'USDT', recentLimit: 10 },
});Callback crediting logic (pseudocode; implement in your database transaction)
Preserve the original HTTP request body as rawBody
Verify x-callback-signature with the API Key associated with the order:
HMAC-SHA256(apiKey, timestamp + "." + nonce + "." + rawBody)
Validate timestamp, replay protection and business fields
Require the correct merchantUid and status == "completed"
Find the member binding by bindKey + chainCode + tokenSymbol
Within one database transaction:
Insert the deposit with unique key (merchantUid, orderNo)
Already recorded → do not credit again
First record → increase member balance by paidAmount using decimal arithmetic
Return 2xx after success; return non-2xx and log the error on failure
// bindKey identifies a member; orderNo identifies one deposit. Do not interchange them.