---
title: "Production readiness checklist"
description: "Verify a BlindPay integration is ready to move from a development instance to production: config, tokens, networks, webhooks, compliance, and monitoring."
date: "2026-08-26"
category: "diagnostics"
products: ["payouts", "payins", "virtual-accounts", "compliance", "webhooks"]
---

Paste this prompt into your coding agent before flipping a development-instance integration to production.

## Prompt

```text
My BlindPay integration works on a development instance. Verify it is ready for production and produce a go/no-go checklist with evidence from my code and configuration.

Ground truth:
- https://blindpay.com/docs/llms.txt (read the sandbox vs production and instances pages, plus the pages for the flows in my code)
- The OpenAPI spec: curl https://api.blindpay.com/doc

Verify each item and mark it pass or fail with the evidence:
1. Instance separation: production uses its own instance ID and its own API key (dev keys do not work in prod); both come from environment config, never hardcoded; the production instance has been requested (approval can take up to 3 business days).
2. Token and network swap: no USDB and no testnet networks (base_sepolia, solana_devnet, sepolia, polygon_amoy, arbitrum_sepolia, stellar_testnet) reachable from production config; production uses USDC/USDT on mainnets.
3. Test scaffolding removed: no sentinel-amount logic ($666.00/$777.00), no auto-approve assumptions. Production KYC takes real time (standard about 60 seconds, enhanced and KYB up to a business day), so onboarding must be genuinely webhook-driven with a pending state in the UX, not a synchronous wait.
4. Webhooks re-registered: endpoint configuration does not carry over between instances; the production endpoint is registered on the production instance, its own whsec_ secret is in production config, and a real signed event has been received and verified there.
5. Real-world failure handling: rejected KYC and RFIs surface to users with a path forward; failed and refunded payouts alert someone; quote expiry triggers re-quote, not a stuck payment.
6. Limits and coverage: expected transaction sizes fit the per-transaction, daily, and monthly limits for my customers' KYC tiers, and every corridor I serve is supported in production; flag anything needing a limit increase in advance.
7. Monitoring: alerting exists for webhook delivery failures, payouts stuck in non-terminal states beyond the rail's expected settlement time, and reconciliation mismatches between my ledger and BlindPay statuses.
8. Runbook: a written procedure exists for a stuck or failed payment, including where to find the payout in the dashboard and how to contact BlindPay support.

Output: the checklist with pass/fail and evidence per item, the blocking failures, and the exact changes needed to reach go.
```

## How to use

1. Run this after the [integration quality audit](/prompts/integration-quality-audit) passes; this one focuses on the dev-to-prod transition.
2. Request your production instance early; approval can take days.
3. Keep the output as your launch sign-off document.

## Related docs

- [Sandbox vs production](https://blindpay.com/docs/learn/sandbox-vs-production)
- [Instances](https://blindpay.com/docs/learn/instances)
- [Cut-off times and limits](https://blindpay.com/docs/kb/cut-off-times)