You're at the withdrawal screen while your buyer in Yiwu waits for a payment reference for ceramic mugs. The exchange lists TRC20 and ERC20, with different charges beside them. The supplier has sent an address and the words "send USDT", without a blockchain name. You need the recipient to name the accepted network before choosing between those lines.

This article is general information. It is not legal, tax or investment advice, and it does not guarantee that a transfer will arrive or that an error can be recovered.

Put the blockchain name beside the address

Tether lists TRC20 USDT on TRON and ERC20 USDT on Ethereum in its supported protocols. Use that page to check the relevant protocol and token identifier. A logo or ticker in a withdrawal menu doesn't establish token identity.

ERC20 describes a token standard. Tether's protocol page includes several blockchains under that standard, so you still need the blockchain name alongside that label. If your recipient says "Ethereum" while the menu displays "ERC20", get confirmation that both parties mean the same route before proceeding.

The token identifier is separate from your receiving address. The issuer publishes identifiers for tokens; the recipient provides a destination for your transfer. Don't copy a token contract address from an issuer's website into the receiving-address field. Your colleague checking the instruction needs both details under separate labels.

Work out who receives the USDT

For a direct wallet payment, the supplier must confirm their destination and how they will match the transfer to the mug invoice. Find out whether the address belongs to them or to a platform account they use. The receiving instructions for that account matter as much as the address they pasted into the chat.

If you're funding a bank payout with USDT, the payment provider receives your funding. The supplier confirms their bank details, and may have no role in choosing the funding network. Get the USDT instruction from the party receiving the USDT rather than expecting the supplier's salesperson to answer for someone else's account.

Write the recipient's name and invoice reference beside the confirmed funding instruction. If a new address arrives after the quote, pause and confirm the change through the contact channel you used for that enquiry. Save both versions so your colleague can see the change before approving payment.

Check both ends of the transfer

Your sending platform must permit withdrawal of the asset on the agreed network. The receiving party must confirm that they accept that asset on that network for the receiving account. You cannot infer the recipient's deposit rules from a menu entry at the sending end.

You cannot settle this from the appearance of the address. You need confirmation of the account, asset and blockchain as a combination. If either party cannot confirm that combination, resolve the question before sending. A colleague recognizing the first characters of an address hasn't checked the receiving platform's rules.

If you hold USDT on another network, describe that situation to the recipient before swapping or bridging. Confirm the transfer arrangement they accept. Record any conversion apart from the supplier funding, so your accountant can trace how you obtained the asset you sent.

Check withdrawal limits with the sender and receiving minimums with the recipient. Finance needs the intended transfer amount and an explanation of how the sending platform treats the displayed withdrawal charge. Your supplier's expected invoice credit should rest on agreed instructions, rather than a figure you read from an unchecked menu.

Give a colleague the whole instruction

For a useful second check, your colleague compares the entire destination address with the source instruction you confirmed. Include the network and token identity. If you compare only the beginning and end, you haven't checked the middle, even if the two strings look familiar on a small screen.

If the sending platform requests another routing field, get an instruction from the receiving party about that field. The invoice number belongs in your purchase record; entering the number into an unexplained field may create a different error. Don't guess what the platform intends you to supply.

You and the recipient need to agree on the test transfer amount and how they will identify receipt. Discuss those points before making the test, then confirm acceptance of the intended payment before sending the remaining funds. Save the test as a separate transaction. You cannot assume the larger payment will clear because the recipient received a small amount.

Match the transfer to the invoice

After sending, save the transaction ID, network, amount and time, plus a platform withdrawal reference if you have one. The recipient should use the reference you agreed in their acknowledgement. Finance needs that connection to identify which transfer concerns the mugs.

For a bank payout, the USDT transaction covers funding. Your accountant needs evidence for the payout and confirmation of the invoice credit to check the supplier's bank receipt. Find out which evidence the provider can supply and the payout's status before closing the invoice. Your accountant needs to trace both legs.

Pause further transfers after a network error. Collect the exact asset and network used and contact the receiving platform through official support. You cannot repair the first transfer by sending again, and finance may have to follow two unresolved records.

To discuss a proposed A2vanta payment, use the invoice-payment page and A2vanta overview, or contact the bot. State the network on which you hold USDT and the supplier's required receipt method. Get instructions for that request before using a funding address from another enquiry.