Docs/Payment-API
SPICEPAY DEVELOPER DOCS

Idempotency

A timed-out request may already have completed.

How it works

A timed-out request may already have completed. Reuse the same business identifier when retrying, and reconcile the original resource before issuing another financial action.

Implementation

The supplied SpicePay documentation describes resource-ID-based deduplication; the newer reference interface also documents Idempotency-Key for payment creation, confirmation and invoices. Confirm the deployed SpicePay release's behavior before relying on header replay. Refund retries should reuse refund_id and retrieve the result; a duplicate resource ID may produce an error rather than replay. Do not generate a new order identifier on each retry. Capture and cancel timeouts require retrieving the payment first.

Where it applies

Request Behaviour
POST /payments, POST /payments/{payment_id}/confirm Replays the first response.
POST /invoices Returns the invoice the first request created; see Invoices.
POST /refunds Not supported. Send your own refund_id; a repeat fails with HE_01.
POST /payments with your own payment_id A repeated payment_id fails with HE_01, key or not.

How payment keys behave

Situation Result
First request Processed; response stored for 24 hours.
Same key, first still running 409 Conflict. Wait and retry.
Same key, first finished The stored status and body, errors included.
Same key, different body The first request's stored response; the new body is ignored.

Request examples

bash
curl -X POST https://api.spicepay.net/payments \
  -H 'api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: order_2042' \
  -d '{
    "amount": 2500,
    "currency": "USD",
    "payment_link": true,
    "return_url": "https://shop.example/return"
  }'