Sandbox request keys
Send Idempotency-Key when creating a test intent. It accepts 8–80 letters, numbers, hyphens or underscores and is scoped to your developer account. Reuse the same key when retrying the same intended purchase. A duplicate request with the same normalised amount, currency and reference returns its existing intent.
Conflicting retries
Reusing an existing key with different purchase details returns HTTP 409. Generate a new key only when you mean to create a new test purchase. A changed response status or connection timeout does not prove that the original operation failed; retry or reconcile before creating a replacement.
Live matching uses other controls
The live API currently has its own waiting-intent reuse behaviour and unique receipt identity. Do not assume that the sandbox Idempotency-Key header applies to live endpoints. Review the live API documentation and maintain your own durable purchase reference and activation deduplication.
Database guarantees
Sandbox idempotency is enforced by a unique account-and-key constraint. Live receipt identity includes merchant, provider, receiving account and transaction ID. Application-level checks alone are insufficient when concurrent workers receive the same request.
KEEP EXPLORING