Static Deposit Webhook
Overview
Static Deposit webhooks are sent when a deposit is detected on a static wallet and its status changes. Unlike PayIn webhooks (which are tied to invoice orders), Static Deposit webhooks track any incoming transfer to a permanent wallet address — no order creation is required.
Webhooks are delivered only if a callback_url was provided during static wallet creation. If no callback_url is configured, notifications are delivered via email to the project owner.
Static Deposit Status Flow
Every deposit on a static wallet follows a linear status progression:
in_mempool
Transaction detected in the mempool, waiting to be included in a block.
confirm_check
Transaction included in a block, accumulating confirmations.
paid
Deposit fully confirmed and finalized.
dropped
Transaction dropped from the mempool without being included in a block.
reorged
Transaction removed due to a blockchain reorganization.
Depending on the network and transaction type, some statuses may be skipped. For example, on networks without a public mempool, deposits go directly to confirm_check.
Webhook Delivery Rules
Webhooks are sent on every status transition.
Confirmation counter updates that cause a status change do trigger a webhook.
Confirmation counter updates that do not cause a status change do not trigger a webhook.
Each webhook includes the current deposit state and the event type.
Webhooks are retried with exponential backoff on
429and5xxresponses, up to 3 retries.
Webhook Events
Each webhook carries an event field that describes what triggered the notification:
static_deposit.mempool
in_mempool
Transaction seen in the mempool, not yet in a block.
static_deposit.found
confirm_check
Transaction found in a block for the first time.
static_deposit.confirming
confirm_check
Confirmation count increased, still below required threshold.
static_deposit.paid
paid
Deposit fully confirmed. Terminal status.
static_deposit.dropped
dropped
Transaction dropped from the mempool. Terminal status.
static_deposit.reorged
reorged
Transaction reverted by a chain reorganization. Terminal status.
Terminal statuses
These statuses are final and will not change:
paid— deposit confirmed and credited.dropped— transaction was seen in the mempool but never included in a block (e.g. replaced or evicted by gas price).reorged— deposit invalidated by a chain reorganization.
Transitional statuses
These statuses reflect the confirmation progress and will eventually resolve to a terminal status:
in_mempool— waiting for block inclusion.confirm_check— accumulating confirmations.
Webhook Payload Example
Payload Field Reference
event
string
Event type that triggered this webhook. See events table above.
uuid
string
Unique deposit identifier.
status
string
Current deposit status.
network
string
Blockchain network (e.g. BSC_MAINNET, ETH_MAINNET, TON_MAINNET).
chain_family
string
Chain family (e.g. EVM, TRON, SOLANA, TON, BTC_UTXO).
coin
string
Coin symbol (e.g. BNB, USDT, ETH, BTC).
contract
string
Token contract address. Empty string for native coin transfers.
decimals
number
Token decimal places.
to_address
string
Static wallet address (deposit recipient).
from_address
string
Sender address.
tx_hash
string
Transaction hash.
amount
string
Deposit amount in token units (human-readable).
amount_fiat
string
USD equivalent of the deposit amount. May be empty if conversion is unavailable.
block_number
number
Block number where the transaction was included. Present only after block inclusion.
confirmations
number
Current confirmation count.
required_confirmations
number
Number of confirmations required for finality on this network.
found_in_mempool
boolean
Whether the transaction was first detected in the mempool before block inclusion.
log_type
string
Transfer type: native for native coin transfers, token for token transfers.
created_at
string
ISO 8601 timestamp — when the deposit was first detected.
updated_at
string
ISO 8601 timestamp — last status update.
confirmed_at
string
ISO 8601 timestamp — when the deposit reached required confirmations. null until confirmed.
paid_at
string
ISO 8601 timestamp — when the deposit was finalized. null until paid.
Differences from PayIn Webhooks
Trigger
Order-based invoice payment
Any deposit to a static wallet
Order required
Yes — invoice must be created first
No — deposits are tracked automatically
Callback URL source
url_callback on the invoice
callback_url on the static wallet
Expected amount
Defined in the invoice
None — any amount is accepted
Settlement statuses
paid, paid_over, paid_less
paid only (no amount comparison)
Appeal flow
cancel/expired may be recovered via appeal
Not applicable
Email fallback
No
Yes — when no callback_url is set
Recommendation
Build your integration logic around the static_deposit.paid event — this represents a fully confirmed, irreversible deposit. Use static_deposit.mempool and static_deposit.confirming for real-time UI updates (e.g. showing pending deposits to users), but do not credit funds until paid is received.
Handle static_deposit.dropped by clearing any provisional UI indicators — the transaction never made it into a block.
Handle static_deposit.reorged by reversing any provisional credits applied during the confirmation phase.
Last updated