Skip to main content
Transaction webhooks notify your systems as money moves across spend, collateral, and payment activity (transaction events) and transfers (transactionTransfer events). Use them to reconcile activity and trigger workflows in real time, without polling the API. The following events are available: The two resources report amounts differently, so do not assume one convention across both. Every spend amount is an integer in cents: 5000 means $50.00. Every transactionTransfer amount is a decimal string in the currency’s major unit: "1000.00" means $1,000.00. Collateral amounts follow the asset and can include decimals for native token amounts.
Spend transaction webhooks include an optional eventReceivedAt timestamp field. This field captures when Rain first received the event from the payment processor, which can help with debugging timing issues and building audit trails.By default, this field is excluded from webhook payloads. Contact your Rain account manager to enable it for your tenant.
A single authorization moves through several states rather than firing once, and each state change is its own transaction.* event. The transaction.created event also covers payment and collateral transactions, while transaction.completed also covers payments. The body distinguishes the type.
Webhook Rain sends youYour handler (ack 2xx)Action / API callCard networkConditional stepException (dispute)
AuthorizationAdjustments · 0..nClearing & settlement
🌧️Rain (issuer · processor)
🌐Card network
👤Cardholder
🖥️Partner backend (you)
1CardholderMake a purchase
2NetworkAuthorization request
3Webhook · pendingtransaction.requested
4RespondApprove or decline
5Webhook · authorizedtransaction.created
6Handleack 2xx
7NetworkReversal / adjustment
8Webhook · 0..ntransaction.updated
9Handleack 2xx
10NetworkClearing / presentment
11Webhook · settledtransaction.completed
12Handleack 2xx

transaction.requested

Rain sends this webhook when an authorization request comes in for a transaction, such as a new purchase or an incremental authorization on an existing transaction.

spend

Rain triggers the spend webhook when a cardholder spends their card. Partner-managed programs need to put a hold on the collateral balance and respond to this webhook to authorize the transaction. You do not need to persist this information.
Payload

Response

Limited availability:Only Partner-managed programs can authorize or reject transactions. Rain-managed programs do not support this feature at this time.
  • Respond with 200 OK (or any 2xx) to approve the transaction.
  • Respond with any non-2xx status code to reject it.
You can return a JSON body to confirm the decision and, when declining, include a rejection code:
The rejectionCode must be one of these exact values; anything else is recorded as UNKNOWN:

transaction.created

Rain sends this webhook whenever it creates a transaction.

collateral

Rain sends the collateral webhook when a user or company adds collateral to their contract. For standard collateral contracts, these transactions are final, and Rain does not send an additional completed webhook. For payment-type contracts (where Rain treats deposits as payments rather than collateral backing), Rain also sends a transaction.completed webhook with type: "payment" when the deposit posts. Contact your Rain account manager to determine your contract configuration.
Payload

spend

Rain sends the spend webhook when it creates a transaction, whether the network authorizes or declines it. You must persist this information.
Payload

payment

Rain sends the payment webhook when you initiate a payment on-chain. Rain sends a separate webhook when the payment completes.
Payload

transaction.updated

Rain sends this webhook whenever it updates a transaction. The transaction may not exist yet when this update arrives.

spend

Rain triggers this webhook for events such as incremental authorizations or refunds.
Payload
The status field can take these values:

transaction.completed

Rain sends this webhook once, when a transaction first closes. If further network messages arrive for a transaction that has already closed, Rain does not send a second transaction.completed, so you can reconcile on this event as the single settlement signal. The transaction may not exist yet when this update arrives.

spend

Rain sends the spend webhook when a transaction settles. No response is required.
Payload
The completionReason field can take these values:
The localAmount and localCurrency fields are populated when the transaction involves a foreign currency or when it is a standard settlement where the authorized amount equals the final settled amount. These fields may be undefined in certain scenarios, such as partial captures where the authorized and settled amounts differ.

payment

Rain sends the payment webhook when an initiated on-chain payment completes.
Payload

transactionTransfer.created

Rain sends this webhook whenever it creates a transfer transaction.

transfer

Rain sends the transfer webhook when you initiate a new transfer. Rain sends a separate webhook when the transfer completes.
Payload
All three transactionTransfer events carry the same transfer object. The status and which optional fields are present vary by lifecycle stage.

transactionTransfer.updated

Rain sends this webhook whenever a transfer’s status changes after creation, except when it reaches settled.

transfer

Rain sends the transfer webhook when a transfer’s status changes after creation, including non-success terminal states (failed, cancelled, expired, refunded).
Payload
The updated webhook fires for in-flight progress (processing) and non-success terminals (failed, cancelled, expired, refunded).

transactionTransfer.completed

Rain sends this webhook when a transfer settles successfully at its destination.

transfer

Rain sends the transfer webhook when a transfer settles at the destination.
Payload

Transfer object reference

The nested address fields and the status values used in the transfer object are detailed below.

Address types

The source.address and destination.address fields can each take one of the following shapes. An onchain address contains these fields: A payment account address contains these fields:

Deposit address types

The depositAddress field can take one of the following shapes. A fiat deposit address contains these fields: An onchain deposit address contains these fields:

Transfer status values

The status field reflects where the transfer is in its lifecycle:

Fund movements

The spend transaction.created, transaction.updated, and transaction.completed webhooks can include a fundMovements array that describes the on-chain movements backing the card transaction, such as the authorization pull that reserved funds on-chain, ordered oldest first. You receive this field only if your tenant is opted in to the webhook version that added it (transaction.created 1.3.0, transaction.updated 1.2.0, transaction.completed 1.4.0). Earlier versions never include it, and the array is empty when no on-chain movements back the transaction. Each entry in fundMovements has the following shape: The kind field can take these values:

What’s next

Sample webhooks

See worked examples of a spend moving through these events end to end.

Decline reasons

Look up what a declinedReason value means and what to do about it.