Trigger and payload
CheckoutService dispatches order.created after the order transaction commits. The payload contains order_id, the local order ID. It does not include card details, a licence grant, service confirmation or a complete frozen order model.
{"order_id": 123}
The ID above is illustrative. Read the actual record referenced by the received event and retain its saved customer, seller, storefront, currency and pricing snapshot. Do not substitute whichever brand happens to be active in a worker request.
Appropriate use
An addon can record its own bookkeeping, schedule a permitted internal review or update an addon-owned operational view. Deduplicate by order ID plus your addon operation/version as appropriate. If your handler needs customer contact data, fetch only the permitted minimum from that same owner and avoid copying it into generic logs.
What it does not mean
An order is not paid merely because it exists. It may still need verification, an issued invoice, actual settlement and provider-confirmed activation. Do not create hosting, register a domain, issue a product licence or email a claim of completed delivery from this event alone. Use the established fulfilment workflow and its payment/provider guards.
Failure and testing
Test with an isolated committed order and an unsupported/unknown event. Repeat the same event and confirm your own operation is not duplicated. A rolled-back checkout must not leave your addon claiming a committed purchase. Inspect the module's event diagnostics for load versus handler failure; never clear payment or provider markers to recover an addon error.