A2 Route Check an address — free

How to check incoming USDT before accepting a payment

A customer wants to pay an invoice in USDT. The amount is right, the deadline is close, and the sales team wants to release the goods. Before treating that payment as settled, separate three questions: who is paying, which transfer is involved, and what the available blockchain evidence says. A wallet check helps with the last question. It does not answer the other two for you.

Start before the customer sends

Ask for the intended sending address, the network and the invoice reference. Confirm that the asset and network match your receiving instructions. An address copied from an old message can belong to a different person or describe a different payment. Have someone verify the details against the actual trade ticket rather than relying on a screenshot forwarded through several people.

An address check before payment is a useful first look, not a check of a future transaction. The customer may send from another wallet, or a service may process the withdrawal. Agree that any change in the proposed sender should be raised before settlement. Do not describe a preliminary check as approval of whichever funds arrive later.

A2 Route supports address screening and USDT/USDC transaction screening on TRON and Ethereum. Use the supported network that matches the payment. See the product page for the current scope. This guide does not extend that scope to other chains or tokens.

Screen the right subject

Record whether you checked an address or a transaction. Before a transfer exists, there is no transaction hash to inspect. Once funds arrive, compare the actual sender, recipient, asset and amount with your records and screen the supported transfer. Keep the address result and transaction result distinct, even if they appear to concern the same customer.

For a fictional training exercise, use labels such as FAKE_SENDER_NOT_A_WALLET and FAKE_TRANSACTION_NOT_A_HASH. These are deliberately invalid, synthetic identifiers, not addresses or hashes to submit to a screening service. In a real trade ticket, keep the actual payment identifiers in your private records, not in a public guide or shared demonstration.

Read more than the headline

A useful review includes the verdict, score, source shares, top exposure and any stated coverage limits. A2 Route's public report description includes those items, sanctions lists and a risk-categories appendix. A reassuring verdict is still an informational screening result. It cannot prove that a customer owns the sending wallet or that an invoice describes a genuine trade.

Check the screening time. Compare it with the payment timeline and read any reduced-coverage warning. A2 Route's public FAQ says a partial result indicates reduced coverage and recommends a re-check. Do not silently treat a partial result as equivalent to complete evidence. If the decision cannot wait, escalate that uncertainty to the person responsible for accepting the payment.

Read wallet risk scores if the number is driving the discussion. Read direct and indirect exposure if a source label or intermediary path is the reason for concern. Neither a number nor a category name should replace an explanation of the actual finding.

Decide what happens to the order

Write a receiving policy that the sales and finance teams can follow. For example, a flagged result can pause release of goods while a named reviewer checks the evidence. That is an internal operational choice, not a claim that a particular threshold satisfies any law. Decide who can approve an exception and what supporting records they need.

If a payment has already arrived, avoid making a hurried onward transfer simply to remove it from the receiving wallet. Keep the trade on hold while the responsible reviewer decides the next step. A proposed return payment needs its own review and verified instructions. A stranger supplying a new return address in a chat is not enough evidence of authority.

Ask focused questions: did the customer send from the agreed wallet, did an intermediary handle the payment, and can they explain the payment source? Record the answer accurately. A customer's explanation may help investigate a mismatch, but it does not change the blockchain evidence by itself. For a flagged wallet, use the step-by-step review guide.

Keep a record someone else can understand

Save the screening result with the invoice, payment details, customer correspondence and decision. Note who reviewed it, what was uncertain and why the business proceeded or declined. Keep the original result if you re-check later. A changed label is easier to understand when the earlier evidence and its timestamp are still available.

If incoming USDT will fund a supplier payment, plan that next decision separately. The A2vanta business payment blog is a starting point for supplier-payment reading; an incoming check does not approve an outgoing destination. See how to read the report before attaching a PDF to the deal file.

If a flagged payment has already arrived, use the received-USDT response checklist. If the team disagrees about the chain, compare TRON and Ethereum screening details before choosing the subject.

Start a supported wallet check with A2 Route, or read the business API documentation for a repeatable intake workflow. The report is an informational tool, not legal advice, a promise of clean funds or a guarantee of regulatory compliance. Your business decision still needs its own accountable owner.