> ## 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.
# Pre-Go-Live FAQ
> Whether you are an exchange, a wallet or a platform, only a handful of things need to be in place before you go live: have DCS issue your access credentials and card configuration, agree with DCS on how KYC will be handled, send DCS your callback and whitelist details, and run the full "register → KYC → issue card → deposit → spend" loop in the sandbox. This page answers the questions we hear most often before launch, in Q&A and checklist form, covering the launch path and who owns each step, customer registration and KYC documents, the Sumsub + POA options, the H5 guidance page, the configuration you need up front, and a pre-go-live self-check list.
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:
| Capability | Description | Read more |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| **Per-customer balance model** | Every end customer has their own balance, expressed through three fields, `free` (available), `freeze` (held) and `total`; DCS checks the available balance internally before approving an authorization | [User balance](../how-to-use/managing-transactions/user-balance) |
| **Crypto deposits and withdrawals** | Crypto deposits across multiple chains and tokens (credited to the DCS ledger once confirmed on chain), plus withdrawals | [Crypto deposit](../how-to-use/virtual-accounts/crypto-deposit) |
| **QR Pay** | Cardholders can pay by scanning a QR code | [QR Pay](../how-to-use/managing-transactions/qr-pay) |
| **Apple Pay / Google Pay** | One-tap card provisioning from inside your app (push provisioning) | [Push provisioning](../how-to-use/managing-cards/push-provisioning) |
| **WebSocket real-time push** | Real-time messaging to end customers (a DeCard-Managed capability) | [Webhook + WebSocket](../integration-resources/webhook-websocket) |
***
## What do I need to prepare before going live?
Partners on DeCard-Managed follow the path below. Ownership of each step is as follows:
| Step | Owner | Description |
| ------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Issue access credentials and card configuration (Program / categoryId) | DCS | You tell us which card types you want to issue (virtual or physical), the card scheme, the card BIN and the issuing markets; DCS generates your access credentials and configures the matching card category (`categoryId`) |
| 2. Agree on the KYC approach (Sumsub Share Token / DCS-hosted H5) | Partner + DCS | Decide whether end customers go through Sumsub Share Token embedded in the card application, or through the DCS-hosted H5 KYC guidance page (see below) |
| 3. Submit your callback URL and network egress IPs | Partner | Give DCS your webhook callback URL, and the egress IPs to be whitelisted (see below) |
| 4. Integrate real-time notifications (webhook / WebSocket) | Partner | Subscribe to card status, transaction and KYC status events; WebSocket is used for real-time push to end customers (a DeCard-Managed capability) |
| 5. Issue your first card end to end in the sandbox | Partner | Complete the "register → KYC → issue card → deposit → spend" loop in the sandbox |
| 6. Cut over to production | Partner + DCS | Collect your production credentials and switch to the production base URL |
> For the end-to-end sequence and prerequisites of the integration path, see [First Steps](../getting-started/first-steps) and [Quickstart](../getting-started/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:
| Registration path | Required fields | Description |
| ----------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Mobile registration** | `mobileCode` (country calling code) + `mobile` (mobile number) + `smsCode` (SMS OTP) | All three must be supplied together. Note that DeCard-Managed uses `mobileCode` / `mobile`, which differ from the `phoneCountryCode` / `phone` fields used in the Partner-Managed model |
| **Email registration** | `email` + `emailCode` (email OTP) | Both must be supplied together |
**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](../integration-resources/overview).
>
> 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](../how-to-use/signing-up-a-customer/overview).
>
> 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](./kyc-documents). The five KYC states (`UNDO`/`INIT`/`PENDING`/`PASS`/`REFUSE`) are in [Compliance · Overview](../basic-concepts/compliance-kyc-flow).
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:
| Your KYC setup | Approach | Key points |
| --------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Already using Sumsub** | Sumsub Share Token | You complete verification in Sumsub, then pass the Sumsub Share Token (field `sumsubShareToken`) to DCS, and DCS retrieves the verification result. If the Sumsub applicant covers POI only, POA still has to be supplied |
| **No KYC capability of your own** | DCS-hosted H5 guidance page | Send the customer to the DCS-hosted KYC and card application pages through the H5 guidance link (`/redirect/v*/guidance-link`); DCS collects the documents and completes verification |
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](./kyc-vendor); H5 guidance page parameters are in [H5 KYC / card application guidance page](../integration-resources/h5-kyc-guidance).
***
## 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](../how-to-use/virtual-accounts/travel-rule).
***
## What configuration is needed up front?
| Item | Purpose | Provided by |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Access credentials (API key / auth headers) | Admission credential for API calls and identification of the caller | **DCS gives these to you** (contact the DCS team for sandbox) |
| API base URL | Target host for every API request | Sandbox: `https://api.thedecard-sandbox.com`; production: `https://api.thedecard.com`. See [First Steps](../getting-started/first-steps) |
| Webhook callback URL | Receives the events DCS pushes to you (card status, transactions, KYC status, deposit credited and so on) | **You give this to DCS** |
| Network egress IPs (whitelist) | Caller egress IPs to be added to the DCS whitelist | **You give these to DCS** |
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](../integration-resources/overview); whitelisting is covered in [IP whitelisting](../integration-resources/ip-whitelisting); webhook events and WebSocket real-time push (a DeCard-Managed capability) are in [Webhook + WebSocket real-time notifications](../integration-resources/webhook-websocket).
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](./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](../how-to-use/managing-transactions/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](./post-go-live) — day-to-day questions once you are live: card spending and refunds, adding cards to mobile wallets, transaction disputes and escalation paths.
## Next steps
* To prepare the launch path and its prerequisites, see [First Steps](../getting-started/first-steps) and [Quickstart](../getting-started/quickstart).
* For end-customer registration and KYC integration, see [Signing up a customer](../how-to-use/signing-up-a-customer/overview) and [Compliance · Overview](../basic-concepts/compliance-kyc-flow).
* For card issuing and management, see [Issuing cards](../how-to-use/managing-cards/issuing-cards).
* For questions that come up once you are live, bookmark the [Post-Go-Live FAQ](./post-go-live) in this section.