A charge settled for a member whose checkout had stalled.
When this fires
The payment ledger recorded a successful charge for the member, through any door and on any rail, while one of their checkouts stood stalled. Every open checkout of the member closes on that charge; the event fires for each one that had stalled, with the charge and the membership it became, and the passage that was running when they came back. The passage itself ends as sequence.converted through the same charge.
Caveats
- The charge need not be for the stalled plan: a member who stalled on the monthly plan and bought the annual one is recovered all the same.
- A member who holds a live membership before the window passes never stalls, so never recovers; their checkouts close without an event.
Related events
- checkout.stalled: the stall this recovers.
- payment.succeeded: the charge.
- sequence.converted: the passage ending as a win on the same charge.
Headers
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
Response
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
Changes
Webhooks have no change history: a webhook is keyed by its event name rather than a path and method, so no recorded change can name it.