Create a refund
Refunds a payment that has already succeeded. The amount is always
required. To refund the full payment, set amount to the payment’s
remaining refundable amount. The refund uses the same currency as the
original payment; currency is not accepted on the refund request.
A payment can be refunded multiple times as long as the accumulated refunded amount does not exceed the original.
The refund is accepted for processing and starts with status: "PENDING".
Monitor the refund’s progress via the returned Refund object, subsequent
GET /v1/payments/{id} calls, or webhooks. The status transitions to
SUCCEEDED when the refund is confirmed or FAILED when it cannot be
completed.
Every refund is recorded with a mandatory reason and is linked to the
original payment via payment_id.
Idempotency
Use the Idempotency-Key header to safely retry refund requests. The
idempotency contract is body-hash-based: a retry with the exact same body
returns the original response, while a retry with the same key but any
different field, including a different reason, amount, or merchant_reference, is rejected
with 409 and error.code: "idempotency_key_reused". Pick a
deterministic key tied to the refund operation and resend the same body
on retries.
Authorizations
Use your secret API key as the Bearer token. Test mode keys start with
api_test_sk_ and live mode keys start with api_live_sk_. Both modes
use the same API host; the mode is determined by the key.
Headers
A unique key to ensure the request is processed only once. If a request with the same idempotency key and the same body has already been processed successfully, the original response is returned. Non-2xx responses are not cached, so callers may retry after errors. Keys expire after 24 hours.
For one-shot requests, such as creating a payment from a checkout button, a random UUIDv4 is fine. For requests tied to a specific business operation, such as refunding an order, a deterministic key is preferred so retries collapse correctly across processes.
255Body
Unique opaque identifier for a payment (pay_ prefix + random alphanumeric suffix).
^pay_[A-Za-z0-9]{24}$"pay_q7Mk2Np8Vr4Xt6Yz9Ab3Cd5E"
Refund amount in minor units, in the same currency as the original payment. Use the remaining refundable amount for a full refund.
x >= 11500
Merchant-provided refund reason passed to the payment provider as the refund comment. Limited to 50 characters by WhiteLark.
1 - 50"Full refund verification"
Optional merchant-side reconciliation reference. The value must contain exactly 10 decimal digits and does not provide idempotency by itself.
1000000000 <= x <= 99999999991234567890
Response
Refund accepted and a Refund object was created. The refund may
still be PENDING or PROCESSING; use the returned status,
subsequent payment retrievals, or webhooks to track completion.
A refund against a payment.
Unique opaque identifier for a refund (ref_ prefix + random alphanumeric suffix).
^ref_[A-Za-z0-9]{24}$"ref_L9xQ4wE2rT8yU6iO3pA7sD1f"
Unique opaque identifier for a payment (pay_ prefix + random alphanumeric suffix).
^pay_[A-Za-z0-9]{24}$"pay_q7Mk2Np8Vr4Xt6Yz9Ab3Cd5E"
Refund amount in minor units.
x >= 11500
Three-letter ISO 4217 currency code. Currently supported for card
acquiring: EUR.
EUR "EUR"
Merchant-provided refund reason stored with the refund.
50"Full refund verification"
Whether the refund covers the full original payment amount or only part of it.
FULL, PARTIAL "FULL"
Current refund lifecycle status. Refunds normally move from PENDING
to PROCESSING, then to SUCCEEDED or FAILED.
PENDING, PROCESSING, SUCCEEDED, FAILED "PENDING"
Unix timestamp when the refund was created.
1719795600
Unix timestamp when the refund was last updated.
1719795660
Whether this refund was created using a live API key.
false
Merchant-side reconciliation reference for this refund, if provided.
1000000000 <= x <= 99999999991234567890
Refund failure details when the refund reaches FAILED.
Unix timestamp when the refund reached a terminal status.
1719799200