API Reference
Transaction event
Use this webhook to keep your product in sync with card activity in near real time.
What it represents
A single payment can evolve over time (authorization → cleared, or failed, plus possible reversals/refunds). Do not treat the first event you receive as final.
Refunds and reversals are emitted as their own transaction events.
Status and type
Use these fields to build your transaction timeline:
-
data.status:APPROVED: the transaction (or authorization) was approvedFAILED: the transaction (or authorization) failed (seedata.declineReasonwhen present)CLEARED: the transaction is finalized/settled
-
data.type:AUTHORIZATION: an authorization attemptREVERSAL: a reversal/void of a previous authorizationREFUND: funds returned to the cardholder
Correlation (transactionId)
For authorization and reversal events, data.transactionId can be the same, but it is not guaranteed. Use it as a best-effort correlation key and build your timeline using the event’s own stable identifiers.
Processing guidance
- Acknowledge fast and process asynchronously (enqueue a job / persist then return 200).
- Make processing idempotent (the same event can be delivered more than once).
- Treat lifecycle changes as updates to the user’s transaction timeline.
- Retries are not guaranteed. Use API backfill/polling for correctness when needed.
WEBHOOK

