> ## 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. # SessionId Public Key / Encryption > This is the key and encryption summary page of Integration Resources. It builds on the signing scheme in the Authentication Guide and the event signature verification in Webhook + WebSocket Notifications, and states factually which encryption and signing capabilities the DeCard-Managed model actually provides. **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: | Aspect | DeCard-Managed | | :--------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Key scheme** | Symmetric: HMAC-SHA256 (API Key + Secret Key) | | **Session token** | No `SessionId`. The hosted guidance page uses a one-time secret token generated by DCS (see below) | | **Display of sensitive card data** | **Clear text never passes through the partner's backend**. Card number, CVV and expiry date are rendered to the end user directly by a DCS-hosted H5 page (see [Viewing Encrypted Card Details](../how-to-use/managing-cards/viewing-encrypted-card-details)) | | **PIN set / reset** | Completed on a DCS-hosted H5 page (see [Managing a Card's PIN](../how-to-use/managing-cards/managing-a-cards-pin)) | | **Published public key** | **None published**. There is no public key infrastructure in this model | **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](./overview#2-request-signing-hmac-sha256) 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](./webhook-websocket#1-4-security-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: ```json theme={null} { "mobile": "" // Mobile number (AES-encrypted or clear text), example: 18232339999 (no country code) } ``` 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](../how-to-use/signing-up-a-customer/overview). #### 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](./h5-kyc-guidance) 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)](../how-to-use/managing-cards/push-provisioning) for details. ### 3. Capability checklist | Requirement | Available? | Mechanism / where to look | | :---------------------------------------------------------------------------------------------- | :----------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | | Verify the origin of an API request | ✅ Yes | HMAC-SHA256 request signature ([Authentication Guide](./overview)) | | Verify the authenticity of a Webhook push | ✅ Yes | `X-Signature` HMAC-SHA256 verification ([Webhook + WebSocket](./webhook-websocket)) | | Transmit a customer mobile number encrypted | ✅ Yes | AES encryption of the `mobile` field, following the official `SecureUtil.aes(Base64.decode(SECRET)).encryptBase64(...)` example (see §2.3) | | Show the full card number and CVV safely | ✅ Yes (DCS-hosted) | DCS-hosted guidance page ([Viewing Encrypted Card Details](../how-to-use/managing-cards/viewing-encrypted-card-details)) | | Set or reset a PIN | ✅ Yes (DCS-hosted) | DCS-hosted guidance page ([Managing a Card's PIN](../how-to-use/managing-cards/managing-a-cards-pin)) | | A server-published RSA/ECC public key for the partner to encrypt a session token | ❌ No | The DeCard-Managed model does not use this security model (see §1) | | Client generates a `SessionId`, sends it in a header, server encrypts and decrypts the response | ❌ No | The DeCard-Managed model does not use this security model (see §1) | | A public key for validating session data | ❌ No | The DeCard-Managed architecture has no session-data public key (see §1) | *** ## Next steps / Related * API authentication and signing: [Authentication Guide](./overview) * Webhook signature verification: [Webhook + WebSocket Notifications](./webhook-websocket) * Showing card data safely: [Viewing Encrypted Card Details](../how-to-use/managing-cards/viewing-encrypted-card-details) * Setting and resetting a PIN safely: [Managing a Card's PIN](../how-to-use/managing-cards/managing-a-cards-pin) * DCS-hosted pages and the one-time secret: [H5 KYC / Card Application Guidance Page](./h5-kyc-guidance) * Apple Pay and Google Pay provisioning encryption fields: [Push Provisioning](../how-to-use/managing-cards/push-provisioning) * Customer registration (including the AES-encrypted `mobile` field): [Signing Up a Customer](../how-to-use/signing-up-a-customer/overview)