Quickstart

​

📄 Guide

The examples below leave out authentication headers and field encryption. Every request must carry the four authentication headers (X-DAPI-API-KEY / X-DAPI-TIMESTAMP / X-DAPI-NONCE / X-DAPI-SIGN) and set Content-Type: application/json, and sensitive fields such as phone number, email and KYC data must be AES encrypted. For the rules, see Authentication.

Why the step-by-step path (create customer, apply for KYC, apply for card):

• The KYC ticket is reusable: when the same customer applies for a second card there is no need to resubmit documents, simply reuse the same kycTicketId.
• Clearer states, easier troubleshooting: KYC and card issuing are decoupled, each with its own ticket and its own state line.

​

1. Create the customer

POST /open-api/customer/v1/create-customer

{ "phoneCountryCode": "SG", "phone": "+6591234567", "email": "user@example.com", "customerRef": "your-uniq-ref-001" }

{ "code": "SYS_SUCCESS", "message": "success", "messageDetail": null, "data": { "customerId": "C100001", "status": "SUCCEED" } }

​

2. Apply for a KYC ticket

Upload the identity documents first: call POST /open-api/intent-ticket/v1/generate-pre-upload-url (businessType=CREATE_CARD_KYC) to get a temporary upload URL, PUT the file, then take the returned objectKey and pass it as identityProofUrl below. For the full sequence, see Apply for KYC, “Option 2, step 1”.

POST /open-api/kyc-ticket/v1/apply-kyc

{
  "kycTicketRef": "your-kyc-ref-001",
  "customerId": "C100001",
  "identifyProofList": [ { "identityProofType": "PASSPORT", "identityProofUrl": "<objectKey returned by the pre-upload call>" } ],
  "addressProofList": [],
  "kycCareerInfo": { "employmentStatus": "EMPLOYED", "occupation": "..." }
}

{ "data": { "kycTicketId": "KYC_1a2b", "kycTicketRef": "your-kyc-ref-001", "status": "PENDING" } }

Wait for the ticket to reach PASSED: take the result from the KYC_TICKET webhook or from the query endpoint. If the status is NEED_VERIFY, guide the customer through liveness verification. For document fields, the state machine and rejection codes, see How-to · Apply for KYC; for eligible regions and the document requirements of each region, see Compliance and KYC.

​

3. Apply for the virtual card (NORMAL mode)

POST /open-api/card-order/v1/apply-virtual

{
  "profileId": "your-card-profile-id",
  "cardOrderRef": "your-order-ref-001",
  "cardApplyMode": "NORMAL",
  "customerId": "C100001",
  "kycTicketId": "KYC_1a2b"
}

The response returns cardOrderId. For any further card the same customer applies for, just reuse the same kycTicketId, there is no need to resubmit KYC.

​

4. Query the card order and wait for issuing to succeed

GET /open-api/card-order/v1/detail?cardOrderId=O100001

{ "data": { "cardOrderId": "O100001", "status": "COMPLETED", "cardId": "CARD100001" } }

Card order state line: PENDING → CUSTOMER_PASS → KYC_PASS → CHANNEL_CUSTOMER_PASS → COMPLETED. On FAILED, check errorCode / errorReason (see Card application error codes).

​

5. Query the card details, the card is ready to spend

GET /open-api/card/v1/detail?cardId=CARD100001

{ "data": { "cardId": "CARD100001", "status": "ACTIVATED", "panFirst6": "441364", "panLast4": "1234" } }

Virtual cards are activated automatically (physical cards must be activated). The full card number and CVV are only available through a dedicated endpoint, see Retrieving card sensitive data. Your first virtual card is now active. When the cardholder spends, DCS forwards the authorization request to your auth_url and you return Approve or Decline in real time. This is the heart of the Partner-Managed model, see Authorization (forwarded decisions).

​

Next steps

• The full card issuing flow and KYC details → Card issuing
• Freeze, unfreeze, replace a card, reset the PIN → Card management
• Understand how money moves → Fund model