> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cryptocheckout.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Refund policy

> The operational policy merchants and support need, and the one rule that must never be broken.

Locked 2026-06-18. Technical background: [Finality and refunds](/settlement/finality-and-refunds).

## The policy

**There is no on-chain refund mechanism on either rail.** Refunds are merchant-initiated, off-chain, and manual.

One path covers every case — overpayment, underpayment, wrong token, and cancellation:

<Steps>
  <Step title="Customer requests a refund">
    Through the merchant's own support channel. The platform is not in this loop.
  </Step>

  <Step title="Merchant collects a self-custody address">
    Supplied by the customer **at refund time**. Not stored in advance, not inferred.
  </Step>

  <Step title="Merchant sends the funds">
    From their own wallet, after the payment has been distributed and claimed.
  </Step>
</Steps>

## The rule that must never be broken

<Danger>
  **Never refund to the inbound sender.**

  CEX withdrawals originate from a shared omnibus hot wallet, not the customer's own address. Returning funds there is unattributable and almost always a permanent loss for the customer.
</Danger>

This holds even when the sending address looks like a normal wallet. The refund target must always be an address the customer supplies and controls.

## Why there is no window

The binding constraint is the refund **target**, not a timer.

Because a large share of deposit-rail payments have no safe on-chain refund target, an on-chain window would have added attack surface and audit scope without protecting the users actually at risk. It also created a free-option exploit — pay, watch the market, reverse within the window — which dies by construction once the window is gone.

Removing it also shrank the audited contract surface and sped up settlement, since funds sweep as soon as the deposit confirms.

## Practical consequences

| Situation                   | What happens                                                                                              |
| --------------------------- | --------------------------------------------------------------------------------------------------------- |
| Overpayment                 | Full amount sweeps to the pool. Merchant refunds the difference off-chain.                                |
| Underpayment                | Status `underpaid` with `confirmed_amount` against `expected_amount`. **No exit path today** — see below. |
| Wrong token                 | Status `wrong_token`. Detected and surfaced rather than lost.                                             |
| Cancellation after payment  | Same manual refund path as everything else.                                                               |
| Cancellation before payment | The intent expires. The counterfactual address still accepts funds forever.                               |
| Late payment after expiry   | Honoured. The chain is the source of truth; a timer never rejects a confirmed payment.                    |

## Open gaps

<Warning>
  **Underpayment has no exit path.** With `refund()` removed, a partial payment sits in a forwarder with no way to complete or return it without manual intervention. The designed answer is a customer top-up prompt plus a merchant sweep-and-refund action. Not built.
</Warning>

<Warning>
  **Refund fees are undecided.** A refund requires distribute and claim to have run first, so the platform fee has already been taken. Whether it is returned, and how that is disclosed to merchants and customers, is an open commercial decision.
</Warning>

## What the platform never does

* Never fronts refund money.
* Never claws back a settled payment.
* Never holds funds pending a dispute.

These are not service limitations to be worked around. Each one, if added, would give the platform custody — see [MiCA position](/compliance/mica).

## Merchant-facing wording

Terms and privacy pages were refreshed to state the general-checkout framing, the deposit rail, and the no-refund-window reality explicitly. Merchants must not be able to discover this policy for the first time during a dispute.