3D Secure

3D secure 2 is the latest standard released by EMVCo that allows merchants and payment service providers to send additional data elements to the issuing bank of the cardholder, which in turn, makes it possible for the issuer of the card to perform frictionless authentication and offer an improved, better, user experience to the cardholder. With the additional data elements relating to the cardholder, issuers can apply Frictionless Authentication flows or “Challenged” authentication flows.

Frictionless Authentication Flows:  issuers can apply risk-based decisions using the additional data received and trust that the real cardholder is making the purchase and auto authenticate the transaction in the background without requesting any additional information from the cardholder.

Challenged Authentication Flows:  When the issuer cannot apply risk-based decision using the data on record, additional information to authenticate the payment is then requested from the cardholder.

• Verified by VISA (VbV),
• SecureCode by Mastercard, 
• SafeKey by American Express, 
• UPOP by UPI
• Protect Buy by Diners
  
  

Merchant Benefits

• Acceptance of authenticated transactions via 3D secure deters unauthorized card use.
• Enables the merchants to receive protection, liability shift from fraudulent chargeback activity

Integrate 3D Secure

Merchants can integrated 3D secure via iVeri Gateway or use their own 3D secure vendor( MPI) both models integration models are supported.

Integrate 3D Secure functions via the iVeri Gateway

• Implement a form post or pop-up with the required data 
• When received, the Gateway will process and handle the enrollment lookups, authentication with the 3DS provider on your behalf. 
• On completion, of the authentication, the merchant can submit payment instructions with 3DS 2 authentication data
  
  

Integrate 3D Secure directly with the 3DSecure MPI vendor 

• Contact your 3D secure Vendor
• Integrate the 3D secure using the 3D secure integration specification from the MPI/3D Secure  vendor
• On completion of the 3D secure process, merchants, or payment service provider (PSP) can include 3D secure authentication data on the payment instructions to the iVeri Gateway.
• When received, the Gateway will process the payment to the appropriate acquiring institution.

Integration Prerequisites 

• Merchant must request a certificate in the merchant portal -  Backoffice.
• • The generated certificate ID is only applicable on the Authorisation/Debit message not the 3DS process.
• The merchants application ID must be enabled for 3DS 2
• Merchant Profile 
• • A merchants test application ID must be enabled for 3DS 2. Contact iVeri support on assist@iveri.com to enable 3D secure. 
  • Integration testing using should use the test application and corresponding  3D secure test cards

3DS 2 Endpoint 

Merchants implementing 3D secure through the iVeri Gateway can submit their 3DS requests to the following endpoints 

Integration Method

Implementation of 3DS 2 to the iVeri Gateway can be done by either using as a form Post or Pop-up

3D Secure Process

1. Initiate 3D secure - Submit 3D secure request in a Form POST  or Pop-Up method
2. 1. Post request on /threedsecure/EnrollmentInitial
   2. The iVeri Gateway act as proxy and submits the 3D secure request to the 3DS MPI onbehalf of the merchant 
   3. 3D secure MPI returns the status to the iVeri Gateway 
3. Handle 3D secure result - iVeri Gateway posts the status of the 3D secure authentication to the merchant ReturnURL
4. Proceed or Cancel transaction - If all mandatory 3D Secure parameters are present and the returned status code is “0”, the merchant should continue with the Authorisation/Debit instruction. If not, the transaction must be terminated

3DS 2 Parameters

Merchants can submit 3DS request parameters using either tokenized data or full PAN information.

Using tokenized data implies that the merchant has obtained and retained the token via PANToken command.

To refer to the 3D secure parameters see more info 

Request Parameters

The following is a list of parameters that can be included in the 3D secure requests to the 3DS endpoint.

Output Parameters that may be returned

Depending on the result of 3D secure authentication, the following fields may be returned

3D Secure 2 implementation using the Pop-Up Method

Mandatory Requirements

• jQuery 
• Bootstrap 

Step1:  Initialize the popup   

Include the following javascript code on your webpage that you want to initiate 3DS from:

Step2:  Load the popup and shows the modal dialog  

Step 3:  Gets the response back after 3D 2 Completes

3D Secure 2 implementation using the Form Post

Merchants can POST form variables to the 3DS2 endpoint, which is accessed via a browser redirect. Once the 3D Secure process is completed, the Gateway returns the result to the merchant’s ReturnURL. The result provided will determine whether the merchant can continue with the authorisation/debit instruction or if the transaction should be terminated

Format: Form Data

Form Post request Sample

Authorisation/Debit with 3DS 2 Data

Merchants have the choice of doing 3D secure authentication directly with their 3DS Vendor ("MPI")  or via the iVeri Gateway. In any event, when the 3D secure authentication process is completed successfully, the merchant can POST the payment instruction to the iVeri Gateway with the authentication data using the SOAP or REST webservice. 

Debit/Authorisation Payment Parameters

The applicable set of 3DS 2 parameters expected in the Authorisation/Debit message are as follows:

Webservice Service Payment Samples

For submission of transactions to the Gateway the merchant can post to the existing Portal URL's . The Portal URL's are listed in the  REST and SOAP sections by acquiring bank. As a note, the submission of the Debit/Authorisation message assumes the following:

• 3DS 2 authentication was a success.
• The merchant is making use of the test application ID with mode "Test" for integration testing 

REST Webservice

Format: JSON

Transaction Endpoint - https://[portal domain]/api/transactions

SOAP Webservice

Format: XML

Transaction Endpoint - https://[portal domain] /iVeriWebservice/Service.asmx

3D Secure 2 Test Cases

The MPI test cases that should be used are determined by the acquiring bank that holds the merchant agreement or PSP that will be processing the payments on the Gateway on behalf of the merchant

Things to note about the test cards:

• CVV not required
• Expiry must be current or future date 
  

BANKSERV 

For merchants and acquiring banks in South Africa and Kenya

CYBERSOURCE