API ReferenceSign In

Authentication (3DS)

Last updated 09/28/2019

Authentication is a process to verify the identity of a cardholder before making a purchase. It helps to reduce identity fraud, and is how acquiring banks in Indonesia determine which party is liable for a chargeback. Across Southeast Asia, authentication is commonly referred to as 3D Secure or 3DS, and often requires cardholder to enter a One-Time-Password (OTP) that is sent to their phone by the issuing bank. Many issuing banks outside of Southeast Asia also supports authentication, but use of OTP is not as common as in some regions, like the US.

New Xendit accounts require 3DS by default, but this can be made optional upon request. If you would like the option to skip 3DS, please ask your Xendit Account Manager.

Some common authentication scenarios for consideration are:

Never authenticateOffers best user experience. The customer does not need to go through the extra process of authentication.Will not work for some debit cards (Malaysian debit cards and Indonesian Mandiri debit cards). No liability protection for chargeback. Higher chargeback risk.
Authenticate once for new cardsHelps to prevent unauthorized transaction, identity theft, and fraud (3DS).No liability protection for chargeback (requires 3DS per charge). Will not work for some debit cards (Malaysian debit cards and Indonesian Mandiri debit cards), even if it successfully passes 3DS.
Authenticate every transactionMaximum liability protection for chargeback (you should win any chargeback dispute and not have to refund customers who raise a chargeback).Least best user experience: Your customer is required to do 3DS for every transaction. Your customer needs to have Indonesia SIM Card in their phone (for Indonesia card), which is inconvenient when traveling.
Rule-based authenticationBalance between liability protection for chargeback and better user experience.Requires coding / updating rules to prevent fraud and ease checkout experience for customer.

This chart illustrates a typical authentication flow.

alt text


  1. Are we obliged to activate 3DS for all transactions?

    • If using Xendit MID: You can request to make it optional and we will make a decision after a risk assessment. Your Xendit Account Manager can guide you through this.
    • If using your own MID: Generally if you sign a waiver accepting all chargeback risks, acquirers will make this optional for you. If you start getting over 0.9% chargebacks, any acquirer will start asking questions and might pull MID if not resolved.
  2. Can we have flexible rules? i.e. 3DS active for specific transactions only

    • Of course! We give you full control over this once your 3DS is set to optional.
  3. Will the 3DS pop-up appear during token creation?

    • Single-Use Token: Yes, if enabled for your account.
    • Multiple-Use Token: No, tokenization & authentication are separate function calls in our JS/iOS/Android SDKs.
  4. Is 3DS required for each subsequent charges? If yes, can we skip those? What are the limitations to skipping 3DS?

    • You don't actually need authentication for any transaction unless the card requires it (which is Malaysian debit cards and some Indonesian ones like Mandiri). Refer to the table above to build your flow.