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.