# Deposit Events
Once the system detects a deposit, a job will call the customer's callback URL with the [deposit event object](#deposit-event-object). The system retries this operation for one day with three minutes intervals **until the customer's end responds with a successful 2xx HTTP status code (200,201,202,203,204)**. Our team has meticulously designed and implemented a robust architecture to ensure that our esteemed clients are promptly notified about the status of their deposits.
{% hint style="info" %}
The system administrators manage the callback URLs. You must communicate with our system administrators to set your callback URL.
{% endhint %}
{% hint style="warning" %}
Every deposit event originates from our static IPs**.** The customers can assume that the callbacks originate from our system if they arrive at their end from our IP addresses.
{% endhint %}
{% hint style="success" %}
Our system signs the **deposit event object** with the customer's **HMAC secret** and sends the signature hash with the **x-payload-hash** header. So the customers can check the integrity of these requests by comparing the **x-payload-hash** with the one they calculated upon receiving the deposit information.
{% endhint %}
{% hint style="danger" %}
### Critical: Deposit Detection Without Active Session
It is technically possible and fully expected for a customer to receive deposit callbacks **even when no active user session exists.**
Once blockchain addresses are generated for a user across the following chains — **BTC, LTC, DOGE, XRP, and USDT (TRON)** — the system continuously monitors them at the blockchain level.
**This monitoring does not depend on an active user session and does not require the user to create one at the time of the deposit.**
#### Automatic Session Allocation on Deposit Detection
When a user sends funds to a blockchain address **without having an active session**, and the system detects this deposit:
* The system automatically allocates **a new session token.**
* The deposit callback is dispatched using this **newly created session token.**
This ensures that every deposit event is associated with a valid session context, even if the deposit occurs completely outside of any user-initiated session flow.
#### Mandatory Customer Responsibility
Customers MUST ensure that deposit detection and callback handling are always active, regardless of whether a user session exists.
Failure to do so may result in:
* Missed deposit events
* Uncredited user balances
* Inconsistent accounting or reconciliation issues
{% endhint %}
## Deposit Event Object
```json
{
"objectType": "depositEventObject",
"userId": "THE USER ID ASSOCIATED WITH THE DEPOSIT EVENT",
"userName": "THE USER NAME ASSOCIATED WITH THE DEPOSIT EVENT",
"date": EPOCH TIME OF THE TRANSACTION ,
"blockChainCurrency": "THE BLOCKCHAIN CURRENCY OF THE DEPOSIT",
"blockChainTxId": "THE BLOCKCHAIN TRANSACTION ID OF THE DEPOSIT",
"blockChainAmount": AMOUNT OF THE TRANSACTION,
"convertedAmount": [
{
"fiatCurrency": "EUR",
"convertedValue": CONVERTED AMOUNT
},
{
"fiatCurrency": "GBP",
"convertedValue": CONVERTED AMOUNT
},
{
"fiatCurrency": "USD",
"convertedValue": CONVERTED AMOUNT
},
//supported fiats
],
"conversionTime": EPOCH TIME OF THE CONVERSION ,
"paymentStatus": {
"minAmountToBePaidInUsd": MINIMUM TO BE PAID IN USD FOR THE SESSION,
"maxAmountToBePaidInUsd": MAXIMUM TO BE PAID IN USD FOR THE SESSION,
"actualPaymentInUsd": ACTUAL AMOUNT IN USD,
"paymentStatus": "PAYMENT STATUS"
},
"associatedSessionToken": "ASSOCIATED DEPOSIT TRACKING SESSION",
"from": "FROM ADDRESS OF THE DEPOSIT",
"to": "TO ADDRESS OF THE DEPOSIT"
}
```
### Object Description
| Field | Type/Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| objectType | STRING
Customers can use this field to create their object hierarchy. All objects sent by the system will have this field. This field can consist of a single value for deposit events.
|
| userId | STRING
The id of the user who makes the deposit.
|
| userName | STRING
The name of the user who makes the deposit.
|
| date | NUMBER
Epoch time of the deposit.
|
| blockChainCurrency | STRING
The blockchain currency of the deposit. It can be BTC, LTC, USDT\_TRON, DOGE, TRON, XRP, or ETH.
|
| blockChainTxId | STRING
The blockchain transaction hash of the deposit.
|
| blockChainAmount | NUMBER
The blockchain amount of the deposit.
|
| convertedAmount | ARRAY OF OBJECTS
The system promises a fixed rate if it detects a deposit within an existing deposit tracking session. In such a case, the system performs cryptocurrency to fiat conversion considering the session start time.
|
| conversionTime | NUMBER
The cryptocurrency to fiat conversion epoch time.
|
| paymentStatus | OBJECT
Customers can use this field to track deposit status. In some cases, users may overpay or underpay; when this happens, the payment status changes to overpaid or underpaid respectively. When the actual payment in dollars is between the minimum and maximum of the session, the payment status becomes correct. The possible values for the payment status field are Overpaid, Underpaid, or Correct.
|
| from | STRING
This parameter is the FROM address of the deposit.
|
| to | STRING
This parameter is the TO address of the deposit.
|
### A Message Regarding Duplicate Deposit Event Objects.
{% hint style="danger" %}
We use a distributed cloud-based queue to notify users of deposit events. To prevent duplicate messages, our system takes all necessary precautions. However, duplicate records can still occur in microservices, especially in a distributed message broker environment. **The responsibility for dealing with duplicate records lies with both parties. Both our system and the customers share this responsibility.** A combination of **userId** and **blockChainTxId** *uniquely* identifies each deposit event object. Customers can differentiate between duplicate messages by examining the values of these two fields. If multiple messages are received with the same values, it is safe to ignore the incoming duplicates.
{% endhint %}