Separate payment matching from webhook delivery
A pending customer experience can come from two different layers: the chain scanner did not match the transfer, or the merchant application did not process the callback.
Why a USDT payment can stay pending after the customer paid
A successful-looking blockchain transaction does not always mean a merchant order should be completed. Pending USDT orders usually come from a mismatch between the transfer and the order rules, or from a webhook delivery problem after the order is already paid.
- Built for
- Pending order triage
- Built for
- Mismatch diagnosis
- Built for
- Webhook recovery
Pending payment checklist
Pending USDT order triage
Network mismatch? TRC20 vs ERC20 vs BEP20
Token contract mismatch? USDT Transfer vs native coin or other token
Amount mismatch? Exact normalized USDT amount
Address mismatch? Transfer.to vs order destination
Confirmation delay? Current confirmations vs required threshold
Order window issue? Payment time vs order expiration
Webhook issue? Paid order but merchant app not updatedPending USDT payment triage flow
Best for merchants and support teams investigating paid-but-pending USDT orders across TRC20, ERC20, and BEP20.
- 01
First decide whether the payment is not detected or the payment is detected but the merchant app did not update.
- 02
If it is not detected, compare network, token contract, destination address, amount, expiration, and confirmations.
- 03
If the order is already completed in BoltUtil, inspect webhook logs, merchant response codes, and signature verification.
- 04
After fixing the underlying cause, use the order status API or webhook resend flow instead of manually fulfilling twice.
Focus on objective mismatch checks
The fastest support path is to compare network, USDT contract, destination address, amount, confirmations, and order expiration instead of debating screenshots.
Recover safely after the issue is fixed
Use idempotent fulfillment, order status reconciliation, and webhook resend so the customer is credited once and audit logs remain clean.
Integration notes
What matters before production
Wrong network is the most common customer mistake
USDT exists on several chains. A customer may send TRC20 while the order expects ERC20, or choose BEP20 from an exchange withdrawal screen by mistake.
A successful tx hash can still be the wrong asset
Native ETH, BNB, or TRX transfers are not USDT token transfers. Other stablecoin contracts should also be rejected by a production gateway.
Webhook failures look like payment failures to the customer
If BoltUtil completed the order but the merchant app returned an error, the next step is webhook log review and resend, not chain scanning.
Questions merchants ask before going live
These answers help developers, founders, and support teams understand the payment lifecycle before accepting real USDT payments.
Why is my USDT payment pending even though the transaction succeeded? +
The transaction may not match the order network, USDT contract, destination address, exact amount, confirmation rule, or expiration window.
What if BoltUtil shows completed but my app still shows unpaid? +
That usually points to webhook delivery, signature verification, or merchant-side fulfillment logic. Check webhook logs and resend after fixing the endpoint.
Should I manually mark pending payments as paid? +
Only after verifying the chain facts and your internal order rules. Keep fulfillment idempotent and record the tx hash to prevent duplicate credit.
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