Deposit Events

Once the system detects a deposit, a job will call the customer's callback URL with the 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.

The system administrators manage the callback URLs. You must communicate with our system administrators to set your callback URL.

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.

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.

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

Deposit Event Object

{
    "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.

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.