Most teams that accept stablecoins eventually get the same ticket. A customer says they paid. They have a transaction hash to prove it. The block explorer agrees the transfer went through. And yet the order is still unpaid, because the customer sent USDT or USDC on the wrong network.
Wrong-network payments are among the most frequent complaints merchants and customers raise about stablecoin payments. They come from how stablecoins are built, and from checkouts that hand the customer a decision they shouldn’t have to make. The cost shows up in the support queue, but the fix belongs in the checkout.
One dollar, many networks
USDT and USDC are each issued separately on many blockchains, including Ethereum, Base, Arbitrum, Polygon and Optimism, and each version is its own contract on its own network. To a customer, “USDC” is one thing. To the infrastructure, USDC on Base and USDC on Ethereum are as separate as two bank accounts at different banks.
EVM networks also share one address format. A wallet address that starts with 0x looks exactly the same on Ethereum as it does on Polygon or Base. Nothing in the address tells the customer which network it’s meant for, and nothing in the blockchain stops them from sending to it on any network they like. The transfer is valid, but it lands on a network the receiving system isn’t watching.
Why the payment succeeds but never arrives
From the customer’s side, everything worked. Their wallet confirmed the transfer, the fee was paid, and the explorer shows the funds delivered. From the merchant’s side, nothing happened, because the payment system was waiting for funds on one network and they arrived on another.
Whether that money can be recovered depends on who controls the receiving address on the network where it landed. If the address belongs to a wallet whose keys someone controls, the funds are usually still there and can be reached by switching networks. Wallet providers such as MetaMask document this case in their help centers. If the address is a deposit address generated by a processor or an exchange that doesn’t support that network, recovery becomes a manual operation that may or may not be offered. And if the transfer crossed into an incompatible network altogether, the funds can be gone for good.
What recovery looks like
In practice, recovery is slow and uncertain, and the cost doesn’t always land on whoever made the mistake. One merchant using a custodial gateway described a customer who paid a 79 USDT subscription on the wrong chain. The payment sat in an unresolved status and was never credited. A customer paying another processor was told that funds sent on an unsupported network could not be returned at all. Some platforms offer manual recovery, but charge a fee for it and state plainly that success isn’t guaranteed.
Even when the money comes back, the process usually runs the same way. The customer opens a ticket, support asks for the transaction hash, someone checks the explorer, the case is escalated to whoever can access the funds, and days later the payment is credited, refunded minus fees, or written off. Every step is manual, and all of it happens after the customer believed they had paid.
What it costs a merchant
A single case usually involves a small amount, but the work around it adds up. Each wrong-network payment turns into a support conversation with a customer who is anxious about their money and frustrated at being told they made a mistake. The order can’t be fulfilled and can’t be cancelled cleanly. Finance is left with an unresolved line to chase at month-end. For subscription businesses, a payment that never arrives can mean a renewal that silently fails.
There’s a quieter cost too. A customer who loses money on their first stablecoin payment with you is unlikely to try a second one.
Why warnings don’t fix it
The standard industry answer is a warning: red text under the address saying “send only on this network,” sometimes repeated in a modal. Warnings help a little, but they ask the customer to do something software should do. The customer has to read the network name, find the matching option in a different app, select it correctly, and paste an address that looks identical on every network. Any step in that chain can go wrong, and the warning only works if every customer reads it every time.
A mistake common enough to have its own section in every help center is a design problem.
Designing the mistake out
The cleaner approach is to remove the step where the error happens. On Woldy, the customer never copies an address or picks a network in another app. They connect their wallet, review the payment, and sign. The request they sign already carries the right token and network, so there’s no point in the flow where they can choose the wrong one. Each payment routes into the merchant branch’s own dedicated vault, and support has nothing to recover. Our docs cover how vaults and settlement work, and the supported networks and assets are listed on the product page.
Covering network fees helps too. When paying requires a separate native token for fees, customers start improvising, moving funds between networks or paying from whichever one is cheapest that day. With fees covered, the customer pays from the wallet and the stablecoin they already hold.
What to ask your payment provider
If you already accept stablecoins, ask your provider three questions. What happens, step by step, when a customer pays on a network you don’t support? Who pays for the recovery, and is it guaranteed? And does your checkout ask customers to copy an address and choose a network themselves? The answers show whether wrong-network payments are an edge case in their design or a recurring cost in yours. We’ve put these next to the other questions worth asking in our stablecoin payments due-diligence checklist.
For the broader reasoning behind how we build Woldy, start with segregated by design.