How do 3DS and Pre-Authorization work?
A brief look at how these features work together to reduce fraud
3DS authentication is a tool that helps us reduce the number of fraudulent transactions in our systems, while introducing the least possible amount of friction for genuine users. A transaction that goes through 3DS successfully is not your liability in case a chargeback is raised against it. The 3DS functionality builds on the foundation of Pre-Authorization. Here's a brief look at how these features work in different scenarios.
During the course of these scenarios below, please keep in mind that 3DS authentications can happen completely in the background, invisible to the user. These "frictionless" authentications are a great way to enhance security, while creating a seamless user experience. There of course will be some situations where a user will need to take some action to complete the authentication, like entering a code.
When a new card is added: The easiest way to reduce fraud is to stop it at the very first step. When a new card is added to our systems, based on complex background factors in our Risk Engine, the user may need to go through a 3DS authentication to verify the card ownership. In some situations, the user's bank may force 3DS for this scenario as well.
When a new transaction is created: If a user creates a taxi booking for example, we will Pre-Authorize a specific amount on their card, based on the estimated fare etc. Our Risk Engine will in real time analyze a variety of data points to decide if this Pre-Authorization should be 3DS authenticated or not. One factor would be the fare amount, if it exceeds a certain threshold, 3DS will automatically be invoked. In case it is necessary, the Pre-Authorization will only be created once the authentication is completed successfully. As is the case with adding a new card, even if our Risk Engine decides to skip 3DS for a specific transaction, the card issuer may force it from their end.
Last updated
Was this helpful?