> ## Documentation Index > Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt > Use this file to discover all available pages before exploring further. # Crypto Deposits (Deposit Addresses / Chain and Token Matrix) > The endpoint reference for on-chain crypto deposits under the DeCard-Managed model: confirm the chain and token (network-coin) → obtain a deposit address (deposit-address) → the user transfers funds and the balance is credited. Covers the chain and token matrix, confirmation counts, and simulated deposits in the sandbox. ## 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: 1. Call `GET /crypto/v1/network-coin` to confirm which chains and tokens are currently supported and whether deposits are enabled. 2. Call `GET /crypto/v2/deposit-address` (recommended) to obtain the user's deposit address on the chosen chain and token. 3. 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](../../basic-concepts/compliance-kyc-flow) | | **Travel Rule completed** | Travel Rule compliance information must be submitted first | Call `POST /account/v1/update-travel-rule`; for the concept, see [Travel Rule](./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 Crypto deposit flow Crypto deposit flow *** ## Endpoints in detail ### Preliminary step: complete the Travel Rule > This step is already listed under [Prerequisites](#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): ```json theme={null} { "externalUserId": "", "channelName": "", "institutionName": "", "name": "", "id": { "type": "", "value": "", "countryOfIssue": "SG" }, "address": { "city": "", "country": "SG", "dependentLocality": "", "postalCode": "", "region": "", "addressLines": "" }, "dateOfBirth": "", "placeOfBirth": "" } ``` > `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](./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](../../integration-resources/overview)): ```bash theme={null} curl -X GET "https://api.thedecard-sandbox.com/crypto/v2/deposit-address?externalUserId=usr_xxx&network=TRON&coin=USDT" \ -H "X-DAPI-API-KEY: " \ -H "X-DAPI-TIMESTAMP: 1760943263227" \ -H "X-DAPI-NONCE: 12345" \ -H "X-DAPI-SIGN: " ``` **Response example** (v2, populated, address is a placeholder): ```json theme={null} { "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 1. **User transfer**: the user sends crypto of the matching chain and token to the deposit address, producing a transaction hash `txHash` on-chain. 2. **Platform monitoring**: DCS watches the blockchain network and waits for the transaction to reach that chain's `minConfirm` / `minConfirmationNo`. 3. **Crediting**: once the confirmation count is reached, the funds are credited to the user's account balance at DCS (the dedicated account `availableBalance`). 4. **WebSocket push**: DCS pushes transaction status changes in **real time over WebSocket** (see [Integration Resources · WebSocket real-time push](../../integration-resources/webhook-websocket)). 5. **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): ```json theme={null} { "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](../simulating-transactions/overview). *** ## 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](../../basic-concepts/compliance-kyc-flow) | | 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](./withdraw-offramp) * For real-time credit notifications, see [Integration Resources · WebSocket real-time push](../../integration-resources/webhook-websocket)