Going live

Live mode moves real USDC. Work through this list in order.

1. Business verification (KYB)Copy Anchor Link

Submit your business details in the dashboard, Verification. Owners and admins can submit; ZyloPay reviews them. Until the status is approved:

• live API keys cannot be created;
• mainnet go-live, mainnet terminals and Smart Tap are blocked;
• live payment intents answer 403 kyb_required.

Subscribe to kyb.status_changed (sent in both modes) to learn about the decision.

2. Go live on mainnetCopy Anchor Link

Switch the dashboard to mainnet and press Go Live. This registers your merchant on the mainnet settlement contract with your settlement wallet. Check that the settlement wallet is the one you control: withdrawals go there.

3. Live terminalsCopy Anchor Link

Provision mainnet terminals (Settings → POS Terminals). Testnet terminals cannot be switched: create new ones. Check each one shows in GET /v1/terminals with a live key.

4. Live API keysCopy Anchor Link

Create a separate live secret key per system, with only the scopes it needs, and an IP allowlist for servers with fixed egress addresses. See Authentication.

• One key per service, named after it.
• Minimal scopes.
• IP allowlist where possible.
• Stored in a secrets manager, not in code or CI variables visible to everyone.
• An owner and a rotation date for each key.

5. Live webhook endpointsCopy Anchor Link

Create live endpoints (https only). Each mode has its own endpoints and secrets.

• Signature verification with the live secret.
• Deduplication on event ID.
• 2xx within 10 seconds.
• Alerting on failing_since and on endpoint auto-disable.
• A scheduled catch-up from GET /v1/events.

6. Code reviewCopy Anchor Link

• Amounts are integers in atoms. No floating point.
• Every POST /v1/payment_intents and POST /v1/refunds uses an idempotency key derived from your own record.
• processing intents and pending refunds are never retried with a new key.
• Unknown fields, event types and error codes are tolerated.
• Request-Id is logged with every call.
• Declines (payment_intent.payment_failed) are shown to staff with a readable reason.

7. First live paymentCopy Anchor Link

Take a small real payment on each live terminal, refund it, and check that your systems recorded the payment, the refund and the events. Then compare with GET /v1/balance.

8. OperationsCopy Anchor Link

• Know how to reach support and keep request IDs in your logs.
• Watch the status page.
• Decide who may refund, and use the dashboard roles (owner, admin, member, viewer) accordingly.