A Stablecoin Refund Is Not a Reversal: Designing the Second Payment Flow

1. A refund is a new obligation, not deletion of the past

The original transaction remains on the blockchain after the customer receives value back. It still proves that a particular asset moved between addresses at a particular time and block. The refund adds a second transaction in another direction. In the books, the first event may close a customer receivable and create revenue or a merchant liability; the second creates a refund payable and settles it only when a new transfer reaches the product's finality threshold.

That separation belongs in the data model. A refund object needs its own identifier, link to the payment intent and order, reason, amount, accounting currency, asset and network, destination, authorisation owner and state. One payment can have a partial refund or several refunds up to a ceiling. A request can be rejected or cancelled. The platform must not rewrite the original paid amount to make reporting look as though the transaction never happened.

The interface should use equally precise language. 'Refund requested', 'refund approved', 'transaction broadcast' and 'refund completed' are different states. If the customer sees 'refunded' as soon as an operator presses a button, support cannot explain a gas failure, a rejected destination or a network delay. State transparency is not technical noise. It is a product promise that operations can keep.

2. The sender is not necessarily the refund recipient

This is the most important safety rule. A payment can arrive from an exchange deposit system, custodian, smart account, relayer, routing contract or temporary address. Coinbase explicitly warns users not to return cryptocurrency automatically to the original sending address: when a transfer came from a Coinbase account, the returned funds may go to Coinbase rather than the intended person. Coinbase Commerce's onchain protocol includes a refund address supplied for the payment—a deliberate architectural distinction.

The refund destination should come from the customer inside an authenticated session and be bound to one request. The platform records who supplied it, when, through which channel, for which network and in what format. A new destination, large amount or shared business account justifies stronger verification. A wallet signature may prove control of a destination, but it does not automatically prove that the signer is the legal customer or economic beneficiary.

A support agent should not be able to paste any address and continue. Manually entered addresses need a checksum where the network supports one, network validation, screening or simulation according to policy, a second approval above a threshold and an audit record. A destination from an old QR code or profile is not permanently trusted: the customer may have changed custodians, or the earlier account may no longer accept deposits.

3. Network, contract and asset belong in the refund instruction

The name USDC is not enough to identify what should be returned. Circle publishes supported networks and contract addresses and warns that sending unsupported assets or routes can result in loss. A refund instruction should include a chain namespace, chain ID, token contract, decimals and destination. On Solana, Stellar or another non-EVM network, the address structure, memo or account requirements may differ.

The sensible default is to refund the same asset on the same network that settled the payment, provided the customer confirms a compatible destination and the route remains supported. Moving to another network is a cross-chain payout, not a simple refund. It introduces a bridge or burn-and-mint process, different finality, cost, failure states and another service dependency. If the product permits it, the customer should explicitly accept the route and conversion terms.

The asset catalogue must be server-managed. It stores verified contracts, decimals, payment and refund status, finality thresholds, amount limits, memo requirements and the RPC or indexer source. Changing support does not erase history. An old request remains tied to the catalogue version used for the decision, while a new execution must also pass current controls.

4. What comes back: token units or commercial value?

When an order is priced in dollars and paid with a dollar-denominated stablecoin, the answer looks obvious. It is not. There may be spread, network fees, service fees, a discount, tax, tip, partial payment or a deviation from the peg. Policy must say whether the refund is based on the order amount, token amount received, net merchant settlement or a rate at approval time. Without a rule, two teams can calculate two apparently reasonable answers.

Retain the calculation, not only the result. A refund quote contains the accounting amount, rate, rate source, expiry, token amount in base units, rounding rule, fees and gas treatment. If it expires before signing, issue another version. Never silently update the existing row, because the organisation must later explain why the customer received a different quantity from the one approved.

The system also maintains a cumulative cap against the refundable order components. If 100 was paid and 30 refunded, the next request can consume only the remaining eligible amount after adjustments. Concurrency control prevents two simultaneous requests from spending the same balance. A row lock, unique key or atomic state transition matters more here than the visual design of the refund button.

• Gross paid — what the customer transferred.
• Refundable value — what policy and order state make eligible.
• Refund quoted — the token quantity approved in the current quote.
• Refund settled — the quantity sent and final under the network policy.

5. A state machine prevents duplicate value

A reliable flow can move through requested, eligibility_review, destination_required, quoted, approved, signing, broadcast, confirming, completed, failed, cancelled and expired. Each transition has a condition and authorised actor. Support may create requested, risk or finance approves a large amount, treasury broadcasts only approved requests, and an observer marks completed only after a valid receipt and finality threshold.

Every command needs an idempotency key. If an operator double-clicks, an API client retries after a timeout or a webhook arrives again, the platform returns the same refund rather than creating another obligation. Chain attempts are retained too: a transaction replaced with a higher fee, a failed one and a successful one belong to the same refund, while only one may settle it.

Completed is not determined when a wallet produces a transaction hash. Verify chain, token contract, sender, recipient, amount, receipt and ERC-20 Transfer event. ERC-20 specifies a Transfer event for successful transfers, but production integrations still face unusual tokens and provider behaviour. The observer is the source of truth for execution, not the wallet or relayer response.

6. Refund authority has a different fraud profile

An incoming payment usually reduces merchant exposure; an outgoing refund increases it. An attacker can take over a customer account and change the destination, persuade support that the original network is unavailable, or exploit an order already refunded through another channel. Eligibility, destination verification and execution authority are therefore three separate gates.

A useful risk model considers account age, contact-detail changes, a new address, amount, refund frequency, order match, dispute history and deviations from normal behaviour. It does not turn an automated score into a verdict. A small amount to a known address may pass automatically; a high amount or network change goes to review. A negative decision is retained with a reason and appeal path.

Treasury should separate proposer, approver and executor. The employee who agrees that a customer deserves a refund should not alone control the key that moves funds. A permanent destination allowlist is impractical for new customer addresses, but a temporary allowlist can bind one destination to a refund ID, amount, asset and expiry. The permission disappears after use.

7. Gas is part of the refund experience

To return an ERC-20 token, the operating account needs both the token and the network's native asset for gas. A refund can be commercially approved but operationally stuck because the refund wallet holds USDC without enough ETH, POL or another required asset. Refund availability therefore includes gas runway: how many operations remain under normal fees and a stress scenario.

The merchant must decide who bears cost. It can absorb gas, deduct it only when the commercial terms allow, or batch transfers through reviewed infrastructure. The amount should not change after approval without consent and a new record. When gas exceeds a very small refund, internal credit or a later execution window may be offered, but the alternative should not reduce a customer's rights contrary to policy or law.

A paymaster or relayer can hide complexity without removing it. The product still needs a budget, rate limits, idempotency and fallback. If the external service is unavailable, the refund becomes queued and the system stops making new promises it cannot fulfil, rather than continuing to display immediate completion.

8. Partial, batched and multi-rail refunds

Real commerce includes cancelling one item, partial fulfilment, returns, service compensation and tax adjustments. Refunds should link to order lines and reasons, not only the whole order. Cumulative value is checked against eligibility, and tax or accounting systems receive the relevant event. If a customer already received store credit and then requests an onchain refund, policy must prevent double value.

Batching can save gas while making failure isolation harder. One transaction may contain dozens of recipients; depending on implementation, one invalid destination or transfer can revert the batch. Keep a manifest of every item, amount and address, prove that calldata totals match approved obligations, and support splitting or retrying without repaying recipients already settled.

In multi-rail products, an order might begin on a card and end in stablecoins, or the reverse. The last connector cannot be treated as the whole source of truth. A central model of orders, payments, refunds and credits calculates total eligibility. Each connector reports execution; no connector decides alone how much remains refundable.

9. Reconciliation connects the chain to the books

The blockchain proves that a transfer executed; the ledger explains why. Approval records a refund payable. Broadcast creates a funds-in-transit state, and settlement closes the liability against treasury outflow and gas expense. A failed transaction does not close the liability. A replacement leaves all attempts attached to the same business event.

Daily reconciliation compares approved requests, pending transactions, Transfer events, balance changes, fees and ERP postings. A break receives a severity, owner and service level. Examples include the wrong base-unit amount, unexpected decimals, payment to an old address, a duplicate webhook or a manual transfer without an order link. Do not fix a difference by deleting a row; create a documented adjustment.

The refund wallet itself needs reconciliation. Funds reserved for approved liabilities are not surplus available for a sweep into reserve. Treasury automation must read the ledger before moving balances. Otherwise, one automation empties the liquidity another requires, and the product appears healthy until the customer waits.

10. Communication, evidence and the runbook

Show the customer the asset, network, shortened but verifiable destination, amount, fee treatment, state and explorer link after broadcast. Before approval, warn that an incorrect address or unsupported network cannot be reversed. Support messages should never request a seed phrase, private key or wallet connection. Official channels must be obvious enough to reduce phishing opportunities.

The refund case retains the request, eligibility decision, quote versions, destination verification, approvals, policy version, attempts, receipt, webhook events and ledger entries. This resolves disputes, supports audit and reconstructs decisions. Evidence belongs outside the operator's workstation with limited access and retention; there is no need to store signing secrets or irrelevant personal data.

Before launch, rehearse an exchange sender that is not a refund address, wrong network, two concurrent refunds, exhausted gas, a replaced transaction, duplicated webhook, partial refund and manual intervention. Measure detection, stop time, rollback and reconciliation. Dor Arad's product principle is straightforward: a payment product is judged not only by how it accepts money, but by whether it can return value with control, precision and a complete explanation.