3D SECURE V2 Manual Ver 1.0.5 EN

History of Changes
Date Version Changes

03/06/2019 1.0 Original version
Change in the possible values of the RecurringInd
10/07/2019 1.0.1
parameter and various improvements
 Section 4: New parameters added to the request
message (shipping address data, billing address
data, cardholder data)
30/07/2019 1.0.2
 Addition of Section 5 (3D-Secure Wrapper Test
Cases)
 <UserAgent> parameter is now set to (M)andatory

and <RecurPurchaseDate>, <RecurFreq>,
<RecurEnd> parameters to (C)onditional
 Desciption and Type enrichment of the following
23/09/2019 1.0.3 parameters: BillAddrCity, BillAddrCountry,
BillAddrLine1, BillAddrLine2, BillAddrLine3,
BillAddrPostCode, BillAddrState, ShipAddrCity,
ShipAddrCountry, ShipAddrLine1, ShipAddrLine2,
ShipAddrLine3, ShipAddrPostCode, ShipAddrState,
CardholderName, Email, HomePhone, MobilePhone
 Desciption and format enrichment of the following
parameters:
o Description
o BrowserIP
o Navigator_language
o Navigator_javaEnabled
o Navigator_jsEnabled
02/01/2020 1.0.4
o Screen_colorDepth
o Screen_height
o Screen_width
o TimezoneOffset
o UserAgent
o BrowserAccept
 Update of the parameters description:

BillAddrCountry, BillAddrLine1, BillAddrPostCode,
BillAddrState, ShipAddrCity, ShipAddrCountry,
20/07/2020 1.0.5
ShipAddrLine1, ShipAddrPostCode, ShipAddrState,
CardholderName, Email, HomePhone, MobilePhone,
WorkPhone
1
Contents
1. Introduction 3
2. General Architecture 4
3. Details for the Creation of a Test Account 6
4. Strong Customer Authentication through 3D-Secure Wrapper 7
5. 3D-Secure Wrapper Test Cases 25
2
1. Introduction
This document describes the development required for the strong authentication
of a card holder debiting their card on a website. This is the so-called “3D Secure
Version 2” or “EMV 3D-Secure” process supported through the “Visa Secure” and
“Mastercard Identity Check” services; it has to be executed prior to any card
debiting attempt initiated by the holder on a company’s website.
More specifically, where a company uses “Web Service” for card debits (see
relevant Piraeus Bank specification) made by card holders through the company’s
website, the process described herein should be implemented.
3D-Secure requires the card details (number and expiry date) which are either
entered by the user on the company’s website, or alternative the company sends
a “token” obtained at an earlier stage using the Piraeus Bank Tokenization service
(see relevant Piraeus Bank specifications).
In the sections below detailed information is provided on the following:
 Section 2  General Architecture:

Description of the 3D-Secure general architecture.
 Section 3  Details on the creation of a Test Account:

The details required to be sent to Piraeus Bank in order to create a test
account and perform test transactions.
 Section 4  Strong Customer Authentication through 3D-Secure

Wrapper:
Description of the 3D-Secure process and of the calls required for strong
customer authentication.
 Section 5  3D-Secure Wrapper Test Cases:

Description of test cases to be executed in order to check the 3D Secure
process
3
2. General Architecture
The following diagrams show the general architecture for executing a transaction
following the 3D Secure process. There are two alternatives:
A) Use of the card’s actual details
Diagram 2.1: General architecture – use of clear card
As shown in the above diagram:

1. The user enters their card details on the company's website (card number,
expiry date, CVV2)
2. 3D Secure is executed; the card details (number and expiry date - see
next section) are included
3. Provided the process is successfully completed, the sale or pre-
authorisation transaction is sent or the user is prompted to try again using
the same or a different card.
Β) Use of a token
In this case the Piraeus Bank “Tokenization” service has been used and the
company has stored a “token” that corresponds to a card, the details of which
have been stored in Piraeus Bank. The 3D Secure process is thus executed, using
the token value and not the actual card details.
4
Diagram1.2: General architecture – use of a token
As shown in the above diagram:

1. The user selects the card to be debited from a list of masked card details.
The company only knows the token and the masked card details acquired
through the Piraeus Bank “Tokenization” service.
2. The 3D Secure process is thus executed using the token, not the actual
card details (see next section).
3. Provided the process is successfully completed, the sale or pre-
authorisation transaction is sent or the user is prompted to try again using
the same or a different card.
5
3. Details for the Creation of a Test Account
The information to be sent to Piraeus Bank in order for the necessary technical
information to be provided (test account) for test transactions is as follows (all is
required):
 Details of the technical manager

 Name of the technical manager
 Telephone of the technical manager
 Email address of the technical manager
 Company where the technical manager is employed
 Details of the merchant owning the system:

 Distinctive Title of the merchant owning the system
 Tax Registration Number of the merchant owning the system
 Domain name of the merchant’s live site
 Technical data:
 IP address: IP address of the server from which calls will be made
The test account details provided by Piraeus Bank, once the above information is
sent, are as follows:
 AcquirerID
 MerchantID
 User
 Password
Information on the usefulness of the above details is provided in the following

sections.
6
4. Strong Customer Authentication through 3D-Secure
Wrapper
The 3D Secure process should precede any sale or pre-authorisation transaction

made by the card holder on the company’s website. This process, however, is not
called prior to any refund or settlement transactions.
The process is executed by calling the Web Service (“3D-Secure Wrapper”)
presented below. The URL to which calls are sent is:
https://paycenter.piraeusbank.gr/services/Wrapper3DSecure.asmx
Caution!
 The amount and currency used in the 3D Secure process should
be identical to those in the sale or pre-authorisation transaction
that follows.
 The response timeout is 60 sec.
 The Web Service call should be made through the Server. Cross-
origin HTTP requests via scripts are not allowed.
The Web Service request and response parameters are described below, followed
by a diagram of the algorithm to be used. Next to each parameter name there is
one of the following indicators:
 M (Mandatory): The parameter must have a value
 O (Optional): It is not required to send a value to the parameter
 C (Conditional): The parameter must have a value subject to the
conditions mentioned in the description.
REQUEST PARAMETERS
Parameter name Description Type
AcquirerID (M) The acquirer id. Provided by Piraeus String
Bank. (up to 5
characters)
MerchantID (M) The merchant ID. Provided by Piraeus Integer
Bank.
User (M) User name. Provided by Piraeus Bank. String
(up to 50
characters)
Password (M) User password encrypted using the MD5 String
hashing algorithm. Provided by Piraeus (up to 50
Bank (in non-encrypted form). characters)
RequestType (M) Request type (see diagram below). String
Possible values:
 EnrollmentRequestInit
7
 EnrollmentRequestContinue
 PAResValidationRequest
MerchantReference (M) Unique reference code of the String

transaction, used in all 3D-Secure (up to 50
Wrapper and Transaction Web Service characters)
requests, regarding the particular
transaction.
 “MerchantReference” accepts Greek
and Latin uppercase and lowercase
alphanumeric characters, spaces and
the following special characters:
/:_().,+-
 Generated by the company’s system,
it is a unique identifier of the
transaction. Even if the transaction is
not approved, it is not possible to use
the same MerchantReference value in
the next attempt.
PurchAmount (C) The transaction amount with an integer Long

value formed by removing the decimal
separator (e.g. for EUR 100.25 the value
10025 should be sent). A value is
required here when
RequestType=EnrollmentRequestInit and
messageCategory ≠02 (see description
of the messageCategory parameter
below).
Exponent (C) Number of decimals in the amount. A Integer

value is required where purchAmount
should have a value.
Currency (C) The ISO 4217 currency code of the Integer
transaction (3-digit numerical value).
E.g. 978 for the Euro. A value is required
where purchAmount should have a value.
Description (O) Description of the purchase (brief String(up to
description of the products/service 125
involved in the purchase). Maximum characters)
length is 125 characters.
The parameter accepts Greek and Latin

uppercase and lowercase alphanumeric
characters, spaces and the following
special characters: /:_().,+-
Note:
Most Issuers do not display this
description.
Pan (C) Card number or token value. String
A value is required when (up to 19
RequestType=EnrollmentRequestInit. numeric
digits)
8
Expiry (C) The card expiry date in YYMM format. String (4
digits)
 When
RequestType=EnrollmentRequestInit
and the pan contains an actual card
number, a value is required in
expiry.
 When
RequestType=EnrollmentRequestInit
and the pan contains a Paycenter
token, no value is sent.
MD (O) The content of this parameter will be String (up to
returned through POST in the company’s 254 bytes)
termURL (see parameter description
below). It should contain ASCII
characters numbered from 0x20 to 0x7E,
excluding “<” and “>”. If additional data
is required, Base64 encoding is
necessary. The final size of the
parameter should be up to 254 bytes. It
may be assigned a value only when
RequestType=EnrollmentRequestInit.
Lang (O) ISO 639-1 language code corresponding String (2
to the language used on the company’s characters)
website. E.g. el for Greek, en for English.
It may be assigned a value only when
TermURL (C) The company’s URL to which the user is String
returned following the authentication
process in their bank (see diagram
below). A value is required when
Pares (C) It may be assigned a value when String
RequestType= PAResValidationRequest.
If the company received a value in the
pares parameter when returning to the
TermURL, this value is sent here.
Cres (C) It may be assigned a value when String
RequestType= PAResValidationRequest.
If the company received a value in cres
parameter when returning to the
TermURL, this value is sent here.
ThreeDSMethodNotificat The company’s URL called under certain String
ionURL (C) conditions during the 3D Secure process,
in order for a subsequent call to 3D
Secure wrapper to follow (see diagram
below). A value is required when
Caution!
It is recommended that its value be
generated dynamically and the
MerchantReference value is
included as a parameter (in the
9
query string), so that there is a
unique element to establish the link
to the transaction upon return (e.g.
https://www.test.gr?ref=abcd
where ‘abcd’ is the
MerchantReference value of the
transaction)
ThreeDSCompInd (C) A value is sent only when RequestType= String
EnrollmentRequestContinue (see diagram
below).
 “Y”: Sent only when the wrapper call
with RequestType=
EnrollmentRequestContinue follows
the company’s
threeDSMethodNotificationURL call.
 “N”: Sent only when the wrapper call
with RequestType=
EnrollmentRequestContinue is made
without prior call of the company’s
threeDSMethodNotificationURL
(TIMEOUT)
PanMode (O) For future use; no value is sent. String
MessageCategory (O) Used when authentication is not followed String
by a card transaction (non-payment
authentication) and only when
RequestType= EnrollmentRequestInit.
 For non-payment authentication,
value “NonPayment” is sent
 Alternatively, for payment
authentication, value “Payment” is
sent.
* ChallengeWindowSize Desirable window size for card holder String
(C) authentication. Potential values:
 W250H400: 250x400
 W390H400: 390x400
 W500H600: 500x600
 W600H400: 600x400
 FullScreen: Full screen
A value is required only when
* BrowserIP (C) The browser’s IP. Values accepted IPv4 String
e.g. 1.12.123.255 or IPv6 e.g.
2011:0db8:85a3:0101:0101:8a2e:0370:
7334
*Navigator_language Value representing the browser language String
(C) as defined in IETF BCP47. Obtained from
navigator.language HTML property.
*Navigator_javaEnabled Value representing the ability of the String
(O) cardholder browser to execute Java.
10
Obtained from the navigator.javaEnabled
property. Accepted values: true/false
*Navigator_jsEnabled Value representing the ability of the String
(C) cardholder browser to execute
JavaScript.
Accepted values: true/false
*Screen_colorDepth (C) Value representing the bit depth of the String (1-2
color palette for displaying images, in characters)
bits per pixel. Obtained from Cardholder
browser using the screen.colorDepth
property. Accepted values: 1, 4, 8, 15,
16, 24, 32, 48.
* Screen_height (C) Total height of the Cardholder’s screen in String (1-6
pixels. Obtained from the screen.height numeric
property. characters)
* Screen_width (C) Total width of the cardholder’s screen in String (1-6
pixels. Obtained from the screen.width numeric
property. characters)
* TimezoneOffset (C) Time-zone offset in minutes between String (1-5
UTC and the cardholder browser local characters)
time. Note that the offset is positive if
the local time zone is behind UTC and
negative if it is ahead. Value is returned
from the getTimezoneOffset() method.
Examples: If UTC -5 hours,
TimezoneOffset=300 or +300. If UTC +5
hours, TimezoneOffset= -300.
* UserAgent (C) Exact content of the HTTP user-agent String (max.
header. If the total length of the User- 2048
Agent sent by the browser exceeds 2048 characters)
characters, the system truncates the
excess portion.
* BrowserAccept (C) Value of the accept header field String (max.
(response types acceptable by the 2048
browser). If the total length of the accept characters)
header sent by the browser exceeds
2048 characters, the system truncates
the excess portion.
11
* BillAddrCity (C) Billing address city String (up to
50 characters)
The parameter contains only Greek or
Latin lowercase & uppercase
alphanumeric characters, space, or the
following special characters /:_().,+-
* BillAddrCountry (C) ISO 3166-1 numeric country code, String (3
corresponding to Billing address country. numeric
E.g. 300 for Greece. digits)
* BillAddrLine1 (C) Additional line 1 of the billing address String (up to
50 characters)
BillAddrLine2 (O) Additional line 2 of the billing address String (up to
50 characters)
BillAddrLine3 (O) Additional line 3 of the billing address String (up to
50 characters)
* BillAddrPostCode (C) Post code of the billing address String (up to
16 characters)
* BillAddrState (C) ISO 3166 country subdivision code String (max. 3
without the country name code, characters)
corresponding to Billing address State (if
available).
Below are the values for the
administrative regions of Greece:
A Eastern Macedonia and Thrace
B Central Macedonia
C Western Macedonia
D Epirus
E Thessaly
12
F Ionian Islands
G Western Greece
H Central Greece
I Attica
J Peloponnese
K Northern Aegean
L Southern Aegean
M Crete
* ShipAddrCity (C) Shipping address city String (up to
50 characters)
* ShipAddrCountry (C) ISO 3166-1 numeric country code, String (3
corresponding to Shipping address numeric
country. E.g. 300 for Greece. digits)
* ShipAddrLine1 (C) Additional line 1 of the shipping address String (up to
50 characters)
ShipAddrLine2 (O) Additional line 2 of the shipping address String (up to
50 characters)
ShipAddrLine3 (O) Additional line 3 of the shipping address String (up to
50 characters)
* ShipAddrPostCode (C) Post code of the shipping address String (up to
16 characters)
* ShipAddrState (C) ISO 3166 country subdivision code String (max. 3
without the country name code, characters)
13
corresponding to Shipping address State
(if available).
Below are the values for the
administrative regions of Greece:
A Eastern Macedonia and Thrace
B Central Macedonia
C Western Macedonia
D Epirus
E Thessaly
F Ionian Islands
G Western Greece
H Central Greece
I Attica
J Peloponnese
K Northern Aegean
L Southern Aegean
M Crete
* CardholderName (C) Name of the card holder String (2-45
characters)
The parameter contains only Latin (not
Greek) lowercase & uppercase
* Email (C) E-mail of the card holder String (up to
254
The parameter shall meet requirements characters)
of Section 3.4 of IETF RFC 5322.
* HomePhone (C) Home phone number of the card holder, String (up to
in (..3-..15) format, namely (up to 3 19 characters)
characters dash up to 15 characters).
E.g. 210-3288000
* MobilePhone (C) Mobile number of the card holder, in String (up to
(..3-..15) format, namely (up to 3 19 characters)
E.g. +30-6972222222
WorkPhone (O) Work phone number of the card holder, String (up to
in (..3-..15) format, namely (up to 3 19 characters)
E.g. 210-3288000
RecurringInd (O) It is only used in recurring transactions. String (1
It concerns the first transaction of a character)
recurring payment (i.e. standing order),
performed online by the card holder and
14
is, therefore, preceded by the 3d-secure
process. It is only sent when
RequestType= EnrollmentRequestInit.
Potential values:
 R, for recurring transactions
(transactions performed at regular
intervals)
 C, for unscheduled recurring
transactions (transactions performed
at irregular intervals)
Unless the process concerns a recurring
transaction, the parameter is omitted.
RecurPurchaseDate (C) In recurring transactions, it contains the String (14
date of the first recurring transaction in characters)
YYYYMMDDHHMMSS format. It may only
have a value when
provided that the RecurringInd has a
value, too.
RecurFreq (C) In recurring transactions, it contains the String (max. 4
recurrence frequency of the transaction characters)
(integer number of days). It may only
have a value when
value, too.
RecurEnd (C) In recurring transactions (i.e. when String(8
RecurringInd=R or C), it contains the characters)
expiry date of the recurring debit in
YYYYMMDD format. It may only have a
value when
value, too.
Attention:
(*): The above parameters are mandatory, as Issuers may soon be
rejecting transactions lacking this information.
The parameters sent with the response are the following:
RESPONSE PARAMETERS
Parameter name Description Type
AcquirerID (M) The AcquirerID value sent with the request String
MerchantID (M) The MerchantID value sent with the Integer
request
User (M) The User value sent with the request String
(up to 50
characters)
15
RequestType (M) The RequestType value sent with the String
request
ResultCode (M) The request result code indicating whether Integer
a technical issue occurred during the call.
Specifically:
Value = 0: No issue occurred and
the remaining parameters have
information on the 3D Secure
process carried out.
Value ≠ 0: There was an issue

with the request data or another
type of technical issue. The
«ResultDescription» parameter
contains the problem description.
ResultDescription (M) The description corresponding to the String

«ResultCode» parameter value. (up to 1024
characters)
Note:
This information is not
recommended to be displayed to
the user.
SupportReferenceID Reference id of the submitted request. It Long
(M) has a different value for each request. integer
Note:
It is necessary to save the value, so
that it can be used as a reference in
the communication with Piraeus
Bank, as required.
MerchantReference (M) The MerchantReference value sent with the String
request. (up to 50
characters)
MdStatus (C) Unless there is some technical problem String
(ResultCode=0), it contains information on
the call outcome during execution of the
3D Secure process. The actions which
should follow in order for the process to be
completed depend on this value (see
diagram below). The possible values are:
0: Not authenticated
1: Fully authenticated
2: Not enrolled
3: Not enrolled cache (not
used any more)
4: Attempt
5: U received
6: Error received (from Directory
or ACS server)
9: Pending
50: Interim status during the
execution of 3D Secure (see
16
diagram below)
80: Skip device case
91: Network error
92: Directory error (read timeout)
93: Configuration error
94: Merchant input error
95: No directory found for
PAN/cardtype
96: No version 2 directory found
for PAN/cardtype
99: System error
MdErrorMsg (C) MdStatus description (up to 128 String

characters)
EnrollmentStatus (C) Enrollment status. Contains a value when String
RequestType=PAResValidationRequest
and is an informative field (not used
anywhere). The potential values are:
Υ: Authentication Available
N: Cardholder not participating
U: Unable to authentication
AuthenticationStatus Authentication status. Contains a value String

(C) when
RequestType=PAResValidationRequest
and is an informative field (not used
anywhere). The potential values are:
Υ: Authentication Successful
N: Authentication failed
U: Authentication could not be
performed
A: Attempts processing performed
R: Authentication rejected
Eci (C) Electronic Commerce Indicator. Its value String

should be included when Transaction Web
Service is called for the execution of the
transaction (Eci parameter). If no ECI
value is returned by 3D Secure wrapper,
the following default values must be sent
to the Transaction Web Service:
For Visa: 07
For Mastercard: 00
Cavv (C) Cardholder Authentication Value. Its value String

transaction (Cavv parameter)
Xid ID of the request returned through the 3D String
Secure process. Its value should be
included when Transaction Web Service is
called for the execution of the transaction
(Xid parameter)
17
PAResVerifed (C) Indicates whether signature verification String
during messaging for the execution of the
3D Secure process was successful or not.
Potential values: True/False. This is an
informative field and its value is not used
anywhere.
Protocol (C) Authentication protocol version used String
during authentication. Possible values: 1
and 2. Its value should be included when
Transaction Web Service is called for the
execution of the transaction (Protocol
parameter)
TDSMethodContent (C) Raw html for browser rendering. May String
contain a value when
RequestType=EnrollmentRequestInit (see
diagram below)
RedirectToACSFormData Raw html for browser rendering. It may String
(C) contain a value when
RequestType=EnrollmentRequestInit or
RequestType=EnrollmentRequestContinue
(see diagram below)
DsTransID (C) Directory server transaction id. Its value String
transaction (DsTransID parameter)
The following diagram shows the algorithm for executing the 3D Secure process,
followed by a text describing the process and the required calls.
18
19
20
Caution!
(*): In such cases, authentication has not been successfully completed.

If, however, the company does decide to send the transaction, the
Issuing bank may reject it. If the Issuer eventually approves the
transaction and this transaction is disputed, the company shall be liable
and no coverage shall be provided.
The process and controls carried out are as follows:
1. 3D-Secure Wrapper call with RequestType=EnrollmentRequestInit
2. The value of Result Code parameter is checked:
2.1 If it is not 0, this means that a technical issue has occurred and the
company will decide whether to send the transaction or not (*).
2.2 If it is 0, the value of the redirectToACSFormData parameter of the

response is checked:
2.1.1 If the redirectToACSFormData parameter has a value, then:
Rendering of the redirectToACSFormData content on the browser (raw

html). At this point the user may need to proceed to an authentication
process (i.e. enter the One Time Password sent to their mobile phone or
be authenticated using their fingerprint on their mobile phone).
Waiting for data through post on TermURL (sent when 3D Secure

wrapper was first called):
 Either a value will be sent through post data to the “pares”
parameter and the content of the md parameter of the first 3D
Secure wrapper call will be sent to “md” parameter
 Or a value will be sent through post data to the “cres” parameter
and the content of the md parameter of the first 3D Secure wrapper
call will be sent to the “threeDSSessionData” parameter
3D-Secure Wrapper call with:

 RequestType= PAResValidationRequest
 MerchantReference: the value which had been used in the first 3D
Secure wrapper call
 pares the value of the pares parameter sent to TermURL or cres the
value of cres sent to TermURL (one of the two parameters will be
sent to TermURL)
The value of Result Code parameter is checked:
 If it is not 0, this means that a technical issue has occurred and the
company will decide whether to send the transaction or not (*).
 If it is 0, the parameter value of the mdStatus response is checked:
21
 If mdStatus=0 (unsuccessful authentication), no transaction is
sent and an informative message is displayed to the user.
 If mdStatus=1, 2, 3 or 4, the transaction is sent using the

Transaction Web Service. Caution: the values of Eci , Cavv, Xid,
protocol, dsTransID parameters of the 3D Secure wrapper in
the 3D Secure wrapper response should be sent and the same
MerchantReference should be used.
 If mdStarus has a different value, the 3D Secure process has not

been completed and the company should decide whether to send
the transaction or not (*).
2.1.2 If the redirectToACSFormData parameter has no value, then:
The value of the response mdStatus parameter is checked:
 If mdStatus=0 (unsuccessful authentication), no transaction is sent

and an informative message is displayed to the user.
 If mdStatus=1, 2, 3 or 4, the transaction is sent using the

Transaction Web Service. Caution: the values of Eci , Cavv, Xid,
protocol, dsTransID parameters of the 3D Secure wrapper in the
3D Secure wrapper response should be sent and the same
MerchantReference should be used.
 If mdStarus has a value other than 0, 1, 2, 3, 4 and 50, the 3D

Secure process has not been completed and the company should
decide whether to send the transaction or not (*).
 If mdStatus=50, then:
 Rendering of the TDSMethodContent content on the browser

(raw html).
 Waiting for a call to threeDSMethodNotificationURL (sent with

the first 3D-Secure Wrapper call).
 If data is sent to threeDSMethodNotificationURL or there is a 10

sec waiting time (in which case a timeout is assumed), 3D-Secure
wrapper is called with
RequestType=EnrollmentRequestContinue and with the same
MerchantReference value used in the first 3D-Secure wrapper call
 The value of Result Code parameter is checked:
− If it is not 0, this means that a technical issue has occurred

and the company will decide whether to send the transaction
or not (*).
− If it is 0, the value of the mdStatus response parameter is

checked:
o If mdStatus=0 (unsuccessful authentication), no

transaction is sent and an informative message is displayed
to the user.
22
o If mdStatus=1, 2, 3 or 4, the transaction is sent using the
Transaction Web Service. Caution: the values of Eci ,
Cavv, Xid, protocol, dsTransID parameters of the 3D
Secure wrapper in the 3D Secure wrapper response should
be sent and the same MerchantReference should be
used.
o If mdStarus has a value other than 0, 1, 2, 3, 4 and 9, the

3D Secure process has not been completed and the
company should decide whether to send the transaction or
not (*).
o If mdStatus=9 and redirectToACSForm has a value,

then:
Rendering of the redirectToACSForm content on the

browser (raw html). At this point the user may need to
proceed to an authentication process (i.e. enter the One
Time Password sent to their mobile phone or be
authenticated using their fingerprint on their mobile
phone).
Waiting for data through post on TermURL (sent when

3D Secure wrapper was first called):
o Either a value will be sent through post data to the

“pares” parameter and the content of the md
parameter of the first 3D Secure wrapper call will be
sent to “md” parameter
o Or a value will be sent through post data to the

“cres” parameter and the content of the md
parameter of the first 3D Secure wrapper call will be
sent to the “threeDSSessionData” parameter
3D-Secure Wrapper call with:
o RequestType= PAResValidationRequest
o MerchantReference: the value which had been
used in the first 3D Secure wrapper call
o pares the value of the pares parameter sent to
TermURL or cres the value of cres sent to TermURL
(one of the two parameters will be sent to
TermURL)
The value of Result Code parameter is checked:
o If it is not 0, this means that a technical issue has

occurred and the company will decide whether to
send the transaction or not (*).
o If it is 0, the parameter value of the mdStatus

response is checked:
− If mdStatus=0 (unsuccessful authentication), no

transaction is sent and an informative message
is displayed to the user.
23
− If mdStatus=1, 2, 3 or 4, the transaction is sent
using the Transaction Web Service. Caution: the
values of Eci, Cavv, Xid, protocol, dsTransID
parameters of the 3D Secure wrapper in the 3D
Secure wrapper response should be sent and
the same MerchantReference should be used.
− If mdStarus has a different value, the 3D

Secure process has not been completed and the
company should decide whether to send the
transaction or not (*).
Caution!
 (*): In such cases, authentication has not been successfully

completed. If, however, the company does decide to send the
transaction, the Issuing bank may reject it. If the Issuer
eventually approves the transaction and this transaction is
disputed, the company shall be liable and no coverage shall be
provided.
 If the ECI parameter has no value and the company decides to

send a transaction (Transaction Web Service call), the following
default values must be submitted to Transaction Web Service:
For Visa: Eci=07
For Mastercard: Eci=00
 When the authentication process is initiated for a transaction, all

3D Secure wrapper calls and any Transaction Web Service call
should have a common MerchantReference value. In the next
transaction, however, a different MerchantReference value should
be used (even if the process involves the same order, the
payment of which is repeated due to a failure in the first time)
 The amount and currency used in the 3D Secure process

(PurchAmount, Exponent, Currency parameters of the
“Wrapper3DSecure service”) should match those to be used in
the Transaction Web Service (Amount and CurrencyCode
parameters)
24
5. 3D-Secure Wrapper Test Cases
Below follows a list of the test cases to be executed in order to check the
implementation of the 3D Secure process. In every test case:
1) The process described in this document should be performed using the
details listed below
2) Depending on the result of the 3D Secure process and provided that the
transaction is to be sent (see previous Section), the Transaction Web
Service should be called with the same card details, same Merchant
Reference, same amount and same currency. Moreover, when the
Transaction Web Service is called:
 The CVV2 parameter (for sales and preauthorisations) must have the
value ‘123’.
 In preauthorisations, the ExpirePreauth parameter must have the
value ‘30’
 The Installments parameter must have the value ‘0’
Test Case 1
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000002
Expiry if a sale transaction is to xx01 where xx the last 2
follow (RequestType=SALE) digits of a future year
Expiry if a preauthorisation xx02 where xx the last 2
transaction is to follow digits of a future year
(RequestType=AUTHORIZE)
Final response parameters:

Parameter Value
ResultCode 0
MdStatus 1
AuthenticationStatus Y
ECI 05
Protocol 2
Company application actions:

 Transaction submission using Transaction Web Service
25
Test Case 2
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000010

Parameter Value
ResultCode 0
MdStatus 0
AuthenticationStatus N
ECI -
Protocol 2

 The authentication was unsuccessful and the transaction should not
be submitted
26
Test Case 3
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the correct
display (‘Challenge’)

Parameter Value
ResultCode 0
MdStatus 1
ECI 05
Protocol 2

27
Test Case 4
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the delayed

Parameter Value
ResultCode 0
MdStatus 94
AuthenticationStatus -
ECI -
Protocol 2

 The authentication process has not been successfully completed and
the company will decide whether the transaction will be submitted
using the Transaction Web Service. If it is submitted, the ECI
parameter should have the value 07 (for a Visa card)
28
Test Case 5
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the attempt

Parameter Value
ResultCode 0
MdStatus 4
AuthenticationStatus A
ECI 05
Protocol 2

 Transaction sumbission using Transaction Web Service
29
Test Case 6
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the cancel

Parameter Value
ResultCode 0
MdStatus 0
ECI -
Protocol 2

be submitted
30
Test Case 7
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the wrong

The message “Authentication failed invalid password” appears and the
user must try again with a different password

 The 3D Secure process is not completed; the process will not
proceed and the user remains on the authentication screen.
31
Test Case 8
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the error

Parameter Value
ResultCode 0
MdStatus 0
ECI -
Protocol 2

be submitted
32
Test Case 9
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016000000051
Code to be entered on the unable

Parameter Value
ResultCode 0
MdStatus 5
AuthenticationStatus U
ECI -
Protocol 2

 The authentication process has been successfully completed with
AuthenticationStatus=U and the company will decide whether the
transaction will be submitted using the Transaction Web Service. If it
is submitted, the ECI parameter should have the value 07 (for a Visa
card).
33
Test Case 10
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4012000000012003001
Code to be entered on the Secret33!
display (‘Password’)

Parameter Value
ResultCode 0
MdStatus 1
ECI 05
Protocol 2

34
Test Case 11
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4012000000012011046

Parameter Value
ResultCode 0
MdStatus 5
ECI -
Protocol 2

card).
35
Test Case 12
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4012000000012011004

Parameter Value
ResultCode 0
MdStatus 1
ECI 05
Protocol 2

36
Test Case 13
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4012000000012011012

Parameter Value
ResultCode 0
MdStatus 0
ECI -
Protocol 2

be submitted
37
Test Case 14
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4012000000012011020

Parameter Value
ResultCode 0
MdStatus 5
ECI -
Protocol 2

card).
38
Test Case 15
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4012000000012011038

Parameter Value
ResultCode 0
MdStatus 0
AuthenticationStatus R
ECI -
Protocol 2

be submitted
39
Test Case 16
REQUIRED
Input parameters:
Parameter Value
Currency 978
5544330000000003
Pan
5544330000000011
Code to be entered on the
unable

Parameter Value
ResultCode 0
MdStatus 1
ECI 02
Protocol 2

40
Test Case 17
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 5544330000000029

Parameter Value
ResultCode 0
MdStatus 0
ECI -
Protocol 2

be submitted
41
Test Case 18
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 5544330000000037
unable

Parameter Value
ResultCode 0
MdStatus 4
AuthenticationStatus A
ECI 01
Protocol 2

42
Test Case 19
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 5544330000000045

Parameter Value
ResultCode 0
MdStatus 5
ECI 00
Protocol 2

is submitted, the ECI parameter should have the value 00 (for a
Mastercard card).
43
Test Case 20
REQUIRED
Input parameters:
Parameter Value
Currency 978
4016001000019
Pan
4016001000035
unable

Parameter Value
ResultCode 0
MdStatus 01
AuthenticationStatus Υ
ECI 05
Protocol 1

44
Test Case 21
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016001000001

Parameter Value
ResultCode 0
MdStatus 2
AuthenticationStatus -
ECI -
Protocol 1

 Transaction submission using Transaction Web Service. If it is
submitted, the ECI parameter should have the value 07 (for a Visa
card).
45
Test Case 22
REQUIRED
Input parameters:
Parameter Value
Currency 978
Pan 4016001000050

Parameter Value
ResultCode 0
MdStatus 0
ECI -
Protocol 1

be submitted
46

3D SECURE V2 Manual Ver 1.0.5 EN

Uploaded by

Copyright:

Available Formats

3D SECURE V2 Manual Ver 1.0.5 EN

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3D SECURE V2 Manual Ver 1.0.5 EN

Uploaded by

Copyright:

Available Formats

History of Changes

Date Version Changes

 <UserAgent> parameter is now set to (M)andatory

 Update of the parameters description:

In the sections below detailed information is provided on the following:

 Section 2  General Architecture:

 Section 3  Details on the creation of a Test Account:

 Section 4  Strong Customer Authentication through 3D-Secure

 Section 5  3D-Secure Wrapper Test Cases:

A) Use of the card’s actual details

Diagram 2.1: General architecture – use of clear card

As shown in the above diagram:

As shown in the above diagram:

 Details of the technical manager

 Details of the merchant owning the system:

Information on the usefulness of the above details is provided in the following

The 3D Secure process should precede any sale or pre-authorisation transaction

 The response timeout is 60 sec.

MerchantReference (M) Unique reference code of the String

PurchAmount (C) The transaction amount with an integer Long

Exponent (C) Number of decimals in the amount. A Integer

The parameter accepts Greek and Latin

The parameters sent with the response are the following:

Value ≠ 0: There was an issue

ResultDescription (M) The description corresponding to the String

MdErrorMsg (C) MdStatus description (up to 128 String

AuthenticationStatus Authentication status. Contains a value String

Eci (C) Electronic Commerce Indicator. Its value String

Cavv (C) Cardholder Authentication Value. Its value String

(*): In such cases, authentication has not been successfully completed.

The process and controls carried out are as follows:

1. 3D-Secure Wrapper call with RequestType=EnrollmentRequestInit

2. The value of Result Code parameter is checked:

2.2 If it is 0, the value of the redirectToACSFormData parameter of the

2.1.1 If the redirectToACSFormData parameter has a value, then:

Rendering of the redirectToACSFormData content on the browser (raw

Waiting for data through post on TermURL (sent when 3D Secure

3D-Secure Wrapper call with:

The value of Result Code parameter is checked:

 If it is 0, the parameter value of the mdStatus response is checked:

 If mdStatus=1, 2, 3 or 4, the transaction is sent using the

 If mdStarus has a different value, the 3D Secure process has not

2.1.2 If the redirectToACSFormData parameter has no value, then:

The value of the response mdStatus parameter is checked:

 If mdStatus=0 (unsuccessful authentication), no transaction is sent

 If mdStatus=1, 2, 3 or 4, the transaction is sent using the

 If mdStarus has a value other than 0, 1, 2, 3, 4 and 50, the 3D

 Rendering of the TDSMethodContent content on the browser

 Waiting for a call to threeDSMethodNotificationURL (sent with

 If data is sent to threeDSMethodNotificationURL or there is a 10

 The value of Result Code parameter is checked:

− If it is not 0, this means that a technical issue has occurred

− If it is 0, the value of the mdStatus response parameter is

o If mdStatus=0 (unsuccessful authentication), no

o If mdStarus has a value other than 0, 1, 2, 3, 4 and 9, the

o If mdStatus=9 and redirectToACSForm has a value,

Rendering of the redirectToACSForm content on the

Waiting for data through post on TermURL (sent when

o Either a value will be sent through post data to the

o Or a value will be sent through post data to the