Transaction Events
TRANSACTION_PROCESSED
The card-transaction lifecycle event. The status field carries the phase — AUTHORIZED, CLEARED, REVERSED, REFUNDED, or ADJUSTED.
WEBHOOK
Fires as a cardholder’s transaction moves through its lifecycle.
A
Payload — settlement (
Payload — reversal (
A reversal carries
TRANSACTION_PROCESSED
is the single, canonical event type for card transactions — you may receive it more
than once for the same purchase as it progresses.
Every payload has two fields you branch on:
type— what kind of transaction it is:PURCHASE,REVERSAL,REFUND, orADJUSTMENT.status— which lifecycle phase / outcome it represents.
type | status | Meaning |
|---|---|---|
PURCHASE | AUTHORIZED | The charge was authorized — a hold. Funds are reserved but not yet final. |
PURCHASE | CLEARED | The charge settled. This is the final, captured amount — mark the transaction successful here. |
REVERSAL | REVERSED | An authorization was voided before it cleared — the hold is released. |
REFUND | REFUNDED | A merchant refund after the charge cleared — funds returned to the card. |
ADJUSTMENT | ADJUSTED | An FX settlement adjustment was applied to a prior charge. |
PURCHASE therefore progresses AUTHORIZED → CLEARED; the other types are terminal.
The authorization → clearing flow
A typical purchase produces twoTRANSACTION_PROCESSED events:
status: AUTHORIZEDwhen the cardholder pays (a hold is placed).status: CLEAREDwhen the merchant settles — often a few days later, and sometimes for a slightly different amount (currency conversion, tips). TheCLEAREDamount is the real, final figure.
authorizationCode, so you can correlate the phases and
act on the CLEARED one.
Some merchants settle almost immediately (you’ll see
CLEARED right away); others
authorize and settle days apart. Always key your “transaction complete” logic off
status: CLEARED, never AUTHORIZED.Correlation fields
| Field | Present on | Description |
|---|---|---|
authorizationCode | AUTHORIZED, CLEARED, REVERSED | Stable across a purchase’s lifecycle — group events by this to reconstruct one purchase. |
relatedTransactionId | CLEARED, REVERSED, REFUNDED | The transaction this one relates to — the authorization for a clearing, or the charge for a reversal. |
chargeId | REVERSED | The specific charge that a reversal undoes. |
Payload — settlement (status: CLEARED)
Payload — reversal (status: REVERSED)
A reversal carries chargeId (the charge it undoes) and relatedTransactionId; a
REFUNDED payload has the same shape with status: REFUNDED and type: REFUND.
Payload Fields
| Field | Type | Description |
|---|---|---|
transactionId | string | Provider transaction identifier for this phase |
cardId | string | The card used for the transaction |
cardholderId | string | The cardholder (best-effort — may be absent if not resolvable) |
externalId | string or null | Your internal user ID from the cardholder profile |
type | string | PURCHASE, REVERSAL, REFUND, or ADJUSTMENT |
status | string | AUTHORIZED, CLEARED, REVERSED, REFUNDED, or ADJUSTED |
amount | number | Transaction amount in dollars. On CLEARED, this is the final settled amount. |
currency | string | Transaction currency (ISO 4217) |
billingAmount | number | Amount in the card’s billing currency, in dollars |
billingCurrency | string | Billing currency — may differ for cross-border transactions |
authorizationCode | string | Purchase-lifecycle correlation key (present on authorization, clearing, reversal) |
relatedTransactionId | string | Related transaction — the authorization for a clearing, the charge for a reversal |
chargeId | string | On a reversal, the charge being reversed |
merchant | object | Merchant details — may be absent for non-purchase transactions |
merchant.name | string | Merchant name |
merchant.id | string | Merchant identifier from the network |
merchant.country | string | Merchant country (ISO 3166-1 alpha-2) |
merchant.mcc | string | ISO 18245 Merchant Category Code |
Common Use Cases
- Mark a transaction successful on
status: CLEARED, using itsamountas the final charge. - Correlate an authorization with its settlement via
authorizationCode, so a hold and its later capture aren’t double-counted. - Handle
REVERSED(authorization voided) andREFUNDED(merchant refund) to restore balance in your ledger — aREVERSEDpayload’schargeIdtells you exactly which charge it undoes. - Send real-time notifications and implement MCC-based spending controls.
TRANSACTION_PROCESSED supersedes the deprecated granular events
(TRANSACTION_AUTHORIZED,
TRANSACTION_CLEARED,
TRANSACTION_REVERSED, and
TRANSACTION_REFUNDED). They remain fully supported for existing integrations — no
migration required — but new integrations should subscribe to TRANSACTION_PROCESSED
and branch on status.Authorizations
API key from the FYATU CaaS portal. Pass as Authorization: Bearer <key>.
Body
application/json
Response
200
Acknowledge the event.

