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

# Security go live

# Security And Go-Live

Use this checklist before accepting live payments or enabling automated fund movement.

<Warning>
  **Important note:** Treat payout API keys, webhook secrets, live API keys, and billing controls as production financial controls. They should be stored, rotated, and reviewed like other payment infrastructure secrets.
</Warning>

## Security topics

* API keys are server-side secrets.
* Standard API keys cannot move funds.
* Payout API keys must be scoped by token, network, destination, amount, daily cap, and optional IP policy.
* Webhooks must be verified with the raw body.
* Dashboard step-up is required for sensitive account actions.
* Payout destinations and dynamic recipients should be validated by the merchant backend.
* Billing, payout, and gas-credit actions should be visible to authorized team members.

## Go-live checklist

### Account and environment

* Live business is approved.
* Sandbox and live modes are clearly separated in the dashboard.
* Production backend points to the live API base URL.
* Sandbox keys are not present in production.
* Production keys are not present in local `.env` files committed to source control.
* Your team knows which business ID is live.

### Secrets and API keys

* Live API keys are stored in a secret manager.
* Standard API key is used for invoices, reads, balances, transactions, networks, tokens, and webhooks.
* Payout API key is used only on trusted backend services that create withdrawals or dynamic payout recipients.
* Payout API key is scoped by token, network, destination policy, amount limit, daily cap, and optional IP policy.
* Contract execution key, if used, is scoped only to approved action IDs.
* Keys are not logged by application middleware, error reporters, or request tracing.
* A key rotation process exists and has been tested.

### Webhooks

* Webhook endpoint uses HTTPS.
* Webhook endpoint is different for sandbox and live.
* Webhook signature verification uses the raw request body.
* Webhook timestamp tolerance is enforced.
* Webhook event ID is stored for idempotency.
* Fulfillment fetches canonical invoice state after webhook verification.
* Handler returns `2xx` quickly after accepting the event.
* Failed webhook retry and replay process is documented and tested.

### Payment flow

* At least one live test invoice has been created.
* Payment details show the correct token, chain, and network.
* Wrong-token and wrong-network behavior is understood.
* Underpayment and overpayment policy is documented in your order system.
* Invoice status, transaction history, and balance reconciliation have been checked.
* Customer/order metadata is stored consistently.

### Withdrawals and payout automation

* Withdrawal quote and create flow has been tested with a small amount.
* Destination validation happens in your backend before creating a payout.
* Dynamic payout recipients are not accepted directly from untrusted frontend input.
* Payout routes have been reviewed by an authorized team member before use.
* Payout route failures are visible in monitoring or the dashboard.
* Payout API withdrawal quota and fees are understood.

### Billing and gas credits

* Current plan is correct.
* Invoice fee and minimum fee are understood by your team.
* Included gas allowance is visible in billing.
* Prepaid gas top-up flow has been tested or reviewed.
* Low-gas and gas-blocked warnings are monitored by your team.
* Renewal invoice, grace period, and downgrade behavior are understood.

### Monitoring and support

* Request IDs are logged without secrets.
* Webhook failures are monitored.
* Withdrawal failures are monitored.
* Gas-blocked operations are monitored.
* Billing past-due warnings are monitored.
* Support contact and incident owner are defined.
* Production smoke test has been completed and recorded.

## Production smoke test

Run this with the smallest practical amount and only against a live business that is approved for production.

1. Create a live invoice.
2. Pay the invoice using the intended token and network.
3. Confirm `invoice.paid` or `invoice.overpaid` webhook is received.
4. Verify your backend fetches the canonical invoice before fulfillment.
5. Confirm dashboard invoice state matches your backend state.
6. Confirm balance and transaction history update.
7. Create a withdrawal quote.
8. Create a small withdrawal with a payout API key where policy allows it.
9. Confirm withdrawal webhook and final status.
10. Check billing usage for invoice fee, payout quota, and gas-credit movement.
11. Confirm no secrets appear in logs.

<Warning>
  **Smoke-test note:** Do not use customer funds for first production smoke. Use a team-controlled payment source and destination that your team can reconcile.
</Warning>

## Irreversible or sensitive actions

Label these clearly:

* Creating payout API keys.
* Creating withdrawals.
* Sending dynamic payout recipients.
* Rotating webhook secrets.
* Changing live webhook URLs.
* Changing billing plan or applying promotional subscriptions.