Skip to main content

​
📄 Guide

In the DeCard-Managed model, the user (Account) is the identity baseline of the whole issuing stack: it carries the end user’s externalUserId, compliance status and transaction restrictions, and every capability — card issuance, deposits and withdrawals, spending — is anchored to it. As a licensed issuer with its own BINs, DCS manages user transaction restrictions centrally on the risk and compliance side and exposes them to you through a standard endpoint you can query at any time. This page is about the day-to-day management that follows user creation: reading a user’s current transaction restrictions (withdrawals blocked / card transactions blocked), and serving as the navigation hub for the rest of the user lifecycle. To register a user, go to Signing Up a Customer.

​
User lifecycle at a glance

Capabilities for an end user, from registration through ongoing management, live on different pages. This page focuses on user status and transaction restrictions; for everything else, go to the page listed below.

​
What we do

To keep financial operations on the platform compliant and secure, DCS applies transaction restrictions to users (for example, blocking withdrawals or card transactions) and provides a standard endpoint so you can read a user’s current restriction status at any time. The rules and trigger conditions behind these restrictions are managed by DCS risk and compliance; the partner reads the outcome through this endpoint and guides the user accordingly in its own system.

​
Query user status

Use the query endpoint to read a user’s current transaction restrictions: whether withdrawals are blocked, and whether card transactions are blocked.

​
Prerequisites

  • You hold your Enterprise ApiKey / SecretKey. If you have not received them yet, see First Steps.
  • You have the target user’s externalUserId (generated by DCS at registration).

​
Endpoint

GET /account/v1/user-status

​
Query parameters

​
Request example

For how to build the authentication headers, see First Steps.
The example uses the masked placeholder u_***** for externalUserId; replace it with a real user ID (never record real PII in documentation or logs).

​
Response example (200)

​
data fields (user status / transaction restrictions)

How to use this: when forbidWithdraw=true, block or hide the withdrawal entry point in your own system; when forbidCardTransaction=true, tell the user that card transactions are currently restricted. The two flags are independent of each other.

​
Common response envelope

Every /account/ endpoint returns the same envelope; the business payload of this endpoint sits in data.
When integrating, use code (SYS_SUCCESS) to decide whether the call itself succeeded, and the fields inside data to decide the user’s business status.

​
Error handling

Every /account/ endpoint uses the common response envelope. Use the code field to decide whether the call succeeded:
  • code = SYS_SUCCESS → the call succeeded and the business payload is in data
  • code ≠ SYS_SUCCESS → the call failed; read message and messageDetail (title / message / type, and so on) to understand why

​
Typical error scenarios

Note: the HTTP statuses above group typical scenarios only. The exact error code and the messageDetail content returned in production take precedence; do not hard-code checks against codes that are not listed here.

​
Assets and balances

This page covers user status and transaction restrictions only. A user’s funding account (available balance free / frozen balance freeze / total total, credits, debits, asset records) belongs to the balance domain and is not repeated here. Instead, go to:

​
Next steps