refund.created, refund.updated, refund.deleted, and refund.sundry. There is no refund.activity — refunds have no comments, attachments, or activity logs. A refund always belongs to exactly one payment, and a payment can have at most one refund. Because refunding and un-refunding a payment also mutates the payment record itself, each of those actions fires a companion payment.updated event alongside the refund event — subscribe to whichever fits your integration, or both if you need the full picture.
The webhook envelope structure, delivery behaviour, and retry logic are documented in Introduction. Signature verification is covered in Verification. Those conventions apply to every event on this page and are not repeated here.
Refund and payment events fire together
A refund can be created or removed from two places — the Refunds section, or the refund button on the Payments list. Both trigger the same events regardless of which UI path is used.
You do not need to subscribe to both event keys. Choose the event that describes the fact your integration cares about:
refund.created / refund.deleted gives you the refund record details; payment.updated gives you the payment’s updated status.
The refund object
Every event key exceptrefund.deleted carries the full refund object. In refund.created the object appears flat inside data; in refund.updated and refund.sundry it is nested under data.refund.
The
dates.created timestamp on refund objects is a raw database value in Y-m-d H:i:s format (for example "2026-07-31 09:00:00"), not the ISO 8601 with microseconds format you see on invoices, payments, and expenses.refund.created
Fires when a refund is created, whether from the Refunds section or the Payments list. data is the full refund object.
refund.updated
Fires when a significant change is made to a refund. Read data.change to determine what changed; data.refund contains the full refund object.
refund.sundry
Fires when a minor or cosmetic field is edited. Read data.field to determine which field changed; data.refund contains the full refund object.
refund.deleted
Fires after the refund is permanently deleted, whether from the Refunds section or the Payments list. Because the record no longer exists, data contains only the refund id.
When you delete refunds from the Refunds section using the checkbox selection, removing several refunds at once delivers one event per refund — not one event containing a list.