Authentication (3DS)
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:
| Scenario | Pros | Cons |
|---|---|---|
| Never authenticate | Offers 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 cards | Helps 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 transaction | Maximum 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 authentication | Balance 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.
ECI Code
Electronic Commerce Indicator (ECI) is a value that is returned from the Directory Server (Visa and MasterCard) to indicate the authentication results of your customer's credit card payment on 3D Secure.
| Visa and other | MasterCard | Description | Chargeback Liability Shifted from Merchants to Cardholder |
|---|---|---|---|
| 05 | 02 | Both cardholder and card issuing bank are 3DS enabled. 3DS Authentication was successful; transaction secured by 3DS | ✅ Yes |
| 06 | 01 | 3DS Authentication was attempted but was not or could not be completed; some of the reasons could be: -Card is not enrolled to 3DS -Issuer is not participating on 3DS -Timeout from the issuer | ✅ Yes |
| 07 | 00 | 3DS Authentication either failed or could not be attempted; some of the reasons could be: -Card is not enrolled to 3DS -The issuing bank does not handle it as a 3D transaction -Error from Directory Server lookup -Card is enrolled to 3DS but failed to authenticate This code is common for foreign cards like the United States and Canada. Even though it’s from a legit cardholder and we have attempted 3DS, sometimes the issuer will still return ECI 00/07 | ❌ No *If you want to block these types of transactions, please send your inquiry to help@xendit.co. |
Enable/Disable 3DS Optional
3DS Authentication, albeit incredibly important to protect your business against fraud exposure, might decrease the success rate for Cards that’s not enrolled to 3DS (i.e. foreign cards like but not limited to US and Canada). Thus, in order to increase your acceptance rate and provide a seamless user experience, we provide an option for merchants to set 3DS authentication as optional meaning that when this feature is enabled:
- For Checkout UI merchants, there will be no 3DS authentication performed
- For API merchants, you are able to choose whether to perform 3DS or skip it according to your implementation
However, you can still opt-to enable/disable your 3DS optional feature based on your business needs (although we highly recommend you to enable 3DS authentication by default). There are several steps you can take to do so:
- Go to your settings page
You can refer to Configuration > Payment Methods > Cards > Click “View Details” button or click here
- Request 3DS Optional for your business
Hover to “Card Settings” tab and click “Request Optional 3DS” button
- Fill in the reason why you would like to enable 3DS optional, then click the Request button.
- Waiting from Xendit to approve your request
Once the request is sent, it will take approximately 3 working days in order to complete this step. - Xendit will send email for approval / rejection
After that, you will get the email notification about your request status. - Approval response:
- Rejection response:
Once we approve your request, you will see that your 3DS optional is already enabled. If you want to disable it, you can simply click on the “Enabled” button and it will disable the 3DS optional (3DS authentication will be performed for every transaction).
FAQs
- 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.
- 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.
- 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.
- 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.
- My end-customer (cardholder) did not receive an OTP message or there is an issue in the OTP page during the 3DS authentication process?
- Please note that OTP message and OTP page is fully owned / controlled by the issuing bank. Thus, whenever there is an issue of unreceived OTP message or error found in the OTP page, please suggest the cardholder to contact their issuing bank directly to resolve the issue.
Last Updated on 2024-12-03