Host-To-Host Integration Guide
Host to Host Integration Guide
If you are PCI DSS compliance, you can use this type of integration to receive card payments.
Payment types
There are 5 payment types available depends on your needs:
SALE
MOTO
AUTHORIZE CAPTURE
INSTALLMENT
RECURRING
(SALE) Integration steps
Here is the overview of how to integrate SALE payment:
Prepare credit card form input / Get token list
Get 3DS authentication ID and 3DS URL
Hit API Charge
Acknowledge payment result
1. Prepare credit card form input / Get token list
You can create credit card form input on your end, so that your customer can input their credit card number, expiry date, and CVV.
If you save the card token from DOKU side, you can use Tokenization to show the saved card of your customers.
2. Get 3DS authentication ID and 3DS URL
To get 3DS authentication, you will need to hit this API through your backend:
API Request
Type | Value |
---|---|
HTTP Method | POST |
API endpoint (Sandbox) |
|
API endpoint (Production) |
|
Here is the sample of request header to get 3DS authentication:
Request Header Explanation
Parameter | Description |
---|---|
Client-Id | Client ID retrieved from DOKU Back Office |
Request-Id | Unique random string (max 128 characters) generated from merchant side to protect duplicate request |
Request-Timestamp | Timestamp request on UTC time in ISO8601 UTC+0 format. It means to proceed transaction on UTC+7 (WIB), merchant need to subtract time with 7. Ex: to proceed transaction on September 22th 2020 at 08:51:00 WIB, the timestamp should be 2020-09-22T01:51:00Z |
Signature | Security parameter that needs to be generated on merchant Backend and placed to the header request to ensure that the request is coming from valid merchant. Please refer to this section to generate the signature |
Here is the sample request body to get 3DS authentication:
Request Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | In IDR Currency and without decimal
Allowed chars: |
| string | Optional | Invoice number of the transaction, if brought use consistent invoice number during charge as well Recommended to bring |
|
| Optional | Card token generated by DOKU, can be used if you already activate tokenization |
|
| Mandatory | Card number, can be optional if you sent |
|
| Mandatory | Card expiry date, can be optional if you sent |
|
| Mandatory | After 3DS process success, customer will be redirected to this page |
|
| Mandatory | After 3DS process success, customer will be redirected to this page |
API Response
After hitting the above API request, DOKU will give the response.
Type | Value |
---|---|
HTTP Status | 200 |
Result | SUCCESS |
Here is the sample response header:
Response Header Explanation
Client-Id | Same as the request |
Request-Id | Same as the request |
Response-Timestamp | Timestamp Response on UTC with format ISO8601 UTC+0 from DOKU |
Signature | Signature generated by DOKU based on the response body |
Here is the sample of response body:
Response Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Same as the request |
|
| Mandatory | Card 3D Secure enrollment status
Possible value: |
|
| Mandatory | 3DS process ID to use on API Charge |
|
| Optional | 3DS page if the |
3. Hit API Charge
After the customer is redirected to the 3DS success page, then your backend must trigger the API Charge to DOKU:
API Request
Type | Value |
---|---|
HTTP Method | POST |
API endpoint (Sandbox) |
|
API endpoint (Production) |
|
Here is the sample of request header to charge the transaction:
Request Header Explanation
Parameter | Description |
---|---|
Client-Id | Client ID retrieved from DOKU Back Office |
Request-Id | Unique random string (max 128 characters) generated from merchant side to protect duplicate request |
Request-Timestamp | Timestamp request on UTC time in ISO8601 UTC+0 format. It means to proceed transaction on UTC+7 (WIB), merchant need to subtract time with 7. Ex: to proceed transaction on September 22th 2020 at 08:51:00 WIB, the timestamp should be 2020-09-22T01:51:00Z |
Signature | Security parameter that needs to be generated on merchant Backend and placed to the header request to ensure that the request is coming from valid merchant. Please refer to this section to generate the signature |
Here is the sample request body to charge the transaction:
Request Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | In IDR Currency and without decimal
Allowed chars: |
|
| Mandatory | Generated by merchant to identify the order
Allowed chars: |
|
| Optional | Name of the product item
Allowed chars: |
|
| Optional | Price of the product item. Total price and quantity must match with the |
|
| Optional | Quantity of the product item
Allowed chars: |
|
| Conditional | Unique customer identifier generated by merchant. Mandatory if merchant wants to use tokenization feature.
Allowed chars: |
|
| Recommended | Customer name
Allowed chars: |
|
| Conditional | Customer email
Allowed chars: Max Length: |
|
| Conditional | Customer phone number. Format: |
|
| Optional | Customer address
Allowed chars: |
|
| Optional | 2 alphabetic country code ISO 3166-1
Allowed chars: |
|
| Mandatory | After 3DS process success, customer will be redirected to this page |
|
| Mandatory | Payment type
Possible value: |
|
| Optional | Tenor for issuer that have installment feature with DOKU - For MOTO and SALE only |
|
| Optional | Promotion ID from the bank for merchant |
|
| Conditional | Card token generated by DOKU, for 3ds transaction please bring |
|
| Conditional | Card number, can be optional if you sent |
|
| Conditional | Card expiry date, can be optional if you sent |
|
| Mandatory | Card CVV, Optional if |
|
| Optional | Set |
API Response
After hitting the above API request, DOKU will give the response.
Type | Value |
---|---|
HTTP Status | 200 |
Result | SUCCESS |
Here is the sample response header:
Response Header Explanation
Parameter | Description |
---|---|
Client-Id | Same as the request |
Request-Id | Same as the request |
Response-Timestamp | Timestamp Response on UTC with format ISO8601 UTC+0 from DOKU |
Signature | Signature generated by DOKU based on the response body |
Here is the sample of response body:
Response Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Same as the request |
|
| Mandatory | Same as the request |
|
| Optional | Same as the request |
|
| Mandatory | Same as the request |
|
| Mandatory | Additional payment info name |
|
| Mandatory | Additional payment info value |
|
| Mandatory | Request ID sent on merchant's request header |
|
| Optional | Authorize ID for authorize transaction. Mandatory if |
|
| Mandatory | Reponse code generated by DOKU / Acquirer |
|
| Mandatory | Response message generated by DOKU / Acquirer |
|
| Mandatory | Payment status
Possible value: |
|
| Mandatory | ECI for this transaction |
|
| Optional | Approval code for success transaction generated by acquirer |
|
| Mandatory | Same as the request |
|
| Optional | Card masked number |
|
| Mandatory | Card type
Possible value: |
|
| Mandatory | Card issuer |
|
| Mandatory | Principal brand
|
|
| Optional | Card token generated by DOKU if |
INFO
You can check the list of possible response code and how to handle them here
4. Acknowledge payment result
After the payment is being made by your customer, DOKU will send HTTP Notification to your defined Notification URL
. Learn how to handle the notification from DOKU:
(MOTO) Integration steps
Here is the overview of how to integrate MOTO payment:
Prepare credit card form input / Get token list
Hit API Charge
Acknowledge payment result
1. Prepare credit card form input / Get token list
You can create credit card form input on your end, so that your customer can input their credit card number, expiry date, and CVV.
If you save the card token from DOKU side, you can use Tokenization to show the saved card of your customers.
2. Hit API Charge
After the customer input the credit card, then your backend must trigger the API Charge to DOKU:
API Request
Type | Value |
---|---|
HTTP Method | POST |
API endpoint (Sandbox) |
|
API endpoint (Production) |
|
Here is the sample of request header to charge the transaction:
Request Header Explanation
Parameter | Description |
---|---|
Client-Id | Client ID retrieved from DOKU Back Office |
Request-Id | Unique random string (max 128 characters) generated from merchant side to protect duplicate request |
Request-Timestamp | Timestamp request on UTC time in ISO8601 UTC+0 format. It means to proceed transaction on UTC+7 (WIB), merchant need to subtract time with 7. Ex: to proceed transaction on September 22th 2020 at 08:51:00 WIB, the timestamp should be 2020-09-22T01:51:00Z |
Signature | Security parameter that needs to be generated on merchant Backend and placed to the header request to ensure that the request is coming from valid merchant. Please refer to this section to generate the signature |
Here is the sample request body to charge the transaction:
Request Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | In IDR Currency and without decimal
Allowed chars: |
|
| Mandatory | Generated by merchant to identify the order
Allowed chars: |
|
| Optional | Name of the product item
Allowed chars: |
|
| Optional | Price of the product item. Total price and quantity must match with the |
|
| Optional | Quantity of the product item
Allowed chars: |
|
| Conditional | Unique customer identifier generated by merchant. Mandatory if merchant wants to use tokenization feature.
Allowed chars: |
|
| Optional | Customer name
Allowed chars: |
|
| Optional | Customer email
Allowed chars: |
|
| Optional | Customer phone number. Format: |
|
| Optional | Customer address
Allowed chars: |
|
| Optional | 2 alphabetic country code ISO 3166-1
Allowed chars: |
|
| Mandatory | Payment type
Possible value: |
|
| Conditional | Token generated by DOKU
|
|
| Conditional | Card number (PAN)
|
|
| Conditional | Card expiry date, not needed if you sent |
|
| Optional | Set |
API Response
After hitting the above API request, DOKU will give the response.
Type | Value |
---|---|
HTTP Status | 200 |
Result | SUCCESS |
Here is the sample response header:
Response Header Explanation
Client-Id | Same as the request |
Request-Id | Same as the request |
Response-Timestamp | Timestamp Response on UTC with format ISO8601 UTC+0 from DOKU |
Signature | Signature generated by DOKU based on the response body |
Here is the sample of response body:
Response Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Same as the request |
|
| Mandatory | Same as the request |
|
| Optional | Same as the request |
|
| Mandatory | Same as the request |
|
| Mandatory | Additional payment info name |
|
| Mandatory | Additional payment info value |
|
| Mandatory | Request ID sent on merchant's request header |
|
| Optional | Authorize ID for authorize transaction. Mandatory if |
|
| Mandatory | Reponse code generated by DOKU / Acquirer |
|
| Mandatory | Response message generated by DOKU / Acquirer |
|
| Mandatory | Payment status
Possible value: |
|
| Mandatory | ECI for this transaction |
|
| Optional | Approval code for success transaction generated by acquirer |
|
| Optional | Card masked number |
|
| Mandatory | Card type
Possible value: |
|
| Mandatory | Card issuer |
|
| Mandatory | Principal brand
|
|
| Optional | Card token generated by DOKU if |
3. Acknowledge payment result
After the payment is being made by your customer, DOKU will send HTTP Notification to your defined Notification URL
. Learn how to handle the notification from DOKU:
(AUTHORIZE CAPTURE) Integration steps
Here is the overview of how to integrate AUTHORIZE CAPTURE payment:
Prepare credit card form input / Get token list
Get 3DS authentication ID and 3DS URL
Hit API Charge
Hit API Capture
Acknowledge payment result
1. Prepare credit card form input / Get token list
You can create credit card form input on your end, so that your customer can input their credit card number, expiry date, and CVV.
If you save the card token from DOKU side, you can use Tokenization to show the saved card of your customers.
2. Get 3DS authentication ID and 3DS URL
To get 3DS authentication, you will need to hit this API through your backend:
API Request
Type | Value |
---|---|
HTTP Method | POST |
API endpoint (Sandbox) |
|
API endpoint (Production) |
|
Here is the sample of request header to get 3DS authentication:
Request Header Explanation
Parameter | Description |
---|---|
Client-Id | Client ID retrieved from DOKU Back Office |
Request-Id | Unique random string (max 128 characters) generated from merchant side to protect duplicate request |
Request-Timestamp | Timestamp request on UTC time in ISO8601 UTC+0 format. It means to proceed transaction on UTC+7 (WIB), merchant need to subtract time with 7. Ex: to proceed transaction on September 22th 2020 at 08:51:00 WIB, the timestamp should be 2020-09-22T01:51:00Z |
Signature | Security parameter that needs to be generated on merchant Backend and placed to the header request to ensure that the request is coming from valid merchant. Please refer to this section to generate the signature |
Here is the sample request body to get 3DS authentication:
Request Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | In IDR Currency and without decimal
Allowed chars: |
|
| Optional | Card token generated by DOKU, can be used if you already activate tokenization |
|
| Mandatory | Card number, can be optional if you sent |
|
| Mandatory | Card expiry date, can be optional if you sent |
|
| Mandatory | After 3DS process success, customer will be redirected to this page |
|
| Mandatory | After 3DS process success, customer will be redirected to this page |
API Response
After hitting the above API request, DOKU will give the response.
Type | Value |
---|---|
HTTP Status | 200 |
Result | SUCCESS |
Here is the sample response header:
Response Header Explanation
Client-Id | Same as the request |
Request-Id | Same as the request |
Response-Timestamp | Timestamp Response on UTC with format ISO8601 UTC+0 from DOKU |
Signature | Signature generated by DOKU based on the response body |
Here is the sample of response body:
Response Body
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Same as the request |
|
| Mandatory | Card 3D Secure enrollment status
Possible value: |
|
| Mandatory | 3DS process ID to use on API Charge |
|
| Optional | 3DS page if the |
3. Hit API Charge
After the customer is redirected to the 3DS success page, then your backend must trigger the API Charge to DOKU:
API Request
Type | Value |
---|---|
HTTP Method | POST |
API endpoint (Sandbox) |
|
API endpoint (Production) |
|
Here is the sample of request header to charge the transaction:
Request Header Explanation
Parameter | Description |
---|---|
Client-Id | Client ID retrieved from DOKU Back Office |
Request-Id | Unique random string (max 128 characters) generated from merchant side to protect duplicate request |
Request-Timestamp | Timestamp request on UTC time in ISO8601 UTC+0 format. It means to proceed transaction on UTC+7 (WIB), merchant need to subtract time with 7. Ex: to proceed transaction on September 22th 2020 at 08:51:00 WIB, the timestamp should be 2020-09-22T01:51:00Z |
Signature | Security parameter that needs to be generated on merchant Backend and placed to the header request to ensure that the request is coming from valid merchant. Please refer to this section to generate the signature |
Here is the sample request body to charge the transaction:
Request Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | In IDR Currency and without decimal
Allowed chars: |
|
| Mandatory | Generated by merchant to identify the order
Allowed chars: |
|
| Optional | Name of the product item
Allowed chars: |
|
| Optional | Price of the product item. Total price and quantity must match with the |
|
| Optional | Quantity of the product item
Allowed chars: |
|
| Conditional | Unique customer identifier generated by merchant. Mandatory if merchant wants to use tokenization feature.
Allowed chars: |
|
| Optional | Customer name
Allowed chars: |
|
| Optional | Customer email
Allowed chars: |
|
| Optional | Customer phone number. Format: |
|
| Optional | Customer address
Allowed chars: |
|
| Optional | 2 alphabetic country code ISO 3166-1
Allowed chars: |
|
| Mandatory | After 3DS process success, customer will be redirected to this page |
|
| Mandatory | Payment type
Possible value: |
|
| Optional | Promotion ID from the bank for merchant |
|
| Optional | Card token generated by DOKU, for 3ds transaction please bring |
|
| Mandatory | Card number, can be optional if you sent |
|
| Mandatory | Card expiry date, can be optional if you sent |
|
| Mandatory | Card CVV, Optional if |
|
| Optional | Set |
API Response
After hitting the above API request, DOKU will give the response.
Type | Value |
---|---|
HTTP Status | 200 |
Result | SUCCESS |
Here is the sample response header:
Response Header Explanation
Client-Id | Same as the request |
Request-Id | Same as the request |
Response-Timestamp | Timestamp Response on UTC with format ISO8601 UTC+0 from DOKU |
Signature | Signature generated by DOKU based on the response body |
Here is the sample of response body:
Response Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Same as the request |
|
| Mandatory | Same as the request |
|
| Optional | Same as the request |
|
| Mandatory | Same as the request |
|
| Mandatory | Additional payment info name |
|
| Mandatory | Additional payment info value |
|
| Mandatory | Request ID sent on merchant's request header |
|
| Mandatory | Authorize ID for authorize transaction. Mandatory if |
|
| Mandatory | Reponse code generated by DOKU / Acquirer |
|
| Mandatory | Response message generated by DOKU / Acquirer |
|
| Mandatory | Payment status
Possible value: |
|
| Mandatory | ECI for this transaction |
|
| Optional | Approval code for success transaction generated by acquirer |
|
| Mandatory | Same as the request |
|
| Optional | Card masked number |
|
| Mandatory | Card type
Possible value: |
|
| Mandatory | Card issuer |
|
| Mandatory | Principal brand
|
|
| Optional | Card token generated by DOKU if |
DOKU will also send the HTTP Notification with the payment.authorize_id
to your defined Notification URL.
4. Hit API Capture
After you get the payment.authorize_id
, then your backend must trigger the API Charge to DOKU:
API Request
Type | Value |
---|---|
HTTP Method | POST |
API endpoint (Sandbox) |
|
API endpoint (Production) |
|
Here is the sample of request header to capture the transaction:
Request Header Explanation
Parameter | Description |
---|---|
Client-Id | Client ID retrieved from DOKU Back Office |
Request-Id | Unique random string (max 128 characters) generated from merchant side to protect duplicate request |
Request-Timestamp | Timestamp request on UTC time in ISO8601 UTC+0 format. It means to proceed transaction on UTC+7 (WIB), merchant need to subtract time with 7. Ex: to proceed transaction on September 22th 2020 at 08:51:00 WIB, the timestamp should be 2020-09-22T01:51:00Z |
Signature | Security parameter that needs to be generated on merchant Backend and placed to the header request to ensure that the request is coming from valid merchant. Please refer to this section to generate the signature |
Here is the sample request body to capture the transaction:
Request Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Authorize ID from the Charge API Response / HTTP Notification |
|
| Optional | The value of transactions which will be paid by the customer. If undefined, capture full transaction. |
API Response
After hitting the above API request, DOKU will give the response.
Type | Value |
---|---|
HTTP Status | 200 |
Result | SUCCESS |
Here is the sample response header:
Response Header Explanation
Client-Id | Same as the request |
Request-Id | Same as the request |
Response-Timestamp | Timestamp Response on UTC with format ISO8601 UTC+0 from DOKU |
Signature | Signature generated by DOKU based on the response body |
Here is the sample of response body:
Response Body Explanation
Parameter | Type | Mandatory | Description |
---|---|---|---|
|
| Mandatory | Same as the request |
|
| Mandatory | Same as the request |
|
| Optional | Same as the request |
|
| Mandatory | Same as the request |
|
| Mandatory | Additional payment info name |
|
| Mandatory | Additional payment info value |
|
| Mandatory | Request ID sent on merchant's request header |
|
| Mandatory | Authorize ID for authorize transaction. Mandatory if |
|
| Mandatory | Reponse code generated by DOKU / Acquirer |
|
| Mandatory | Response message generated by DOKU / Acquirer |
|
| Mandatory | Payment status
Possible value: |
|
| Mandatory | ECI for this transaction |
|
| Optional | Approval code for success transaction generated by acquirer |
|
| Mandatory | Same as the request |
|
| Optional | Card masked number |
|
| Mandatory | Card type
Possible value: |
|
| Mandatory | Card issuer |
|
| Mandatory | Principal brand
|
|
| Optional | Card token generated by DOKU if |
5. Acknowledge payment result
After the payment is being made by your customer, DOKU will send HTTP Notification to your defined Notification URL
. Learn how to handle the notification from DOKU:
List of Error Code
If something happens, you can see the following error code to find out what error is happening :
API | Error message | Error Code | HTTP Status Code | Explanation |
---|---|---|---|---|
Check-three-d-secure | Invalid Client-Id |
| 400 | Invalid Client ID |
Check-three-d-secure | Header Client-Id is required |
| 400 | empty client id |
Check-three-d-secure | Invalid Header Signature |
| 400 | Payment charge with invalid signature |
Check-three-d-secure | Invalid CC Number LENGTH |
| 400 | Invalid CC Number LENGTH |
Check-three-d-secure | Luhn Validation |
| 400 | Card number not valid |
Check-three-d-secure | Expiry Date Validation |
| 400 | Invalid expiry date 2525 |
Check-three-d-secure | This field is required.,This merchant does not have three d secure configuration |
| 400 | invalid configuration / haven't 3ds mid |
Check-three-d-secure | This card is not support three d secure |
| 400 | card not support 3ds / cannot connect to mpi |
Charge | Invalid Client-Id |
| 400 | Invalid Client ID |
Charge | empty client id |
| 400 | empty client id |
Charge | size must be between 1 and 128 |
| 400 | Payment charge with client id length more than max |
Charge | Invalid format Header Request-Timestamp |
| 400 | Payment charge with invalid format request timestamp |
Charge | Header Request-Timestamp is not in +- 10 second of now |
| 400 | Payment charge with request timestamp < now |
Charge | Header Request-Timestamp is not in +- 10 second of now |
| 400 | Payment charge with request timestamp > now |
Charge | Invalid Header Signature |
| 400 | Payment charge with invalid signature |
Charge | Invalid Header Signature |
| 400 | Payment charge using signature has been used |
Charge | Invalid Format Email |
| 400 | Payment charge with invalid format email |
Charge | Invalid amount |
| 400 | Payment charge with amount contain comma |
Charge | Invalid amount |
| 400 | Payment charge with amount contain dot |
Charge | Expiry Date Validation |
| 400 | Payment charge with format expiry is YYMM |
Charge | Expiry Date Validation |
| 400 | Payment charge with expiry date is expired |
Charge | Invalid AuthenticationId. |
| 400 | invalid authentication_id |
Charge | Country Is Not Exists |
| 400 | Payment charge with invalid country |
Charge | Invalid CC Number LENGTH |
| 400 | Invalid CC Number LENGTH |
Charge | Luhn Validation |
| 400 | Card number not valid |
Charge | REQUEST ID IS NOT VALID |
| 400 | Payment charge with request id has been used for transaction |
Charge | Unauthorized Transaction |
| 400 | Payment charge sale using card rejected |
Charge | Invalid Authentication Id |
| 400 | Invalid Authentication Id |
Charge | Invalid Authentication Id |
| 400 | Different amount check 3ds & charge |
Charge | Invalid Authentication Id |
| 400 | Three D Secure Process Not Yet Done (Not yet send OTP) |
Charge | Line item 1 quantity must be not empty |
| 400 | Invalid line item (quantity is null) |
Charge | Your transaction is detected to be concurrent, please create another transaction |
| 400 | Concurent Request |
Charge | Conflict |
| 409 | duplicate request with same request body |
Charge | Precondition failed |
| 412 | duplicate request with different request body |
Capture | Invalid Client-Id |
| 400 | Invalid Client ID |
Capture | Header Client-Id is required |
| 400 | empty client id |
Capture | Invalid Header Signature |
| 400 | Payment charge with invalid signature |
Capture | Authorize Id Must Not Be Blank |
| 400 | authorize_id is null |
Capture | Failed Get Transaction |
| 400 | Invalid authorize_id |
Capture | Conflict |
| 409 | duplicate request with same request body |
Capture | Precondition failed |
| 412 | duplicate request with different request body |
Last updated