Difference between revisions of "3DSecure"

From Barion Documentation
Jump to navigation Jump to search
 
(24 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{PageTitle|title=3DSecure}}
 
{{PageTitle|title=3DSecure}}
{{IncompletePage}}
+
{{TableOfContents}}
  
3D Secure (3DS, Three-Domain Secure) is a messaging protocol developed by [https://www.emvco.com 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.
+
3D Secure (3DS, Three-Domain Secure) is a messaging protocol developed by [https://www.emvco.com EMVCo] to provide a more secure online card payment process. It enables consumers to authenticate themselves with their card issuer when making card-not-present (CNP) e-commerce purchases.
 +
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 (the bank or other institution that issued the card) not by the Barion system.  
  
{{draft|text=TODO: Describe the deadlines, legislative restriction and project milestones, when will what be available. }}
+
There are two major versions of the protocol:
 +
* '''3D Secure 1''' is a HTTP redirect based scenario where the customer almost always needs to provide some extra proof for the transaction. The verification is usually a password or SMS code.
 +
 
 +
* '''3D Secure 2''' 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. The card issuer may verify the shopper's identity using passive, biometric, and two-factor authentication approaches. According to the [https://en.wikipedia.org/wiki/Strong_customer_authentication Strong Customer Authenticaton (SCA) rules of PSD2 RTS] from 14th of September every card issued in the EU has to be authenticated with 3D Secure 2.
 +
 
 +
Card schemes will decommission 3D Secure 1 by 2020/2021, until that some card issuers will still support and require 3D Secure 1. At the same time we expect that by the PSD2 SCA compliance date, so by 14 September 2019, some EU card issuers may not be ready for 3D Secure 2 and still use 3D Secure 1 to comply with SCA.
 +
 
 +
{{NotificationBox|title=IMPORTANT|text=If the shopper completes a 3DSecure authenticaton successfully, the liability shifts from the merchant to the card issuer in case of fraud.|color=#FF7A3D}}
 +
==Liability shift rules==
 +
If a merchant implements 3D Secure authentication, he/she can avoid the liability for chargebacks in case of fraud (e.g. chargeback claim because of lost or stolen cards). This is called a liability shift.
 +
In general if a shopper completes a 3D Secure challenge authentication flow succesfully, the liability for fraudulent chargebacks shifts from the merchant to the card issuer.
 +
 
 +
{| class="wikitable"
 +
|-
 +
!Transaction type
 +
!Liability shift to card issuer?
 +
|-
 +
|3D Secure 1 transactions with challange.||style="text-align:center;" | Yes
 +
 
 +
|-
 +
|3D Secure 2 transactions with challange.||style="text-align:center;" |Yes
 +
 
 +
|-
 +
|3D Secure 2 transactions where '''card issuer applies a PSD2 exemption''' without the merchant requesting it. E.g. issuer TRA.||style="text-align:center;" |Yes
 +
 
 +
|-
 +
|3D Secure 2 PSD2 SCA out-of-scope transactions: shopper's issuer is outside of the EEA, anonymous prepaid cards up to 150€ or merchant initiated transactions.||style="text-align:center;" |No
 +
 
 +
|-
 +
|3D Secure 2 transactions where '''merchant or acquirer requests for a PSD2 exemption''' and the issuer grants an exemption.||style="text-align:center;" |No
 +
 
 +
|}
 +
 
 +
==The payment process==
  
 
The payment follows these steps:
 
The payment follows these steps:
# The customer checks out from the merchant's website and decides to pay for the goods via Barion.
+
# The shopper checks out from the merchant's website and decides to pay for the goods via Barion.
# Customer is redirected to the Barion Smart Gateway.
+
# Shopper is redirected to the Barion Smart Gateway.
# Customer inputs it's card information and clicks the ''Pay'' button. <br/>--- Until this point nothing changed ---
+
# Shopper inputs card details and clicks the ''Pay'' button. <br/>--- Until this point nothing changed ---
# 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.  
+
# Barion checks whether the card the shopper used is a 3DSecure capable card and also the version the issuer supports. If the card is not '''3DSecure capable''', the card authorization (charge) goes along without any extra step.  
# If the card is protected
+
# If the card is 3D Secure capable
#* with 3DS authentication v1.0, the v1 flow will be started:
+
#* with 3DSecure 1, the v1 flow will be started:
#*# {{draft|text= TODO: Describe the v1 process steps}}
+
#*# an authentication screen is displayed for the shopper within the Barion UI
#* with 3DS authentication v2.0, the v2 flow will be started:
+
#*# the customer must complete the challenge displayed
 +
#*# if the challenge is successful the payment process continues
 +
#* with 3DSecure 2, the v2 flow will be started:
 
#*# 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.
 
#*# 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.
 
#*# 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.
 
#*# 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.
Line 25: Line 58:
 
# At the end of the payment the customer will be redirected to the merchant's website
 
# At the end of the payment the customer will be redirected to the merchant's website
  
== 3D Secure 1.0 ==
+
== 3D Secure 1 ==
{{draft|text= TODO: Describe the process}}
 
  
 +
In case the card is protected with 3DSecure 1 the customer will be presented with a popup. This popup will show an extra authentication step that has to be completed in order to continue the payment.
  
== 3D Secure 2.0 ==
+
== 3D Secure 2 ==
  
 
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:
 
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)
+
* merchant's data about the customer (purchase behavior, addresses, etc)
* customer's browser information
+
* customer's browser information (screen size, timezone, language, etc)
* customer provided data  
+
* customer provided data (card information, e-mail address)
* Barion's data about the merchant, the purchase and the customer
+
* Barion's data about the merchant, the purchase and the customer (merchant's MCC code, name of the shop, etc)
 +
 
 +
The card issuer receives this information package and calculates the risk of the transaction. The result of this calculation specifies the flow:
 +
* Frictionless flow: The customer will not be presented with any challenge screen, no more information needed, the authorization can take place.
 +
* Challenge flow: The information was not sufficient, additional challenge is needed to make sure that the card is not stolen.
 +
 
 +
To achieve the frictionless flow the merchant has to provide as many information as possible about the purchase and the customer. This must be provided during the [[Payment-Start-v2-3DS|v2/payment/start]] API call. The properties marked as '''3DS''' must be specified. However there are scenarios where not all of this data is available. In these cases there are ways to indicate the lack of information. If the merchant does not provide the necessary data the payment will be most likely fall into the challenge flow. This should be avoided because it causes friction and may result in the customer leaving the payment.
 +
 
 +
Although providing this data enhances the possibility of the frictionless flow it does not make it certain. This decision is up to the card issuer, Barion does not influence it. In case of challenge flow the card issuer will provide a challenge screen that the customer must complete. This can be various things: one time password sent via text, secret password, etc.
 +
 
 +
=== Token payment with 3D Secure v2 ===
 +
 
 +
A token payment is a payment where the customer (the payer) is not redirected to the Barion Smart Gateway instead a previously created token is used to charge the customer. The second version of 3DS defines different scenarios for different token payments.
 +
 
 +
* '''Merchant Initiated Transaction''' is when the merchant initiates the payment without the customer being present on the merchant's website. This creates a subscription like behavior. In this scenario no 3DS authentication is required.
 +
* '''One Click Payment''' is when the merchant makes is available for the customer to purchase goods without using the Barion Smart Gateway to input the payment information again. In this case the customer is present at the time of the purchase. In this scenario the 3DS authentication is required.
  
=== How to achieve the frictionless flow ===
+
In case of '''One Click Payment''' the merchant has to reference JavaScript file provided by Barion on the checkout page.
  
[[File:Name-on-card.png]]
+
{{draft|text=TODO: Describe the One Click Payment process in detail }}

Latest revision as of 11:39, 14 August 2019

3DSecure


3D Secure (3DS, Three-Domain Secure) is a messaging protocol developed by EMVCo to provide a more secure online card payment process. It enables consumers to authenticate themselves with their card issuer when making card-not-present (CNP) e-commerce purchases. 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 (the bank or other institution that issued the card) not by the Barion system.

There are two major versions of the protocol:

  • 3D Secure 1 is a HTTP redirect based scenario where the customer almost always needs to provide some extra proof for the transaction. The verification is usually a password or SMS code.
  • 3D Secure 2 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. The card issuer may verify the shopper's identity using passive, biometric, and two-factor authentication approaches. According to the Strong Customer Authenticaton (SCA) rules of PSD2 RTS from 14th of September every card issued in the EU has to be authenticated with 3D Secure 2.

Card schemes will decommission 3D Secure 1 by 2020/2021, until that some card issuers will still support and require 3D Secure 1. At the same time we expect that by the PSD2 SCA compliance date, so by 14 September 2019, some EU card issuers may not be ready for 3D Secure 2 and still use 3D Secure 1 to comply with SCA.

IMPORTANT
If the shopper completes a 3DSecure authenticaton successfully, the liability shifts from the merchant to the card issuer in case of fraud.

Liability shift rules

If a merchant implements 3D Secure authentication, he/she can avoid the liability for chargebacks in case of fraud (e.g. chargeback claim because of lost or stolen cards). This is called a liability shift. In general if a shopper completes a 3D Secure challenge authentication flow succesfully, the liability for fraudulent chargebacks shifts from the merchant to the card issuer.

Transaction type Liability shift to card issuer?
3D Secure 1 transactions with challange. Yes
3D Secure 2 transactions with challange. Yes
3D Secure 2 transactions where card issuer applies a PSD2 exemption without the merchant requesting it. E.g. issuer TRA. Yes
3D Secure 2 PSD2 SCA out-of-scope transactions: shopper's issuer is outside of the EEA, anonymous prepaid cards up to 150€ or merchant initiated transactions. No
3D Secure 2 transactions where merchant or acquirer requests for a PSD2 exemption and the issuer grants an exemption. No

The payment process

The payment follows these steps:

  1. The shopper checks out from the merchant's website and decides to pay for the goods via Barion.
  2. Shopper is redirected to the Barion Smart Gateway.
  3. Shopper inputs card details and clicks the Pay button.
    --- Until this point nothing changed ---
  4. Barion checks whether the card the shopper used is a 3DSecure capable card and also the version the issuer supports. If the card is not 3DSecure capable, the card authorization (charge) goes along without any extra step.
  5. If the card is 3D Secure capable
    • with 3DSecure 1, the v1 flow will be started:
      1. an authentication screen is displayed for the shopper within the Barion UI
      2. the customer must complete the challenge displayed
      3. if the challenge is successful the payment process continues
    • with 3DSecure 2, 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

In case the card is protected with 3DSecure 1 the customer will be presented with a popup. This popup will show an extra authentication step that has to be completed in order to continue the payment.

3D Secure 2

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)

The card issuer receives this information package and calculates the risk of the transaction. The result of this calculation specifies the flow:

  • Frictionless flow: The customer will not be presented with any challenge screen, no more information needed, the authorization can take place.
  • Challenge flow: The information was not sufficient, additional challenge is needed to make sure that the card is not stolen.

To achieve the frictionless flow the merchant has to provide as many information as possible about the purchase and the customer. This must be provided during the v2/payment/start API call. The properties marked as 3DS must be specified. However there are scenarios where not all of this data is available. In these cases there are ways to indicate the lack of information. If the merchant does not provide the necessary data the payment will be most likely fall into the challenge flow. This should be avoided because it causes friction and may result in the customer leaving the payment.

Although providing this data enhances the possibility of the frictionless flow it does not make it certain. This decision is up to the card issuer, Barion does not influence it. In case of challenge flow the card issuer will provide a challenge screen that the customer must complete. This can be various things: one time password sent via text, secret password, etc.

Token payment with 3D Secure v2

A token payment is a payment where the customer (the payer) is not redirected to the Barion Smart Gateway instead a previously created token is used to charge the customer. The second version of 3DS defines different scenarios for different token payments.

  • Merchant Initiated Transaction is when the merchant initiates the payment without the customer being present on the merchant's website. This creates a subscription like behavior. In this scenario no 3DS authentication is required.
  • One Click Payment is when the merchant makes is available for the customer to purchase goods without using the Barion Smart Gateway to input the payment information again. In this case the customer is present at the time of the purchase. In this scenario the 3DS authentication is required.

In case of One Click Payment the merchant has to reference JavaScript file provided by Barion on the checkout page.

TODO: Describe the One Click Payment process in detail