Skip to main content

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.

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

​
Merchant account

1

Complete KYB

Identity verification and business underwriting must be approved before any live payout will clear pending_screening. Track status in the merchant dashboard.
2

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

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.

​
Integration

1

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

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

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

Rate limit handling

On 429, honor the Retry-After header with jittered backoff. Do not retry everything at the same instant. See Rate Limits.
5

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

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.

​
Operations

1

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

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

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.

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

​
If something looks wrong

Pause new payout creation and contact 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.