PCI DSS-allowlisted partners call retrieve-secure-card for ciphertext-level PAN / CVV2 / expiry and decrypt them in their own frontend under the AES-GCM contract; plus the cardholder data protection requirements and opening receiving accounts for dedicated-balance cards (open-va).
A card’s full number (PAN), CVV2 and expiry date are sensitive authentication data; the ordinary card queries return only panFirst6 / panLast4 (see the single-card query in Applying for a virtual card). To show the full card details to a cardholder, PCI DSS-certified partners call this page’s retrieve-secure-card for the ciphertexts and decrypt them for display themselves; partners without PCI DSS can integrate the DCS hosted secure card page instead. This page also covers open-va, the receiving-account endpoint for dedicated-balance cards.
Returns ciphertext-level PAN / CVV2 / expiry for secure display in your frontend.
Only PCI DSS-certified partners may call this endpoint (PCI_NOT_CERTIFIED otherwise); partners without PCI DSS can integrate the platform’s hosted secure card page.
Algorithm: AES/GCM/NoPadding with a 128-bit authentication tag.
Key: your SK.
IV: the three ciphertext fields encryptedPan / encryptedCvv2 / encryptedExpireDateshare the same iv (randomly generated per call, returned Base64-encoded).
CVV2 and expiry are fetched live and must never be cached — call this endpoint again for fresh ciphertexts every time they need to be displayed.
Under PCI DSS, the full PAN, CVV2 and expiry date are sensitive authentication data and must be handled end-to-end under the minimum-exposure principle:
Mask by default: the frontend shows only the masked PAN by default — first 6 and last 4 digits preserved (e.g. 531993 •••• •••• 8888); CVV2 and expiry are not shown by default.
Temporary display only when needed: decrypt and display the plaintext only when there is a genuine business need and the cardholder’s identity has been verified.
Plaintext never persisted: during display the plaintext must not be stored in any form — databases, files, logs, caches, analytics and tracing must all keep none of it; CVV2 must not be retained after authorization either.
Keys in a KMS: decryption keys must be held in a key management service (KMS) and rotated regularly.
Opening a receiving account for a dedicated-balance card
POST /open-api-corp/card/v1/open-va
Opens a top-up account (VA) per currency for a dedicated-balance card; you can then fund the card either by bank transfer or by allocation from the company pool (for funding and reconciliation see Funding and reconciliation).
≤50; the card ID; must belong to your partnership and be a dedicated-balance card
fundingCurrencies
Array<String>
Yes
The currencies to open VAs for (at least one; values USD / HKD; one VA per currency); no empty elements, no duplicate currencies — empty/duplicate/non-enum values → DAPI_PARAM_INVALID; the set must also be a subset of the company’s permitted currencies, and anything out of range rejects the whole request (no partial opening) → CURRENCY_NOT_ALLOWED
An action endpoint: data is null. To read the account numbers that were opened, call get deposit account information with subjectType=CARD — opening a VA and reading its account number are two separate endpoints, and this one only opens.
The card does not exist / does not belong to your partnership
CARD_NOT_DEDICATED
Not a dedicated-balance card; VAs cannot be opened
CURRENCY_NOT_ALLOWED
A requested currency is not in the company’s permitted list (the message names the currency)
SUBJECT_INVALID
The card’s ledger holder (account_holder) is missing, or the cardholder’s KYB/KYC name is missing (both holder-side problems that prevent opening a VA)