SCA

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).

Strong customer authentication


Important notice:
The new SCA parameters are not yet activated in the D2 platform, you can plan for the upcoming regulation but will not be able to test functionality of the new SCA parameters. Information will be sent to you when the SCA parameters are possible to use and test.
 

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:

How to implement

Do you use Hosted Payment Window with the scenario 1, 2, 3, 4A or 5A, then click on this standard parameter overview to read more about COF, mitType and ticket.

If you are a merchant from example 1, 2, 3, 4A or 5A and use API then click here: 3dsecure.cgi and read how to enable COF, mitType and ticket for your webshop.
If you are a merchant from example 4B or 5B click here:  ticket_auth.cgi and read how to enable this for your webshop.

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.

Stored Credentials – Use case of mitType and COF

To bring the concepts of parameter “mitType” into a practical business perspective below use case describes the concepts in a real-world scenario.

Initial commitment from new customer - Pay-as-you-go Plan (mitType=Recurring)

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. As there is no monthly fee for having the pay-as-you-go plan, the amount Carlos must charge will always vary based on Hans’ usage. Carlos takes payment for the creation of the plan and makes sure that the "mitType” parameter is set to “RECURRING”, to make it possible to use the credit card for later billing. As the customer, Hans, initiates the transaction, 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 ticket from the initial transaction, to charge the variable amount. The amount is sometimes 5€, sometimes 15€ and others 10€. Carlos uses ticket_auth.cgi to with process the future payments. 

Transactions

Transactions
Initiator
SCA required
mitType
Initial payment of creation fee Cardholder yes mitType=RECURRING
Repeated payment according to usage Merchant No ticket_auth.cgi

 

Top up of user account (mitType: UCOF)

Carlos company introduce a new payment plan. The plan introduce the possibility for Carlos’ customers pay in credit which an automated functionality ensuring that the balance on the credit account never goes below 20€ or above 100€ . Christian is a new customer and think’s this plan would be a perfect plan for this cellular phone usage and decides to sign up for the new plan. Now, every time Christians credit goes below 20€, he can automatically top up this account to 100€. The automatic system sets the mitType=UCOF and charges X € and unscheduled time intervals. 

Transactions

Transactions
Initiator
SCA required
mitType
Initial payment of Topupfee fee Cardholder yes mitType=UCOF
Repeated payment according to usage Merchant No ticket_auth.cgi

 

One-click purchases (COF)

Carlos has a webshop selling T-Shirts. Donald would like to purchase a nice T-Shirt. He selects the correct size and proceeds to checkout. Donald enters creditcard information. At the website there is a question: “Would you like register and store your creditcard for later usage?” Donald registres, tick the checkbox and complete the purchase – including SCA.

A month later Donalds returns to buy a T-Shirt. He enters his login credentials and selects and new T-Shirt. During checkout the Flexwin payment window is displayed. Donalds recognizes his creditcard (prefix), enters CVC and click “Accept Payment”. SCA is now required on the transactions. Donald completes the payment

Transactions

Transactions
Initiator
SCA required
mitType
Initial payment of T-shirt Cardholder yes COF=Yes
Repeated payment  Cardholder Yes Flexwin with ticket

 

Repeated payment / Flexwin with ticket is done by sending the ticket parameter to the Flexwin Payment window. See 'ticket' parameter here: https://tech.dibspayment.com/D2/Hosted/Input_parameters/Standard

Example of Flexwin post

<form method="post" action="https://payment.architrade.com/paymentweb/start.action" accept-charset="utf-8">
        <input type="hidden" name="accepturl" value="https://www.yourdomain.com/payment_accepted">
        <input type="hidden" name="amount" value="100">
        <input type="hidden" name="currency" value="DKK">
        <input type="hidden" name="merchant" value="Merchant ID">
        <input type="hidden" name="orderid" value="Order_ID-123">
        <input type="hidden" name="calcFee" value="yes">
        <input type="hidden" name="ticket" value="INSERT_TICKET_ID_FROM_INITIAL_TRANSACTION">
        <input type="submit" name="pay" value="pay">
</form>

Flexwin is then displayed with cardholder masked credit card and expiry date.

(Note: we are currently discussing if CVC should be removed from the payment window - for later payments)

 

Do you have a question or need help?
Follow us
DIBS Payment Services
Stockholm +46 (0)8-527 525 00
Göteborg +46 031-600 800
København +45 7020 3077
Oslo +47 21 55 44 00
Close menu