Refund events

Fires as a refund is created and sent to the provider, then as the provider settles it. There is no approval step, so the same events as Stripe's cover the whole lifecycle.

{
  "id": "rfnd_01J9ABCDEFGHJKMNPQRSTV",
  "object": "refund",
  "charge_id": "ch_01J9ABCDEFGHJKMNPQRSTV",
  "amount": 50000,
  "currency": "THB",
  "status": "pending",
  "reason": "requested_by_customer",
  "balance_transaction": "txn_01J9ABCDEFGHJKMNPQRSTV",
  "destination": "source",
  "provider": "omise",
  "metadata": { "order_id": "SO-2026-0042" }
}

All three events share this shape:

• refund.created — the refund was created and is being sent to the provider, status: "pending" or, when the provider answered at once, a later status.
• refund.updated — any later change of status or metadata: the provider confirmed it ("succeeded"), it needs something more ("requires_action"), you canceled it ("canceled"), or it failed.
• refund.failed — the provider refused the refund. status is "failed", failure_reason says why, and failure_balance_transaction is the entry that gave the money back to your balance. A refund.updated is sent alongside it.

When a refund succeeds, the charge also sends charge.refunded.