> ## 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. # Escalations and Support Paths > Explains when and how to escalate an issue to DCS: the escalation channel and the reference fields to include, the categories of scenarios worth reporting, emergency response to unauthorized use, how disputes are handled, and a self-service troubleshooting index. ## 📄 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](../how-to-use/virtual-accounts/crypto-deposit). * **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](../how-to-use/virtual-accounts/withdraw-offramp). ### 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 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**: 1. **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](../how-to-use/managing-cards/overview). 2. **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. 3. **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): ```json theme={null} { "externalUserId": "usr_xxx", "block": true, "cardId": "card_xxxxxxxx" } ``` Successful response (masked placeholders): ```json theme={null} { "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](../how-to-use/managing-cards/overview) and [Transaction Issues and Disputes](./transaction-issues-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](./transaction-issues-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](../how-to-use/managing-transactions/authorizing-transactions), [Managing Transactions · Overview](../how-to-use/managing-transactions/overview) | | User balances (available / frozen) and the asset model | [User Balance](../how-to-use/managing-transactions/user-balance) | | Crypto deposits, deposit addresses, the chain and token matrix, crediting | [Crypto Deposits](../how-to-use/virtual-accounts/crypto-deposit) | | Meaning of reconciliation and report fields | [Reporting Field Descriptions](../how-to-use/managing-transactions/reporting-field-descriptions) | | KYC rejection reasons | [KYC Rejections and Resubmissions](./kyc-rejections) | | Card status, freezing, cancellation | [Managing Cards · Overview](../how-to-use/managing-cards/overview) | | Physical card shipping progress | [Physical Card Shipping](./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](./transaction-issues-disputes). * For consolidated answers to common operational questions after launch, see [Customer Success › Pre-Go-Live FAQ](./pre-go-live) and [Post-Go-Live FAQ](./post-go-live). * For the complete freeze, unfreeze, and cancellation operations on a card, see [Managing Cards · Overview](../how-to-use/managing-cards/overview).