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

# Go-Live Checklist

> What to check before you switch to production

Go through this list before you ask for production access. Production access is only granted after your integration passes in [sandbox](/api-reference/sandbox-testing).

## Production access

<Check>
  You have tested every outcome in [Sandbox Testing](/api-reference/sandbox-testing): completed, payment failed and expired.
</Check>

<Check>
  You have asked [support@rampnow.io](mailto:support@rampnow.io) for production access and have your production API key and secret from the [Partner Dashboard](https://partner.rampnow.io).
</Check>

<Check>
  Production uses `https://api.rampnow.io` and `https://app.rampnow.io`, with production keys. No sandbox host or key is left in your production config.
</Check>

## Requests

<Check>
  Your API secret is only on your server. It never ships in a browser or mobile app.
</Check>

<Check>
  Your server clock is synced (NTP). The signature timestamp must be within 1 minute of Rampnow's time. See [Authentication](/api-reference/authentication).
</Check>

<Check>
  Your error handling branches on the error `code`, not on `message`. You show `displayError` to users when it is present. See [Error Codes](/api-reference/error-codes).
</Check>

## Order ids

<Check>
  Every order gets its own unique `externalOrderUid`, and you store it before you call Create Order.
</Check>

<Check>
  Before you retry a Create Order call that timed out or failed, look the id up with [Get Order](/api-reference/onramp-&-offramp-intent/get-an-order-by-external-id). Rampnow does not reject a repeated `externalOrderUid`, so a blind retry can create a second order.
</Check>

## Webhooks

<Check>
  Your webhook endpoint is set in the API Hub of the Partner Dashboard, subscribed to `ramp_order.status_change`, and reachable over HTTPS.
</Check>

<Check>
  You verify the `X-RAMPNOW-SIGN` signature on every webhook and reject requests that fail.
</Check>

<Check>
  You return any `2xx` fast and do slow work afterwards. Failed deliveries are retried for about 24 hours.
</Check>

<Check>
  You deduplicate on `eventUid`, so a retried event is only processed once.
</Check>

See the [Webhook Guide](/api-reference/webhook).

## Status handling

<Check>
  You handle every status on [Order Status](/api-reference/order-status), and unknown values don't break your code.
</Check>

<Check>
  You treat `failed` as in progress, not final. Rampnow operations either retry the order, so it can still reach `completed`, or block and refund it.
</Check>

<Check>
  You treat `completed`, `payment_failed`, `expired`, `canceled` and `blocked` as final for the user, but still apply later webhooks: a late payment can move a `payment_failed` or `expired` order to `processing`.
</Check>

<Check>
  You reconcile on `dstFillAmount` (the amount actually delivered), not on the quoted `dstAmount`.
</Check>

## Return URL

<Check>
  You set `returnUrl` on each order, with your own order id in it, so the user lands back on the right page in your app after checkout.
</Check>

<Check>
  You don't treat the return to your app as proof of payment. A user can come back before paying or after a failure. Read the status from the webhook or Get Order.
</Check>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.