> ## 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.

# Finality

> When a payment is genuinely irreversible, and when it is safe to ship.

The single rule: **ship when we say `payment_confirmed`, not before.**

## Why "seen" isn't "paid"

A transaction appearing on-chain is not the same as a transaction being permanent. Blocks can be reorganised, and a payment that existed a moment ago can cease to exist.

The attack is simple and old: pay, take the goods, then get the block containing the payment reorganised away. Crediting on first sight is how operators lose money.

```mermaid theme={null}
flowchart LR
    A[Transaction broadcast] --> B[Included in a block]
    B --> C[N confirmations]
    C --> D[Final]
    style B fill:#7f1d1d,stroke:#ef4444,color:#fff
    style D fill:#064e3b,stroke:#10B981,color:#fff
```

We only tell you about the green state.

## What confirmed means per rail

<Tabs>
  <Tab title="Connect rail">
    Final once the customer's `deposit()` transaction reaches the required confirmation depth for that chain.

    <Note>
      Today the `payment_confirmed` signal waits a little longer than it strictly needs to — until our settlement step also confirms. Shortening it to the deposit confirmation is a known improvement. It makes confirmation slightly slower, never less safe. [Roadmap](/reference/roadmap).
    </Note>
  </Tab>

  <Tab title="Deposit rail">
    Confirmed when **both** the inbound transfer confirms **and** our sweep into your pool confirms.

    Two steps, because the money isn't in your pool until the second one lands. We do the second automatically.
  </Tab>
</Tabs>

## Confirmation depth

Depth scales with value — a €5 order and a €50,000 order don't warrant the same wait. Defaults are per chain and account for each chain's actual reorg behaviour, which differs a lot. TRON needs around 19 confirmations for practical finality; some L2s have a soft-versus-hard distinction that matters at large values.

You can raise the thresholds in **Settings**. Consider it if you sell anything instantly consumable — account credit, digital keys, gambling chips — where a reversal can't be recovered by withholding shipment.

<Warning>
  Raising thresholds makes customers wait longer. It's a real trade-off between conversion and risk, and the right answer depends on what you sell.
</Warning>

## Ship from webhooks

<Danger>
  The browser callback `onPaymentConfirmed` fires only if the customer's tab is still open. Close the tab, and it never fires — but the payment still completed.

  Fulfil from the **webhook**. Use the browser callback for the thank-you screen and nothing else.
</Danger>

```mermaid theme={null}
flowchart TD
    A[Payment confirmed on-chain] --> B[Webhook to your server]
    A --> C[Browser callback]
    B --> D[Fulfil the order]
    C --> E[Show success UI]
    style B fill:#064e3b,stroke:#10B981,color:#fff
    style D fill:#064e3b,stroke:#10B981,color:#fff
```

## Once confirmed, it's permanent

No chargebacks. No reversals. No disputes. Neither the payer, nor their bank, nor we can undo a confirmed payment.

That cuts both ways: you're protected from fraudulent reversals, and you cannot claw back a payment you'd rather not have taken. Refunds are something you send. [Refunds](/money/refunds).

## Late payments still count

Quotes expire. Payment addresses do not.

If a customer's exchange withdrawal takes six hours and arrives long after the quote lapsed, the funds still reach your pool and still get credited. A confirmed payment is never rejected because a timer ran out.

What you'll see is an `expired_paid_late` status rather than a clean `paid`, so you can decide whether to honour the original order or contact the customer.

<Warning>
  One gap worth knowing: if a payment arrives at an address whose order has **already settled**, it currently isn't picked up automatically. The funds are safe — that address can only pay your pool — but recovering them needs us to intervene. Contact support if a customer says they paid an address twice. A fix is in progress. [Roadmap](/reference/roadmap).
</Warning>

[Edge cases](/money/edge-cases).