In this article
Most crypto payments go through without incident. The customer scans, sends the right amount, the transaction confirms in seconds, and everyone moves on. That's the normal case.
But problems do occur, and figuring out what to do while a customer is waiting at the counter is a bad way to learn. What follows covers the most common payment errors and what to do about each one.
Underpayment
A customer sends less than the amount due. This happens for a few reasons: they misread the display, their wallet rounded down, or network fees were deducted from the send amount rather than added on top.
What your system shows: Most payment processors flag underpayments explicitly. The transaction will appear as partial or underpaid, not complete. Do not release goods based on a partial payment.
Your options:
- Request the difference. The customer can send a second transaction covering the shortfall. Check whether your processor handles split payments before a customer asks.
- Adjust the order. If the shortfall is small, some businesses choose to honor the partial amount against a smaller order. That's a business call, not a technical one.
- Refund and restart. Return the partial payment and ask the customer to send the correct amount in a single transaction. This is cleaner but adds friction. Use it when the discrepancy is significant or your system doesn't support partial payments.
Frequent small underpayments often point to a setup issue. On some networks, the sender's wallet deducts transaction fees from the payment rather than adding them on top. If customers keep coming up a few cents short, it's worth checking whether your processor is accounting for expected network fees in the amount it displays.
Overpayment
A customer sends more than the amount due. This is less common, but it happens, usually from rounding up, a copy-paste error, or a stale exchange rate cached in their wallet.
Don't pocket the difference and move on. Treat it the same way you'd handle a cash overpayment: communicate with the customer and offer to return the excess.
Returning the overage means initiating a transaction back to the customer's address. Before you do, confirm the address. The process is the same as a refund, which is covered in the refund guide. Document the exchange either way.
If the overage is genuinely trivial (a few cents due to rounding), many merchants treat it as a tip or credit and keep a note in the transaction record. Whatever you decide, handle it consistently so your accounting stays clean.
Wrong asset
A customer sends Bitcoin when you only accept USDC, or Litecoin to your Bitcoin address. This is more serious than an underpayment.
Incompatible address formats: Bitcoin, Ethereum, Litecoin, and other assets use different address structures. Most wallets reject an incompatible send before it goes through, but not always. If a customer manages to send an unsupported asset to your address, recovery ranges from difficult to impossible depending on the network.
Compatible address, unsupported asset: This is rarer, but possible on EVM-compatible networks. A customer might send an ERC-20 token you don't accept to your Ethereum address. In that case, the funds typically sit in your wallet, accessible in principle, but not without technical steps to retrieve them.
Prevention is the right answer. Display only the payment methods you accept, clearly labeled. A Bitcoin QR code should only be used for Bitcoin. If you accept Ethereum and USDC, keep them on separate labeled displays. When a wrong-asset payment does happen, don't try to troubleshoot it at the counter. Get the customer's contact information, document what they say they sent, and follow up once you've had time to investigate.
Wrong network
This is one of the most consistent sources of lost funds in crypto, and it catches people who should know better. Several assets run on multiple networks. USDC, for example, exists on Ethereum, Solana, Base, Arbitrum, and others. Sending USDC over Ethereum to an address configured for Base USDC means the funds arrive at the right address but on the wrong network, where they may be inaccessible without technical intervention.
If you accept stablecoins or any multi-network asset, your processor or wallet is configured for one specific network. Your payment display needs to say which one. "USDC" is not enough. It should read "USDC on Ethereum" or "USDC on Base," with the network label visible alongside the QR code.
If a wrong-network send happens, recovery depends on which networks are involved and whether you or your processor controls the receiving keys. Some processors can assist. If you're self-custodying, you may be able to recover the funds with the right tools, but this is not a fix you attempt at the counter. Document the transaction details and get technical guidance before doing anything else.
Clear labeling upfront prevents almost all of these situations.
Partial payment / split payment
A customer wants to pay part of the total in crypto and the rest in cash or card. This is legitimate and more common than you'd expect, especially at higher price points.
Whether your setup supports it depends on your processor or POS system. Some handle split tenders natively; others require manual calculation. Know your system's capability before a customer asks for it mid-transaction.
If your system doesn't handle split payments cleanly, agree on the split with the customer, generate a crypto payment for the crypto portion, and process the remainder separately. Make sure both are logged together in your transaction record.
Talking to the customer
How you handle the situation matters as much as how you resolve it. A few things worth keeping in mind:
Stay calm and matter-of-fact. Most payment errors aren't the customer's fault; they're using an unfamiliar system in good faith. Treating it like a routine procedural issue, because it is, keeps the interaction from becoming tense.
Be specific about what you can and can't do right now. "I can't confirm that payment at the moment" is better than "something went wrong." Vague language makes people anxious.
Get contact information before the customer leaves. A refund, a wrong-network recovery, an overpayment return: any of these require follow-up. A name and email is enough.
Don't make promises you can't keep. "I'll take care of this" is fine. "You'll have it back by tomorrow" is not, unless you're certain. Recovery timelines vary across networks.
Document everything. Transaction IDs, timestamps, amounts, what the customer says they sent, what your system shows. This protects you in any dispute and gives your processor what they need to investigate.
Preventing these situations
Most wrong-amount and wrong-network problems are preventable with the right setup.
A processor that generates amount-specific QR codes for each transaction takes most of the math off the customer entirely. The code encodes the exact amount, currency, and network; there's not much left to get wrong. That alone eliminates a large share of the errors covered in this article.
Label everything on your counter display: asset, network, amount. Every QR code. No exceptions. And train staff to read the full confirmation screen, not just that a notification appeared, but that the amount and asset actually match what was expected.
Some problems will still slip through. The goal isn't zero incidents. It's knowing exactly what to do when they happen.
The Merchant's Guide covers payment processor selection and counter setup in detail. The refund guide walks through what to do when you need to return funds to a customer. If you're setting up for the first time and want a nothing-missed checklist, the 0-to-Live Launch Toolkit covers display labeling, network selection, and the full go-live sequence.