The 3DS of the payment

Recently, I have been working on the fraud check part of the payment flow. More precisely, I am trying to integrate the 3DS 2.0 into our payment system. It’s another dimension that I never touched.

Introduction

What is the 3DS

The 3DS is a type of fraud check method. Generally, it will display a verification page when a user makes a payment with a credit card. The verification page will require a verification code from SMS or email. After the user input the correct code and press the process(or submit) button, the payment will continue processing.

You can see the Visa 3DS User Experience Guidelines to learn more about the 3DS experience.

Why do we need it

Now that we know the 3DS verification experience. Let me give future information about why we need the 3DS.

Do you worry about getting your money back if you lose your credit card or leak your card information(card number, expiry date, and CVV)? Or have you already experienced it?

If it is not you to make that payment, you can make a phone call to the customer support team of your bank to get your money back, that called: chargeback. And you do not need to care about the purchase fee and take any responsibility.

And for the merchant, if the merchant enabled the 3DS, the result of 3DS shows the payment is safe. When the user calls the bank to do the chargeback, the merchant will not need responsibility either.

That is why we need it, whether you are a customer or a merchant.

But here still have a question: who should take responsibility for the payment? The answer is issuing bank. You can see more detailed information in a later chapter and think about why is the issuing bank.

A history of 3DS

For the article, we will focus on the 3DS 2, but before that, let us talk about the history of the 3DS.

From the previous chapter, we can know the 3DS is used to avoid fraudulent payments. Still, before the 3DS came up, some merchants could use the Address Verification System (AVS) or the CVC verification to avoid fraudulent payment. Even has the AVS and CVC verification payments still have a high risk of fraud.

So the card schemes implemented the first version of the 3DS system in 2001 called 3DS 1. It can distinguish some fraudulent payments and decline them. Also, the 3DS guarantee if any fraudulent payments get safe results from the 3DS system, will be no responsibility for the merchant.

Is it look great? For the merchant, perhaps it is. Letting the end-user provide additional information and do more strict verification in their system can avoid a lot of fraudulent payments. At least, no chargeback for the merchant.

But for the end-user, that will not be so great. In the payment flow of the 3DS 1, the end-user always sees the verification page and needs to input some verification code to complete this payment. It is a little annoying, and in some cases, the user does not bring their phone or loses access to email, which means that the user can not make any online purchase.

So, when some users see the 3DS verification page, they will stop or cancel the payment. Let us back to the merchant. Finally, the merchant got more safety but lost some orders, so it may not be great.

So, that’s why the 3DS 2 came up. In some cases, it will skip the end-users verification page, but the merchant still has no responsibility for the chargeback. It is called frictionless flow.

How it works

Terms

Here are some terms about the payment and 3DS. Before you read other content of the article, I recommend you read the terms table first. But if you already know the terms, you can skip them.

Which systems are involved

In the payment world, it has too many roles. They all do different things to build the payment system together.

The above picture shows the systems are involved. About the detailed description, you can see the table.

The result of the 3DS

Before I explain, I should point out: the 3DS is a choice, not required in the payment process. And the merchant can control whether enable it. And in the payment gateway can still process the payment even if the 3DS result is failed or does not pass.

As I mentioned, the 3DS 2 has a different flow from the 3DS 1 called frictionless flow. In the frictionless flow, the end-user will pass the verification directly without an explicit verification page.

That is why the 3DS 2 will not break the user experience. The end-user does not even see the verification page, but payment has been proven safe.

The 3DS server should go to a different flow for the client according to the authentication response. Such as: pass or decline directly, or show challenge page for end-user.

The flow of the 3DS 2 challenge

Let us hypothesize the merchant enabled the 3DS for all payments, and when an end-user wants to pay with a credit card, what happens?

1. The end-user starts to make a payment with a credit card.

2. The 3DS server (a part of the payment gateway) received the payment request and tried to send the 3DS authentication request to the directory server of the card scheme.

3. The directory server forward (or reconstruct) the authentication request to issuing bank and forward the response back to the 3DS server.

4. The 3DS server received the response of the authentication request, then parsed the response to check whether the payment passed the 3DS check.

5. If the issuing bank can not decide whether the payment pass 3DS, it will send a challenging result to the 3DS server, and the 3DS server needs to redirect the end-users page to the challenge page of issuing bank.

6. The challenge page is provided by issuing bank, and after the end-user input the verification code, it will redirect to another web page provided by the 3DS server. And at the same time, the issuing bank will send a message to the directory server, and the directory server will forward the message to the 3DS server.

7. The challenge page redirects to the 3DS server using a hidden form submitted, and then the web page control permission will hand over to the 3DS server. The hidden form also includes a part of the 3DS result.

8. After the above flows, the 3DS server knows the 3DS check result of the payment and then can decide whether decline the payment.

What the 3DS server needs to do

We now know the 3DS verification from the previous chapter. Let us talk about more detailed work about the 3DS server.

First, the 3DS server should get the card range data from the card scheme. The card range data include the card data and method URL, the data such like this:

Range: from 4111111111111111 to 4222222222222222

Method URL: https://acs.url/path

When a payment comes in, the 3DS should get the method URL and let the end-users browser redirect to the method URL using a hidden form. In some systems, this is called pre-auth flow.

After the pre-auth, the 3DS server then can start the 3DS verification flow. First, it will send the credit card data, merchant id, 3DS requestor id, etc., to the card scheme. That called the authentication request. Then the card scheme will respond to a set of fields, and it has a field that can indicate whether the 3DS pass.

Suppose the authentication response told us we should go to the challenge flow. In that case, we should redirect the end-user page to the challenge page by returning a hidden form and submitting some data to the issuing bank. The browser will redirect to the challenge page of issuing bank automatically.

This is the detailed work that I did not mention in previous chapters. Then you can see below the sequence diagram, which shows the detailed flow about the 3DS integration work.

The payment with 3DS

After the 3DS, let us talk a little about payment flow. I drew the below picture to help you learn the payment flow with the 3DS. It combined the 3DS verification flow.

Typically, after the 3DS verification and the 3DS server gets the pass result, the 3DS server will send the payment message to the acquiring bank to start the actual payment. The message will include the card data, amount, currency, etc.

Then we can see the acquiring bank sends the message to the card scheme network block. The acquiring bank talked with the issuing bank to complete the payment using the card scheme network, but I am unsure what the card scheme network is. But one thing I knew: it can reduce the integration work between acquiring bank and issuing bank. You can think: Have too many banks in the world, if they want to talk to each other to make payment, it will be a huge work for every bank, so that is why the card scheme network came up. Also, the card scheme can earn profit by providing the card scheme network to banks.

After the issuing bank receives the payment message, it will check the credit of the card and send the pass of other error (e.g., insufficient funds) response to acquiring bank, and acquiring bank wrap the response and send to 3DS server.

Finally, the 3DS server shows the payment result to the end-user and marks the payment as finished.

Reference

• 3DS user experience
• 3DS verification flow and payment flow