Understand payment and refund webhook events

Use the root-level `id`, `type`, `created_at` and `data` fields in each webhook. Some deliveries also include a deprecated `event` object; new integrations should use the root-level fields.

{
  "id": "evt_EXAMPLE",
  "type": "payment.paid",
  "created_at": "2026-01-01T12:00:00+00:00",
  "data": {
    "order_id": "PAYERONE_ORDER_ID",
    "status": "Paid",
    "amount": 25.00
  }
}

Payments and orders

| Event | Meaning |

| --- | --- |

| `payment.paid` | The order was fully paid. |

| `payment.partially_paid` | The order received less than the expected amount. |

| `payment.failed` | A payment failed verification or was rejected. |

| `express_wallet.paid` | An Express Wallet payment was received. |

| `order.expired` | The order payment window expired. |

| `webhook.test` | A delivery test, not a customer payment. |

Refunds

| Event | Meaning |

| --- | --- |

| `payment.refund.created` | A refund request was recorded. |

| `payment.refund.pending` | A provider accepted a refund that is not final. |

| `payment.partially_refunded` | Successful refunds are less than the captured amount. |

| `payment.refunded` | Successful refunds equal the captured amount. |

| `payment.refund.failed` | Refund creation or provider processing failed. |

`data` fields vary by event. Use the relevant order and refund references to fetch current authenticated state when needed. A request-created or pending event is not evidence that the refund finished. An expired order can still have a received amount; expiry does not automatically refund it.

Repeated and delayed notifications

Store event IDs to handle repeated delivery. Also make the business action idempotent using the relevant order, transaction or refund reference, so receiving another event for the same payment cannot duplicate fulfillment or wallet credit. Reconcile current state when events arrive after your application already processed a later update.

Verify the signature before trusting the event. Safely store or queue it before returning HTTP 2xx. A non-2xx response or timeout may be retried; do not rely on a fixed retry count or interval.