Sandbox

A separate Coinetic instance with no real networks. The API, signatures, checkout page, statuses and webhook retries all work exactly as in production; only the payments are simulated.

Sandbox and production keys are separate. A sandbox key doesn't work in production, and vice versa.

Test payments with buttons

On the sandbox checkout page, once a currency is selected, you'll see a “Sandbox: test payment” panel:

Test payments from automated tests

The same scenarios, via a request. The token is the part of checkout_url after #t=. A currency must already be selected (on the page, or via POST /v1/invoices/{id}/select with the same token).

POST /sandbox/v1/invoices/{id}/pay
Authorization: Bearer <token from checkout_url after #t=>
Content-Type: application/json

{"scenario": "exact"}

scenario values: exact, underpay, overpay, half, rest.

In the sandbox, a refund is executed with a single call, POST /v1/refunds/{id}/simulate (see Refunds).

Differences from production

• Invoices and webhooks carry livemode: false. Your production store must reject such invoices and events so that a sandbox connected by mistake can't ship goods.
• Webhooks and return_url can point to http://localhost and http://127.0.0.1. Public URLs must use https:// and port 443, just like production.
• AML checks always come back clean.
• Rates for volatile assets are real, sourced from exchanges.

What to test before launch

• Exact payment, underpayment plus top-up, overpayment, two halves.
• Expired invoice: a new invoice for the same order.
• Forged and stale webhooks are rejected; a repeated webhook doesn't fulfill twice.
• Webhook secret rotation and API key rotation without downtime.