SCA and 3DS 2
Introducing Strong Customer Authentication and 3DS 2
Strong Customer Authentication (SCA) is part of the PSD2 (Payment Services Directive) regulation in Europe. SCA aims to increase the security of electronic payments by requiring customers to authenticate themselves based on the use of elements categorized as knowledge (i.e. something only the user knows), possession (i.e. something only the user possesses) and inherence (i.e. something the user is).
One of the solutions for providing SCA, is 3DS 2 (also known as EMV 3D Secure). As the successor to 3DS 1, it has been designed to provide for a more secure and user-friendly authentication experience. With 3DS 2, data (such as device information) transmitted in the background is mostly enough to authenticate without an extra step for the customer. It’s only when the provided information does not suffice to determine the risk-level of the transaction that an extra authentication step may be required.
Where 3DS 1 Fell Short
In a 3DS 1 flow, you redirect the customer to an authentication page on their bank’s website, where they are prompted to enter a password associated with the card or a verification code sent to their phone. While it is a solid authentication step, this redirect flow is rather clunky (it’s not supported natively in app and in web flows) and is confusing to customers. As a result, legitimate customers drop out of the payment flow thereby impacting your acceptance rates and bottom line.
Exemptions to Strong Customer Authentication
There are circumstances in which you may want to exempt a user from an SCA flow. One example would be a merchant-initiated transaction (MIT) with a user’s stored card credentials (in which case the SCA flow has already been completed as part of the consent transaction). Other examples include transactions identified as low-risk or transactions with a low value.
Exempting users from an SCA flow is useful since it increases the chance that the transaction will proceed frictionless (that is, without an additional authentication step) and thus decreases user drop-outs. To exempt a user from an SCA flow, you may need to indicate your intention to do so in the Create Authorization or Create Charge request. Bear in mind that the decision of whether to grant the exemption lies with the card issuer. If granted, the chargeback liability shifts back to you (as the merchant).
Note
The provider you are transacting against may offer fraud protection services for analyzing a transaction’s risk level.3DS 2 Transaction Flows
When implementing a 3DS 2 transaction flow, you have three options to choose from:
-
The PaymentsOS 3D Secure Authentication service. This service is integrated into PaymentsOS and has been designed to handle the entire 3D secure authentication flow for you. Using the PaymentsOS 3D Secure Authentication service greatly simplifies the process of implementing a 3D secure flow and reduces your PCI scope. For more information and instructions on implementing the service, see 3D Secure Authentication service.
-
An external MPI for authorizing a card using 3DS 2. If you use an external MPI for handling the 3D secure authentication flow, then you simply pass the 3DS data returned from the external MPI in the
three_d_secure_attributes.external
object of a Create Authorization or Create Charge request.. -
A 3DS 2 flow as part of your PaymentsOS transaction flows. When choosing this option, you must pass all relevant information in the
three_d_secure_attributes.internal
object of a Create Authorization or Create Charge request. Depending on the provider you integrated with, you then either handle the remainder of the 3DS 2 authentication process yourself or let the provider handle it for you. See 3DS 2 Internal Transaction Flows below.
Note
If you use an external MPI (merchant plug-in) to authorize a card using 3D Secure, then you can pass the 3DS data returned from the MPI in theobject
object of a Create Authorization or Create Charge request. However, not all the providers you transact against may be able to receive this data. You should thus configure a route rule to direct the request to a provider that can process data received from an external 3DS service. For more information, see Routing Transactions to a Provider Supporting External 3DS.
3DS 2 Internal Transaction Flows
Rather than using the PaymentsOS 3D Secure Authentication service, you may also choose to implement a 3D secure flow yourself as part of your payment flows integrated with PaymentsOS. There are two types of 3DS 2 internal flows:
-
Self-handled. This flow is fully handled by you. See 3DS 2 Self-handled Flow.
-
Provider-handled. This flow is fully handled by the provider you integrated with. See 3DS 2 Provider-handled Flow.
Can I use either flow?
No. The type of flow you can use, depends on the provider you integrated with. To see whether a provider supports a specific flow type, first find the provider you’re looking for (you can filter on Transaction Type Cards and Features 3DS 2.0 Internal to find only those providers supporting a 3DS 2 Internal flow). Then open the relevant provider topic; the Notes column in the Features table will list the type of 3DS 2.0 Internal flow that is supported3DS 2 Self-handled Flow
In a 3DS self-handled flow, you must implement the 3DS flow logic yourself. There are three types of 3DS self-handled flows (the response received from the issuer following your initial Authorization or Charge request will determine the flow that you must invoke):
-
3DS data collection flow: In this flow, data (such as device information) transmitted in the background is enough to authenticate without an extra step for the customer.
-
3DS data collection and challenge flow: This flow is the complete 3DS flow. It is similar to the 3DS data collection flow but includes an additional authentication step (challenge) that will be invoked if the information provided in the data collection step does not suffice to determine the risk-level of the transaction.
-
3DS challenge only flow: In this flow, the customer is immediately redirected to an authentication step (challenge).
Notes
In some cases you may receive a synchronous response ofSucceed
or Failed
when invoking the initial Create Authorization or Create Charge request (for instance, if the transaction was exempted from SCA). In this case, proceed with a regular transaction flow.
Let’s take a look at each of those flows in more detail.
3DS Data Collection Flow
In this flow, device data is used to authenticate the customer. This flow is frictionless, in that authentication occurs under the hood and no extra authentication step is needed for the customer.
The following image illustrates the 3DS Data Collection flow:
The flow is as follows:
-
Create a new Authorization or Charge request.
In the
three_d_secure_attributes.internal
object, pass in additional information that will help the card issuer assess the fraud risk level of the transaction. The response will include aredirection
resource with anoperation_type
field whose value isdata_collection
, indicating that data collection is required. The authorization will have a status ofPending
. -
Initiate the data collection process and pass the data to the issuer, as explained in Initiating the Data Collection Process. Under the hood, a communication session will be opened to the issuer and the issuer will collect the browser or device information from the user. The device or browser information will be used in combination with the data passed in the
three_d_secure_attributes.internal
object to authorize the payment (see the next step). -
After receiving a notification from the card issuer indicating that the analysis of the user’s device or browser information has been completed, invoke the Continue Authentication Flow or Continue Charge Flow request to continue the authentication process.
Implementing a Timeout Check
We recommend you implement a 10 second timeout for obtaining the notification response. If a timeout occurs, invoke the Continue Authentication Flow or Continue Charge Flow request and pass athree_d_secure_attributes.internal.data_collection_completed_ind
value of N
.
- When authentication is completed, we will update the status of the Authorization or Charge request.
3DS Data Collection and Challenge Flow
This flow is the complete 3DS flow. It is similar to the 3DS data collection flow but includes an additional authentication step (challenge) that will be invoked if the information provided in the data collection step does not suffice to determine the risk-level of the transaction.
The following image illustrates the 3DS Data Collection and Challenge flow:
The flow is as follows:
-
Complete the 3DS data collection flow until step 3. The response of this step will indicate that a challenge is required and will include a challenge URL.
-
Open the challenge URL to allow the user to complete the additional authentication step. After the user completed the step, we will redirect the user to the
merchant_site_url
.
3DS Challenge Only Flow
In this flow, the customer is immediately redirected to an authentication step (challenge).
The following image illustrates the 3DS Challenge Only flow:
The steps in the flow are as follows:
-
Create a new Create Authorization or Create Charge request. In the
three_d_secure_attributes.internal
object, pass in additional information that will help the card issuer assess the fraud risk level of the transaction. Also pass in amerchant_site_url
, to which the user will be redirected when authentication is completed. The response will indicate that a challenge is required and will include a challenge URL. The authorization will have a status ofPending
. -
Open the challenge URL to allow the user to complete the additional authentication step. After the user completed the step, we will redirect the user to the
merchant_site_url
.
3DS 2 Provider-handled Flow
A 3DS Provider-handled Flow is a 3DS flow handled in full by PaymentsOS and the provider that you transact against. All you need to do is supply enough information to help the card issuer assess the fraud risk level of the transaction. The provider will then handle all the remaining 3D Secure steps, such as collecting device information for constructing a fingerprint or redirecting the user to a challenge step (if needed).
Note
No. This flow is supported by specific providers only. To see whether a provider supports a specific flow type, first find the provider you’re looking for (you can filter on Transaction Type Cards and Features 3DS 2.0 Internal to find only those providers supporting a 3DS 2 Internal flow). Then open the relevant provider topic; the Notes column in the Features table will list the type of 3DS 2.0 Internal flow that is supported.The following image illustrates the 3DS 2 provider-handled Flow:
The steps in the flow are as follows:
-
Create a new Authorization or Charge request. In the
three_d_secure_attributes.internal
object, pass in additional information that will help the card issuer assess the fraud risk level of the transaction. Also pass in amerchant_site_url
, to which the user will be redirected when authentication is completed.The response will indicate that a redirect is required and will include a redirection URL. The authorization will have a status of pending.
-
Open the redirection URL to allow the provider to handle the 3DS flow.
After the provider completed the 3DS flow, we will redirect the user to the merchant_site_url
.
Initiating the Data Collection Process
To initiate the data collection process do the following:
-
Create a JSON object holding a
threeDSMethodNotificationURL
field (this is your notification URL to which the issuer will send the completion status of the data collection process) and athreeDSServerTransID
field (this is the 3DS transaction ID you receive in theprovider_data.three_d_secure_result.internal.three_d_secure_server_transaction_id
field returned in the response of a Create Authorization or Create Charge request).{ "threeDSMethodNotificationURL": "http://urlforreceivingapproval", "threeDSServerTransID": "4c9a869e-2e75-4b1b-9bc4-3635edbb5973" }
-
Format the object using Base64 encoding.
-
Render a hidden HTML iframe in the cardholder’s browser containing a form with a field named
threeDSMethodData
. Store the Base64url JSON Object in the field and send the form via HTTP POST to the redirection URL received in theredirection.url
field in the response of the Create Authorization or Create Charge request.
Setup and Configuration Considerations
When implementing your 3DS 2 flow, you should take the following into account:
-
PaymentsOS may not yet a support 3DS 2 flow with all providers. We thus strongly recommend you configure routing rules in your PaymentsOS account to route payments to a provider supporting 3DS 2 authentication. Refer to the relevant provider guide to determine whether 3DS 2 is supported.
-
There may be some additional fields (such as billing and shipping address) in a Create Payment request that are required for a 3DS flow.
3DS 2.0 API Fields
See the three_d_secure_attributes.external
and three_d_secure_attributes.internal
object fields in the Create Authorization or Create Charge request, for an overview of the fields you can pass in an external or internal 3DS 2 flow.
Note that there may be some existing fields (such as billing and shipping address) and additional fields in a Create Payment request that are required for a 3DS flow. There may also be additional provider-specific fields that you will need to pass in a Create Authorize or Create Charge request.
SCA Enforcement Timelines
While SCA requirements are scheduled to go into full effect on 14 September 2019, some countries have released official statements following the European Banking Authority published opinion, which discusses an extension for SCA implementation for eCommerce and card payments. Here is a breakdown of the different European countries and their statements:
Country | Statement |
---|---|
Austria | Austria announced a temporary enforcement extension for Austrian cards. The enforcement should go into full effect by the end of September. |
Belgium | The Belgian regulator released a formal announcement setting out the Bank's expectations regarding the regulatory technical standard for SCA of online payments. No set timeline has been published as of now. |
Denmark | Denmark released an official announcement of an 18 month extension period for SCA. The FSA emphasized that the implementation period will not change the fact that the rules on strong customer authentication will enter into force on 14 September 2019. |
Finland | Finland announced a temporary enforcement extension for Finnish cards. The Financial Supervisory Authority will decide on the length of the transitional period this year after further consulting with the supervisors of other Member States. |
France | The French are also working on a phased implementation plan, and have released an official document breaking down their current status and plans ahead. |
Germany | Payment service providers based in Germany are allowed to make credit card payments on the Internet from September 14, 2019 initially without strong customer authentication. BaFin estimates that the card-issuing payment service providers in Germany are prepared for the new requirements, while companies that use credit card payments on the internet as payees might not be fully prepared yet. |
Ireland | Ireland released an announcement stating a migration period limited only to eCommerce transactions. Therefore no disruption to payments systems is anticipated. |
Italy | The Italian regulators also released an announcement stating a transitional migration period, although its length of delay has not yet been officially confirmed. |
Luxembourg | The Luxembourg regulator announced a temporary enforcement extension for Luxembourg cards. The financial institutions that wish to make use of the extension period are required to inform the CSSF and back their request with a proper migration plan and timelines. |
The Netherlands | The DNB (De Nederlandsche Bank) has released the regulator's intention to allow parties that were unable to prepare for SCA (for credit card transactions) a limited extension time - the amount of time hasn't been stated. |
Norway | The Norwegian regulator also announced a temporary enforcement extension for eCommerce and card payments. The payment service providers who need to extend their deadline are requested to contact the Financial Supervisory Authority. |
Poland | The Polish regulator also announced an extension for Polish cards, contactless payments, and eCommerce. A proper migration plan will need to be submitted by the relevant parties in order to benefit. |
Slovenia | Since the authentication of the majority of card payments made in online stores in Slovenia (and the wider EU) is currently protected only by a one-time password received via a text message, such method of authentication does not meet the requirements of SCA. To ensure compliance, the Bank of Slovenia allows an extension for Slovenian payment providers with registered office in Slovenia beyond the deadline of 14 September. |
Sweden | The Swedish regulator also published an announcement that allows extension beyond 14 September for SCA. The extension applies for eCommerce transactions made with card payment. A submission of a detailed plan will have to be submitted and should include the company's planned communication activities to inform e-merchants and payment service users about the new conditions. |
UK | The UK regulator announced a transitional 18 month period for SCA implementation on online card payments. |
What should you do as a merchant?
As you can see from the above, the enforcement of SCA in Europe will be gradual and the majority of regulators will allow merchants an extension period for card payments and eCommerce (please check your country’s specific requirements). Since there is still some obscurity regarding the exact extension time and implications, we recommend that you make all of the necessary arrangements to be compliant on time (i.e. 14 September 2019). Learn more about it here.