Going to the merchant does not help. Going to the platform does not help either. Once an on-chain transfer is confirmed, nobody can reverse it. If your x402 payment succeeded but you did not get the content, the only way to get a refund is to negotiate with the receiver of the money.
Previously, a user reported that after paying 0.5 USDT to call an AI data API, the API returned a 500 error and no content was delivered. He first contacted Coinbase support. Support said x402 is an open protocol, and the platform is only a facilitator, so it does not handle refunds. Then he contacted the API service provider. The provider said the transaction was not shown in their logs, so they could not process it. Both sides pushed him back and forth, leaving the user stuck and unsure whom to ask.
The short answer: find whoever holds the money. The x402 protocol itself has no 'forced refund' mechanism. After on-chain settlement is completed, the funds are already in the receiver (merchant) wallet. A refund is a second transfer that the merchant starts voluntarily. It is not an automatic protocol feature.
Step 1: Confirm who actually received the money
Open a block explorer (for Base, use basescan.org; for Solana, use solscan.io) and find your transaction.
Check the receiving address:
If the receiving address is the merchant's direct address, the money is with the merchant. Ask the merchant for a refund.
If the receiving address is a DepositRelay contract address, the money went into an escrow contract. You may be able to recover it through the contract mechanism.
x402 supports a refundable option. Merchants can configure payments to route to a DepositRelay contract, so funds first go into an escrow account instead of directly to the merchant wallet. If the merchant uses this mode, the refund can be handled by the contract, without the merchant's cooperation.
Done when: you can see the transaction status is Success in the block explorer, and you know who owns the receiving address.
Step 2: Use the right channel based on the receiver type
Case A: The receiver is the merchant's direct address (most common)
The default x402 mode sends money directly to the merchant. Once on-chain confirmation happens, it cannot be reversed.
What to do:
Find the 'Contact Us' or 'Support' page on the merchant's website.
Provide your transaction hash (tx hash) and request ID, if you have one.
Explain that you paid but did not get the content. Ask for a refund or a re-delivery.
Done when: the merchant replies and confirms a refund, and you receive an incoming transaction in your wallet.
High-risk reminder: if the merchant does not admit the payment or does not reply, you have no on-chain way to force the refund. The x402 design does not include a 'dispute resolution' layer. This is completely different from a credit card chargeback. Before using x402 to call an unfamiliar service, try a very small amount first, such as 0.01 USDT, to confirm the service works normally.
Case B: The receiver is a DepositRelay escrow contract
The merchant used x402's refundable extension. Funds first go into an escrow account instead of being settled directly to the merchant.
What to do:
Check whether the merchant's payment options include a refundable mark.
If escrow mode is used, you can start a dispute or refund request through the EscrowFactory contract.
The exact steps depend on the escrow window configured by the merchant, such as 60 seconds or 24 hours.
Done when: the funds are returned from the escrow account to your wallet, and the status changes from escrowed to refunded.
Case C: You used a service that supports refunds, such as Browserbase
Some service providers actively support refunds. For example, Browserbase is a browser session service. If you end a session early, you may get a refund for unused time.
What to do:
Check the service provider's API documentation for refund-related endpoints.
For Browserbase, call the /terminate endpoint. The response includes a refund.eligible field that tells you whether a refund is possible and the amount.
Step 3: If the merchant uses a facilitator, check for a failed status
Some x402 facilitators implement refund management endpoints. For example, some open-source facilitator implementations allow an administrator to start a refund through the /admin/refund endpoint after a payment status becomes failed.
What to do:
Ask the merchant whether they run a facilitator with a refund function.
If they do, the merchant can manually process the refund through the Admin API.
You need to provide your payment nonce or transaction hash.
Final check after a refund
After the refund is completed, check your wallet for an incoming transaction from the merchant address or escrow contract.
Done when: the block explorer shows a new transfer. The amount is equal to or close to your original payment, and the note may include the word 'refund.'
If the merchant does not respond within 24 hours, and the merchant did not enable refundable escrow mode, the money is likely lost. Next time before making a call, use a small test payment to confirm the service is stable.
