> ## 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.

# Escalation and Support Path

> A single page on the operational escalation path: when to escalate, who to escalate to (your DCS Customer Success contact channel), what reference details to bring with you (transactionId/authId/outsId/panLast4/cardId/customerId/kycTicketId and so on), how disputes and fraud are handled today, and where to find the reference codes for self-diagnosis.

## 📄 Guide

Whether you are dealing with a transaction that has not landed, a KYC case stuck in review, or a cardholder reporting a suspicious charge, DCS gives you one clear escalation path to get the case to the right team quickly. This page explains **when to escalate, who to escalate to, and what to bring**, so the investigation can be done in a single round.

As a licensed issuer, DCS provides post-launch support to partners through a dedicated Customer Success team. Anything involving the issuing channel (the card scheme), clearing or disputes is taken up with the channel by DCS on your behalf, so you never need to contact the scheme yourself.

## How to escalate

Submit your case through the **Customer Success contact channel** agreed with DCS (your dedicated Customer Success contact, the shared mailbox, or the project chat group). To help the DCS team pinpoint the case faster, **bring as much of the following as you can**:

| Detail                           | Where the field comes from                                                                                                     | Provided by |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------- |
| Transaction ID                   | `transactionId` from the transaction report or webhook                                                                         | Partner     |
| Authorization ID                 | `authId` from the authorization report or authorization webhook                                                                | Partner     |
| Statement ID                     | `outsId`, which links authorization to clearing                                                                                | Partner     |
| Last 4 digits of the card number | `panLast4` from the card detail (a card detail endpoint field; see [Card Management](../how-to-use/cards/card-management))     | Partner     |
| Card ID                          | `cardId`                                                                                                                       | Partner     |
| User ID                          | `customerId` (where the case relates to a user)                                                                                | Partner     |
| Decline code                     | The decline code from the authorization webhook or the reports (see [Decline Codes](../how-to-use/transactions/decline-codes)) | Partner     |
| Error logs / payload screenshots | The raw request and response of the failing call                                                                               | Partner     |

<Tip>
  for transaction cases, `transactionId` plus the last 4 digits of the card number is usually enough to locate the record; for KYC cases, attach `customerId` and `kycTicketId`; for API errors, attach the full request and response payload, including `code` and `messageDetail` from the standard response envelope.
</Tip>

## When to escalate

Escalate to the DCS Customer Success team promptly in the following situations:

* **A refund has not arrived for a long time**: the merchant has refunded, but the cardholder's account still shows nothing after a long period (as a guide, more than 30 business days).
* **A KYC application is stuck**: the KYC ticket has been sitting under review well beyond the committed review window (about 2–3 business days). Before escalating, confirm that the documents submitted are legible and that the front, back and selfie are labeled correctly (see [About KYC Documents](./faq-kyc-documents)).
* **A cardholder reports a suspicious or unauthorised transaction**: the cardholder says a charge was not made by them, and suspects fraud or an incorrect debit.
* **You need a suspicious merchant blocked**: you have identified a risky merchant and want it blocked.
* **An API keeps returning errors and you cannot pinpoint the cause**: you have already checked your [authentication configuration](../integration-resources/authentication), the error code and the request payload without resolving it.

## Handling disputes and fraud

When a cardholder needs to raise a transaction dispute or chargeback over an **unauthorised transaction, an incorrect debit, or a merchant that failed to deliver**:

* **Today**: submit the case through the Customer Success contact channel above, and DCS will raise the dispute with the scheme and follow the outcome through on your behalf. Provide the `transactionId`, the last 4 digits of the card number, the dispute reason and whatever evidence you have (order screenshots, correspondence with the merchant, and so on).
* **Fraud containment**: where fraud is confirmed, freeze the affected card at the same time through the [freeze endpoint](../how-to-use/cards/card-management) (`POST /open-api/card/v1/freeze` with `freeze=true`), or cancel it outright, to prevent further loss.

<Note>
  disputes and fraud are currently submitted and followed up with the help of the DCS Customer Success contact channel. Self-service endpoints for raising a dispute, uploading evidence and checking dispute progress are on the roadmap (see [Disputes How-to](../how-to-use/disputes)); this page will be updated to describe the self-service flow once they are live.
</Note>

## Where to find the reference codes for troubleshooting

Before escalating, check the following data dictionaries: many cases can be diagnosed from them without help.

| Scenario                                          | Reference code / dictionary                                                                                                                |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| A card purchase was declined                      | Decline code → [Decline Codes](../how-to-use/transactions/decline-codes)                                                                   |
| Card issuing failed                               | Card order error code (`errorCode` on a `FAILED` status) → [card application error codes](../how-to-use/cards/card-order-codes)            |
| KYC failed                                        | KYC reject code → [KYC Reject Codes](../how-to-use/kyc/kyc-reject-codes)                                                                   |
| An API call returned an error                     | Standard API response error code (the `code` field) → [decline and error codes](../how-to-use/transactions/decline-codes)                  |
| Understanding authorization and transaction types | Authorization dictionary (`authType` / `transactionType`) → [Authorization and Settlement](../how-to-use/transactions/auth-and-settlement) |

## Next steps

Before escalating, it is worth going through the [Post-Go-Live FAQ](./post-go-live): many common issues (mobile wallet provisioning failures, delayed refunds, pending applications and so on) already come with self-service guidance.