5 - 3DSecure

3DSecure authentication is required when creating a virtual card in the latest version of Corporate payments. This is done to be in full compliance with the new Strong Customer Authentication (SCA) Regulatory Update that came into effect on October 30th 2020.

5.1 - Process

Overview

When creating a virtual number or updating virtual card expiration date, Valitor will perform a 0 amount authorization request. This request is used as the first transaction in a transaction chain between the merchant and the cardholder.
The 0 amount authorization must be a fully authenticated with 3DSecure to ensure the cardholder participation at the start of the business relationship between cardholder and merchant.

Info

It is only possible to create virtual card for a fully authenticated card.

All subsequent transactions done with the FaHeimild operation will have a reference to this first transaction through the 3DSecure virtual card number.

Info

Active existing virtual cards that were created before October 31th 2020 are still valid, they are not to be registered again in this version of Corporate Payments. Active virtual cards have received an authorization on merchant's agreement in the last 18 months before the change took effect.
If you are a merchant that is migrating to the 3DSecure version of Corporate Payments, then you will be able to use your active virtual numbers until their expiration. Please note that old cards registered after 31.October 2020 can still be used here but they are at a higher risk of rejection by card issuers sometime in the future since they do not contain a valid first transaction reference. Cards regisered before 31.October 2020 are exempt from this rule.

5.1.1 - Initiate authentication

  • To initiate authentication in Corporate Payments, the FaAudkenningu operation needs to be called.

    • Identify the merchant attempting to connect using the following parameters: 

      Notandanafn:    
Lykilord:   
Samningsnumer:  
SamningsKennitala:  
PosiID:

    • Identify whether a card number or a virtual number is to be used. When creating a virtual number, the actual card number is needed. When updating the expiration date, the virtual number is used.

    • If a card number is sent through FaAudkenningu (NotaKortnumer = 1), then it is forwarded directly to a 3DSecure MPI hosted by Valitor. When a virtual number is sent through FaAudkenningu (NotaKortnumer = 0), Corporate Payments will fetch the real card number behind the virtual number and forward that to a 3DSecure MPI hosted by Valitor.

    • Identify expiration date and the transaction currency to use in the authentication.

    • The type of the cardholder device must be identified in the parameter GerdTaekis.

      • Supported values: Website (0), phone app (1), digital tv software (4).

    • Identify the URL the cardholder is to be redirected to, upon successful authentication. Parameter: AudkenningTokstUrl

    • Identify the URL the cardholder is to be redirected to, upon failed authentication. Parameter: AudkenningMistokstUrl

    • The Dulkodun field can be used in two different ways, depending on how the merchant wants to store card data

      • To prevent merchant's storage of card data on personal web servers, it is recommended that the merchant sends in an encrypted string containing the card data (Card number/virtual number, expiration date, cvv) in the Dulkodun field. The encryption must use a key that only the merchant knows and is stored safely on the merchant web server.
      • If the merchant does not choose this method, then he needs to store the card data on his web server (in a database, session or with other methods). The merchant then needs to have some kind of a reference number that points to the data and send it using the Dulkodun field. The reference number is then returned to the AudkenningTokstUrl as the post parameter MD, and there the merchant can use the MD to point to the card data to create virtual number with FaSyndarkortnumer.

Warning

It is strictly forbidden to send in card data to the Dulkodun field without encryption.

5.1.2 - Finalizing authentication and create virtual number

The response from this operation is a HTML form that the merchant must execute in the cardholder browser using Javascript. The cardholder is then redirected to a Valitor website where he must enter a security code that he/she should have received concurrently via SMS.

If this process is successful, the cardholder is redirected back to the merchant web site (AudkenningTokstUrl), there the merchant needs to capture the following post parameters.

Parameter Description
MD Same value as was sent into the Dulkodun field in FaAudkenningu. We recommend that the merchant uses the Dulkodun field to send a encrypted string with the card data (card number/virtual number, expiration date, cvv).
cavv Cardholder Authentication Verification Value. A cryptogram representing the authentication itself.
xid Valitor reference number for the authentication.
mdStatus Possible values
0 = Not Authenticated, do not continue transaction
1 = Fully Authenticated, continue transaction
2,3,4 = authentication attempt, do not continue transaction.
5 = Gray area, do not continue transaction
6,7,8 = authentication failed, not possible to continue.
Even though Authentication is partially successful with mdStaatus is 2,3,4 or 5 it will not be possible to create a virtual card. Virtual cards must be created with a fully authenticated card.
dsTransId A globally unique identifier (GUID) that represents the directory server transaction id, required when merchant is enrolled in 3DS2.x

When the merchant has obtained the above data, FaSyndarkortnumer operation can be called.