Process a test payment

Creates a new payment. Requires an idempotency key to prevent duplicate payments on retry.

Idempotency Key Best Practices

1. Generate unique keys: Use UUIDs or similar unique identifiers, prefixed with a descriptive operation name
2. Store keys client-side: Save the key with the original request so you can retry with the same key
3. Key format: Between 6-64 alphanumeric characters
4. Expiration: Keys expire after 24 hours by default
5. Use case: Perfect for ensuring payment operations are never processed twice, even during network failures

Example Request (curl)

curl -X POST \
  https://api.example.com/rest-api/v0/test-payment \
  -H 'Content-Type: application/json' \
  -H 'Client-Key: your-api-key' \
  -H 'Client-Secret: your-api-secret' \
  -H 'Idempotency-Key: payment_123456_unique_key' \
  -d '{
    "amount": 100.00,
    "currency": "USD",
    "description": "Test payment for order #12345",
    "customerId": "cus_12345"
  }'

Example Response (First Request)

{
  "id": "pay_abc123xyz456",
  "amount": 100.00,
  "currency": "USD",
  "status": "succeeded",
  "timestamp": "2023-07-01T12:00:00.000Z"
}

Example Response (Duplicate Request)

The exact same response will be returned for any duplicate request with the same idempotency key, without creating a new payment.

Retry Scenario Example

Network failure during payment submission:

1. Client creates payment request with idempotency key: “payment_123456_unique_key”
2. Request begins processing, but network connection fails before response received
3. Client retries the exact same request with the same idempotency key
4. Server detects duplicate idempotency key and returns the result of the first request
5. No duplicate payment is created

If you retry with same key but different parameters (e.g., different amount), you’ll receive a 409 Conflict error.