Skip to main content
DCS is a licensed issuer with its own BINs. Under DeCard-Managed, both KYC review and authorization decisions happen inside DCS, so you do not have to build your own authorization engine or manage collateral. This is what sets it apart from the Partner-Managed model, where the partner owns the authorization decision. The pre-launch configuration work is split between DCS and the partner, and every step below states who does it.

​
DeCard-Managed capabilities at a glance

The capabilities below are what DeCard-Managed adds on top of the Partner-Managed model. Each has a dedicated page in this documentation set; the table is a navigation aid rather than a full description:

​
What do I need to prepare before going live?

Partners on DeCard-Managed follow the path below. Ownership of each step is as follows:
For the end-to-end sequence and prerequisites of the integration path, see First Steps and Quickstart.

​
What information is needed to register an end customer?

Under DeCard-Managed, end customers are registered inside the system. There are two mutually exclusive registration paths, mobile and email. Pick one:
The two paths are mutually exclusive: smsCode and emailCode must never be sent in the same request; doing so is rejected outright with SMS_EMAIL_CODE_MUTUALLY_EXCLUSIVE. If neither path’s field set is satisfied, the API returns INVALID_PARAMETER.
The registration path (endpoints are always as defined in the API reference):
  1. Call POST /captcha/v1/send-mobile-code or POST /captcha/v1/send-email-code to send the one-time code, depending on the path you chose;
  2. Call POST /account/v1/register with the field set for that path to complete registration.
Every endpoint returns the same {code, message, messageDetail, data} envelope, with code=SYS_SUCCESS on success. See the authentication guide. Once registration succeeds, the system generates a customer identifier (externalUserId) that ties together all later KYC, card issuing, deposit and query calls. The register endpoint returns it directly in the data field of the response (data is a plain string), so store it as soon as registration succeeds. Full details of the registration endpoints and fields are in Signing Up a Customer. Examples always use masked placeholders: mobile number +65xxxxxxxx, email user@example.com. Never put real end-customer data in support tickets or logs.

​
What documents does end-customer KYC require?

DCS runs both the automated and the manual review inside the system. End customers need to provide:
  • Proof of identity (POI): which document types are accepted (passport, national ID, driving license and so on) varies by country or region; the DCS document whitelist is authoritative;
  • Proof of address (POA): required in some countries or regions, and whenever the Sumsub verification covers POI only;
  • Selfie / liveness: used to confirm that the document belongs to the person presenting it.
For the accepted POI/POA whitelist per country or region and whether POA is mandatory, see Compliance · KYC documents. The five KYC states (UNDO/INIT/PENDING/PASS/REFUSE) are in Compliance · Overview.
DeCard-Managed currently does not support corporate onboarding (KYB), ultimate beneficial owner (UBO) collection or company registration documents; the pre-launch document list covers individual KYC only.
KYC review turnaround times and standardized rejection reason codes still need to be confirmed per Program and against compliance policy. REFUSE is the terminal state of that application; if a new application is needed, the system allows at most 10 submissions in any 24-hour window (configurable).

​
Sumsub Share Token or DCS-hosted H5? How do I choose?

It comes down to whether you already run KYC yourself: If you go the Sumsub route, you need to configure the DCS partner token separately for sandbox and production on the Sumsub platform. Before going live, confirm with DCS which token sharing mode applies, and make sure the corresponding contract with Sumsub is signed. An unsigned contract will hold up your launch.
The two Sumsub token sharing options and the integration steps are covered in Sumsub KYC data sharing; H5 guidance page parameters are in H5 KYC / card application guidance page.

​
What has to happen before cross-border fund movements? (Travel Rule)

DeCard-Managed follows Travel Rule requirements: a customer must upload their Travel Rule information (identity, source of funds, source of wealth and so on) before you can obtain an on-chain deposit address for them.
  • Upload: POST /account/v1/update-travel-rule
  • Query: GET /account/v2/query-travel-rule
This is a DeCard-Managed compliance capability; see Compliance · Travel Rule.

​
What configuration is needed up front?

Provide the egress IPs for sandbox and production separately, matching your actual network topology, so that a missing whitelist entry does not block you at launch.
Auth headers and signing rules are in Integration Resources · Overview / authentication guide; whitelisting is covered in IP whitelisting; webhook events and WebSocket real-time push (a DeCard-Managed capability) are in Webhook + WebSocket real-time notifications.
Access credentials are sensitive. Never put them in support tickets, logs or the body of outbound email; confirm with your DCS business or technical contact how production credentials will be handed over.

​
Pre-go-live self-check list

  • Card types, card scheme, card BIN and issuing markets are confirmed, and DCS has configured your access credentials and card category (categoryId)
    (Evidence: an authenticated sandbox call such as /card/v2/detail succeeds and returns something other than 401/403)
  • The KYC approach (Sumsub Share Token or DCS-hosted H5) is agreed with DCS, and if you are using Sumsub, the contract and token setup are done
    (Evidence: one complete KYC run through the chosen approach in the sandbox, reaching a final state of PASS)
  • The individual KYC document list (POI / POA / selfie) is confirmed and checked against the document whitelist for each issuing market
    (Evidence: an item-by-item comparison against KYC documents, with every document required in each issuing market ready)
  • Your webhook callback URL and network egress IPs are submitted to DCS, for both sandbox and production
    (Evidence: the DCS team confirms the whitelist is active, or a test push triggered from the sandbox console proves your callback endpoint is reachable)
  • Real-time notifications are integrated (webhook event subscriptions, plus WebSocket if you need real-time push to end customers)
    (Evidence: a test webhook triggered from the DCS sandbox console arrives at your endpoint and passes signature verification)
  • The “register → KYC → issue card → deposit → spend” loop runs end to end in the sandbox
    (Evidence: at least one sandbox card created, one simulated deposit credited and visible as available balance via User balance, and one simulated purchase or authorization completed)
  • The handover process for production credentials is agreed with DCS and you have switched to the production base URL
    (Evidence: the production base URL (https://api.thedecard.com) and production credentials are confirmed ready)

​
In this section

  • Post-Go-Live FAQ — day-to-day questions once you are live: card spending and refunds, adding cards to mobile wallets, transaction disputes and escalation paths.

​
Next steps