Part 12
Testing checklist
Test scenarios, production readiness, and information for investigations.
Test scenarios
| Scenario | What must be proven |
|---|---|
| Normal payin | The client shows the instruction and completes the order once, on a completed webhook or a GET SUCCEEDED. |
| Request timeout retry | The same body/key/reference leads to the same transaction. |
| Same key, different body | The client handles the 409 without automatically creating a new transaction. |
| QR not ready or expired | The UI shows the matching status; the API key never leaks to the browser. |
| Duplicate webhook | The order or user withdrawal is not processed twice. |
| Out-of-order webhook | The client status does not go backwards; GET is the source of confirmation. |
| Wrong signature / stale timestamp | The payload is rejected without changing any data. |
| Webhook endpoint down | The client fetches the status through the API and can process a replay. |
| Payout with insufficient balance | The client handles the rejection without finally reducing the user's balance. |
Payout UNKNOWN | The client keeps an under-review status; it does not create a replacement transfer. |
| Cancel races with execution | The client receives INVALID_STATE and fetches the latest status. |
| Balances and journal | CREDIT/DEBIT follow the buckets; a hold is not counted as an expense twice. |
| Wrong tenant access | The resource cannot be read or modified. |
| Rate limit and 5xx | Retries use backoff/jitter, Retry-After, and the same key. |
Before production activation
- Obtain the base URL, keys, webhook secret, scopes, channels, limits, and effective fee policy from AntaraPay.
- Run every sandbox scenario. Do not use real money to test timeouts or duplicate deliveries.
- Make sure you have a durable webhook inbox, business-transaction deduplication, polling fallback, log masking, and synchronised server clocks.
- Separate sandbox and production credentials and data, and prepare a key rotation procedure.
- Monitor the number of pending payins, payouts that are not final, failed webhooks, and report discrepancies.
Information for investigations
When asking for help, include the request_id, transaction ID, reference, UTC time, environment, endpoint, HTTP status, and error code. Do not send API keys, webhook secrets, full account numbers, or customers' personal data in support logs. Use the support channel given during onboarding.
Contract note
All endpoints, validation limits, and examples in this guide are a draft v1 contract for implementation. Breaking changes must use a new API version or a migration schedule communicated to clients.