Go-live Checklist

Check credentials, Webhooks, limits, reconciliation, and alerts before launching.

Live credentials are issued only after every item is checked.

[ ] Create a live API Key with a nonempty IP allowlist containing your actual outbound IPs
[ ] Verify signing in the sandbox: PATH included, with query; raw body, without reserialization; nonce replay protection
[ ] Generate a UUID idempotency key per business operation; retry 504 with the same key, and corrected business failures with a new key
[ ] Deploy your Webhook endpoint with signature verification, deduplication by event_id, and forward-only merging by status_version
[ ] Allowlist our Webhook outbound IPs
[ ] Handle unknown states as unknown and alert, rather than using default to Processing
[ ] Parse all amounts as fixed-point strings, never floating-point values
[ ] Choose a step-up integration: hosted page / assertion / platform-direct; irreversible actions use the hosted page

[ ] Your funding-account balance exceeds estimated first-month costs, and low-balance thresholds are configured
[ ] Product and BIN authorizations are set, with verified tests showing you can retrieve only authorized products
[ ] Custody responsibilities are documented in the contract; custody_model and asset allowlists are configured
[ ] Your fees, limits, and risk settings are configured and reviewed in central administration
[ ] Isolation acceptance: merchant A's credentials return 404 for all attempts to read merchant B's members and orders
[ ] Cross-merchant probing acceptance: attempt registration with an email / document number belonging to another merchant, and confirm 400 invalid_request, not 409 email_taken. We do not disclose that a person already exists, which could enable account probing. ⚠ This is also a current limitation: one individual cannot yet create separate accounts under two merchants; identity-layer unique indexes are not yet merchant-scoped. Such a conflict produces the same generic 400.
[ ] Rate-limit quotas are sized for your volume and load-tested
[ ] Your Webhook dead-letter alerts reach our operations address

When your prepaid funds are insufficient, members may see a failed transaction despite sufficient personal balances.

This follows from the model where you custody member funds while business costs use your prepaid account. We mitigate it in three ways:

The balance check runs before freezing, stopping the flow before funds enter a locked bucket that neither the user nor ordinary operations controls can release.
Three low-balance levels: < 7 days of average spend → portal banner + email; < 3 days → daily alerts copied to our operations team; < 1 day → automatic suspension of products in descending cost order.
Member-facing messages do not reveal the cause; only Service temporarily unavailable is shown.

Configure a low-balance alert recipient whose mailbox is actively monitored.