This policy is part of the Terms and describes what the system actually does. It is deliberately narrower than a card gateway’s equivalent, because the rail is narrower.
1. Definitions
- Refund — a voluntary return of funds initiated by the merchant, from the merchant’s balance, to the address that paid the invoice.
- Dispute — a claim recorded by an end-customer against a merchant. It is a record and an escalation, not a payment instruction.
- Reversal — a ledger correction we make when a blockchain reorganises and a payment we credited turns out not to have happened. It is not a dispute outcome.
2. Who can refund
Only the merchant. Refunds are issued from the dashboard or by calling POST /v1/refunds or POST /v1/payments/:id/refund with a project API key. There is no customer-initiated refund and no operator-initiated refund of a merchant’s payment. If you are a customer, your route is the merchant, and then §6.
3. What a refund can and cannot be
- The invoice must be paid or overpaid. An invoice that is still partially paid, expired or cancelled cannot be refunded through this route.
- It must go back to the address that paid. The destination is checked against the payer source addresses observed on chain for that invoice, and rejected otherwise. There is no alternate-refund-address mechanism, for partial refunds or for anything else. The one exception is an invoice with no observed chain data at all, where the check has nothing to compare against.
- It is paid in the invoice’s settlement asset, on a network valid for that asset. You cannot refund in a different asset.
- Partial refunds are supported. The refundable amount is the invoice amount less every refund already completed or in flight — measured against the gross invoice, not against what you netted after fees.
- There is no deadline. No time window is enforced anywhere. A refund can be issued as long as the invoice qualifies and your balance covers it.
- A refund covering the full remaining amount moves the invoice to
REFUNDED.
4. Who pays for it
You do. A refund is debited from your available balance, and the network fee for sending it is debited on top. If your balance does not cover both, the refund is refused; we do not extend credit and we do not invoice you for a shortfall.
Processing fees on the original payment are not returned. Refunding a payment does not reverse the fee we earned on it, in whole or in part, at any point after the payment. Price your own refund policy on that basis.
5. Checks a refund still has to pass
- Sanctions screening of the destination address — a match is a hard refusal.
- Your project’s payout allowlist, if you have enabled one.
- Per-asset exposure caps on outbound value.
- An idempotency key, which is mandatory once live broadcast is enabled.
Two operational notes worth knowing before you build against this. Where on-chain broadcast is not enabled on the deployment, a refund completes immediately against internal balances with a placeholder reference beginning sandbox_ and nothing moves on any chain. Where live broadcast is enabled, the direct refund endpoints are deliberately refused in favour of the approved batch and operator workflows — so a working sandbox integration against POST /v1/refunds will not simply switch on in live. Design for that.
Refund progress is reported by the refund.processing, refund.completed and refund.failed webhooks.
6. Disputes
An end-customer can file a dispute from the receipt page linked in their payment confirmation. It records a reason — not received, not as described, duplicate, unauthorised, or other — and notifies the merchant. It moves through open, in review, and then resolved or rejected. If it sits unresolved beyond a threshold (three days by default) it is escalated to the operator.
Being precise about what this is: filing a dispute does not move any money. There is no automatic debit of the merchant’s balance, no reversal, no arbitration timetable, no appeal stage, and no adjudication by us that binds either side. A dispute creates a record, a notification, and pressure. A refund, if one happens, is still an act by the merchant under §2.
Your contract for the goods or services is with the merchant, and your consumer rights run against the merchant. Where a merchant is systematically failing to honour them we can suspend or terminate them under the acceptable-use policy, and we will — but that is enforcement against the merchant, not compensation to you.
7. Reversals we do make
If a blockchain reorganises and a transaction we already credited is no longer in the canonical chain, we reverse the settlement on the ledger: the merchant balance that was credited is debited back and the invoice returns to an unpaid state. This is the only automatic debit of a merchant balance in the system, it is chain-driven, and it has nothing to do with disputes.
8. Situations we are asked about, answered honestly
- Wrong network. Funds sent to a veilnebu.la address on a network the invoice was not for are not automatically detected or returned. Recovery may be technically possible and is best-effort at the operator’s discretion; there is no committed window and no committed fee. Ask at [email protected].
- Underpayment. The invoice sits at partially paid and does not settle. It is not refundable through the refund endpoint, because that requires a paid or overpaid invoice. Topping up within the invoice window is the intended route; anything else is a manual conversation.
- Overpayment. The invoice settles as overpaid and the excess is part of what the merchant received. It is refundable by the merchant like any other amount, back to the paying address. It is not returned automatically.
- Wrong address entirely. Funds sent to an address that is not associated with your invoice never reach us and are outside anything we can act on.
9. Contact
Customers: contact the merchant first, then file from your receipt page. If you cannot find either, write to [email protected] with the transaction hash and the merchant name.
Merchants: the same address for anything a dashboard action cannot resolve.