SCA

Important notice:
For questions regarding how to manage preexisting card registrations and future transactions please contact your acquirer.

On September 14, 2019, a new requirement for all online payments is being introduced in the EU, stating that all transactions (with certain exceptions) should be verified by the consumer.

The change is part of an initiative to harmonize European payments and ensure consumers are protected. This requirement is known as SCA - Strong Customer Authentication – and is part of the EU regulation called PSD2 (Payment Service Directive 2).

What does Strong Customer Authentication (SCA) mean for E-commerce?
An electronic transaction will be defined as having gone through Strong Customer Authentication if at least two of the following three factors have been provided by the consumer:

If you need technical guidelines, please follow these four API links: 

• https://tech.dibspayment.com/DT/API/WebService/authorize
• https://tech.dibspayment.com/DT/API/WebService/authorizeAndSettle
• https://tech.dibspayment.com/DT/API/WebService/subscribe
• https://tech.dibspayment.com/DT/API/WebService/authorizeAndSettle3DS

Why is this important?
This is important because the Payment Services Directive 2 (PSD2) is a regulatory demand in the EU, as of the 14th September 2019. More importantly, PSD2 dictates that all remote electronic transactions must have Strong Customer Authentication (SCA). This includes E-commerce transactions, which might be rejected by Card Issuers if SCA requirements are not complied with.

How to ensure Strong Customer Authentication on my Card transactions?
In order to ensure Strong Customer Authentication on all of your transactions, you need to activate and send transactions through the SCA protocol that is attached to Card schemes that consumers pay with today (e.g. Visa and Mastercard). For Visa and Mastercard the SCA protocol is called 3D Secure, which you may already be familiar with. In the 3D Secure process, the consumer is often requested to perform an action to confirm that they are making the transaction. This action is the SCA element in the payment process, for example, a consumer may be asked to enter a password that is sent to their phone.

Changes to DT Webservice API

This chapter describes changes to the DT Webservice API.

You can find a full description of the Webservice API here:

https://tech.dibspayment.com/DT/API/WebService

The change consists of a new parameter: recurringType. The change does not require changing endpoint or schema version, since the new parameter must be part of the existing parameter: extra.

The parameter should be added according to the guidelines on the Tech Site. 

Example: recurringType=merchantStored

New parameter “recurringType”

This new parameter determines the intent of an Authorize and the usage of Subscribe.

Subscribe
Currently Subscribe is used for recurring and Stored Credential transactions and this will not change. The parameter “recurringType” is a way for both the card provider and DIBS to distinguish between the two kinds of transactions.

For Subscribe the recurringType parameter has 3 possible values: "merchantStored", "cardholderStored" and "recurring" as shown in the table below.

"recurring" marks the Subscribe transaction as a recurring transaction. Later regulation might introduce a specific amount and/or interval with which calls to this must be made. "merchantStored" and "cardholderStored" are based around Stored Credentials and describe who started the given transaction, be it the merchant or the cardholder.

Authorize
For Authorize the recurringType parameter has 3 possible values: “single”, “initialStored” and “initialRecurring”.

For merchants not using the Subscribe functionality, the change to authorize is simple – recurringType  should always be set to the value "single", indicating that this transaction will never be used as a basis for Subscribe. 

For merchants using the Subscribe functionality, the recurringType determines what a given Authorize authorizes. If Authorize is to be used as a basis for Subscribe, then one of the values "initialRecurring" or "initialStored" is required. If, on the other hand, the VerifyID returned by the Authorize function will never be used in a Subscribe context, the value "single" is the value to choose, as mentioned earlier. 

If an Authorize is made with "initialStored" then it can be used as a basis for a Subscribe with the recurringType parameter set to either "merchantStored" or "cardholderStored", but it cannot be used for a Subscribe with the recurringType parameter set to “recurring”. If "initialRecurring" is used, then "recurring" is also a valid value for recurringType parameter when using Subscribe.  The table below shows the connection between value of reccuringType parameter for the Authorize and the possible values for a subsequent Subscribe.

Considerations before using recurringType

For most acquirers you will need an agreement before using recurringType since part of this rollout is a change that could impact the use of Subscribe, if used without an agreement with acquires that require one.

We therefore urge all merchants that uses subscribe to ensure that they have an active agreement with the acquirers that allow for Stored Credentials and recurring transactions.

As mentioned, the changes regarding recurringType will come into effect on the date stated earlier. But it is very important to state that if you start using recurringType towards a specific acquirer between the date of the release of the changes from DIBS and the date of entry of force it will come into effect immediately from that moment on, on that specific acquirer.

Strong Customer Authentication - 3DS

As SCA is required on all Cardholder initiated transactions, the endpoint “askIf3DSEnrolled” needs to be used. 

When merchants subsequently call subscribe (WebService) with reccurringType=cardholderStored in the extra fields they need to provide the paRes=<paRes> in the extra fields.

For merchants unaccustomed to handle 3DS: See information about 3DS https://tech.dibspayment.com/DT/API/3d-secure_guide.

Overview

To recap, the overview in the table below shows the possible values of the new parameter, recurringType, and the connection between values used on Authorization and possible values on subsequent Subscribes.

The overview also shows where SCA is required, namely on all cardholder-initiated transactions. 

Stored Credentials – Use case

To bring the concepts of recurringType into a practical business perspective this use case describes the concepts in a real-world scenario.

Initial commitment from new customer - Pay-as-you-go Plan

Carlos has a telecommunication company. He provides his customers with cellular plans of different types. 
Hans is a new customer at Carlos’ company. He has his eye set on a pay-as-you-go plan, where everything from calls to data is billed by the minute on a bi-weekly basis. Carlos is happy to provide Hans with such a plan. He wants to store Hans’ credit card information, in order to make it possible to charge Hans easily. Carlos takes payment for the creation of the plan and, as the amount Carlos must charge bi-weekly will vary based on Hans’ usage, he makes sure that the recurringType parameter is set to “initialRecurring”. This way it is possible to use Hans’ credit card for later billing. Since the initiator of the transaction is the customer, Hans, it is a Cardholder initiated transaction and it must go through SCA.

Every two weeks when Carlos wants to bill Hans for the data and minutes used, he uses the Subscribe method and sets recurringType to “recurring”. He also provides the VerifyID from the initial transaction. Using the recurringType value “recurring”, Carlos indicates that the transaction is made on the basis of an agreement with Hans that allows Carlos to make new transactions on a regular basis using Hans Stored Credentials, without the need for customer involvement at the time of execution.

Transactions (recurring)

*The 2nd transaction is inititated by the Merchant, under the exemption: recurring 

New purchase by existing customer - buy more minutes

Three weeks later, Hans is on a business trip. He realizes that he is going to be on his phone a lot over the next couple of days, so he wants to buy a pack of minutes. Carlos’ company has a webpage where Hans can log in and buy minutes. Hans logs in, and because he has an active plan, he doesn’t need to punch in his credit card information. The online system uses the same Stored Credentials as the plan does, and charges Hans’ credit card directly. It sets the recurringType to “cardholderStored”, to indicate that this is a transaction that Hans himself has started. And since this is a transaction initiated by Hans, the cardholder, it requires SCA.

Transactions (cardholderStored)

Changing to recurring flat-rate payment

Six months later Hans has realized that he uses a lot more minutes than expected, so he wants a plan with flat-rate, unlimited minutes and variable data. Carlos has a plan where Hans will pay €5 a month plus a variable amount according the data Hans uses. Carlos collects a fee for changing the plan. He must create a new transaction, as the old plan was made with a different intend – to pay a variable amount. Carlos needs to use the “recurring” for future payments of the new plan. He has Hans provide his credit card number again, just like he did when they set up his first plan. Carlos makes sure to set recurringType to “initialRecurring” on the transaction.
Now, every month, Carlos can automatically charge his €5 plus an amount according to how much data Hans has used. The automatic system sets the recurringType to “recurring” and charges this set amount on a regular interval. 

*The ongoing payments of data usage uses the Stored Credentials from the initial agreement with Hans

Top up of user account

One year later, Carlos’ company introduces a new payment plan. The Plan works by charging the customer initially a certain amount of €100, the customer’s credit. Whenever the customer’s credit goes below €20, the customer is charged another €100. Hans thinks this plan would be a perfect plan for his cellular phone usage and decides to sign up for the new plan. Hans enters Carlos’ website to switch his plan. Since this is a new agreement, which is not recurring since the interval Carlo’s will charge Hans is variable depending on when Hans’ credit goes below €20, Carlos and Hans must enter a new contract. However, Carlos is still allowed to use Hans’ Stored Credentials so Hans will not have to reenter his Credit Card information – but since the new agreement is initiated by Hans, the Cardholder, it requires SCA. Carlos authorizes the new contract using Authorize and recurringType parameter set to “initialStored”. 

Now, every time Hans’ credit goes below €20, Carlos can automatically top up Hans’s credit to €100 by using the Subscribe method with recurringType "merchantStored" under the UCoF exemption. 

Transactions (merchantStored)

*The repeated payment does not require SCA, as it is now based on the previously authenticated agreement between Carlos and Hans as described above, using the UCoF exemption

Changes to DT Payment Window

For merchants who use DIBS’s payment window there will be changes regarding how the window is called and how to subsequently call Subscribe. You can find a full description of the Payment Window here: https://tech.dibspayment.com/dt/pw2/input_parameters The new rules according to PSD2 (Revised Payment Service Directive) dictates that the intent of an agreement between the cardholder and merchant shall be stated at the time of creation. Transactions are either initiated by the cardholder - such transactions are named CIT for Cardholder Initiated Transactions – or initiated by the merchant – such transactions are name MIT for Merchant Initiated Transactions. For DIBS’s hosted payment window this means that the merchant must send in a new parameter in the URL that calls the payment window – and a new parameter in any subsequent calls to Subscribe through the API.

New parameter “recurringType”

This new parameter determines the intent of the usage of Authorize when performing a transaction between the cardholder and merchant. Furthermore, it determines the allowed usage of subsequent calls to Subscribe. The table below shows which “recurringType” value to use depending on the merchant’s intent of the initial transaction.

* As an exemption to a recurring transaction agreement the merchant can actually perform an unscheduled transaction using a so called UCOF (Unscheduled “Card On File” or COF). The merchant must use the “recurringType” “merchantStored” when calling Subscribe for a UCOF.

CIT/COF Transaction in DT PaymentWindow

In order to do a CIT/COF transaction in the PaymentWindow the merchants needs to provide three additional/changed parameters:

- recurringType: cardholderStored.
- verifyID: The DIBS transactionID of the original transaction (having recurringType initialStored).
- MAC: A special generated MAC including the verifyID given above.

How to generate the MAC

When dibs are checking the MAC key for the CIT/COF transactions we append the given verifyID to the active MAC order key:

Assume that the active MAC order key is:

data&currency&method&SecretKey&referenceNo&

Then we will expect a MAC generated from the following MAC order key:

data&currency&method&SecretKey&referenceNo&verifyID&

Note that the MAC for other transaction remains unchanged.