Sandbox testing & going live

The hosts, the API key prefixes and the card numbers are the same whichever version you integrate — they live in Test cards. What follows is the v1-specific part: the endpoint-by-endpoint checklist, and the cutover.

Typical testing checklist

Before switching to production, confirm the following all succeed in sandbox:

1. Auth + capture without 3DS — POST /v1/payment/direct with 4111111111111111 returns Status: captured and Code: 0.
2. 3DS challenge — POST /v1/payment/direct with 4000000000003220 and 3DS: "yes" returns 3DSecureUrl; after redirect, /v1/status reports captured.
3. Webhook signature — a webhook reaches your configured sandbox endpoint, signature verifies successfully with your whsec_... sandbox secret (see Webhooks).
4. Refund — /v1/refund on the captured transaction returns Status: captured, OperationType: refund.
5. Status lookup by Tid — /v1/status with your own Tid returns the same transaction as when queried by Reference.
6. Error handling — a malformed request produces the expected numeric Code (e.g. 206 for an invalid card number). See Error codes.

A mismatch between the host and the key prefix — a test key sent to the production host, say — is rejected with Code: 3 (Invalid API key).

Going live

Once the checklist passes, the cutover is simple:

1. Switch the base URL from https://api.sandbox.settleflow.io to https://api.settleflow.io and replace the pk_test_ key with your pk_live_ key.
2. Replace the sandbox whsec_ secret with the production one.
3. Point your ReturnUrl and your dashboard webhook endpoint at production URLs (HTTPS required).
4. Run a single low-value transaction on a real card and reconcile it in the merchant dashboard.
5. Monitor the first production webhook deliveries to confirm signatures verify with the live secret.