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

# Merchant quickstart

> What a merchant does to go live, and what gates each step.

## The path

<Steps>
  <Step title="Sign in with a wallet">
    SIWE only. No email, no password. The `merchants` row is created on first sign-in, and the merchant wallet is screened for sanctions at this point.
  </Step>

  <Step title="Attest a payout recipient">
    Call `setRecipient` on `MerchantRegistry` from the wallet that will own the settlement. This is ownerless and `msg.sender`-scoped, so nobody else can attest on the merchant's behalf.

    Optional in the sense that `effectiveRecipient` is identity-default — an unattested merchant resolves to themselves — but an explicit attestation is what makes the anchor check meaningful.
  </Step>

  <Step title="Deploy the pool, per chain">
    The merchant signs the prepared factory transaction from the dashboard and pays native gas. Roughly $0.07 on Ethereum, **$29.37 on TRON\*\*.

    No contract change is needed for this: the pool address is CREATE2-deterministic and its init code commits the recipients, so anyone can deploy it.
  </Step>

  <Step title="Get the embed snippet">
    SDK keys and the iframe snippet unlock only once the pool has code on-chain.
  </Step>

  <Step title="Pin the settlement anchor">
    Put the payout wallet in the embed on the merchant's **own site**. This is the root of the client-side verification chain and the thing a database compromise cannot reach.
  </Step>
</Steps>

## Why deployment gates integration

<Info>
  The gate sits at **integration**, not at signup and not at checkout. A merchant can create an account and explore freely, but cannot ship anything until their pool exists.
</Info>

Two reasons:

* **It stops an unproven account from spending platform money.** The keeper previously deployed pools lazily on its own gas at first use. Ten thousand fake accounts would cost $99 on Base and **$288,200 on TRON\*\*. The cost is not the point on EVM; the unauthenticated ability to make the platform spend is.
* **A live integration always has a settlement destination.** No customer can pay into a configuration that was never finished.

<Warning>
  This gate is **not** a security requirement. The client-side trust verification works fine against an undeployed pool — `predictPoolAddress` is pure CREATE2 arithmetic and the load-bearing chain read is against the registry, not the pool. Do not justify the gate on security grounds; that claim would be wrong.
</Warning>

## Rail availability per chain

|      | Connect rail                  | Deposit rail     |
| ---- | ----------------------------- | ---------------- |
| EVM  | Requires a deployed pool      | Works pre-deploy |
| TRON | Not yet — GO given, not built | Live             |

The deposit rail works before deployment because a sweep into an undeployed pool is a plain ERC-20 transfer that becomes distributable the moment the pool exists. The connect rail does not, because `deposit()` is a contract call that reverts against an address with no code.

<Info>
  Keep a keeper-side rescue path for a customer payment that lands while a pool is somehow still undeployed. Never strand a real payment over a merchant's unfinished setup step.
</Info>

## Configuration

| Setting                       | Default            | Notes                                                              |
| ----------------------------- | ------------------ | ------------------------------------------------------------------ |
| Settlement stablecoin         | EURC               | USDC, USDT, EURC, or MATCH. A database default, not a positioning. |
| Display currency              | EUR                | USD offered equally.                                               |
| Enabled chains                | Per-merchant       | Only activated chains appear in checkout.                          |
| Enabled token cells           | Per (token, chain) | Enforced server-side, not just hidden in the UI.                   |
| Sanctions screening of payers | Off                | Per-merchant opt-in.                                               |
| Settlement cost tolerance     | —                  | Designed: one percentage that becomes a per-chain minimum.         |
| Distribute cadence            | Manual             | Backstop still applies.                                            |

## Payment links

A single Generate modal produces a hosted, single-use payment link: price and currency, optional title, accepted tokens, networks, and an optional expiry defaulting to one hour.

<Warning>
  Known issues in the shipped version: single-use is not enforced server-side, so a settled link keeps opening a working checkout; URL parameters can override the fixed amount because the checkout page reads editable parameters rather than the resolved link row; and comma-locale amounts parse as `NaN`.
</Warning>

## What the customer sees

A single-panel wizard: currency → network → rail → pay. Copy is de-jargoned — no "pool", "rail", "forwarder", or "deposit" in customer-facing text.

Amounts display to at most two decimals, like fiat. The decided fix is to round the **quoted token amount** at quote time rather than only at render, so a customer who types exactly what they see is not technically off by the difference.