Ordered, retry-safe billing webhooks
Billing event handling now records provider state before applying ordered changes, making duplicate delivery and retries safer.
Mohith / 4 min read- Status
- Preview
- Ordering
- Provider state before mutation
- Replay handling
- Idempotent event processing
What changed
The billing webhook route now records provider event identity and processing state before it mutates subscription data. Repeated completed events become no-ops, while failed events can be retried without pretending they succeeded.
Ordering checks prevent an older provider event from overwriting a newer accepted subscription state.
How ordering works
The handler compares the provider event position with the latest accepted subscription state before applying a change. An older event cannot overwrite a newer accepted state simply because network delivery arrived out of order.
How retries stay safe
Completed provider events are idempotent no-ops on repeat delivery. Failed events retain a retryable state instead of being marked complete, so a later attempt can continue without applying an already completed transition twice.
Availability
The handling foundation is implemented and tested as a Preview. Paid checkout, refund, cancellation, replay, and metering behavior still require an approved production billing account before the complete billing flow can be presented as available.