Match the invoice's asset, network, receiving address and amount as one instruction. A token symbol or familiar address format is insufficient. Check the sending wallet's network and fee behaviour before authorising a transfer, and use only a payable invoice from a verified, connected order service.
Treat the network as part of the asset choice
The same token name can appear on more than one blockchain. That does not make every route interchangeable. USDT on Ethereum and USDT on TRON are separate payment instructions, even when a wallet displays the same asset symbol. The receiving service must explicitly support the selected network and the actual token used on that network.
Start from the invoice, not from the cheapest network offered by a withdrawal screen. If the sending service uses a different label or provides several versions of an asset, resolve that difference before sending. An unsupported network is not corrected merely because the address looks familiar or the token has the intended name.
Read the catalogue's routes precisely
SwissOctet lists six assets across seven routes because USDT has two network choices. Use the complete invoice instructions for the actual order and verify the selected route before sending funds. A catalogue or receiving address alone does not authorise a transfer.
The table preserves the route distinction without displaying a receiving address out of an invoice context. A live invoice must provide the exact network and destination for the selected order. Other networks offered by a wallet or exchange are not automatically supported just because the asset also exists there.
| Asset | Network in the checkout design | Selection to keep distinct |
|---|---|---|
| BTC | Bitcoin | Native BTC route |
| ETH | Ethereum | Native ETH route |
| USDT | TRON | TRC-20 token route |
| USDT | Ethereum | ERC-20 token route |
| USDC | Ethereum | ERC-20 token route |
| SOL | Solana | Native SOL route |
| LTC | Litecoin | Native LTC route |
Verify token identity, not only its ticker
Ethereum's ERC-20 documentation describes an interface for fungible tokens, while TRON documents its TRC-20 standard. A standard defines how a token can behave; it does not establish that a particular token with a familiar symbol is the intended asset. The issuer's official information and the invoice's configured token identity matter to an integration.
Tether publishes supported protocols and contract information for its tokens. If your wallet identifies a token through a contract or offers several similarly named assets, compare that information with the official issuer and the invoice's required asset. Investigate any warning before proceeding. Do not replace the payment instructions with a contract address copied from a search result or message.
Read fees from the sending side
The amount entered in a wallet or exchange can differ from the amount delivered when fees are deducted from a withdrawal. Review the final confirmation screen and the service's fee handling. A real invoice states the required receiving amount; the sender must make sure that amount, rather than only the entered amount, will arrive under the specified route.
For self-custody token transfers, network fees may require the network's native asset. Ethereum documents gas as the mechanism for paying computational work on its network. Do not confuse the token being sent with the asset used to pay a network fee. Check current wallet instructions and available balances rather than assuming a token balance alone is sufficient.
Verify the complete instruction before approval
Read the asset, network, destination, amount and invoice expiry together. Verify the destination in a way appropriate to the wallet, because copied text can be altered or mistaken. A QR code is a convenient representation, not independent proof that an invoice is legitimate. Keep your order reference and access token private while checking the details.
Use an illustrative USDT order to practise the review without moving funds. The invoice specifies Ethereum, but the withdrawal screen initially defaults to TRON. The correct response is to select and verify the invoice's route or stop to resolve the mismatch. Sending on the default network and hoping for recovery is not a payment procedure.
Handle expiry and uncertainty deliberately
A quote can have an expiry and a policy for late or partial transfers. If you have not sent the payment, obtain a current invoice when the instructions expire. If you have already sent it, preserve the transaction reference and request reconciliation through the order process. Do not start repeated transfers simply because a screen has not updated.
Differentiate the wallet's local status from the receiving service's verified state. A broadcast transfer, an included transaction and an accepted order are different events. Keep the transaction reference, asset and network available for a technical inquiry, but never share seed phrases, private keys or a wallet recovery file. Those are not required to identify a public transfer.
Keep the payment decision bounded
This process is about matching a transfer to a valid invoice, not selecting assets as investments or promising privacy from a public ledger. A no-KYC order flow limits identity-document collection; it does not erase transaction history or information disclosed through account use. Keep personal and technical information proportionate to the actual order need.
Review the invoice's complete instructions and follow verified order status. Keep the transaction reference if you need assistance. Do not send a second transfer simply because a confirmation screen is taking time to update.
Your practical checklist.
- Use a payable invoice from the connected order service.
- Match asset and network as one route.
- Check token identity through official issuer information.
- Verify the amount delivered after sending-side fees.
- Review address, amount and expiry together.
- Preserve the public transaction reference without sharing wallet secrets.
The details that matter.
Can I send USDT on any network if the symbol is the same?+
No. Use the exact network and token route specified by the invoice. Similar names do not make different blockchain transfers interchangeable.
Does a QR code prove that the payment instructions are valid?+
No. It encodes information. Verify the invoice, asset, network, destination and amount before authorising a transfer.
Should I resend if the order screen remains pending?+
Preserve the transaction reference and use the reconciliation process first. A delayed display is not proof that the transfer failed or needs duplication.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Ethereum: ERC-20 token standard ethereum.org
- TRON: TRC-20 standard developers.tron.network
- Tether: Supported protocols tether.to
- Ethereum: Gas and fees ethereum.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.