Underpaid, Overpaid, Wrong Chain: Crypto Payment SOP

With a non-custodial gateway, by the time a customer opens a support ticket the money is already in your wallet. No processor is holding it, no dispute queue exists, and nothing can be reversed. So every payment exception — short, over, late, wrong chain — is a decision you make about an order, not a request you file with a provider. Most published guidance ignores this, because most gateways are custodial.

The four answers in one line each. Underpayment: auto-accept shortfalls under 1% of order value with a $1 floor, request a top-up above that, refund above 25%. Overpayment: whether you can refund at all depends on the chain, because on Tron the network fee can exceed the amount you are returning. Late payment: USDT, USDC and DAI carry no rate risk, so honour the order; only BTC and ETH need a policy. Wrong chain: no gateway can recover it, but if the funds landed on an EVM chain at an address you hold the keys for, you can recover it yourself.

We sell a payment gateway, so read the recommendations with that in mind. The thresholds come from our own measured network fees and from settings two other processors publish, all cited below. Nothing here needs our product to work.

The exception table

This is the part worth pinning above the support desk. Every row is a decision rule, not a description. “N” is the amount in question; “the fee” is the outbound network fee on the chain the payment arrived on.

Exception	Decision rule	What you do	What you tell the customer
Underpaid, shortfall under max($1, 1% of order)	Auto-accept	Mark paid, fulfil, book the shortfall as a processing cost	Nothing. Silence is the correct message here
Underpaid, above tolerance but under 25%	Request top-up, 24-hour window	Hold in an underpaid state; do not fulfil, do not refund yet	“We received N of the M due. Send the difference to the same address and your order releases automatically.”
Underpaid 25% or more, or no top-up inside 24 hours	Refund less the network fee	Cancel the order, send a new transaction from your wallet	“We have returned N, less the network fee. Transaction hash attached.”
Overpaid, excess is smaller than the network fee	Refund is impossible	Issue store credit at full face value	“Returning this costs more in network fees than the amount itself, so we credited the full N instead.”
Overpaid, excess is 1x to 3x the network fee	Give the customer the choice	Ask before sending anything	“We can refund N minus the fee, or credit the full N. Which would you prefer?”
Overpaid, excess is over 3x the network fee	Refund by default	Send within one business day, fee deducted and disclosed	“Refunded N less the network fee. Transaction hash attached.”
Paid after quote expiry, stablecoin	Honour at the original price	Fulfil normally	Nothing
Paid after quote expiry, BTC or ETH, price moved 2% or less	Honour	Fulfil normally	Nothing
Paid after quote expiry, BTC or ETH, price moved over 2%	Re-price against what actually arrived	Fulfil at the recalculated value or request a top-up	“Your payment arrived after the price lock closed. At the rate when it landed it covers N of the order.”
Wrong EVM chain, address is one you hold keys for	Recoverable by you, never by the gateway	Sweep with the same key after funding gas on that chain, then credit the order manually	“The funds landed on the wrong network. We control that address and can retrieve them. Allow a few business days.”
Wrong chain into a non-EVM address, or tokens sent to a contract	Not recoverable	Do not promise a timeline or a partial fix	“We cannot recover this, and neither can any gateway or exchange. Here is the transaction and what happened.”
Unsupported asset sent to a supported address	Order stays uncredited	Case-by-case; sweeping is possible if you hold the key	“We accept BTC, Bitcoin Lightning, ETH, USDT, USDC and DAI only. This transfer cannot be matched to an order.”

Underpayment: pick a floor, not just a percentage

Almost every underpayment has one cause, and it is not carelessness. The buyer pays from an exchange account rather than a self-custody wallet, the exchange deducts a flat withdrawal fee from the amount sent, and what arrives is short by exactly that fee. CoinGate documents the same pattern and lets merchants auto-accept shortfalls of up to 10%, while recommending 1–2% as the setting that covers over 90% of accidentally underpaid orders (checked 7 September 2026). BTCPay Server exposes the same control as a percentage, alongside a network-cost feature that adds an allowance to the invoice total to protect merchants against partial payments (Stores FAQ, checked 7 September 2026).

A pure percentage breaks at the bottom of your catalogue, where it matters most. A flat $1 withdrawal fee is 0.2% of a $500 order and 4% of a $25 order. Set tolerance at 1% and the $500 order clears itself while the $25 order, the one with the least support budget attached, lands in the queue. Use a floor and a cap: accept a shortfall up to the greater of $1 or 1% of order value, capped at $5. Two rules constrain the upper end: tolerance must never exceed your gross margin on the cheapest item you sell, nor the cost of the support interaction you are avoiding. If a ticket costs $4 of staff time, absorbing a $3 shortfall is cheaper.

Above tolerance, the top-up flow needs one property: the customer must be able to send the difference to the same address and have it counted, so check how your gateway derives payment addresses first. Your order state machine also needs a real underpaid state. Collapse it into failed and support cannot find the money; collapse it into paid and finance quietly loses it. We worked through the full state set and the idempotency rules in our guide to crypto payment API webhooks and reconciliation. Cap the top-up window at 24 hours; past that, refund and cancel.

Overpayment: the refund can cost more than the refund

This is the exception merchants underestimate, because the refund is not a reversal. It is a new outbound transaction from your own wallet, and you pay the network fee to send it. On one of the two stablecoin rails, that fee is larger than a typical overpayment.

We measured the outbound cost ourselves on 31 August 2026, from public chain endpoints rather than repeating another article. A USDT or USDC transfer on ERC-20 cost about $0.02. The identical transfer on TRC-20 cost $2.11 to $4.36, roughly a hundred times more on Tron than on Ethereum, and the reverse of what most gateway comparison pages still claim. It changes the refund decision entirely depending on which rail the customer used.

Chain	Outbound fee, measured 31 Aug 2026	Refund becomes sensible above	Below that, do this
Ethereum (ERC-20 USDT, USDC, DAI, ETH)	about $0.02	about $0.06	Nothing to manage. Refund almost any excess
Tron (TRC-20 USDT, USDC)	$2.11–$4.36	about $7–$13	Offer store credit at full face value
Bitcoin mainnet	Varies with mempool congestion; quote before promising anything	3x the fee quoted at send time	Store credit, or batch with other outbound payments
Bitcoin Lightning	Negligible	Any amount worth the ticket	Refund

The three-band rule in the main table follows directly. Below one fee, a refund is arithmetically impossible. Between one and three fees, the customer receives less than two-thirds of what you are returning, which reads as an insult even when it is honest, so ask rather than assume, and offer credit at 100% of face value instead. Above three fees, refund by default and attach the transaction hash so the deduction can be verified.

Two practices make this defensible rather than arbitrary: publish the rule in your refund policy before it comes up, including that network fees are deducted, and denominate the bands in fees rather than dollars so it stays correct when Bitcoin mempool costs move. Store credit at full face value is often what the customer prefers anyway: on a $6 TRC-20 overpayment they take $6 of credit or roughly $3 in cash.

Late payment: only BTC and ETH need a policy

Quote windows exist to cap volatility exposure. BTCPay Server defaults its invoice timer to 15 minutes, describing it as a protection mechanism that locks the crypto amount against the fiat rate for that period (checked 7 September 2026). What nobody writes down is what happens next on a non-custodial setup.

With a custodial processor, a payment to an expired invoice hits the processor’s address and their policy decides the outcome, typically a decline and a refund flow you do not control. With a non-custodial gateway the payment address belongs to your wallet, so a late payment simply arrives. Nothing declines it, no refund follows automatically, and only you can resolve the mismatch between an unpaid order and money already in your wallet. It is one of the practical differences in our comparison of custodial and non-custodial payment gateways.

Because Aurpay settles the asset the customer paid, with no automatic conversion to fiat, rate exposure depends entirely on which asset arrived. A USDT, USDC or DAI payment landing 40 minutes late is worth what it was worth at checkout, to within a rounding error. There is no reason to hold that order or explain anything. Honour it. Nearly every “expired invoice” ticket falls into this category, and its SOP is a single automated rule.

BTC and ETH are the real cases. Use a 2% band: inside it, honour the order and absorb the difference; outside it, re-price against the value that actually arrived and either fulfil at that amount or ask for a top-up. State the window length on the checkout page so the conversation starts from a published number, and set different windows per asset if your gateway allows it. A 15-minute lock makes sense for BTC and is needlessly aggressive for a stablecoin, where a longer window means fewer abandoned checkouts, as we cover in our notes on reducing crypto cart abandonment.

Wrong network: what is genuinely lost and what is not

Start with what no gateway can do, because this is where customers are most often misled. A non-custodial gateway holds no funds pool, no intermediary account, and no key to your wallet. It cannot reverse a transaction, recover misdirected funds, or refund on your behalf. Any refund is a new transaction from your own wallet, paid for by you. If a support page implies otherwise, it is describing a custodial product. Aurpay supports Ethereum, Tron, Bitcoin mainnet and Bitcoin Lightning; nothing sent outside those four chains is credited to an order automatically.

The recoverable case: a customer sends USDT to your Ethereum address but picks the wrong EVM network in their exchange withdrawal dropdown, so the funds settle on Polygon, BSC, Base or Arbitrum instead. Your address exists on those chains too. MetaMask states this directly: a Secret Recovery Phrase generates the same address across all EVM-compatible networks, so tokens sent to the right address on the wrong EVM network are not lost (checked 7 September 2026). You hold that key. Add the network, fund the address with a little of that chain’s native gas token, move the funds, credit the order manually. The gateway plays no part. One condition decides it: whether the settlement wallet is genuinely yours. If you set an exchange deposit address as your settlement address, you do not hold that key and you are in the exchange’s support queue like everyone else.

The unrecoverable case: anything crossing between address formats. MetaMask is equally direct that funds sent to a non-EVM address are likely gone forever, because a seed phrase generates different addresses on different networks. Tron is an odd middle case worth knowing but not worth promising. It derives an address from the same secp256k1 key and Keccak-256 hash as Ethereum, then prepends a 0x41 byte and Base58Check-encodes it, so one key controls the corresponding address on both chains (TRON developer documentation, checked 7 September 2026). In practice wallets reject the mismatched format before broadcast, so it rarely becomes a live ticket. Tokens sent to a contract with no recovery function are gone in every case.

Say the unrecoverable version plainly and immediately. The worst outcome is a support thread that keeps hope alive for three weeks and ends in the same place, which is the gap recovery scams operate in. Tell the customer the funds cannot be retrieved, that no gateway or exchange can retrieve them, and that anyone promising otherwise for a fee is a scam.

Prevention is worth more than the entire SOP

Every exception above is cheaper to prevent than to handle. Four checkout changes remove most of them.

• Name the network next to the address, not in a tooltip. Most wrong-network incidents start in an exchange withdrawal dropdown, so checkout has to make the correct value obvious enough to copy.
• Warn about exchange withdrawal fees at the point of payment. One sentence at checkout (“if you are paying from an exchange, its withdrawal fee comes out of what we receive, so send the fee on top”) prevents most underpayments outright.
• List supported assets exhaustively. BTC, Bitcoin Lightning, ETH, USDT on ERC-20 and TRC-20, USDC on ERC-20 and TRC-20, DAI on ERC-20. An abbreviated list ending in “and more” is what produces the unsupported-asset ticket; our guide to accepting USDT on ERC-20 and TRC-20 covers choosing between the rails.
• Publish the tolerance and refund rules. A customer who reads “shortfalls under $1 are accepted, network fees are deducted from refunds” before paying does not open a ticket afterwards.

Two of the four depend on what your gateway renders at checkout rather than on anything you can edit, which makes exception handling a real selection criterion, and we treat it as one in our breakdown of the best crypto payment gateways for Shopify.

Where this sits in your operations

Everything above concerns money arriving incorrectly. What happens after a payment confirms, covering how many confirmations to wait for before you ship, customs values on cross-border orders and how returns work when nothing on the chain reverses, is a separate problem with its own rules, and we set it out in our guide to crypto order fulfilment, shipping and refunds.

One structural point drives every rule here. Non-custodial settlement means funds reach your wallet directly at a flat 0.8% per transaction, with no intermediary account in the path. That removes a processor’s ability to freeze, reverse or withhold your money, and equally removes their ability to resolve an exception for you. Copy the table above into your support documentation, set the tolerance and windows to your margins, and these stop being incidents.

Aurpay settles BTC, Bitcoin Lightning, ETH, USDT, USDC and DAI directly to your own wallet, with no contracts or banking details required. If you are still choosing a provider, exception behaviour is one of the criteria we weigh in our Shopify crypto gateway comparison.