Order events

Order events are emitted independently of how the order is paid (payment rail, currency, or settlement method).

---

Supported order events

---

Event semantics

order:created

This event is emitted once per order.

Typical use cases:

• Persist the order in your internal system
• Initialize fulfillment workflows
• Display payment instructions to the customer

---

order:updated

This event may be emitted multiple times during the order lifecycle.

Examples of updates that can trigger this event:

• Status transitions (e.g. awaiting_payment → partially_paid)
• Expiration updates
• Metadata changes
• Capability changes (when allowed)

Note
Not every update implies a payment event. For payment-level changes, see Payment events.

---

order:paid

This event is emitted once when the order transitions to the paid status.

Typical use cases:

• Fulfill the order (ship goods, deliver digital content, unlock services)
• Mark the order as completed in your internal system
• Trigger downstream settlement or accounting logic

Important
An order may receive multiple payments before this event is emitted. order:paid is emitted only when the order is fully paid.

---

Relationship with order lifecycle

Order events are tightly coupled with the order lifecycle:

• order:created → initialized
• order:updated → any non-terminal update
• order:paid → transition to paid

For a detailed view of order status transitions, see Order lifecycle.

---

Payload overview

All order events include the order object as their main payload. The exact webhook payload format is documented in the Webhooks section.