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. Three core steps:

Call GET /crypto/v1/network-coin to confirm which chains and tokens are currently supported and whether deposits are enabled.
Call GET /crypto/v2/deposit-address (recommended) to obtain the user’s deposit address on the chosen chain and token.
The user transfers to that address; the platform monitors the on-chain transaction, credits the funds once the confirmation count is reached, and pushes the status over 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
Travel Rule completed	Travel Rule compliance information must be submitted first	Call `POST /account/v1/update-travel-rule`; for the concept, see Travel Rule

Method note: use POST /account/v1/update-travel-rule to submit Travel Rule information and GET /account/v2/query-travel-rule to read it back.

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. The minimum confirmation count for each chain comes from the network-coin configuration (minConfirm) and varies by chain.

API flow

Endpoints in detail

Preliminary step: complete the Travel Rule

This step is already listed under Prerequisites; it is a compliance action that must be completed before the deposit flow begins. A full request example is given here for reference.

POST /account/v1/update-travel-rule

Request body (8 top-level fields plus 6 address sub-fields; only externalUserId is required, and all PII is a placeholder):

{
  "externalUserId": "<DECARD_USER_ID>",
  "channelName": "<CHANNEL_NAME>",
  "institutionName": "<INSTITUTION_NAME>",
  "name": "<FULL_NAME>",
  "id": {
    "type": "<ID_TYPE>",
    "value": "<ID_VALUE>",
    "countryOfIssue": "SG"
  },
  "address": {
    "city": "<CITY>",
    "country": "SG",
    "dependentLocality": "<DISTRICT>",
    "postalCode": "<POSTAL_CODE>",
    "region": "<REGION>",
    "addressLines": "<ADDRESS_LINES>"
  },
  "dateOfBirth": "<YYYY-MM-DD>",
  "placeOfBirth": "<PLACE_OF_BIRTH>"
}

dateOfBirth (date of birth, format YYYY-MM-DD), placeOfBirth (place of birth), and address.dependentLocality (county or district name) are optional compliance fields; only externalUserId is mandatory. Values for the other optional fields such as channelName and institutionName are supplied by the partner as needed. For the full field list and the query endpoint (GET /account/v2/query-travel-rule), see Travel Rule.

Step 1: confirm the supported chains and tokens

GET /crypto/v1/network-coin?type=DEPOSIT

Parameter	In	Type	Required	Description
`type`	query	string	✓	`DEPOSIT` (deposit) / `WITHDRAW` (withdrawal)

Returns an array of the user’s current wallet configuration. For deposits, use this response to decide dynamically which chains and tokens are available and how many confirmations are needed, rather than hard-coding a static list. Commonly used fields (data[]):

Field	Type	Description
`network`	string	Blockchain network identifier
`networkNativeAsset`	string	Native asset of the network
`asset`	string	Token code
`depositEnable`	boolean	Whether deposits are enabled
`withdrawEnable`	boolean	Whether withdrawals are enabled
`minConfirm`	integer	Minimum confirmations for a deposit
`lockConfirm`	integer	Lock confirmation count
`estimatedArrivalTime`	integer	Estimated time to credit
`addressRegex`	string	Regex for validating the address
`memoRegex`	string	Regex for validating the memo/tag
`contractAddress`	string	Contract address (token contract)
`depositDesc`	string	Deposit instruction copy
`specialTips`	string	Special notice copy
`withdrawIsTag`	boolean	Whether a tag is required for withdrawals
`withdrawFee` / `withdrawMin` / `withdrawMax`	number	Withdrawal fee / minimum / maximum (used in withdrawal scenarios)

Call network-coin first to confirm the configuration, then call deposit-address.

Step 2: 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; both are available from network-coin (see minConfirm).

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 that chain’s minConfirm / minConfirmationNo.
Crediting: once the confirmation count is reached, the funds are credited to the user’s account balance at DCS (the dedicated account availableBalance).
WebSocket push: DCS pushes transaction status changes in real time over 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/v1/network-coin?type=DEPOSIT returns at the time of the call; do not hard-code a static list, as the configuration changes with the business. The endpoint returns depositEnable, minConfirm, addressRegex, contractAddress, and more for each chain and token.

On specific values: in production, the available chains and tokens follow the dynamic configuration from GET /crypto/v1/network-coin, so do not hard-code a static list. If you need to confirm the exact values accepted by the sandbox simulation endpoint, contact the DCS team.

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/v1/deposit

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

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

When filling this in, set address to the deposit address obtained in step 3. If you need to confirm the accepted values for chain and currency, contact the DCS team. Simulated deposits work in the sandbox only, and exist to trigger crediting and the WebSocket push so you can verify your integration. For an overview of the simulation endpoints and other sandbox capabilities, see Simulating Transactions.

Error handling

Scenario	Description	Recommended handling
Travel Rule not completed	The address was requested before calling `update-travel-rule`	Complete `POST /account/v1/update-travel-rule` first
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	The `network`/`coin` pair is absent from the `network-coin` response, or `depositEnable=false`	Validate against `network-coin` before requesting an address
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
Address or memo format mismatch	The address or memo used for the transfer does not match `addressRegex`/`memoRegex`	Validate against the regex in your front end, and prompt the user to include 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 crypto withdrawals, see Crypto Withdrawal
For real-time credit notifications, see Integration Resources · WebSocket real-time push

​Overview

​Prerequisites

​Key concepts

​Chain model

​Deposit address

​Confirmation

​API flow

​Endpoints in detail

​Preliminary step: complete the Travel Rule

​Step 1: confirm the supported chains and tokens

​Step 2: 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

Preliminary step: complete the Travel Rule

Step 1: confirm the supported chains and tokens

Step 2: 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