## 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](/docs/payment-api/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. |

## Related guides

- [Invoices & credit notes](/docs/payment-api/invoices/)

## 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"
  }'
```