Why is there no chargeback?#
An x402 settlement is a completed on-chain transfer. There is no chargeback, no reversal and no arbiter. Once it is in a block, the money has moved and nobody can unmove it.
That is a real difference from card rails and it is not a defect. It is why a seller can treat a payment as final immediately, with no reserve against disputes and no fraud exposure to a stolen instrument. The cost is that every failure becomes a decision the seller makes rather than a process somebody else runs.
Which four cases do you design for?#
| Case | What happened | Correct handling |
|---|---|---|
| Verified, not settled | You hold a valid promise, no money moved | Do not serve. It is not a payment |
| Settled, work failed | You have the money, the buyer has nothing | Refund, or retry at your cost |
| Settled twice | Two settlements for one request | Refund one |
| Served, settlement failed | Buyer has the resource, you have nothing | Absorb it, and fix your ordering |
Verified but not settled#
The most common and the easiest to get wrong. Verification says the authorisation is valid; it does not move money. A seller that serves on verification is extending credit and should know it is doing so.
If you serve first for latency reasons, measure your actual loss rate rather than assuming it is zero. The failures cluster: a facilitator having a bad hour produces a burst, not a trickle.
Settled but the work failed#
You were paid and the buyer got an error. This is the case that needs an actual policy, and silence is the worst option because it is the one that damages your public record.
Three defensible choices: refund by sending a payment back, retry at your own cost, or issue a credit on a keyed path if the buyer has one. Pick one, document it in your terms, and apply it consistently. Refunding costs you the gas, which at these amounts can exceed the refund, so a credit is often the better shape where a relationship exists.
Settled twice#
Rare, and it happens. A client that retried on a timeout, a header replayed, a settlement that looked failed and landed. If you have the money twice for one unit of work, send one back.
Detecting it requires recording the payment identity per request, which you should be doing anyway to prevent replay. The same record answers both questions.
Served but not settled#
Your loss. The authorisation expired, the nonce was consumed elsewhere, or the facilitator failed after you had already responded. Absorb it and look at your ordering: if this happens often, serve-then-settle is costing you more than the latency was worth.
Important
Decide the serve order deliberately at build time. Settle-then-serve has a latency cost you can measure in advance. Serve-then-settle has a loss rate you only discover in production. Both are legitimate; discovering which one you chose by accident is not.
How do you actually send a refund?#
Send a payment to the payer's address for the amount you are returning.
Three details that matter:
You pay the gas. The buyer authorised a transfer to you; nothing authorised a transfer back. You are sending an ordinary transaction, which means your refund wallet needs a native token, which your receiving address may not have.
Reference the original. There is no field for it in a plain transfer, so put the reference wherever your buyer will look: a response body, a webhook, an email if you have one. An unexplained incoming transfer is not obviously a refund.
Below a threshold, do not bother. If the gas to refund exceeds the refund, you are destroying value to make a gesture. Set a floor, say so in your terms, and credit instead where you can.
What to tell buyers up front#
Your terms should answer three questions before anybody pays:
- What happens if the work fails after payment?
- Is there a refund threshold below which you will not refund?
- How does a buyer reach you about it?
That third one is awkward and worth confronting. An anonymous buyer has no account and you have no contact details for it. The practical answer is a documented contact path on your site and a reference the buyer can quote, which is the transaction hash it already has.
Frequently asked questions#
Can I reverse a settlement?#
No. The chain has no mechanism for it. A refund is a new transfer in the opposite direction.
What if the buyer paid the wrong amount?#
An underpayment should have failed verification against your terms. An overpayment is the buyer's error and refunding it is a courtesy, subject to the same gas threshold as any refund.
Do I need a reserve for disputes?#
No, and this is a genuine advantage over card rails. There are no chargebacks, so there is nothing to reserve against. What you may want is a float for refunds you choose to make.
How do buyers handle this risk?#
By capping first payments to new sellers and screening before paying. Screening a counterparty covers the checks, and the cap is the control that works when the record is thin.
Should I offer refunds at all if I do not have to?#
If you want repeat buyers, yes, and your public record is part of why. A seller whose address shows outgoing refunds alongside incoming payments is visibly behaving well, and that is legible to anyone screening you.
Where to check this yourself#
Errors documents the failure responses and which ones mean a payment did or did not settle, which is what you need to handle each case correctly. /transactions shows settlements in both directions against an address, so a refund you send is visible in the same record as the payment you received.