A crypto payment refund is usually a new transfer, not an undo button for the original payment. Before sending it, verify the customer's request, confirm a receiving address for the exact asset and network, agree the amount, and prevent a second refund while the first is pending.
This checklist is for merchants managing refunds from funds they control. A provider-managed refund may follow different destination and approval rules: use that provider's documented process rather than bypassing it. The controls below are recommendations for your business, not a claim that Yolfi offers an automatic refund feature. Consumer rights, tax treatment and required refund terms depend on your jurisdiction.
Separate the refund decision from the transfer
First decide whether a refund is due under your sales terms and applicable law. Then decide how to deliver it safely. An irreversible payment method does not, by itself, cancel a customer's legal rights or your contractual obligations.
Link the request to the original order, payment reference and verified incoming transfer. Record the reason, refundable amount and approval. If the original payment is still unconfirmed, keep the request open rather than refunding money you have not verified receiving.
For an amount mismatch, first use the underpayment and overpayment guide. Refunding an excess amount and cancelling an entire purchase are different business decisions.
Do not copy the sending address blindly
The address visible on a blockchain explorer may belong to an exchange or payment intermediary rather than a receiving wallet controlled by the customer. Sending money back to it may not credit that customer's account.
Circle's stablecoin refund documentation warns that exchanges can send from shared omnibus wallets and recommends confirming the intended destination with the customer. This is evidence of a destination risk, not a description of Yolfi's functionality or a universal permission to override a provider's refund rules.
For a merchant-controlled return, ask the authenticated customer for receiving instructions. Confirm that the destination accepts the exact asset on the exact network, including any required memo or tag. For an exchange deposit, the customer should check their current deposit instructions, minimum and any restrictions on third-party deposits. An address that looks valid is not proof of account ownership or crediting eligibility.
Treat an address change as a new approval step. Confirm it through the established customer account or another previously trusted channel, not only the message that requested the change. Do not ask for a private key or recovery phrase. Do not publish customer details in transaction notes.
| Situation | Safe next step | Do not assume |
|---|---|---|
| Customer paid from a personal wallet | Confirm the receiving address, asset and network through the authenticated order channel | The original address is still the desired destination |
| Customer paid from an exchange | Obtain current deposit instructions and confirm that the exchange can credit this return | A withdrawal source address is a personal deposit address |
| Customer requests another network | Pause for a separate supported-transfer and fee review | The same address format makes networks interchangeable |
| Another person asks for the refund | Verify authorization against the order before approving a destination | Knowledge of a public transaction hash proves identity |
Use the wrong-network payment guide for destination checks. Never send a refund to an unsupported network simply to clear a support ticket.
Agree what amount the customer will receive
A refund promise needs a unit. State whether you are returning the original token quantity or an amount based on the invoice currency. If conversion is necessary, agree the valuation source and time before approving the transfer. A stablecoin's dollar target is not a guarantee of a fixed market price or redemption access.
Also state who bears network fees and any legally permitted deductions. Do not silently subtract a fee after promising a full token refund. For Ethereum transactions, network fees are paid in ETH; holding enough USDC does not mean a self-managed sending wallet has enough ETH for gas. Other networks and sponsored-wallet arrangements have different requirements.
Keep the refund amount separate from the fee paid to execute it. If a provider handles the return, check its actual refund and fee policy instead of assuming the original processing fee will be returned.
Use a controlled six-step refund procedure
1. Verify the original receipt and remaining entitlement
Match the order to the actual incoming asset, network, recipient and amount. Check earlier completed refunds and funds already reserved for pending refunds. The total returned or reserved must not exceed the approved refundable amount. Restrict access to the business record and retain only necessary customer information.
2. Confirm the destination and commercial terms
Save the verified receiving instructions, agreed amount, fee treatment and customer confirmation. Record who checked the destination and when. Where your process supports it, require a second reviewer for higher-risk returns or changed addresses. This is an operational control, not a substitute for legally required checks.
3. Create one refund record before sending
Give the refund a unique internal reference linked to its order. Reserve the amount and mark the record approved for execution. Ensure another worker cannot create a second transfer for the same approved return. When using a provider API, check its documented duplicate-request protection; a locally named reference alone does not make an API call idempotent.
4. Check and authorize the transfer
Verify the destination, network, asset identifier and exact quantity again in the signing interface. Check the fee balance and any memo or tag. A small test transfer may help in some self-managed cases, but does not prove identity and can fail an exchange's minimum-deposit rule. Agree any test and its accounting with the customer; it is not a universal requirement.
5. Track the existing attempt before retrying
Store the transaction hash or provider transfer reference immediately. A timeout is not proof that no money moved. Inspect the existing attempt and its network status before submitting another transfer. If a transaction is pending, investigate that transaction through your wallet or provider's documented process rather than sending an unrelated second payment.
6. Close only with verified evidence
Confirm the relevant outgoing transfer and its destination, amount and network using your confirmation policy. Where a provider or exchange is involved, distinguish blockchain delivery from provider completion or customer account crediting. Share the reference through the customer channel and keep any unresolved crediting issue visible. A submitted request is not a completed refund.
Keep a compact refund record
Use these fields in your own system or controlled register. They are not a proposed Yolfi API schema.
- Original order and payment references, plus the verified incoming transfer.
- Refund reference, reason, approved amount and previous or pending returns.
- Asset identifier, network, destination and any required memo or tag.
- Destination confirmation, amount agreement, approver and timestamps.
- Execution reference, actual amount sent, network fee and its asset.
- Status, confirmation evidence and any unresolved customer-crediting issue.
Connect the outgoing refund to the daily reconciliation checklist. A refund is a separate outflow linked to the sale, not a reason to erase the original receipt. Keep fees distinct so the records explain both the returned amount and the cost of sending it.
Where Yolfi fits
Yolfi's payment links page describes payment tracking and funds arriving directly in the merchant's wallet. Direct receipt makes it especially important to define who can approve and sign an outgoing return.
Before offering refunds, verify what your current Yolfi setup and wallet actually support. Do not infer a refund button, refund API, automatic destination verification or exchange-crediting guarantee from a payment-link page. Keep your refund policy alongside your payment instructions, and use the provider's documented route wherever it controls the return.
FAQ
Can a confirmed crypto payment simply be reversed?
Do not treat a confirmed transfer as something the merchant can undo. A merchant-controlled refund normally requires a separate authorized transfer; provider-managed returns follow the provider's process.
Should I always refund to the original sending address?
No. That address may be an exchange's shared wallet. Follow the provider's destination rules or, for a merchant-controlled transfer, verify receiving instructions through the authenticated customer channel before sending.
Can I refund USDC on a cheaper network?
Not merely because it is cheaper. The customer must be able to receive that asset on that network, the method must support the transfer, and the change must be explicitly agreed and recorded. Do not assume matching tickers mean identical assets or destinations.
What if the customer says the refund never arrived?
Check the existing transfer first: network, asset, destination, memo or tag, confirmation and provider status. An exchange may need the transaction reference to investigate crediting. Do not send a second refund just because a message or API response was delayed.
Make the return as traceable as the sale
A safe refund has an authenticated request, an approved amount, a verified destination and one traceable execution. Set those rules before sharing your first payment link, then preserve the original receipt and return together so both customer service and finance can explain what happened.
