> ## 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.
# Settlement architecture
> The deep explanation: why money moves the way it does, and what each piece is for.
This is the long version. If you only want to integrate, [How it works](/get-started/how-it-works) is enough. Read this when you need to explain the model to a CTO, an auditor, or a nervous finance lead.
## The problem being solved
A crypto payment processor has to answer one question: **where does the customer's money go first?**
Almost every processor answers "into our wallet." That single choice creates everything merchants dislike about them — withdrawal delays, account freezes, minimum payout thresholds, and the risk that the processor's insolvency becomes your insolvency.
We answer "into a contract that can only pay the merchant." Everything else follows from that.
## The pool
Each merchant gets a **pool** — a small, immutable contract, one per chain.
```mermaid theme={null}
flowchart TB
subgraph pool["Your pool contract"]
direction TB
R["Payout: your address
Rate: fixed at creation
Hard cap: 2.5%"]
end
IN1[Connect payment] --> pool
IN2[Deposit sweep] --> pool
pool --> OUT1["You — 99%"]
pool --> OUT2["CryptoCheckout — 1%"]
```
Three properties matter:
No admin function, no upgrade path, no pause switch. The code that exists at deployment is the code that runs forever.
Nobody holds a privileged key. There is no owner to compromise, subpoena, or socially engineer.
Payout addresses are part of the contract's creation code, so the contract's **address is derived from them**. Different recipients means a different address.
That last one is subtle and it's the foundation of everything. Because the address is computed from the payout configuration, anyone can independently check that a given address pays a given merchant — by recomputing it. There is no database to trust.
## Counterfactual addresses
Addresses are computed before the contract exists, using CREATE2 — a deterministic function of the creation code and a salt.
```mermaid theme={null}
flowchart LR
A["Your payout address
+ split config"] --> B["Creation code"]
B --> C["CREATE2
hash"]
C --> D["Pool address
(known before deployment)"]
```
Two consequences you'll notice:
* Your pool has the **same address on all seven EVM chains**, because the creation code is byte-identical across them. One address to whitelist, one to reconcile against.
* We can show a customer a payment address before any contract exists there. The contract is deployed lazily, at the moment it's needed.
## Two rails
Customers arrive in two different states, so there are two paths in.
The customer has a browser wallet. They sign one transaction that calls `deposit()` on your pool directly.
* Funds move straight into the pool
* The customer pays their own network fee
* Attribution is exact — the payment ID is in the transaction
* Requires your pool to be deployed on that chain
Simple, cheap, and the best experience when it's available.
The customer has no connected wallet — they're paying from an exchange, a hardware wallet, or a phone app that can't sign contract calls.
They get a **one-time address**, unique to that invoice. They send a plain transfer to it. We deploy a small **forwarder** contract at that address and sweep 100% into your pool.
* Works from literally anywhere that can send a token
* We pay the network fees for deploying and sweeping
* Attribution is exact, because the address is unique to the invoice
* Works even before your pool is deployed
The forwarder deserves a note: it is **sweep-only**. It has no refund function and no way to send funds anywhere except the pool its address commits to. It also stays callable after its first sweep, so a customer who pays the same address twice — which happens, when exchange withdrawals are slow or an address is re-pasted — doesn't lose the second payment.
## Distribution
Funds accumulate. Nothing is split per payment, because splitting per payment means three transfers per order and network fees that dwarf small orders.
When you claim, `distribute()` reads the pool's balance and credits each recipient, then `claim()` moves your share out.
`distribute()` is callable by **anyone**. Not just you, not just us. This is the property that makes the whole arrangement non-custodial — there is no party who can decline to release your funds, because releasing them doesn't require anyone's permission.
We also run a monthly backstop that distributes dormant pools, so a merchant who forgets about a small balance doesn't leave it stranded.
## Where the trust actually sits
The honest map:
| Component | Trusted with | Not trusted with |
| ----------------- | ---------------------------------------- | ---------------------------------------------- |
| The blockchain | Everything about money and routing | — |
| Our database | Showing you dashboards and analytics | **The fund path** |
| Our API responses | Convenience | Anything the browser can verify itself |
| Our keeper | Making sweeps happen on time | Choosing a destination — it re-reads the chain |
| Your own site | Pinning the payout address in your embed | — |
The database is display-only for money. If it were entirely rewritten by an attacker, the checkout would still refuse to send funds anywhere except your real address — because the browser checks the chain, not the database. [How that check works](/concepts/verification).
## What this costs you
Non-custody isn't free. The honest trade-offs:
Deploying your pool once per chain, and each claim. Both are transactions you sign. A custodial processor absorbs these — and charges you for them elsewhere.
You can't claim on a chain where you hold no ETH, POL, BNB, AVAX, or TRX.
We can't refund on your behalf, because we never hold the money. [Refunds](/money/refunds).
A wrong payout address cannot be undone by support. This is why the payout attestation is signed from your own wallet and shown back to you for confirmation.
When each is offered, and how to think about them.