You copied the address, pasted it, picked a network and pressed send. The transaction confirmed, but the shop says nothing arrived, or your exchange balance didn't change. Then you notice the network: BNB Smart Chain instead of Ethereum, or Polygon instead of Base. This guide explains what actually happened to the coins, when they can be recovered and by whom, and what both customers and merchants can do about it.
Why crypto ends up on the wrong network
Most coins used for payments exist on more than one blockchain. Tether issues USDT on many networks, and USDC and Ether also exist on several. Each version lives only on its own network. USDT on Tron and USDT on Ethereum are separate tokens, even though they have the same name and the same value.
So every transfer involves a choice of network, and there are a few ordinary ways to get it wrong:
- An exchange's withdrawal screen offers several networks, and the cheapest one is picked without checking what the recipient asked for.
- Networks have different names in different places.
TRC20,TronandTRXcan all mean the same network, whileBEP20andBSCboth mean BNB Smart Chain. - A wallet remembers the network used last time and sends on it again.
- The address was copied from an old message that was about a different network.
The result is the same each time: the transaction confirms on a network the recipient didn't expect. The coins are not burned or destroyed. They sit at an address on that network, waiting for someone with the right key to move them.
EVM networks: one address, many chains
Ethereum, BNB Smart Chain, Polygon, Base and Arbitrum One are all EVM networks: they run the Ethereum Virtual Machine and use the same kind of accounts. An Ethereum address is worked out from a public key, by taking the last 20 bytes of a Keccak-256 hash of it, and the network plays no part in that. So one private key controls the same 0x address on every EVM chain.
What keeps the chains apart is a chain ID that is part of every signed transaction, introduced by EIP-155 so that a transaction made for one chain can't be replayed on another. Your wallet signs the transfer for the network you selected, and the coins land at the address on that network.
That explains both sides of the problem. The mistake is easy because the address is valid everywhere, so the wallet has nothing to warn you about. And it is often fixable, because the key that controls the address on Ethereum also controls it on BNB Smart Chain or Polygon.
Networks with their own address formats
Other networks use their own formats. Tron addresses, for example, are 34 characters starting with T, and Bitcoin, Litecoin, Solana, TON and the XRP Ledger each look different again. Most wallets refuse to send to an address in the wrong format, so the cross-network mix-up is rare there. On these networks the usual mistake is a different coin on the right network: TRX instead of USDT on Tron, for example, or a token the recipient never asked for.
When crypto sent on the wrong network can be recovered
Whether the coins can be moved again comes down to three questions:
- 1Does the address exist on the network the coins landed on? Between EVM networks, yes. Between networks with different formats, the transfer usually can't be made at all.
- 2Who holds the private key for that address? If it is your own wallet, you do. If it is an exchange or a payment gateway, they do, and it is up to them.
- 3Does that service support the network and the coin? If it does, it can usually see the coins and credit or return them. If it doesn't, it may not be able to. Some services say so plainly: Binance.US, for example, states in its help center that it is unable to recover deposits of unsupported assets or deposits sent on unsupported networks.
| What happened | Usually recoverable? | Who can move the coins |
|---|---|---|
| Sent on another EVM network to your own wallet | Yes | You: add that network to your wallet |
| Sent on another EVM network to an exchange or gateway | Often, if the service supports that network | The service |
| A different coin, on the right network | Usually, if the service supports that coin | The service |
| Sent on a network the receiving service doesn't support | Sometimes, case by case, often not | The service, if it can and agrees to |
| Sent to the wrong address | Only if the owner of that address returns it | Whoever owns that address |
| Sent to an address nobody controls, such as a token's own contract | Almost never | Nobody |
If you sent crypto on the wrong network
- 1
Don't send the payment again yet
Sending a second time doesn't fix the first transfer, and you may end up paying twice. Work out what happened first.
- 2
Find the transaction ID
Your wallet or exchange history shows the transaction ID, also called the hash, and the network it was sent on.
- 3
Look it up on a block explorer
Open a block explorer for that network and search for the transaction ID. It shows the address the coins went to and confirms they arrived there.
- 4
If it went to your own wallet
Add the network the coins landed on to your wallet, using the same recovery phrase or account, and they appear there.
- 5
If it went to a business or an exchange
Write to them with the transaction ID, the network, the coin, the amount and, for a business, the invoice or order link. Exchanges often have a recovery form for deposits.
If a customer paid you on the wrong network
For a business, a wrong-network payment is a support case, and how hard it is depends on how you receive payments. If customers pay into your own wallet, you hold the key on every EVM network, so you can usually switch networks and see the coins yourself. With a custodial gateway, it depends on what the gateway supports and how it handles these payments.
- Ask the customer for the transaction ID and look it up before anything else.
- Check whether your gateway already saw the payment. Many show unexpected payments somewhere in the dashboard or in a support ticket.
- Don't ask the customer to pay again until you know what happened to the first payment.
- If the coins can't be credited, tell the customer plainly and keep a record of what you found.
- If the payment is credited but you can't ship, for example because it covered only part of the order, settle it with the customer. Our guide on how to refund a crypto payment covers sending coins back safely.
How Crypto Merchant counts wrong-network payments
Crypto Merchant gives each invoice its own deposit address and watches it for every supported coin, on every supported network that uses that address. One EVM address works on Ethereum, BNB Smart Chain, Polygon, Base and Arbitrum One, and Crypto Merchant holds its key on all of them. So USDC sent on Base to an invoice for USDC on Ethereum still reaches an address Crypto Merchant controls. On Tron, Solana and the other networks with their own addresses, this covers a different coin on the same network, such as TRX sent to an invoice for USDT on Tron.
Counted automatically
The payment counts for the invoice on its own when both of these are true:
- nothing else has been paid on the invoice yet;
- the coins cover the invoice amount, within the merchant's underpayment tolerance.
The invoice then switches to the coin that was actually sent. The customer's invoice page says what they paid in instead of the coin asked for, and the merchant sees the requested coin on the payment and in the payment email. In the API, coin is what was paid and requested_coin is what the invoice asked for.
Stablecoins count as one US dollar each. The same coin on another network, such as ETH on Base for an invoice in ETH on Ethereum, keeps the rate the customer was shown. Any other coin is valued at the market price when it arrived. This also works for late payments, after the invoice has expired, while the address is still being watched, which is for at least 24 hours.
Smaller amounts and stray tokens
Anything else never changes the invoice: a partial payment in another coin, a second coin on an invoice that already has a payment, or a stray token. It is credited to the merchant's balance like a payment without an invoice, minus the 1% fee, and a support ticket tells the merchant, so it isn't lost and can be settled with the customer. A tiny token sent to the address can't take over an invoice. Late payments to cancelled or refunded invoices are handled the same way.
Fees and limits
There is no extra fee for counting a payment that arrived in another coin or on another network: the usual 1% applies. If an extra fee is ever set, it applies to that payment only and is shown on it. Two things are still not covered: coins on a network or in a coin Crypto Merchant doesn't support, and coins sent to any address other than the invoice's. Those can be lost. The checkout docs have the full rules.
How to avoid it
Being able to recover a mistake is good. Not making it is better. A few habits help on both sides:
- Merchants: turn on the networks your customers already use, so nobody has to improvise.
- Show the network name next to the address and the amount, and repeat it in order emails.
- Customers: in an exchange's withdrawal screen, pick the network by name, not by price, and compare it with the invoice.
- Use the QR code or the copy buttons on the invoice page instead of retyping an address.
- For a large amount to a new address, send a small test first if the recipient agrees.
- Pay each invoice in one transfer, in the coin it asks for.
For more on keeping customers on the right network, read our guide to accepting USDT payments. If the network was right but the amount was off, underpaid and overpaid crypto payments explains what happens next.