Test your integration
Verify payment and retry behavior before accepting live customer orders.
Choose the right environment
Ask for the API origin, credentials, available assets, and payment-testing procedure for your environment. A development checkout preview or test webhook does not execute a blockchain payment and is not a full testnet sandbox.
The API examples use placeholder hostnames. Do not send a real payment to an illustrative address from a documentation example.
Integration scenarios
| Scenario | Expected application behavior |
|---|---|
| Valid invoice | Save the invoice ID and use its returned checkout URL. |
| Invalid signature | Handle 401 without exposing the key. |
| Unicode in a signed body | Produce the same JSON serialization as the gateway. |
| Creation times out | Retry the same order and conditions, without duplicating the order. |
| Same order with a changed amount | Handle the conflict instead of silently replacing the invoice. |
| Valid webhook | Verify raw bytes and persist the event before acknowledging. |
| Tampered or stale webhook | Reject it without changing the order. |
| Duplicate or older event | Avoid duplicate fulfilment and state regression. |
| Underpayment or confirming transfer | Keep the order pending under your policy. |
| Overpayment or late payment | Apply the documented merchant policy once. |
| Secret rotation | Accept the matching entry in the plural signature header during overlap. |
| Webhook receiver unavailable | Observe retries in the console delivery log. |
Test webhook
Use the test-delivery action in merchant webhook settings to verify endpoint reachability and signing. A merchant.webhook.test event must not create a paid order. Confirm its delivery status in the console.
Going live
Use the appropriate production origin and merchant credentials, synchronize server time, configure HTTPS, and confirm that your receiver durably handles events and retries. Review payment statuses, authentication, and webhooks.