Skip to main content

📄 Guide

Whether you are an exchange, a wallet or a platform, once DCS hands you a key pair you can call every /open-api/ endpoint with one uniform signing rule. This page gets your authentication working in a single pass. As a licensed issuer with its own BINs, DCS requires a verifiable origin and replay protection on every API call. Three topics are covered here: HMAC signing for API calls, secure retrieval of production credentials, and the RSA public key used for authorization notifications.

1. Credentials and Request Headers

What DCS gives you

For sandbox apiKey/secretKey, contact the DCS team. Production credentials must go through the secure retrieval process.

Headers required on every request

Every partner call to /open-api/ must carry the following HTTP headers. A JSON request body additionally requires Content-Type: application/json, which the public API reference omits but whose absence causes a 415 error:
secretKey is used only to compute the signature locally. Never transmit it in cleartext in a request header.

2. Request Signing (HMAC-SHA256)

Signing rule

Use the HmacSHA256 algorithm with secretKey as the key, and sign the concatenated string:
The output is a lowercase hexadecimal string. What each segment of the concatenated string is:
The signing algorithm is fixed to HmacSHA256. Always use it.

Replay protection (who does what: DCS verifies / partner generates)

  • TIMESTAMP: DCS accepts requests within a 5-second window by default; anything later is rejected outright. Keep your local clock synchronized to UTC.
  • NONCE: Generate a random number in [10000, 99999] for every request and never reuse one. Partners should still use idempotency keys for business write operations and avoid replaying an identical request inside the 5-second window.

Signing implementation examples

JavaScript (Postman pre-request script)
Java

Full request example (GET)

Here payload = cardOrderRef=14 (the GET query string). To validate your implementation, first reproduce the same X-DAPI-SIGN from a set of apiKey/timestamp/nonce/payload values supplied by DCS, then go live.

Uniform response envelope

Every /open-api/ endpoint returns the same envelope:
Judge success by code == "SYS_SUCCESS". On failure, code carries the specific error code (see the error code page).

3. Secure Retrieval of Production Credentials

To prevent production apiKey/secretKey values from leaking in transit, production credentials are never sent to you directly. They are collected through a one-time secure retrieval flow.
The sandbox does not use this flow; just contact the DCS team for sandbox credentials.

The flow (and who does what)

  1. Partner provides: one secure email address plus the IP that will perform the retrieval.
    • The email address receives the retrieval instructions; that IP is added to the credential-retrieval whitelist.
  2. DCS sends: an email arrives at the secure address containing a temporary secure link that is valid exactly once.
  3. Partner retrieves: concatenate extractUrl with extractSecretKey and run it from the machine at the designated IP to receive the apiKey/secretKey.

Fields in the email

Success response
Failure response
If the retrieval fails: the link may already have been consumed while still within its validity period, which means the credentials may be compromised. Contact your DCS business contact immediately and repeat the email flow to have them reissued.

4. RSA Public Key (authorization notifications only)

Authorization forwarding notifications (DCS to the partner auth_url) protect sensitive data such as transaction amount and currency with RSA-2048 mutual signing plus encryption. This is a mechanism entirely separate from the HMAC used for API calls. Authorization notifications add no AES/IV layer: the business fields are encrypted as a whole using segmented RSA, and the signature algorithm is SHA256withRSA.
  • HMAC: used when a partner calls /open-api/ endpoints (sections 1 and 2 of this page).
  • RSA: used when DCS pushes authorization notifications to a partner, protecting sensitive fields along the authorization path.
The partner generates its own RSA key pair, hands the public key (external_public_key) to DCS, and keeps the private key.

How to generate (who does it: partner)

The single-line string from step 3 is your external_public_key. Provide it to DCS together with auth_url.

DCS RSA public key (provided by DCS)

Partners use the DCS RSA public key to verify DCS notifications and to encrypt their responses.
  • Sandbox:
  • Production: contact the DCS team.

Java example for encryption, decryption and signing

The signature algorithm is SHA256withRSA with a 2048-bit key, and encryption and decryption run in blocks (245-byte encryption block / 256-byte decryption block):
For the full encryption, decryption and signature verification details of authorization notifications, see Authorization Forwarding and Encryption.

5. IP Whitelists (three types, all required)

DCS whitelists every direction of traffic. Partners must give DCS their static egress IPs separately for sandbox and production, covering these three directions:
Configure sandbox and production separately and never mix them. The credential-retrieval IP (section 3) and the API call IP may differ; tell DCS which purpose each one serves.

Next steps

With authentication working, head to Quickstart to issue your first card, or go back to First Steps to confirm that provisioning, callbacks and whitelists are in place. For the RSA encryption and decryption details of authorization notifications, see Authorization Forwarding and Encryption.