> ## Documentation Index
> Fetch the complete documentation index at: https://docs.antonpayments.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Going Live

> The checklist you walk through before your first production payout. Every item is a hard dependency — sandbox cannot prove any of it for you.

Moving from sandbox to production is a deliberate switch, not an upgrade. The environments are isolated by design: different credentials, different data, different base URL. This checklist covers what sandbox can't simulate.

<Warning>
  A single missed item — unverified webhook signatures, no idempotency on payout creation, missing `429` handling — can mean duplicate payouts, silent failures, or being billed for funds you can't prove you sent. Walk the list.
</Warning>

## Merchant account

<Steps>
  <Step title="Complete KYB">
    Identity verification and business underwriting must be approved before any live payout will clear `pending_screening`. Track status in the merchant dashboard.
  </Step>

  <Step title="Fund your balance">
    Deposit fiat or stablecoin for the corridor you intend to use. Live payouts draw from your balance — a zero balance returns `insufficient_funds`.
  </Step>

  <Step title="Enable your corridors">
    Confirm every source/destination currency pair your application uses is active on your account. Requesting a corridor that isn't enabled returns `corridor_not_enabled`.
  </Step>
</Steps>

## Integration

<Steps>
  <Step title="Idempotency on every mutation">
    Every `POST`, `PUT`, or `PATCH` that creates or mutates state must carry an `Idempotency-Key` header. Derive keys deterministically from your own business data so you can safely retry after a network failure without double-sending. See [Idempotency](/api-reference/idempotency).
  </Step>

  <Step title="Webhook endpoint in production">
    Deploy your webhook receiver with HTTPS, a publicly reachable hostname, and logging. Subscribe to `payout.*`, `beneficiary.*`, `rfi.*`, and any other events you depend on.
  </Step>

  <Step title="Signature verification on every delivery">
    Reject any webhook whose signature fails verification. Use a constant-time compare. Enforce a replay window — reject deliveries older than 5 minutes. See [Webhook Signing](/api-reference/webhook-signing).
  </Step>

  <Step title="Rate limit handling">
    On `429`, honor the `Retry-After` header with jittered backoff. Do not retry everything at the same instant. See [Rate Limits](/api-reference/rate-limits).
  </Step>

  <Step title="Error handling for every documented code">
    Parse the `error.code` field on `4xx` and `5xx` responses and map each to a deliberate behavior: retry, escalate to a human, surface to the end user, or fail the job. See [Errors](/api-reference/errors).
  </Step>

  <Step title="Graceful handling of manual_review">
    Payouts in `manual_review` can clear in minutes, or take longer if an RFI is raised. Surface a pending state to your end user; do not treat review as an error.
  </Step>
</Steps>

## Operations

<Steps>
  <Step title="Monitoring and alerting">
    Alert on: unexpected payout failures, webhook delivery retries exhausted, elevated `5xx` rates from the Anton API, stale `manual_review` payouts, and open RFIs older than your SLA.
  </Step>

  <Step title="Credential management">
    Production API keys live in your secrets manager — never in environment files committed to source control, never in frontend code. Document your rotation procedure before go-live, not after the first incident.
  </Step>

  <Step title="Audit log access">
    Confirm your team has access to the merchant audit log in the dashboard. Every state-changing API call generates an audit entry; this is the authoritative record for compliance and incident response.
  </Step>
</Steps>

## Cutover day

Swap `ant_oc_test_*` for `ant_oc_live_*` in your production secrets manager and redeploy. Verify the first live request with a **very small payout** to a beneficiary you control — confirm the full lifecycle (`created → approved → sent → completed`) before ramping traffic.

<Note>
  Production payouts cannot be rolled back once a rail accepts them. There is no undo. Test the lifecycle end-to-end at minimum volume first.
</Note>

## If something looks wrong

Pause new payout creation and contact [help.antonpayments.com](https://help.antonpayments.com). Include the `X-Request-ID` header from any response that behaved unexpectedly — it lets support trace the exact call in our logs.