> ## 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 > Answers the questions we are asked most often before go-live on the Partner-Managed model: how the launch track is divided between the two sides, the DCS configuration items (apiKey/secretKey/webhookUrl/authUrl/externalPublicKey), the three IP allowlists, RSA public key generation, how to integrate KYC, and the one-time secure retrieval of production keys. A pre-go-live checklist closes the page. ## 📄 Guide 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 set up your enterprise entity and card configuration, submit your callback and allowlist details to DCS, agree with DCS on how KYC will be integrated, and retrieve your production keys securely. This page answers the most common pre-go-live questions in Q\&A form. DCS is a licensed issuer with its own BINs, and provides the full compliance stack from onboarding and KYC through to real-time authorization and reconciliation. The pre-go-live setup is shared between DCS and your team, and every item below is labeled with who owns it. *** ## What needs to be in place before go-live? Partners on the Partner-Managed model complete the following track before go-live, with ownership as shown: | Step | Owner | Description | | ---------------------------------------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Set up the enterprise entity (Enterprise) and card configuration (Card Profile) | DCS | You tell us the card types you want to issue (virtual / physical), the card scheme and the card BIN; DCS creates your Enterprise together with its `apiKey` / `secretKey`, and creates the Card Profile (which yields `profileId`) | | 2. Submit callback URLs and the encryption public key | Partner | Provide DCS with `webhookUrl`, `authUrl` and `externalPublicKey` (see below) | | 3. Submit the three egress IPs for allowlisting | Partner | DCS maintains separate allowlists for API calls, webhooks and authorization forwarding notifications | | 4. Agree on the KYC integration approach and Sumsub setup | Partner + DCS | KYC is always submitted through the `apply-kyc` endpoint; if you run your own Sumsub integration, you must configure the DCS partner token in your Sumsub console (see below) | | 5. Issue the first card end to end in sandbox | Partner | Complete the card issuing, authorization and reconciliation loop in sandbox | | 6. Retrieve production keys securely and switch to production endpoints | Partner + DCS | Retrieve the production `apiKey` / `secretKey` through a one-time secure link | > For the full sequence diagram of the integration track (card issuing → card operations → physical card → card replacement → 3DS → authorization → reconciliation), see [Quickstart](../getting-started/quickstart) and [Preparation](../getting-started/first-steps). *** ## What will DCS configure for us? DCS configures the following for every Enterprise. The Enterprise is the core identity object of the Partner-Managed model: it represents the institution integrating card issuing, and it is the hub between DCS services and your end users. | Configuration item | Purpose | Provided by | | ---------------------- | -------------------------------------------------------------------------------------------------------------------- | ----------------------------- | | `apiKey` / `secretKey` | Identifies you and traces the origin of each request; the admission credential for all API calls | **DCS provides these to you** | | `webhookUrl` | Receives event notifications pushed by DCS (card order status changes, transaction authorization results, and so on) | **You provide this to DCS** | | `authUrl` | Receives authorization forwarding requests; the core interaction endpoint for controlling funds | **You provide this to DCS** | | `externalPublicKey` | The RSA public key used to encrypt sensitive data (amount, currency, and so on) in authorization notifications | **You provide this to DCS** | > In sandbox, contact the DCS team for your `apiKey` / `secretKey`. For production, follow the secure retrieval process described below. *** ## How many egress IPs do we need to submit? DCS maintains a separate allowlist for each of three entry points. When you submit your callback URLs, include the egress addresses for **both** sandbox and production: * **API allowlist**: the egress IP that calls the `/open-api/` endpoints * **Webhook allowlist**: the egress IP that receives DCS event notifications * **Authorization forwarding allowlist**: the egress IP that receives authorization forwarding requests > These three IPs may or may not be the same. Provide each one according to your actual network topology, so that nothing is rejected at go-live because it was never allowlisted. *** ## How do we generate the RSA public key (externalPublicKey)? `externalPublicKey` encrypts the sensitive data carried in authorization notifications. You generate the key pair locally, hand the **public key** to DCS and keep the **private key** safe on your side. Generate it as follows: ```shell theme={null} # Generate private key openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048 # Derive the public key from the private key openssl rsa -pubout -in private_key.pem -out public_key.pem # Strip the header and footer lines (-----BEGIN/END PUBLIC KEY-----) and remove line breaks to get a single-line string cat public_key.pem | sed '/BEGIN/d; /END/d' | tr -d '\n' ``` Submit that single-line string to DCS as your `externalPublicKey`. > Authorization notifications use RSA mutual signing plus encryption. For the full explanation of keys, signing and verification, see [Authentication and Signing](../integration-resources/authentication). *** ## How is KYC integrated? Whether or not you run your own Sumsub integration, DCS always collects KYC material through the `apply-kyc` endpoint, and review takes roughly 2–3 days. When the same user applies for multiple cards, the KYC material only has to be uploaded once and the `kycTicketId` can be reused. **If you run your own Sumsub integration**, you need to configure the DCS partner token for both your UAT and PROD environments in Sumsub. **Before go-live, make sure your Sumsub contract covers the sharing-partner relationship with DCS** — without it your launch will be held up. > For the details, see [About the KYC Vendor](./faq-kyc-vendor) and [About KYC Documents](./faq-kyc-documents); for the application flow, see [Apply for KYC](../how-to-use/kyc/apply-kyc). *** ## How do we retrieve production keys securely? > For sandbox `apiKey` / `secretKey`, simply contact the DCS team. To keep production keys from being exposed to third parties, the production `apiKey` / `secretKey` are retrieved through a **one-time secure link**: 1. **You provide**: a secure email address, plus the IP that will request the keys. The email address receives the retrieval instructions, and the IP is added to the retrieval allowlist. 2. **DCS sends**: an email arrives at that secure address containing a temporary secure link (**valid for a single retrieval only**). 3. **You retrieve**: concatenate `extractUrl` with `extractSecretKey` and run it on the designated machine to retrieve the keys. Fields returned in the email: | Name | Type | Description | | ------------------ | ------ | ----------------------------------------------- | | `expireTime` | string | Validity period of the extraction security code | | `extractSecretKey` | string | Key extraction security code | | `extractUrl` | string | Key extraction URL | | `howToUse` | string | How to use it | | `notes` | string | The keys can only be extracted once | Example of a successful response: ```json theme={null} { "code": "SYS_SUCCESS", "message": null, "messageDetail": null, "data": { "expireTime": "2024-10-21T16:52+08:00[Asia/Shanghai]", "extractSecretKey": "4f72b1e9c49e4ac1bbc2cd12b5e44993", "extractUrl": "https://{domain}/internal/open-api/v1/secret-extract/", "howToUse": "Please concatenate the url with the secret-key and execute it on the specified machine.", "notes": "This link is only valid for one AKSK extraction, if the content is not properly accessed, the AKSK may have been compromised, please contact us promptly." } } ``` If the retrieval fails, assume the keys may have been exposed within the validity window: talk to your business contact and have the email reissued. > Every response on this page uses the standard envelope `{code, message, messageDetail, data}`, where success is indicated by `code` = `SYS_SUCCESS`. See [Authentication and Signing](../integration-resources/authentication) for details. *** ## Pre-go-live checklist * [ ] Card types, card scheme and card BIN confirmed, and DCS has created the Enterprise (`apiKey`/`secretKey`) and Card Profile (`profileId`) * [ ] `webhookUrl`, `authUrl` and `externalPublicKey` submitted to DCS * [ ] Sandbox and production egress IPs submitted for all three entry points: API, webhook and authorization forwarding * [ ] KYC integration approach agreed with DCS (Sumsub or non-Sumsub), with the Sumsub contract and tokens in place * [ ] Card issuing → authorization → reconciliation loop completed end to end in sandbox * [ ] Production keys retrieved through the one-time secure link and endpoints switched to production *** ## Next steps Once you are live, keep the [Post-Go-Live FAQ](./post-go-live) at hand for day-to-day operational questions; when an issue needs to be escalated, see [Escalation and Support Path](./support-escalation).