Track refunds and prevent duplicate requests

Use `GET https://api.payerone.com/checkout/v1/refunds` from your server with your Merchant Token. This lists refunds for the authenticated merchant. Keep the PayerOne refund reference beside your local refund record.

Filter the history

Use `order_id` for the PayerOne order, or `transaction_id` for its PayerOne payment transaction UUID. You can also filter by `refund_id` or `status`, and paginate with `page` and `limit`. Supported status filters are `created`, `processing`, `pending`, `succeeded`, `failed` and `cancelled`.

GET /checkout/v1/refunds?order_id=PAYERONE_ORDER_ID&page=1&limit=20 HTTP/1.1
Host: api.payerone.com
Authorization: Bearer YOUR_MERCHANT_TOKEN
Accept: application/json

`data` contains refund records. `info.pagination` contains page information. When filtered by order or transaction, `info.order_refund_details` also contains the order refund history and `refund_summary`.

Read statuses correctly

| Status | What it means for your workflow |

| --- | --- |

| `created` | The request was recorded. |

| `processing` | Provider processing is in progress or not yet reconciled. |

| `pending` | The provider has not reported a final outcome. |

| `succeeded` | The refund is recorded as successful. |

| `failed` | Refund creation or processing failed; inspect the recorded reason before retrying. |

| `cancelled` | The refund is recorded as cancelled. |

The summary separates successful `refunded_amount`, active `pending_refund_amount` and remaining `refundable_amount`. Pending requests reserve refundable capacity. Do not add a new request to bypass an in-progress refund.

Refresh an existing refund

For an order with refund history, open its **Refunds** tab in the dashboard. Active refund rows can offer a refresh action to check the existing provider refund. Refreshing status is different from creating another refund. Provider events and refund webhooks can update the same recorded request.

Retry the intended request

If the create response was uncertain, query the refund and reuse the original idempotency key. An already successful, pending or processing request returns the existing request rather than creating a new refund. A failed or locally recorded request may be retried through the existing lifecycle; first confirm the provider result and that the intended amount is unchanged.

Use signed refund events to trigger reconciliation. Do not consider `payment.refund.created` or `payment.refund.pending` complete. For a mismatch between PayerOne and the provider, contact support with the refund ID, PayerOne order ID, provider refund reference if available, and approximate time. Never include provider credentials.