Crypto Deposits (Deposit Addresses / Chain and Token Matrix)

Overview

On-chain deposits let your users send crypto over a blockchain network to a deposit address held in custody by DCS. Once credited, the funds appear in the user’s dedicated account balance at DCS (availableBalance) and can be spent with a linked card. The whole flow runs on the blockchain, so no partner float or intermediary funding is required. As a licensed issuer with its own BINs, DCS handles on-chain monitoring, confirmation, and crediting on your behalf, turning “crypto → available balance → card payment” into a single path. The flow is: the user sends crypto in → the platform monitors and confirms it → the funds are credited as available balance. Two core steps:

Call GET /crypto/v2/deposit-address (recommended) to obtain the user’s deposit address on the chosen chain and token; no address is returned when the chain or token is unsupported or deposits are disabled.
The user transfers to that address; the platform monitors the on-chain transaction, credits the funds once the confirmation count is reached, and pushes ORDER_STATUS over webhook and WebSocket.

Prerequisites

Before making an on-chain deposit, the user must complete the following compliance steps. Otherwise no deposit address can be issued and no funds can be credited:

Prerequisite	Description	Where to go
KYC passed	The user’s identity verification must be in a passed state	See Compliance · Overview

Key concepts

Chain model

The chain model means the user moves crypto directly over a blockchain network by transferring it to an on-chain address issued by the platform (an inbound deposit). The platform keeps the whole flow traceable through the blockchain transaction hash (txHash).

Deposit address

The receiving address the platform allocates to a user for a specific chain and token. Any transfer of the matching asset to that address counts as a deposit into the user’s DCS account.

Confirmation

An on-chain transaction must reach a certain number of block confirmations before it is treated as final. DCS configures the required count per chain, and it varies by chain; no endpoint returns it, so confirm with DCS if you need to show it to users.

API flow

Endpoints in detail

Step 1: obtain the deposit address

Query parameters:

Parameter	In	Type	Required	Description
`externalUserId`	query	string	✓	User ID
`network`	query	string	✓	Blockchain network name
`coin`	query	string	✓	Token code

GET /crypto/v2/deposit-address — data fields:

Field	Type	Description
`network`	string	Blockchain network identifier
`address`	string	Deposit address
`fxRate`	number	Exchange rate, used for currency conversion
`coin`	string	Token code
`status`	string (enum)	Address allocation status: `PENDING` / `SUCCESS` / `FAILED`

fxRate (conversion rate) lets you show a converted amount, and status tells you whether the address is ready. The minimum deposit and confirmation count are not returned here. When the chain or token does not exist, data is empty; when deposits are disabled for it, the error code NETWORK_COIN_CONFIG_NOT_SUPPORTED is returned.

Request example (placeholders/redacted; for authentication headers see Integration Resources · Authentication guide):

curl -X GET "https://api.thedecard-sandbox.com/crypto/v2/deposit-address?externalUserId=usr_xxx&network=TRON&coin=USDT" \
  -H "X-DAPI-API-KEY: <YOUR_API_KEY>" \
  -H "X-DAPI-TIMESTAMP: 1760943263227" \
  -H "X-DAPI-NONCE: 12345" \
  -H "X-DAPI-SIGN: <YOUR_SIGNATURE>"

Response example (v2, populated, address is a placeholder):

{
  "code": "SYS_SUCCESS",
  "message": "",
  "messageDetail": null,
  "data": {
    "network": "TRON",
    "address": "T...placeholder address, do not copy verbatim...",
    "fxRate": 1.0,
    "coin": "USDT",
    "status": "SUCCESS"
  }
}

The response envelope is the same across the documentation: { code, message, messageDetail, data } (no success boolean). messageDetail is normally null; when populated it is an object {message, title, type, icon, action, linkTitle, linkUrl}. The success value of code is SYS_SUCCESS (identical in both integration models).

What happens once the funds arrive

User transfer: the user sends crypto of the matching chain and token to the deposit address, producing a transaction hash txHash on-chain.
Platform monitoring: DCS watches the blockchain network and waits for the transaction to reach the confirmation count that chain requires.
Crediting: once the confirmation count is reached, the funds are credited to the user’s account balance at DCS (the dedicated account availableBalance).
Status push: DCS pushes ORDER_STATUS order status changes in real time over webhook and WebSocket (see Integration Resources · WebSocket real-time push).
Partner query: the partner can call GET /card/v1/fiat/transactions?externalUserId=... at any time to retrieve deposit and fiat transaction records and reconcile what was credited.

For a deposit record in fiat/transactions, the on-chain details sit in the transferDetails sub-object, which contains channelCode, txnAmt, txnCcy, sender, receiving, timeStamp, txHash, network, and asset.

Real-time push is the proactive “funds credited” notification; fiat/transactions is the on-demand reconciliation query. Use both: let WebSocket drive UI updates and use fiat/transactions for final reconciliation.

Time to credit: deposits in DPT mode are typically credited in about 2 minutes (after the on-chain confirmation count is reached). Actual timing varies with network congestion and the required confirmation count; treat the WebSocket push and the status in fiat/transactions as authoritative.

Supported chain and token matrix

The supported chains and tokens are whatever GET /crypto/v2/deposit-address can return an address for; the configuration changes with the business, so do not hard-code a static list.

On the sandbox: sandbox deposit simulation currently supports only two pairs: TRON + USDT and Ethereum + USDC.

Simulating a deposit in the sandbox

To test the on-chain deposit and crediting flow, use the simulation endpoint to create a credit directly:

POST /simulation/v2/deposit

Request body (placeholder template; do not copy a specific chain or token from it):

{
  "chain": "",
  "currency": "",
  "amount": 100.0,
  "address": ""
}

When filling this in, set address to the deposit address obtained in step 3. chain and currency currently support only two pairs: TRON + USDT and Ethereum + USDC. Simulated deposits work in the sandbox only, and exist to trigger crediting and the ORDER_STATUS push (webhook and WebSocket) so you can verify your integration; the endpoint returns the simulated txHash. For an overview of the simulation endpoints and other sandbox capabilities, see Simulating Transactions.

Error handling

Scenario	Description	Recommended handling
KYC not passed	The user’s identity verification has not reached a passed state	Guide the user through KYC; see Compliance · Overview
Chain or token unsupported or disabled	`deposit-address` returns empty `data`, or returns `NETWORK_COIN_CONFIG_NOT_SUPPORTED`	Ask the user to choose another chain or token
v2 address `status=PENDING`	The deposit address is still being allocated	Poll until `SUCCESS` before showing it to the user; on `FAILED`, retry or contact support
Wrong address or memo	The user transfers to a wrong address or omits a required memo/tag	Ask the user to double-check the deposit address, and prompt for a memo/tag on chains that require one

Request the full error code dictionary from the DCS team; for any specific failure, the code and message returned by the API are authoritative.

Next steps

For real-time credit notifications, see Integration Resources · WebSocket real-time push

Getting Started

Basic Concepts

How to Use

Integration Resources

Customer Success

Crypto Deposits (Deposit Addresses / Chain and Token Matrix)

Overview

Prerequisites

Key concepts

Chain model

Deposit address

Confirmation

API flow

Endpoints in detail

Step 1: obtain the deposit address

What happens once the funds arrive

Supported chain and token matrix

Simulating a deposit in the sandbox

Error handling

Next steps

​Overview

​Prerequisites

​Key concepts

​Chain model

​Deposit address

​Confirmation

​API flow

​Endpoints in detail

​Step 1: obtain the deposit address

​What happens once the funds arrive

​Supported chain and token matrix

​Simulating a deposit in the sandbox

​Error handling

​Next steps

Overview

Prerequisites

Key concepts

Chain model

Deposit address

Confirmation

API flow

Endpoints in detail

Step 1: obtain the deposit address

What happens once the funds arrive

Supported chain and token matrix

Simulating a deposit in the sandbox

Error handling

Next steps