3DSecure

3DSecure

WARNING

This article is incomplete. It may change significantly without any notice, so don't rely on any content you find here yet. Please check back later.

3D Secure (3DS, Three-Domain Secure) is a messaging protocol developed by EMVCo to provide a more secure online card payment process. If the card is enrolled into 3DS authentication additional information is required to decide whether the purchase is fraudulent or not. This decision is made by the card's issuer (in most cases the bank that issued the card) not by the Barion system. There are two different versions of the protocol:

• 3D Secure 1. version is a HTTP redirect based scenario where the customer almost always needs to provide som extra proof for the transaction.

• 3D Secure 2. version is more sophisticated and uses additional information about the purchase, the shop and the cardholder to make the decision. This requires more input data but provides better flow with less friction.

TODO: Describe the deadlines, legislative restriction and project milestones, when will what be available.

The payment follows these steps:

1. The customer checks out from the merchant's website and decides to pay for the goods via Barion.
2. Customer is redirected to the Barion Smart Gateway.
3. Customer inputs it's card information and clicks the Pay button.
   --- Until this point nothing changed ---
4. Barion checks whether the card the customer used is protected with 3DS authentication. The card could be either protected or not. If the card is not protected then nothing changes, the card authorization (charge) goes along as it would normally.
5. If the card is protected
   • with 3DS authentication v1.0, the v1 flow will be started:
     1. TODO: Describe the v1 process steps
   • with 3DS authentication v2.0, the v2 flow will be started:
     1. Barion starts the 3DS authentication in the background. Sends a lot of relevant information about the purchase to the card issuer. From this information the issuer decides whether the payment is secure or should the customer be challenged in some form.
     2. If the result is that the customer should not be challenged (it is called frictionless flow) the customer's card is charged and the payment flow is continued.
     3. If the result is that the issuer needs more proof from the customer a popup window will be displayed. In this window the issuer will display something for the customer. The content is up to the issuer but will be something that allows the customer to provide proof (SMS, token, question).
     4. After the customer successfully completed the challenge the card is authenticated and the payment flow continues with the authorization of the card. The card still can be declined after successful 3DS authentication.
6. At the end of the payment the customer will be redirected to the merchant's website

3D Secure 1.0

TODO: Describe the process

3D Secure 2.0

The reason behind the second version was to provide a way to achieve the same level of security for the authentication but with less friction. For this a lot more information is required (or at least it is strongly recommended to provide them). This information comes from different sources:

• merchant's data about the customer (purchase behavior, addresses, etc)
• customer's browser information (screen size, timezone, language, etc)
• customer provided data (card information, e-mail address)
• Barion's data about the merchant, the purchase and the customer (merchant's MCC code, name of the shop, etc)

How to achieve the frictionless flow