📄 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 datacode ≠ 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
