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

# Payment rails

> Connect and deposit: when each is offered, what your customer sees, and what it means for you.

Two ways into the same pool. Your customer picks; you don't have to choose.

## Side by side

|                          | Connect                       | Deposit                         |
| ------------------------ | ----------------------------- | ------------------------------- |
| Customer needs           | A browser wallet              | Any way to send tokens          |
| Works from an exchange   | No                            | **Yes**                         |
| Who pays the network fee | Customer                      | We do                           |
| Settles in               | One confirmation              | Inbound confirm, then our sweep |
| Attribution              | Payment ID in the transaction | Unique address per invoice      |
| Needs your pool deployed | **Yes**                       | No                              |
| Minimum order            | None                          | Per-chain minimum applies       |

## Connect

```mermaid theme={null}
flowchart LR
    A[Customer connects wallet] --> B[Approves token]
    B --> C["Signs deposit()"]
    C --> D[(Your pool)]
```

The customer's wallet talks to your pool directly. Fastest to settle, exact attribution, and it costs us nothing — which is why it has no minimum order value.

Available on all seven EVM chains. TRON support is built and shipping.

## Deposit

```mermaid theme={null}
flowchart LR
    A[Customer sees address + QR] --> B[Sends a plain transfer]
    B --> C[One-time forwarder address]
    C -->|We deploy and sweep| D[(Your pool)]
```

The customer gets an address and a QR code. They can pay from a phone wallet, a hardware wallet, or by withdrawing straight from Binance, Coinbase, or Kraken.

<Tip>
  This rail is why the product works commercially. A large share of real crypto payments come straight off an exchange, where the customer has no connected wallet at all. Processors that only support wallet connection quietly turn those customers away.
</Tip>

We pay to deploy the forwarder and sweep it. Because that cost is fixed per invoice while our fee is a percentage, very small orders on expensive chains aren't viable — hence a per-chain minimum. Below it, the checkout offers the connect rail instead of refusing.

## What decides what's shown

```mermaid theme={null}
flowchart TD
    A[Customer picks a chain] --> B{Pool deployed<br/>on this chain?}
    B -->|No| C[Connect hidden<br/>Deposit offered]
    B -->|Yes| D{Order above the<br/>deposit minimum?}
    D -->|Yes| E[Both rails offered]
    D -->|No| F[Connect offered]
```

You can also set your own minimum per chain in **Settings**, expressed as a percentage of order value — a cap on how much settlement cost you'll tolerate.

## Which should you steer customers to

You don't need to. But if you're designing your own flow:

<Columns cols={2}>
  <Card title="Prefer connect for small orders" icon="feather">
    No minimum, faster settlement, and exact attribution with no sweep step.
  </Card>

  <Card title="Prefer deposit for reach" icon="globe">
    It's the only option for customers paying from an exchange, which is a large share of crypto buyers.
  </Card>
</Columns>

## A third rail, coming

For repeat customers — subscriptions, balance top-ups, marketplaces — a **per-customer address** is in development. One permanent address per customer instead of one per invoice, which makes repeat deposits dramatically cheaper on TRON.

The trade-off is attribution: the address identifies *who*, not *which order*, so matching relies on amount and timing. Good for balance models, wrong for one-shot e-commerce. It'll be opt-in. [Roadmap](/reference/roadmap).