Escalations and Support Paths - DCS Technical Documentation

📄 Overview

In the DeCard-Managed model, both KYC review and authorization decisions are made by DCS inside the system, and user assets are held in each user’s own account (available balance and frozen balance). Most operational questions can be answered from this documentation set on your own; when you hit a scenario that needs DCS to investigate, coordinate, or intervene manually, report it through the path on this page.

1. How to escalate an issue to DCS

Report through the Customer Success channel agreed with DCS during onboarding (a dedicated chat group, email, or a ticketing system, whichever was agreed). To help the DCS team locate and resolve the issue quickly, include as much of the following reference information as applies to the issue type. All of these are identifier fields from the DeCard-Managed API:

Reference information	Field in the interface definition	Description
User identifier	`externalUserId`	User ID (the DeCard-Managed model uses `externalUserId`; there is no `customerId`)
Card identifier	`cardId`	Card ID (string)
Last four digits of the card number	`cardMantissa`	Last 4 digits of the card number (this model uses `cardMantissa`; there is no `panLast4`)
Transaction identifier	`transId` / `orderId`	Identifier of a single transaction or order (for example a QR Pay order or entry). If you need to resolve a transaction ID into its posting status and related records, use `POST /card/v1/transaction/id/resolve`, whose input is `ids[]` (values are `outstandingTransactionId` / `postedTransactionId`); that is unrelated to the `transId` / `orderId` in this table
Statement identifier	`statementId`	Identifier of a statement or a statement line item
Symptoms and evidence	—	Reproduction steps, timestamps, error messages, and the relevant response bodies (masked)

Field note: the DeCard-Managed model does not have the fields transactionId / authId / outsId / customerId / panLast4; those belong to the Partner-Managed model. Use the fields in the table above when reporting, to avoid confusion.

PII red line: report only the identifier fields needed to locate the case. If you must attach an example, mask it (for example externalUserId = usr_xxx, card last four = 1234, email = u***@example.com). Never paste a user’s real phone number, identity document, full card number, address, or other personal data in plain text into a chat group or a ticket.

2. When to escalate an issue to DCS

Report to DCS when you hit one of the scenarios below and self-service troubleshooting with this documentation set does not resolve it. The list is organized around the independent-account custody model, and covers the asset, deposit and withdrawal, transfer, and mobile wallet issues specific to the DeCard-Managed model:

Assets, deposits, and withdrawals (specific to this model)

A crypto deposit has not been credited for a long time: the transfer is confirmed on chain but the user’s available balance has not increased, well beyond a reasonable window. Report with the externalUserId plus the chain, token, and on-chain transaction hash of the deposit. For the troubleshooting path, see Crypto Deposits.
A crypto withdrawal has not arrived for a long time: the on-chain withdrawal has been initiated but has not arrived, well beyond a reasonable window. For the troubleshooting path, see Crypto Withdrawals.

Cards and spending

A user reports an unauthorized transaction (suspected fraud): treat this as high priority. Freeze the card concerned first, then report to DCS for follow-up; see “Emergency response to unauthorized use” below.
QR Pay or mobile wallet (Apple Pay / Google Pay) provisioning or payment failures: the user cannot add the card to a mobile wallet, or QR payments keep failing. Report with the externalUserId and cardId plus a description of the failure.
You want a suspicious merchant blocked: provide the merchant identifier and the reason for blocking, and DCS will handle it at the risk-control or card network level (there is no self-service merchant-blocking endpoint for integrators in this model).

KYC and card review

A KYC application has been stuck in review for a long time: the documents are correct but the application stays in review well beyond a reasonable window. Report with the externalUserId and the KYC ticket identifier.
Transaction disputes or refund issues: see “How disputes are handled” below.

Escalation and support path for operational issues

3. Emergency response to unauthorized use (suspected unauthorized transactions)

When a user reports suspected fraud or an unauthorized transaction, containing the loss comes first:

Freeze the card concerned first: call POST /card/v2/block, identify the card by cardId, and set block = true in the body (this model uses the block field, not freeze, and has no /freeze endpoint). Once frozen, new authorizations on that card are declined. For the full description of freezing and unfreezing, see Managing Cards · Overview.
Identify the transaction concerned: get its identifier from the transaction or statement queries (for example transId / orderId, or a posted / outstanding transaction ID). If you need to resolve a transaction ID into its posting status and related records, use POST /card/v1/transaction/id/resolve, whose input is ids[] (values are outstandingTransactionId / postedTransactionId); it returns whether that ID has been posted and the related transaction ID.
Escalate to DCS along the path above: include the externalUserId and cardId, the identifier of the transaction concerned (transId / orderId, or the posted / outstanding transaction ID you resolved), and the reproduction details, and hand the case to DCS to follow up.

Freeze request body (masked placeholders):

{
  "externalUserId": "usr_xxx",
  "block": true,
  "cardId": "card_xxxxxxxx"
}

Successful response (masked placeholders):

{
  "code": "SYS_SUCCESS",
  "message": "",
  "messageDetail": null,
  "data": false
}

In the interface definition, the required fields of POST /card/v2/block are externalUserId, block, and cardId; unfreezing (block=false) additionally requires either smsCode or emailCode for verification (freezing to contain a loss needs no verification code). The response envelope is always { code, message, messageDetail, data } with the success code code = SYS_SUCCESS; messageDetail may be null or a structured object (containing message / title / type / icon / action / linkTitle / linkUrl). For the complete freeze and unfreeze fields and examples, see Managing Cards · Overview and Transaction Issues and Disputes.

4. How disputes are handled

Capability boundary (important): the DeCard-Managed model currently does not provide a dispute or chargeback API for integrators to raise a dispute or track its progress in the system.

Disputes, refunds, and unauthorized-use cases in this model are therefore handled as follows:

Today: DCS helps you submit and follow up through the Customer Success channel, and handles the case at the card network and risk-control level according to the established process.
A self-service dispute API in the system: on the roadmap.

For the full description and handling path, see Transaction Issues and Disputes in the FAQ group. This page does not describe any self-service dispute endpoint that does not exist in this model.

5. Reference codes and troubleshooting index (where to look)

Before escalating, use the table below to locate the answer yourself; most questions have a matching troubleshooting page in this documentation set:

What you want to look up	Where to look
Transaction and authorization fields and scenarios (`DEBIT` / `CREDIT`, refunds, settlement)	Real-Time Authorization, Managing Transactions · Overview
User balances (available / frozen) and the asset model	User Balance
Crypto deposits, deposit addresses, the chain and token matrix, crediting	Crypto Deposits
Meaning of reconciliation and report fields	Reporting Field Descriptions
KYC rejection reasons	KYC Rejections and Resubmissions
Card status, freezing, cancellation	Managing Cards · Overview
Physical card shipping progress	Physical Card Shipping
Decline code dictionary / error code dictionary	Responses from endpoints such as simulated authorization, card application, deposit, and withdrawal may carry `data.errorCode` / `data.errorMsg`, but there is no central dictionary page for this product explaining what each code means; for now, judge from the response `code` / `message` and escalate along the path above

On the error code dictionary: this product has no central dictionary page explaining each code. Judge from the code / message the API actually returns, and escalate along the path above when needed.

Next steps

For common questions and handling paths for transaction problems, refunds, and disputes, see Transaction Issues and Disputes.
For consolidated answers to common operational questions after launch, see Customer Success › Pre-Go-Live FAQ and Post-Go-Live FAQ.
For the complete freeze, unfreeze, and cancellation operations on a card, see Managing Cards · Overview.

​📄 Overview

​1. How to escalate an issue to DCS

​2. When to escalate an issue to DCS

​Assets, deposits, and withdrawals (specific to this model)

​Cards and spending

​KYC and card review

​3. Emergency response to unauthorized use (suspected unauthorized transactions)

​4. How disputes are handled

​5. Reference codes and troubleshooting index (where to look)

​Next steps

📄 Overview

1. How to escalate an issue to DCS

2. When to escalate an issue to DCS

Assets, deposits, and withdrawals (specific to this model)

Cards and spending

KYC and card review

3. Emergency response to unauthorized use (suspected unauthorized transactions)

4. How disputes are handled

5. Reference codes and troubleshooting index (where to look)

Next steps