# Security And Go-Live

Security docs should be concrete and direct. Readers should know which actions are safe, which are risky, and what must be checked before live payments.

{% hint style="danger" %}
**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.
{% endhint %}

### 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 operator actions.
* Payout destinations and dynamic recipients should be validated by the merchant backend.
* Billing, payout, and gas-credit actions should be visible to operators.

### 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.
* Operators know 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 understood by operators.

#### 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 internally.
* 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 operator before use.
* Payout route failures are visible to operations.
* Payout API withdrawal quota and fees are understood.

#### Billing and gas credits

* Current plan is correct.
* Invoice fee and minimum fee are understood by finance and operations.
* Included gas allowance is visible in billing.
* Prepaid gas top-up flow has been tested or reviewed.
* Low-gas and gas-blocked warnings are routed to operators.
* 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.

{% hint style="warning" %}
**Smoke-test note:** Do not use customer funds for first production smoke. Use an operator-controlled payment source and destination that your team can reconcile.
{% endhint %}

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.paychainhq.io/paychainhq-documentation-page/security-and-go-live.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.