3DSecure: Difference between revisions

From Barion Documentation
Jump to navigation Jump to search
No edit summary
No edit summary
 
(53 intermediate revisions by 5 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. {{draft|text=TODO: Describe the legislative restrictions. }}
If the card is enrolled into 3DS authentication additional information is required to decide whether the purchase is fraudulent or not. There are two different versions of the protocol:
* '''3D Secure 1. version''' {{draft|text= TODO: Describe the v1 process in a few words}}.


* '''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 ([https://en.wikipedia.org/wiki/3-D_Secure|3DS, Three-Domain Secure]) is a messaging protocol developed by [https://www.emvco.com EMVCo] that provides 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 issuer (the bank or other institution that issued the card), not by the Barion system.  


This decision is made by the card's issuer (in most cases the bank that issued the card) not by the Barion system. Barion does not have any
There are two major versions of the protocol:
* '''3D Secure 1''' is an 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. Card schemes decommissioned 3D Secure 1 in 2021/2022. Barion does not support this old protocol.


{{draft|text=TODO: Describe the deadlines and project milestones, when will what be available. }}
* '''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 Authentication (SCA) rules of PSD2 RTS] every card issued in the EU has to be authenticated. 3D Secure 2 complies with the regulation.
 
{{NotificationBox|title=IMPORTANT|text=If the shopper completes a 3DSecure authentication 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, they can avoid liability for chargebacks in case of fraud (that is, chargeback claims because of lost or stolen cards). This is called a liability shift.
In general, if a shopper completes a 3D Secure challenge authentication flow successfully, the liability for fraudulent chargebacks shifts from the merchant to the card issuer.
 
{| class="wikitable"
|-
!Transaction type
!Liability shift to card issuer?
 
|-
|3D Secure 2 transactions with challenge.||style="text-align:center;" |Yes
 
|-
|3D Secure 2 transactions where '''card issuer applies a PSD2 exemption''' without the merchant requesting it. For example, 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.
# You check out your purchase from the merchant's website and select to pay via Barion.
# Customer is redirected to the Barion Smart Gateway.
# You are redirected to the Barion Smart Gateway.
# Customer inputs it's card information and clicks the ''Pay'' button. <br/>--- Until this point nothing changed ---
# You input your card details and click '''Pay'''.  
# 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 you 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 steps.  
# If the card is protected
# If the card is 3D Secure capable with 3DSecure 2, the flow changes:
#* with 3DS authentication v1.0, the v1 flow will be started:
#*# Barion starts the 3DS authentication in the background and sends the relevant information about the purchase to the card issuer. From this information, the issuer decides whether the payment is secure or if you should be challenged in some form.
#*# {{draft|text= TODO: Describe the v1 process steps}}
#*# If the result is that you '''should not be challenged''' (this is the frictionless flow) your card is charged and the payment flow continues.
#* with 3DS authentication v2.0, the v2 flow will be started:
#*# If the result is that the issuer '''needs more proof''' from you, a popup window is displayed. In this window, the issuer displays ''something'' for you. The content varies according to the issuer, and it allows you to provide proof (SMS, token, question).
#*# 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.
#*# After you successfully complete the challenge, the card is authenticated and the payment flow continues with the authorization of the card. The card can still be declined after successful 3DS authentication.
#*# 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.
# At the end of the payment you are redirected to the merchant's website.
#*# 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).
 
#*# 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.
== 3D Secure 2 ==
 
The reason behind the second version was to provide a way to achieve the same level of security for 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, and so on)
* customer's browser information (screen size, timezone, language, and so on)
* 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, and so on)


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 is not presented with any challenge screen, no more information is needed, and authorization can take place.
* Challenge flow: The information is not sufficient, an additional challenge is needed to make sure that the card is not stolen.


== 3D Secure 1.0 ==
<div>
{{draft|text= TODO: Describe the process}}
To achieve the frictionless flow the merchant has to provide as much 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 {{3dsfield}} 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 typically falls into the challenge flow. Ideally, we should avoid this as it causes friction and may result in the customer leaving the payment.
</div>


Although providing this data enhances the possibility of 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 provides a challenge screen that the customer must complete. This can be various things: one-time passwords sent via text, secret passwords, biometric identification, and so on.


The second version of the protocol is meant to address the friction in the flow
== Known issues ==
* If the user is challenged, additional user interaction is required, which results in increased abandonment. We recommend the following to reduce the churn:
** Send all available fields marked with the {{3dsfield}} badge in the [[Payment-Start-v2|PaymentStart]] request.
** Request [[ChallengePreference|TRA]] exemption. <br /> '''Note''': If you apply for this option, you are held liable in case of fraud.


[[File:Name-on-card.png]]
== Additional resources ==
*[[Token_payment_3D_Secure|3DSecure Token payment]]
*[[3DS_FAQ|3DSecure FAQ]]

Latest revision as of 13:45, 13 March 2024

3DSecure


3D Secure (Three-Domain Secure) is a messaging protocol developed by EMVCo that provides 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 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 an 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. Card schemes decommissioned 3D Secure 1 in 2021/2022. Barion does not support this old protocol.
  • 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 Authentication (SCA) rules of PSD2 RTS every card issued in the EU has to be authenticated. 3D Secure 2 complies with the regulation.
IMPORTANT
If the shopper completes a 3DSecure authentication 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, they can avoid liability for chargebacks in case of fraud (that is, chargeback claims because of lost or stolen cards). This is called a liability shift. In general, if a shopper completes a 3D Secure challenge authentication flow successfully, the liability for fraudulent chargebacks shifts from the merchant to the card issuer.

Transaction type Liability shift to card issuer?
3D Secure 2 transactions with challenge. Yes
3D Secure 2 transactions where card issuer applies a PSD2 exemption without the merchant requesting it. For example, 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. You check out your purchase from the merchant's website and select to pay via Barion.
  2. You are redirected to the Barion Smart Gateway.
  3. You input your card details and click Pay.
  4. Barion checks whether the card you 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 steps.
  5. If the card is 3D Secure capable with 3DSecure 2, the flow changes:
      1. Barion starts the 3DS authentication in the background and sends the relevant information about the purchase to the card issuer. From this information, the issuer decides whether the payment is secure or if you should be challenged in some form.
      2. If the result is that you should not be challenged (this is the frictionless flow) your card is charged and the payment flow continues.
      3. If the result is that the issuer needs more proof from you, a popup window is displayed. In this window, the issuer displays something for you. The content varies according to the issuer, and it allows you to provide proof (SMS, token, question).
      4. After you successfully complete the challenge, the card is authenticated and the payment flow continues with the authorization of the card. The card can still be declined after successful 3DS authentication.
  6. At the end of the payment you are redirected to the merchant's website.

3D Secure 2

The reason behind the second version was to provide a way to achieve the same level of security for 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, and so on)
  • customer's browser information (screen size, timezone, language, and so on)
  • 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, and so on)

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 is not presented with any challenge screen, no more information is needed, and authorization can take place.
  • Challenge flow: The information is not sufficient, an additional challenge is needed to make sure that the card is not stolen.
To achieve the frictionless flow the merchant has to provide as much 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 typically falls into the challenge flow. Ideally, we should avoid this as it causes friction and may result in the customer leaving the payment.

Although providing this data enhances the possibility of 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 provides a challenge screen that the customer must complete. This can be various things: one-time passwords sent via text, secret passwords, biometric identification, and so on.

Known issues

  • If the user is challenged, additional user interaction is required, which results in increased abandonment. We recommend the following to reduce the churn:
    • Send all available fields marked with the
      3DS
      badge in the PaymentStart request.
    • Request TRA exemption.
      Note: If you apply for this option, you are held liable in case of fraud.

Additional resources