Skip to main content
The DeCard-Managed model publishes no RSA public key and has no SessionId request header: it has no SessionId header, no published RSA asymmetric public key and no JWT-style session token. This page lists no public keys, because none are published. Sensitive data such as encrypted card details and PINs is not obtained by “the partner encrypting a session token with a public key and exchanging it for ciphertext”; it is confined to a DCS-hosted H5 page instead (see below).

​
1. How the DeCard-Managed model protects sensitive data

For sensitive operations such as viewing encrypted card details and handling PINs, the DeCard-Managed model applies the following security policy: Conclusion: the DeCard-Managed model confines sensitive data to DCS-hosted H5 pages, which architecturally removes any path where the partner handles encrypted card data. The partner does not have to hold a decryption key or mint a session token, yet can still show the card number, CVV and PIN safely to end users on clients with no PCI scope.

​
2. Encryption and signing capabilities available

The DeCard-Managed model offers the capabilities below. Each is documented in full on its own page; this page is the index that helps you find the right one quickly.

​
2.1 API request signing: HMAC-SHA256

Every call to a DCS API must carry an X-DAPI-SIGN signature in the request header. The signature is computed with HMAC-SHA256 over the concatenated string (apiKey + timestamp + nonce + payload), keyed with the SecretKey DCS issued to you.
See Authentication Guide · Request Signing for details.

​
2.2 Webhook signature verification: HMAC-SHA256 (X-Signature)

When DCS pushes a Webhook to you, it carries X-Signature in the HTTP headers. That signature is also HMAC-SHA256, keyed with your SecretKey and computed over the raw message body. Recompute the signature on receipt and compare it, and you have verified both the authenticity of the sender and the integrity of the message.
See Webhook + WebSocket Notifications · X-Signature verification for details.

​
2.3 Field-level AES encryption: mobile number

The mobile field of the customer registration API POST /account/v1/register supports AES-encrypted transmission (clear text is also accepted). The API definition annotates it as:
This lets a partner encrypt the mobile number with AES before transmission and so reduce the risk of exposure in transit. The official DCS example uses SecureUtil.aes(Base64.decode(SECRET)).encryptBase64(mobile): build the AES key from the Base64-decoded Secret Key and emit the ciphertext as Base64. The same rule applies to email addresses. The example passes no separate IV parameter, so stay consistent with the official implementation and do not substitute your own AES-GCM or AES-CBC message format. For the exact request and response format of /account/v1/register, see Signing Up a Customer.

​
2.4 One-time secret token for the hosted guidance page

DCS-hosted H5 pages (KYC, viewing card details, activating a physical card, setting a PIN and so on) are authenticated with a one-time secret token: you call the issuing API to obtain a guidance link that carries a one-time secret, the end user opens that link, and the DCS page validates it with GET /redirect/public/v1/secret-validate?secret=…. The secret is generated by DCS and is valid for a single use, expiring once consumed or timed out. This is a server-issued, single-use token model: DCS mints and delivers the token, and DCS validates and consumes it when the end user opens the link. The partner never has to generate or encrypt a session token on the client.
See H5 KYC / Card Application Guidance Page for details.

​
2.5 Apple Pay / Google Pay provisioning encryption

In the push provisioning flow, the DeCard-Managed model involves encrypted Apple Pay fields such as encryptedPassData (encrypted PAN, expiry, date and time, Base64), activationData (encrypted nonce + nonceSignature + authCode, Base64) and ephemeralPublicKey (ECC P-256 curve, uncompressed format, Base64). These fields are encrypted by the Apple and Google payment tokenization infrastructure, and the keys are managed by Apple, Google and the card networks. They are not part of any public key scheme published by DCS to partners.
See Push Provisioning (Apple / Google Pay) for details.

​
3. Capability checklist