Start with chain facts
A tx hash lets support teams verify the network, token contract, transfer target, value, and confirmation status without relying on screenshots.
How to debug a USDT payment that did not match an order
A successful blockchain transaction can still fail to match a merchant order. The fastest way to diagnose it is to compare objective chain facts against the order rules before touching fulfillment manually.
- Built for
- Tx hash triage
- Built for
- Order matching rules
- Built for
- Support workflow
Unmatched payment checklist
USDT payment did not match an order
Start with the tx hash:
1. Open the correct explorer for TRC20, ERC20, or BEP20
2. Confirm the transfer is a successful USDT Transfer
3. Compare network, token contract, destination, and amount
4. Check order status, expiration time, and confirmations
5. Search whether the tx hash already completed another order
6. If chain facts match, inspect scanner lag and webhook logsUnmatched USDT payment triage flow
Best for support teams and developers investigating customers who paid USDT but still see an unpaid or pending order.
- 01
Collect the tx hash and identify the network the customer actually used.
- 02
Verify the transaction is a successful USDT Transfer from the configured token contract.
- 03
Compare destination address, normalized amount, confirmations, order status, and expiration.
- 04
Check duplicate tx hash records and scanner/webhook logs before manually completing anything.
Separate mismatch from delay
Some payments are genuinely wrong. Others are correct but still waiting for confirmations, scanner catch-up, or webhook processing.
Protect fulfillment from duplicates
Before marking an order paid, check whether the same transaction hash has already completed another order.
Integration notes
What matters before production
The wrong network is still a real payment
A customer may successfully send TRC20 USDT while the order expects ERC20. The chain transaction succeeded, but it should not complete that order.
Expired orders need policy, not guesswork
If a customer pays after expiration, the system should follow a consistent refund, manual review, or credit policy rather than silently completing old orders.
Scanner lag and webhook failure are different incidents
If no order is completed, inspect scanner progress. If the order is completed but the merchant app is stale, inspect webhook delivery.
Questions merchants ask before going live
These answers help developers, founders, and support teams understand the payment lifecycle before accepting real USDT payments.
Why did a successful USDT transfer not match my order? +
The transfer may be on the wrong network, use the wrong token contract, target the wrong address, send a different amount, arrive after expiration, or still be below the confirmation threshold.
Should support manually complete the order? +
Only after verifying the chain facts and internal order rules. Record the tx hash and keep fulfillment idempotent.
What if the order is completed in BoltUtil but not in my app? +
That is usually a webhook delivery or merchant-side processing issue, so inspect webhook logs and resend after fixing the endpoint.
Related resources
Launch a cleaner USDT payment flow
Create orders, monitor transfers, and notify your backend without asking customers to send screenshots.
Create free account