USDT wallet address monitoring and notifications: observation versus member top-ups
USDT wallet address monitoring tracks chain activity. Payment notifications connect a confirmed collection result to your business. A balance change, a completed payment order and a credited member account are separate events. Choose the wallet mode before designing account matching and notification handling.
Observe an existing wallet address
Add an external address for its network in wallet management to observe receipts or use it as a sweep destination. Observation does not import a private key, and the platform cannot sign payouts from that address. It does not replace dedicated member addresses. See wallet types.
USDT uses TRC20 or BEP20; USDC uses BEP20 or SPL. Check both the asset and network rather than merging balances of the same token across chains. Fee top-up addresses belong to the separate fee account, not customer collection wallets.
Monitoring does not identify a member
Multiple people can send to one address. A higher balance alone does not identify the member or invoice to credit. Use the verified order-matching or dedicated-binding flow, retaining the relationship between a business object and payment records.
External address observation is not a promise of custom webhooks for every arbitrary chain transaction. Business callbacks come from the applicable collection order or dedicated top-up flow under the current API contract.
Bind a member with bindKey
Derive a stable bindKey from an authenticated member on your server, then create or query a dedicated binding for the merchant, network and asset. Save bindingId, addressId, address and bindKey before showing the address to that member. Repeated binding may reuse the original result; it does not overwrite label or notifyUrl.
The binding API does not return cashierUrl. Use your own top-up page or copy the wallet checkout link from the console. Follow the dedicated collection tutorial.
Credit wallet notifications safely
After chain confirmation and platform processing, a dedicated receipt produces an order and sends its configured callback. Verify the rawBody with the original order's API Key, then check merchant identity, order number, network, asset, bindKey, completed status and paidAmount.
Create a unique credit record for merchant plus orderNo, and deduplicate and update the account balance in one database transaction before returning HTTP 2xx. Repeated notifications acknowledge the existing result. Deduplicating by bindKey alone would discard a second valid top-up. See the callback protocol.
Investigate funds without a notification
Check the transaction network, token, destination and confirmations first, then binding activity, collection status, notifyUrl, signature verification and application logs. Query the original platform order when its number is available; dedicated binding queries also expose recent orders and transactions.
The console callback button actively resends a notification. Use it only after repairing the receiver and verifying idempotency, rather than to view logs. See callback recovery.
Reconcile balances and receipts
Real chain RPC is the authority for wallet balances; list snapshots and ledger records help trace activity. Failed monitoring means an unknown balance, not zero. Sweeps, payouts and other transfers change current funds, so cumulative receipts are not the current wallet balance.
- Retain query time, network, asset, order references and chain evidence.
- Record payment confirmation, notification receipt and member credit separately.
- Inform users before disabling or changing a wallet, and retain historical ownership.
See the reconciliation guide.
Match the flow to your business
Start with wallet types for existing-address observation, dedicated addresses for member top-ups, or the USDT API for fixed-amount website orders. Compare payment entries in the checkout guide.