api_version 2026-05-18. It documents every field, its type and nullability, and which stage objects are populated for each event type. For endpoint setup, signature verification, and delivery guarantees, see Webhooks.
All timestamps in the payload are ISO 8601 UTC strings.
The event envelope
Every event has the same top-level shape.The payment snapshot (data)
data is always a full snapshot of the payment at the moment the event occurred, never a delta. Every event type carries the same field set; what varies is status and which stage objects are non-null.
Stage objects by event type
Which stage objects are non-null depends on the event type.
“May be present” means the payment can fail or expire either before or after processing started:
processing is null when the buyer never committed to a payment option, and populated otherwise. Cancellation is only possible while the payment awaits buyer action, so payment.cancelled always carries processing: null. On payment.succeeded, settled is null unless settlement had already completed at snapshot time; settlement completion is carried by payment.settled.
Objects
Amount
An asset amount. Used fordata.amount and inside the processing, fee, and settled objects.
fee
Fee applied to the payment, inside processing.processing
Present once the buyer has committed to a payment option.success
Present once the payment succeeded.failed
Present once the payment failed.cancelled
Present once the payment was cancelled.expired
Present once the payment expired.settled
Present once merchant settlement completed.Event types
One example per event type. The examples are the golden fixtures the payload contract is tested against.payment.created
A payment was created and awaits buyer action. Initial snapshot: no lifecycle stage has happened yet, so every stage object isnull and payment_state_version is 0.
payment.created
payment.processing
The buyer committed to a payment option and the payment started processing.processing is populated from this point on.
In this example the buyer pays 10 USDC on Base for a $10.00 payment, a 2.9% fee applies, and the merchant is expected to receive 9.71 USDC. processing.buyer_caip10 is null instead when the payment has no on-chain buyer, and live is false for test-mode payments.
payment.processing
payment.succeeded
The payment succeeded.success is populated, and processing carries the committed option. settled is usually null here; settlement completion is carried by payment.settled. It may be non-null when settlement had already completed at snapshot time.
payment.succeeded
payment.failed
The payment failed.failed is populated. processing is null when the payment failed before the buyer committed, as in this example, and populated when the payment had started processing before failing.
payment.failed
payment.expired
The payment expired before completing.expired is populated. A payment can expire after processing started, as in this example; processing is null when it expired while still awaiting buyer action.
payment.expired
payment.cancelled
The payment was cancelled.cancelled is populated. A payment can only be cancelled while it awaits buyer action, so processing is always null.
payment.cancelled
payment.settled
Merchant settlement completed for a succeeded payment.settled is populated, and status stays succeeded; settlement is a stage, not a status. settled.amount is what actually settled to the merchant.
payment.settled
Next steps
Webhooks
Endpoint setup, signature verification, and delivery guarantees.
Test mode
Drive a test payment through every transition and watch these events arrive.