QuickPay Transaction API*
Seamless and hassle free checkout experience process
This section will show you how you can tokenize the user and make the payment more seamless with Indodana. With this QuickPay checkout integration, Indodana user can enjoy the easy & fast checkout experience on your platform. Contrast to normal checkout, user with QuickPay checkout activated won't have to input credentials / sign-in to Indodana platform on every transaction. The user will directly proceed to checkout your transaction if we don't detect any suspicious behavior after you redirect the user to our checkout page.
This section only covers the specific QuickPay API integration, so we recommend you to read the Direct API Integration first for general integration information.
Preparation
QuickPay builds on top of the Direct API, so first complete the base Direct API preparation (merchant API key & secret, sandbox / production URLs, and IP whitelist). In addition, QuickPay requires:
The userTokenCallbackUrl and userTokenRevokeCallbackUrl are configured on Indodana's side during onboarding — contact your Indodana PIC to register them. They are not passed per request.
Integration Flow
The end-to-end QuickPay flow starts by checking whether the user is eligible (has an active PayLater limit), then tokenizes the user, and finally reuses that token for seamless checkouts.
User Tokenization Options
This section will guide you on how to get the Indodana QuickPay user token. The Indodana QuickPay user token is a long live unique token per-user that you can store in your system. You need to pass this Indodana QuickPay user token when checkout to enable seamless transaction experience without user sign-in process.
Indodana provides two tokenization flows :
Explicit user tokenization from merchant's platform menu The explicit user tokenization is a flow when user explicitly says that he/she wants to tokenize Indodana account on your platform menu. Upon successful authorization, your system will get the Indodana QuickPay user token via callback request.
User tokenization on checkout User tokenization on checkout is a flow when user does tokenization while he/she checkouts transactions on your platform using Indodana. Upon successful transaction, your system will get Indodana QuickPay user token via callback request.
API Method References
In this section, {baseUrl} corresponds to https://sandbox01-api.indodanafinance.co.id/chermes/merchant for sandbox and https://api.indodanafinance.co.id/chermes/merchant for production. Authentication uses the same Authorization: Bearer {api_key}:{nonce}:{signature} scheme described in the Direct API Integration.
Indodana Connect Account
POST https://{baseUrl}/v1/connect
Use this API to initiate user tokenization. After calling this API, you will get a redirection URL for the user to authorize your tokenization request. You need to redirect the user to the redirection URL and upon successful authorization, you will get the Indodana QuickPay user token from the callback.
* means the parameter is required
Headers
Authorization*
string
The generated authentication signature with format
Bearer {api_key}:{nonce}:{signature}
Request Body
merchantUserKey*
string
User identifier in merchant's platform. Indodana will send the Indodana QuickPay token alongside this information so you know the owner of token.
phoneNumber*
string
Phone number of user in merchant's platform.
backToStoreUrl*
string
Url to be redirected by Indodana to user after the connect process is complete. Must use https://.
metadata
object
Key value pair of additional information of user / transaction.
All callback URLs (backToStoreUrl) must use HTTPS. Requests with http:// URLs will be rejected.
When you initiate checkout with null / invalid Indodana QuickPay user token, it will give the signed-in user an option to do tokenization on Indodana checkout page. With this method, you don't need to create a dedicated menu for connecting Indodana account to your platform.
Please refer to checkout using QuickPay for the API specification.
Get Payment Calculation
POST https://{baseUrl}/v3/payment_calculation
Once the user is tokenized, you can use this API to know installment options available for the current user based on his/her limit balance.
If you pass a valid Indodana QuickPay user token to call this API, this API will respond with additional properties currentAvailableLimitBalance and isEligible. When the user's current limit balance is insufficient on the particular tenure option, the property isEligible will be false, so you can gray out the payment option based on your platform UI/UX design.
* means the parameter is required
Headers
X-User-Token
string
[Optional] If token is set, this will be used to authenticate the user. userToken is generated specified per merchant
Authorization*
string
The generated authentication signature with format
Bearer {api_key}:{nonce}:{signature}
Request Body
items*
array
Array of <Item>. Details of shopping items in the transaction.
amount*
number
Total amount of the transaction. Should be equal to the sum of all the <Item>'s costs.
Purchase Transaction Checkout
POST https://{baseUrl}/v3/checkout_url
This checkout API v3 enables QuickPay integration. You need to pass valid x-user-token on the header so user can enjoy the easy & fast checkout experience.
Don't worry if you don't have the Indodana QuickPay user token for current checkout user in the first place, our checkout page already handle the flow and you need to store the token every time Indodana sends the token via callback to your system and use this token for subsequent transaction.
* means the parameter is required
Headers
X-User-Token*
string
Indodana QuickPay user token. You can pass null if user account not connected yet in your platform.
Authorization*
string
The generated authentication signature with format
Bearer {api_key}:{nonce}:{signature}
Request Body
merchantUserKey*
string
User identifier in merchant's platform. Indodana will send the Indodana QuickPay user token alongside this information so you know the owner of the token.
transactionDetails*
object
<Transaction> - Detail of the transaction.
customerDetails*
object
<Customer> - Detail of the customer.
sellers*
array
Array of <Seller> - Detail of the sellers involved in the transaction. May contain more than 1 seller.
billingAddress*
object
<Address> - Billing address of the customer for the transaction.
shippingAddress*
string
(Required only for goods, for service / digital product is not required) <Address> - Shipping address of the customer for the transaction.
paymentType*
string
(Required for active Indodana QuickPay user token) Installment options / payment terms chosen by the customer. Possible values: 30_days, 3_months, 6_months, 12_months
approvedNotificationUrl*
string
The URL that will be called by Indodana when the transaction is approved and successful. Must use https://.
cancellationRedirectUrl
string
[Optional] The URL for user to be redirected if transaction's cancelled in Indodana's checkout page. If set, must use https://.
backToStoreUrl*
string
The URL for user to be redirected after completes the checkout process. Must use https://.
expirationAt
string
Timestamp when the transaction expired on merchant's platform.
metadata
object
Key value pair contains additional information of transaction.
couponCodes
Array of String
Coupon Code
All callback URLs (approvedNotificationUrl, cancellationRedirectUrl, backToStoreUrl) must use HTTPS. Requests with http:// URLs will be rejected.
Object Type References
For object specification of Transaction, Customer, Seller, Address, and Metadata can refer to this API reference.
QuickPay User Token Revocation
POST https://{baseUrl}/v1/revoke_user_token
You can revoke the Indodana QuickPay user token from your platform permanently. When token is revoked, the token will be invalid and system will trigger tokenization again on next user checkout from your platform. The token itself can be revoked from your side and Indodana side. So for the integration, we expect you to always save the token from our callback to your system with the purpose to always have the valid token of the user.
* means the parameter is required
Headers
X-User-Token*
string
Indodana QuickPay user token to be revoked
Authorization*
string
The generated authentication signature with format
Bearer {api_key}:{nonce}:{signature}
Object Type References
For object specification of Item, can refer to this API reference.
User QuickPay Eligibility
GET https://{baseUrl}/v2/users/check_eligibility?phoneNumber={phoneNumber}
This API is used to check whether a user is eligible to connect QuickPay or not. Eligible means the user has active PayLater Limit
Headers
Authorization*
String
The generated authentication signature with the format
Bearer {api_key}:{nonce}:{signature}
Query Parameters
Pass phoneNumber as a URL query parameter (this is a GET request — do not send it in the request body).
phoneNumber*
String
User Registered Phone Number
User Credit Details
GET https://{baseUrl}/v1/user_details
Once user is tokenized, you can use this API to know about user information details including account status and remaining credit limit.
* means the parameter is required
Headers
X-User-Token*
string
Indodana QuickPay user token
Authorization*
string
The generated authentication signaturee with format Bearer {api_key}:{nonce}:{signature}
Sample API Request and Response
Indodana Connect Account
Purchase Transaction Checkout
Handling Transaction Confirmation Notification
Get Payment Calculation
Callback User Token
This step is used to retrieve the Indodana QuickPay user token from callback after the authorization from user already completed.
You need to inform us the URL to be registered on Indodana side. After successful store token in your system, you need to response with status code 200 like defined in the response example tab below to acknowledge the token.
Revoke User Token Callback
When a user revokes the QuickPay connection from the Indodana app, Indodana sends a POST request to your registered userTokenRevokeCallbackUrl so you can mark the stored token inactive on your side. Acknowledge with a 200 response, then stop using the token and re-tokenize on the user's next checkout.
Security Best Practices
First follow the general Security Best Practices that apply to every Indodana integration — verifying inbound callback signatures, protecting your secret key, TLS, IP allowlisting, and not using SSL/certificate pinning. The items below are specific to QuickPay's stored user token.
Protect the stored user token
The QuickPay userToken is long-lived and lets you initiate seamless checkouts for that user, so treat it as a sensitive credential:
Store it encrypted at rest — never in plaintext.
Keep it server-side only — never expose it to the browser or client-side code.
Restrict and audit access to the token store.
Fail closed on revocation
When you receive a revoke callback on userTokenRevokeCallbackUrl, or when any API call returns 401 "User token is invalid", immediately mark the stored token inactive and trigger re-tokenization on the user's next checkout. Never keep using a token after the user has disconnected.
Last updated