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

# Status and roadmap

> What's live, what's coming, what's known-broken, and what gates mainnet.

## Today

<Warning>
  CryptoCheckout runs on **testnet**. No contracts are deployed to any mainnet yet — deliberately, not as an oversight.
</Warning>

Both rails work end to end on all eight chains: payment, settlement, distribution, claiming, webhooks, and the dashboard. A full payment cycle has been verified on every supported chain.

Integrate now on testnet and you'll be ready the day your chains switch on.

## Known limitations

Stated plainly, because you'd find them eventually and it's better you plan around them.

<AccordionGroup>
  <Accordion title="BNB Chain is not yet offerable" icon="triangle-exclamation">
    Stablecoins there are 18-decimal rather than the 6 used elsewhere, and our deposit path doesn't yet handle that consistently. Enabling it before the fix risks a decimal-scaling error, so it stays off.

    **Affects:** anyone wanting BNB Chain. **Workaround:** use another chain.
  </Accordion>

  <Accordion title="USDT on Ethereum mainnet needs an approval fix" icon="triangle-exclamation">
    Mainnet USDT rejects changing a non-zero allowance to another non-zero value. A repeat customer with a leftover allowance would have their **wallet** payment fail.

    Testnet is unaffected. This is a mainnet go-live gate. Pay-by-address is unaffected either way.
  </Accordion>

  <Accordion title="A late payment to an already-settled address isn't picked up" icon="clock">
    If a customer pays an address whose order already settled — usually by reusing an old one — it currently isn't detected automatically.

    The funds are safe: that address can only pay your pool. Recovery needs us to intervene, so contact support.

    **Affects:** repeat customers who save addresses, and slow exchange withdrawals.
  </Accordion>

  <Accordion title="Underpayments need a manual conversation" icon="circle-half-stroke">
    There's no automatic prompt asking the customer to top up. The address stays valid and a second transfer is picked up, but you have to ask them.
  </Accordion>

  <Accordion title="No dedicated view for unmatched arrivals" icon="eye">
    Money that arrives without a matching order appears in Payments without one, rather than in a purpose-built surface. Finding it means scanning.
  </Accordion>

  <Accordion title="Payment links: single-use isn't enforced, amounts are editable" icon="link">
    A paid link still opens a working checkout, and the amount can be altered via the URL.

    **Workaround:** for anything where a duplicate or altered payment matters, use the embed and reconcile against your own order state.
  </Accordion>

  <Accordion title="Wallet payments confirm slightly later than necessary" icon="hourglass">
    The confirmation signal waits until our settlement step also confirms, rather than just the customer's transaction. Slower, never less safe.
  </Accordion>

  <Accordion title="On-chain verification is EVM-only" icon="shield-halved">
    TRON has no on-chain registry for payout attestations yet, so the browser-side check doesn't extend there. TRON payments settle correctly; they don't carry that specific verification. [Verification](/concepts/verification).
  </Accordion>

  <Accordion title="Refund fee policy is being finalised" icon="rotate-left">
    Whether a refunded order gets its 1% returned isn't settled. Assume you absorb it for now. [Refunds](/money/refunds).
  </Accordion>
</AccordionGroup>

## Coming

<Update label="Next" description="In active development">
  **TRON wallet payments.** TRON supports pay-by-address only today. Direct wallet payment removes the minimum order there entirely, which matters more on TRON than anywhere else.

  **Cheaper settlement.** A more efficient contract pattern plus better network-resource sourcing cuts what it costs to settle a pay-by-address payment substantially — lowering minimum order sizes on every chain, most dramatically on TRON.

  **One-tap claiming.** Collapsing distribution and payout into a single button and a single signature, with a live network-fee estimate.

  **A true 1% everywhere.** New pools will be provisioned so the merchant share is exactly 99%, matching the published rate precisely rather than approximately.
</Update>

<Update label="Planned" description="Designed, not yet built">
  **Merchant-signed pool deployment.** You sign and pay for your own payout contract, which removes any ambiguity about whose contract it is. Deployment then becomes a prerequisite for API keys and the embed.

  **Percentage-based cost controls.** Cap settlement cost as a share of order value instead of setting an absolute minimum per chain, with the implied minimum shown live as you adjust it.

  **Unsettled deposits surface.** One place showing every case where money arrived but never matched an order.

  **Customer top-up prompt** for underpayments, and a merchant-side sweep-and-refund action.

  **Payment link fixes.** Server-enforced single use, and amounts that can't be altered via the URL.

  **Per-customer deposit addresses.** One permanent address per customer instead of one per invoice — much cheaper for repeat deposits, so it suits subscriptions, balance top-ups, and marketplaces.

  The trade-off: the address identifies *who*, not *which order*, so matching relies on amount and timing. Right for balance models, wrong for one-shot e-commerce. It'll be opt-in.

  **Late-payment re-quoting.** A payment arriving long after expiry is currently honoured at the original amount however stale. It will instead be re-quoted at the current rate and re-checked against tolerance.
</Update>

<Update label="Phase 2" description="Not committed">
  **Volatile asset acceptance.** Letting customers pay in ETH or similar with conversion to your settlement token at checkout. The contract path exists but is not enabled — accepting volatile assets means someone bears price risk between payment and settlement, and that needs to be right rather than fast.

  **Multi-token checkout.** A wider set of tokens than you've explicitly enabled.
</Update>

## What gates mainnet

Four items, none of them engineering. Each chain is enabled separately.

<Steps>
  <Step title="Third-party security audit" icon="clipboard-check">
    Independent review of the settlement contracts.
  </Step>

  <Step title="Public bug bounty" icon="bug">
    Live before real money moves, so the contracts have been adversarially tested by people paid to break them.
  </Step>

  <Step title="Legal sign-off" icon="scale-balanced">
    Counsel review of the custody position and every public claim.
  </Step>

  <Step title="Per-chain approval" icon="key">
    Each chain reviewed and enabled individually rather than all at once.
  </Step>
</Steps>

Alongside those, per-chain technical gates: the USDT approval fix for Ethereum, the decimal fix for BNB Chain, and a re-verification of TRON's address derivation against real mainnet USDT.

<Note>
  We'd rather be late than be the crypto payment company that lost merchant funds to an unaudited contract. The gates are the product.
</Note>

## Keeping up

Changes that affect integrations are announced before they ship. Breaking changes to the API or webhook format come with notice and a migration path.

<Card title="Get set up now" icon="rocket" href="/get-started/quickstart" horizontal>
  Testnet integration carries straight over to mainnet.
</Card>