'6HFXUHΠ
3URWRFRO6SHFLILFDWLRQ

&RUH)XQFWLRQV 



Version 1.0.2
July 16, 2002

Copyright © 2001-2002 Visa International Service Association, Patent Pending

This work is proprietary and confidential information of Visa International Service Association and may
not be disclosed or used without authorization by Visa. All use and disclosure of this work is governed
by the terms and conditions of the 3-D Secure Publication Suite Master License Agreement.
70000-01
 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page ii July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page iii

The enclosed documentation and technology

has been developed and is owned by Visa.
These materials have been distributed and
provided to Visa Regions and Visa Members for
their internal use. Any use or disclosure of
these materials to third party vendors or any
other entity outside of the Visa membership
association requires that such third party or
entity first obtain a license from Visa.
The 3-D Secure Publication Suite Master
License Agreement which governs such third
party use is available through the “Vendors &
Merchants” link on http://corporate.visa.com.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page iv July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page v

Preface

3-D Secure A full set of documentation has been developed for 3-D Secure™. The primary
Introduction sources for introductory and general information are:
and System
Overview 3-D Secure: Introduction, Visa Publication 70001-01
3-D Secure: System Overview, Visa Publication 70015-01
If you have not yet read those documents, you are encouraged to do so. The
documents are available through the “Vendors & Merchants” link on
http://corporate.visa.com.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page vi July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page vii

Table of Contents

Preface v
Chapter 1: Document Overview 1
Introduction 1
References 3
Document Organization 5
Chapter 2: Entity Overview 7
Chapter 3: Technical Requirements 11
Transport Security Requirements 12
Certificate Requirements 15
Redundant Routing Requirements 16
HTTP Connections 17
Chapter 4: Setup and Cardholder Enrollment 19
Process Flow Diagram 20
Process Flow – Issuer Setup 21
Process Flow – Cardholder Enrollment 22
Chapter 5: Purchase Transaction 23
Purchase Transaction Architecture and Message Flows 24
Purchase Transaction Process Flow Description 26
Chapter 6: Message Descriptions 41
Message Handling 42
CRReq 46
CRRes 47
VEReq 49
VERes 51
PAReq 53
PARes 57
Invalid Request Values 60
Message Extensions 61
Error Message 63
Appendix A: 3-D Secure XML Message Format 65
XML-Signature Syntax and Processing 66
3-D Secure Messages 68
3-D Secure DTD 74
Appendix B: 3-D Secure Field Formats 77
Appendix C: Visa Directory Elements 89
Appendix D: Compression 91
Glossary 93
Revision Log 99

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page viii July 16, 2002

Table of Figures

Figure 1: Sample Cardholder Enrollment Process 20

Figure 2: Sample Purchase Transaction 24
Figure 3: Sample Authentication Form 36
Figure 4: Signature Structure 67
Figure 5: Overview of 3-D Secure Messages 68
Figure 6: CRReq 69
Figure 7: CRRes 69
Figure 8: VEReq 70
Figure 9: VERes 70
Figure 10: PAReq 71
Figure 11: PARes 72
Figure 12: Error Message 73

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2Introduction
July 16, 2002 Page ix

Table of Tables

Table 1: Issuer Domain Entities 8

Table 2: Acquirer Domain Entities 9
Table 3: Interoperability Domain Entities 10
Table 4: 3-D Secure Messages 11
Table 5: Transport Security Requirements 12
Table 6: Cryptographic Suites 14
Table 7: Certificate Requirements 15
Table 8: Redundant Routing Requirements 16
Table 9: Sample Enrollment Server Data 21
Table 10: Sample Cardholder Enrollment Data 22
Table 11: Example Fields Displayed for Cardholder Authentication 36
Table 12: ACS Sets Transaction Status 37
Table 13: CRReq Fields 46
Table 14: CRRes Fields 47
Table 15: VEReq Fields 49
Table 16: VERes Fields 51
Table 17: PAReq Fields 53
Table 18: Recurring Frequency 56
Table 19: PARes Fields 57
Table 20: Invalid Request Values 60
Table 21: Message Extension Attributes 61
Table 22: Error Message Fields 63
Table 23: Error Code, Error Description, and Error Detail 64
Table 24: XML Signature Profile 66
Table 25: XML Signature Algorithms 66
Table 26: 3-D Secure Fields 77
Table 27: Visa Directory Elements 89

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page x July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 1

Chapter 1: Document Overview

Introduction

Purpose Payment authentication is the process of verifying cardholder account ownership

during a purchase transaction in an online commerce environment.
Visa has developed the Three-Domain Secure (3-D Secure™) protocol to improve
transaction performance online and to accelerate the growth of electronic commerce.
The objective is to benefit all participants by providing Issuers with the ability to
authenticate cardholders during an online purchase, thus reducing the likelihood of
fraudulent usage of Visa cards and improving transaction performance.
This document describes 3-D Secure, including the messages supporting payment
authentication as defined by Visa.
As described in this document, 3-D Secure defines a base level of security.
Enhancements will be included in later versions.

Intended This document is intended for the use of vendors and Members that are interested in
audience developing 3-D Secure products and supporting 3-D Secure implementations.

Overview of The major changes included in 3-D Secure version 1.0.2 are:
updates
• Support is provided for generating a proof of authentication attempt when
authentication is not available.
• The Account Identifier in the Verify Enrollment Response and Payer
Authentication Request must not be the PAN.
• The PAN value that is included in the PARes must be masked. Regions,
however, may waive this requirement and require that the full PAN be included.
• Adjusted DTD to show Serial Number as optional in CRRes; it is omitted
when Invalid Request Code is included.
For details, see the Revision Log on page 93.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 1: Document Overview 3-D Secure: Protocol Specification
Introduction Core Functions v1.0.2
Page 2 July 16, 2002

Future The base 3-D Secure protocol has been designed for the current business and market
considera- environment. In the future, enhancements to this protocol may be defined in order to
tions properly support the requirements that arise from additional market and business
opportunities.
Possible future enhancements include adding signatures to PAReq and VEReq to
provide for more robust merchant authentication.

Errata From time to time, errata will be published for these specifications. You should
ensure that you have all of the relevant errata in addition to this document.

Document The following words are used often in this document and have specific meanings:
word usage
Must Describes a product or system capability that is required,
compelled, or mandatory.
Should Describes a product or system capability that is highly
recommended.
May Describes a product or system capability that is optional.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 1: Document Overview
Core Functions v1.0.2 References
July 16, 2002 Page 3

References

Introductory The following documents provide fundamental information about 3-D Secure and
information are available through the “Vendors & Merchants” link on http://corporate.visa.com.
You are encouraged to read them (in the following order) before reading this
document:
3-D Secure: Introduction, Visa Publication 70001-01
3-D Secure: System Overview, Visa Publication 70015-01

3-D Secure Every 3-D Secure component must comply with the requirements of the core
specifications protocol, described in this document:
3-D Secure: Protocol Specification – Core Functions, Visa Publication
70000-01 (licensed)
In addition, each 3-D Secure component must comply with the functional
requirements defined for that component:
3-D Secure: Functional Requirements – Access Control Server, Visa
Publication 70002-01 (licensed)
3-D Secure: Functional Requirements – Merchant Server Plug-in, Visa
Publication 70003-01 (licensed)
Any 3-D Secure component that supports mobile Internet devices must also comply
with the specifications for the supported extension:
3-D Secure: Protocol Specification – Extension for Mobile Internet
Devices, Visa Publication 70006-01 (licensed)
Throughout this documentation suite, those requirements collectively are referred to
as “the 3-D Secure specifications.”

Licensed Some 3-D Secure documents are available only to parties that have executed with
documents Visa a 3-D Secure Publication Suite Master License Agreement. Information
regarding these publications and the license agreement is available through the
“Vendors & Merchants” link on http://corporate.visa.com.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 1: Document Overview 3-D Secure: Protocol Specification
References Core Functions v1.0.2
Page 4 July 16, 2002

Compliance All software components that are developed as 3-D Secure solutions are required to
testing demonstrate compliance with Visa International’s 3-D Secure requirements.
This testing must be completed successfully and the component must receive
acknowledgement of compliance from Visa International before any claims of
3-D Secure compliance may be made. For details, see:
3-D Secure: Compliance Testing Facility – Policies & Procedures, Visa
Publication 70017-01

Other The following documents are referenced in this specification and/or provide useful
documents background information:
1) Certificate Infrastructure Group Brand Certificate Authority – Operating
Procedures, version 1.0, dated August 1999.
2) Certificate Infrastructure Group Brand Certificate Authority – Business Policies
and Procedures, version 1.0, dated August 1999.
3) Extensible Markup Language (XML) W3C Recommendation, version 1.0
(Second Edition), dated 6 October 2000, available at
http://www.w3.org/TR/2000/REC-xml-20001006.
4) Canonical XML, W3C Recommendation, version 1.0, dated 15 March 2001,
available at http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
5) XML-Signature Syntax and Processing, W3C Proposed Recommendation, dated
20 August 2001, available at http://www.w3.org/TR/2001/PR-xmldsig-core-
20010820.
6) Namespaces in XML W3C Recommendation, dated 14 January 1999, available
at http://www.w3.org/TR/1999/REC-xml-names-19990114.
7) The TLS [Transport Layer Security] Protocol, Version 1.0, dated January 1999,
available at http://www.ietf.org/rfc/rfc2246.txt.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 1: Document Overview
Core Functions v1.0.2 Document Organization
July 16, 2002 Page 5

Document Organization

The document is organized as follows:

• Chapter 1, this chapter, contains an overview of the document and a list of
references.
• Chapter 2 provides an entity overview.
• Chapter 3 lists and describes the technical requirements for 3-D Secure.
• Chapter 4 provides an overview of Issuer setup and cardholder enrollment
functions.
• Chapter 5 describes the design of the purchase transaction.
• Chapter 6 describes the 3-D Secure messages.
• Appendix A includes the XML message format of the 3-D Secure messages, as
well as diagrams of the messages.
• Appendix B provides a single sorted list of the fields in all the 3-D Secure
messages.
• Appendix C lists the data elements required by the Visa Directory.
• Appendix D describes the method for compressing data that is sent from one
entity to another through the cardholder browser.
• A glossary defines selected terms and acronyms related to 3-D Secure.
• The revision log summarizes the changes in each production version of the
document.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 1: Document Overview 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 6 July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 7

Chapter 2: Entity Overview

Organization This chapter describes the systems and functions necessary to implement
3-D Secure. Descriptions are divided according to domain:
Issuer domain Systems and functions of the Issuer and its
customers (cardholders).
Acquirer domain Systems and functions of the Acquirer and its
customers (merchants).
Interoperability Systems, functions, and messages that allow
domain Issuer domain systems and Acquirer domain
systems to interoperate worldwide.
Note that third parties may operate many of the systems in the Issuer and Acquirer
domains on behalf of Visa Members.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 2: Entity Overview 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 8 July 16, 2002

Issuer domain Cardholder The cardholder shops online, providing the account holder
name, card number, and expiration date, either directly or via
software such as a digital wallet, then indicates readiness to
finalize the transaction. In response to the Purchase
Authentication Page, the cardholder provides information
needed for authentication, such as a password.
Cardholder The cardholder browser acts as a conduit to transport messages
browser between the Merchant Server Plug-In (in the Acquirer domain)
and the Access Control Server (in the Issuer domain).
Additional Optional cardholder hardware and software may supplement
cardholder the abilities of the browser. For example, chip card
components implementations, will require additional cardholder software
and a card reader. Implementations that authenticate
cardholders using passwords should not require any additional
hardware or software.
Issuer A Visa Member financial institution that:
• enters into a contractual relationship with the cardholder for
issuance of one or more Visa cards
• determines the cardholder’s eligibility to participate in
3-D Secure
• defines card number ranges eligible to participate in
3-D Secure
• provides data about those card number ranges to the Visa
Directory
• performs enrollment of the cardholder for each payment
card account (via the Access Control Server, a separate
Enrollment Server, or manually)
Access The Access Control Server (ACS) has two functions:
Control Server • to verify whether a given card number is enrolled in
3-D Secure and whether authentication is available
• to authenticate the cardholder for a specific transaction.
Although these functions are described as belonging to a single
logical ACS, implementations may divide the processing by
function or by other characteristics such as card number range
among multiple physical servers.
Table 1: Issuer Domain Entities

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 2: Entity Overview
Core Functions v1.0.2
July 16, 2002 Page 9

Acquirer Merchant Existing merchant software handles the shopping experience,

domain obtains the card number, then invokes the Merchant Server Plug-in
to conduct payment authentication.
After payment authentication, the merchant software may submit an
authorization request to the Acquirer, if appropriate.
Merchant The Merchant Server Plug-in (MPI) creates and processes payment
Server authentication messages, then returns control to the merchant
Plug-in software. As part of processing the authentication response message
from the Issuer, the MPI may validate the digital signature in the
message; alternatively, this function may be performed by a
separate server, or by the Acquirer or a third party.
Validation This function validates the signature received in the message from
Process the ACS to the merchant. (This process may be implemented as an
integral part of the Merchant Server Plug-in, or as a separate server.
In the latter case, the Acquirer may operate it on behalf of multiple
merchants.)
Acquirer A Visa Member financial institution that:
• enters into a contractual relationship with a merchant for
purposes of accepting Visa cards
• determines the merchant’s eligibility to participate in
3-D Secure
Following payment authentication, the Acquirer performs its
traditional role:
• receives authorization requests from the merchant
• forwards them to the authorization system (such as VisaNet)
• provides authorization responses to the merchant
• submits the completed transaction to the settlement system
(such as VisaNet)
Table 2: Acquirer Domain Entities

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 2: Entity Overview 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 10 July 16, 2002

Interoperability Visa Directory The Visa Directory, operated by Visa:

domain
• receives messages from merchants querying a specific card
number
• determines whether the card number is in a participating
card range
• directs the request for cardholder authentication to the
appropriate ACS (in the Issuer domain) or responds
directly to the merchant
• forwards the response from the ACS to the merchant
Commercial Generates selected certificates for the use of 3-D Secure
Certificate entities, including:
Authority • SSL/TLS client and server certificates
Visa Certificate Generates selected certificates for the use of 3-D Secure
Authority entities, including:
• signing certificates
• Visa Root certificate
Authentication The Authentication History Server, operated by Visa:
History Server • receives a message from the ACS for each attempted
payment authentication (whether or not authentication was
successful)
• stores the records received
A copy of the data stored by the Authentication History Server
is available to Acquirers and Issuers in case of disputes.
Additional information describing how to populate this
database is provided in 3-D Secure: Functional
Requirements – Access Control Server.
VisaNet Following payment authentication, VisaNet performs its
traditional role:
• receives authorization requests from the Acquirer
• forwards them to the Issuer
• provides responses from the Issuer to the Acquirer
• provides clearing and settlement to the Acquirer and Issuer
Table 3: Interoperability Domain Entities

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 11

Chapter 3: Technical Requirements

Organization The technical requirements for 3-D Secure have been grouped into the following
categories:

Topic Page

Transport Security Requirements 12

Certificate Requirements 15
Redundant Routing Requirements 16
HTTP Connections 17

Message The following messages, which are discussed in detail in subsequent chapters, are
names occasionally mentioned in this one:
CRReq CRRes Card Range Request and Response
VEReq VERes Verify Enrollment Request and Response
PAReq PARes Payer Authentication Request and
Response1
Error Error message
An additional message pair, used to populate the Authentication History, is
mentioned only briefly in this document, and documented in detail in 3-D Secure:
Functional Requirements – Access Control Server:
PATransReq PATransRes Payer Authentication Transaction message
and Response
Table 4: 3-D Secure Messages

1Implementations that support mobile Internet devices use the Condensed Payer Authentication Request
and Response messages, CPRQ and CPRS. There are significant differences in transporting and
processing these messages, as well as differences in the associated VEReq and VERes messages. For
details, see 3-D Secure: Protocol Specification – Extension for Mobile Internet Devices, Visa
Publication 70006-01.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 3: Technical Requirements 3-D Secure: Protocol Specification
Transport Security Requirements Core Functions v1.0.2
Page 12 July 16, 2002

Transport Security Requirements

Channel The channels listed in Table 5 must be encrypted using 128-bit SSL cipher suite(s).
encryption The SSL servers that are described below must be capable of initiating sessions using
128-bit (or stronger) cipher suites, with the exception of the merchant which should
be capable of initiating such sessions if possible. Channels 1 and 2 must support the
40-bit SSL cipher suites, due to the proliferation of US-exportable browsers on
cardholder systems.
For additional certificate requirements, see page 15 and the Functional Requirements
documents listed in “3-D Secure specifications” on page 3.

1) Cardholder to This channel is used:

Merchant • for the cardholder to enter payment information
• to transport the PAReq from the Merchant Server Plug-in
to the cardholder
• to transport the PARes from the cardholder to the
Merchant Server Plug-in
The merchant must secure this channel with an SSL session
initiated using a server certificate.
2) Cardholder to This channel is used:
Access Control • to forward the PAReq to the ACS
Server (ACS) • to receive the signed PARes from the ACS
The ACS must secure this channel with an SSL session
initiated using a server certificate.
Processors operating an ACS on behalf of multiple Issuers
must be able to support using SSL server certificates specific
to each Issuer. The decision about whether to use multiple
certificates in a given implementation will be made based on
individual processor and Issuer business requirements.

Table 5: Transport Security Requirements

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 3: Technical Requirements
Core Functions v1.0.2 Transport Security Requirements
July 16, 2002 Page 13

3) Merchant to This channel is used to transport VEReq, VERes, CRReq,

Visa Directory CRRes, and Error.
The Visa Directory must secure this channel with an SSL
session initiated using a server certificate. The Visa Directory
must be able to authenticate the merchant using SSL client
certificates (during session initiation). The actual use of SSL
client certificates for authentication of the VEReq will
depend on specific regional requirements, but both systems
(Visa Directory and merchant) must be capable of supporting
client authentication.
4) Visa Directory This channel is used to transport the VEReq, VERes, and
to Access Error messages.
Control Server
The ACS must secure this channel with an SSL session
initiated using a server certificate and a client certificate for
the Visa Directory.
5) Merchant to When the validation process is implemented as a separate
Validation server, this channel is used to transport the PARes (for
Process validation) and the server’s response.
The validation process server must secure this channel with
an SSL session initiated using a server certificate. The
validation process server must authenticate the merchant
initiating the session; it may do so using SSL client
certificates or using another mechanism selected by the
Acquirer.
6) Merchant to This channel is used to transport the Error message.
Access Control
The ACS must secure this channel with an SSL session
Server
initiated using a server certificate.

Table 5: Transport Security Requirements, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 3: Technical Requirements 3-D Secure: Protocol Specification
Transport Security Requirements Core Functions v1.0.2
Page 14 July 16, 2002

SSL cipher The security protocol used at the transport layer for 3-D Secure is the Transport
suites Layer Security Protocol (TLS) defined in the IETF RFC 2246. This protocol
standard is based on the Netscape Secure Sockets Layer V3 (SSL).
TLS sessions for 3-D Secure must use one of the cryptographic suites listed in Table
6. The cryptographic suite listed as required must be supported; the suite listed as
optional may also be supported.
Note: If a session cannot be established using TLS, 3-D Secure components may
attempt to establish a session using SSL version 3.
Servers accepting connections from the browser (ACS and MPI) may use
US-exportable cipher suites to establish connections with the browser, but should
still attempt to establish as strong a connection as possible.

TLS_RSA_WITH_3DES_EDE_CBC_SHA required
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA optional
Table 6: Cryptographic Suites

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 3: Technical Requirements
Core Functions v1.0.2 Certificate Requirements
July 16, 2002 Page 15

Certificate Requirements

Table 7 lists the certificates that are necessary to implement 3-D Secure.
For more information regarding the Visa Certificate Authority Key Management
Policies, please see the Certificate Infrastructure Group documents described on
page 4.
Note: The Visa Root certificate is a self-signed certificate.

Entity Purpose Certificates Required

Merchant Server To authenticate the SSL client certificate
Plug-in merchant to the Visa Visa Root certificate and all other certificates needed to
Directory and an optional validate the client certificate
Validation Process Server
To protect the cardholder’s SSL server certificate
PAN data and the PAReq Visa Root certificate and all other certificates needed to
and PARes data validate the server certificate, if it was issued under the
Visa Root
Visa Directory To protect the VEReq and SSL server certificate
VERes data Visa Root certificate and all other certificates needed to
validate the server certificate
To authenticate the Visa SSL client certificate
Directory to the ACS Visa Root certificate and all other certificates needed to
validate the client certificate
Access Control To protect the VEReq, SSL server certificate
Server VERes, PAReq, and Visa Root certificate and all other certificates needed to
PARes data validate the server certificate, if it was issued under the
Visa Root
Note: Processors operating an ACS on behalf of
multiple Issuers must be able to use a different SSL
server (encryption) certificate for each Issuer.
To sign the PARes signing certificate (issued to Issuer)
message Visa Root certificate and all other certificates needed to
validate the signing certificate
Note: Processors operating an ACS on behalf of
multiple Issuers must be able to use a different signing
certificate for each Issuer.
Validation To validate the PARes Visa Root certificate and all other certificates needed to
Process Server message signature validate the server certificate
Table 7: Certificate Requirements

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 3: Technical Requirements 3-D Secure: Protocol Specification
Redundant Routing Requirements Core Functions v1.0.2
Page 16 July 16, 2002

Redundant Routing Requirements

Applications must support multiple path routing to the Visa Directory and Access
Control Server.

Visa Directory When the Visa Directory converts a domain name into an IP
address, it must retrieve all registered addresses from the domain
name server and attempt a connection with the alternate
address(es) if a session cannot be established with the primary
address.
Merchant Server When the Merchant Server Plug-in establishes a session with the
Plug-in Visa Directory and converts a domain name into an IP address, it
must retrieve all registered addresses from the domain name
server and attempt a connection with the alternate address(es) if a
session cannot be established with the primary address.
Table 8: Redundant Routing Requirements

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 3: Technical Requirements
Core Functions v1.0.2 HTTP Connections
July 16, 2002 Page 17

HTTP Connections

Persistent 3-D Secure components may use HTTP Keep Alive to establish persistent sessions
sessions with other 3-D Secure components.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 3: Technical Requirements 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 18 July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 19

Chapter 4: Setup and Cardholder Enrollment

Organization This chapter outlines a model implementation of the setup and cardholder enrollment
processes. Since the cardholder enrollment process is entirely within the Issuer
domain, alternate implementations are possible. The topics discussed within this
chapter are provided as background material for the reader.
The following topics are included:

Topic Page

Process Flow Diagram 20

Process Flow – Issuer Setup 21
Process Flow – Cardholder Enrollment 22

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 4: Setup and Cardholder Enrollment 3-D Secure: Protocol Specification
Process Flow Diagram Core Functions v1.0.2
Page 20 July 16, 2002

Process Flow Diagram

Figure 1 illustrates a possible architecture for cardholder enrollment.

1 Cardholder visits
Issuer enrollment site

Internet
Information stored for
later use in 3-D Secure
4 purchase transaction
authentication
Cardholder provides Enrollment
2 enrollment data, Server
establishes shared secret Acct
Holder
File

Issuer or
Third Party
Validation

3 Issuer verifies cardholder identity

Figure 1: Sample Cardholder Enrollment Process

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 4: Setup and Cardholder Enrollment
Core Functions v1.0.2 Process Flow – Issuer Setup
July 16, 2002 Page 21

Process Flow – Issuer Setup

Issuer setup 1) Issuer loads its Enrollment Server with data necessary for 3-D Secure
enrollment.
Table 9 lists data that may be needed.

a) Beginning of range (13 – 19 digits)

b) End of range (13 – 19 digits)
c) If applicable, the definitions of Issuer-specified
authentication data. (For example, “Place of Birth”.)
If this option is selected, one (1) to several fields may be
required.
d) The Issuer’s Terms of Use and Data Privacy Policy
e) Authentication methods supported by Issuer (depending
on the implementation, these methods may be an integral
part of the Enrollment Server or may be customizable by
the Issuer)
f) Data needed by the authentication methods, such as
conditions for approval of an enrollment request
Depending on the implementation, additional data may be
required. For example, a service operated on behalf of multiple
Issuers will also require information to identify the specific Issuer
that owns a particular card range.

Table 9: Sample Enrollment Server Data

2) Issuer provides to Visa the data needed to load the Visa Directory, as listed in
Table 27 on page 89.
3) Visa updates the Visa Directory.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 4: Setup and Cardholder Enrollment 3-D Secure: Protocol Specification
Process Flow – Cardholder Enrollment Core Functions v1.0.2
Page 22 July 16, 2002

Process Flow – Cardholder Enrollment

Cardholder A possible cardholder enrollment process follows:

enrollment
1) Cardholder visits the Issuer’s 3-D Secure Enrollment Web page and is required
to enter information such as that listed in Table 10.
2) The Issuer displays its 3-D Secure Terms of Use and Data Privacy Policy, an
ACCEPT button and a NOT ACCEPT button. If the cardholder selects ACCEPT,
enrollment proceeds. If the cardholder selects NOT ACCEPT, continue with
Step 7.
3) The Issuer’s 3-D Secure application validates that the PAN falls within a card
range that is registered in the Issuer’s Enrollment Server. If the PAN is not
within a defined range, the enrollment is rejected; continue with Step 7.
4) The Issuer’s 3-D Secure application displays an enrollment form to the
cardholder.
5) The Issuer matches the information entered by the cardholder against its own
records.
6) If not successful, an appropriate message is displayed to the cardholder and the
process continues with Step 4 (up to an Issuer-specified number of failed
attempts). If successful, the Issuer updates the 3-D Secure Account Holder
database. See sample data listed in Table 10.
7) The Issuer displays an appropriate completion-of-enrollment message to
cardholder.

a) PAN
b) Card Expiry Date
c) Cardholder Name
d) E-mail Address
e) Personal Assurance Message (PAM); created by the user, displayed within
the secret code prompt window to help reduce spoofing
f) Cardholder Password
g) Special question/hint
h) Special question/hint response
i) Issuer-specified authentication information

Table 10: Sample Cardholder Enrollment Data

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 23

Chapter 5: Purchase Transaction

Organization This chapter describes the components that are invoked and the messages that are
exchanged in a 3-D Secure purchase transaction. The following topics are included:

Topic Page

Purchase Transaction Architecture and Message Flows 24

Purchase Transaction Process Flow Description 26
Merchant Server Plug-in – load cache 26
Purchase transaction initiation 27
Merchant Server Plug-in – query PAN enrollment 27
Visa Directory – query ACS 28
Access Control Server – verify enrollment 30
Visa Directory – forward enrollment verification 32
Merchant Server Plug-in – receive enrollment verification 32
Merchant Server Plug-in – send payer authentication request 33
Access Control Server – receive payer authentication request 35
Access Control Server – authenticate shopper 36
Access Control Server – prepare payer authentication response 37
Access Control Server – return payer authentication response 38
Merchant Server Plug-In – validate payer authentication response 39
Payment authorization 40
Electronic commerce processing 40
Alternate account 40

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Architecture and Message Flows Core Functions v1.0.2
Page 24 July 16, 2002

Purchase Transaction Architecture and Message Flows

Figure 2 illustrates and page 25 describes the steps in the purchase transaction flow.

Issuer Domain Interoperability Domain Acquirer Domain

CARDHOLDER MERCHANT
MERCHANT
1

6
Plug-in
10

7 9 2
8
5
12
3 Visa
Access Directory
Control 4

9 Authentication
History

Issuer VisaNet Acquirer

Figure 2: Sample Purchase Transaction

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Architecture and Message Flows
July 16, 2002 Page 25

Step 1 Shopper browses at merchant site, adds items to shopping cart, then
finalizes purchase. (Note: Merchant now has all necessary data,
including PAN.)
Step 2 Merchant Server Plug-in (MPI) sends PAN (and user device information,
if applicable) to Visa Directory.
Step 3 If PAN is in participating card range, Visa Directory queries appropriate
Access Control Server (ACS) to determine whether authentication (or
proof of authentication attempt) is available for the PAN.
Step 4 ACS responds to Visa Directory.
Step 5 Visa Directory forwards ACS response to MPI.
Step 6 MPI sends Payer Authentication Request2 to ACS via shopper’s device.
Step 7 ACS receives Payer Authentication Request.
Step 8 ACS authenticates shopper using processes applicable to PAN
(Password, Chip, PIN, etc.),. Alternatively, ACS may produce a proof of
authentication attempt.
ACS then formats the Payer Authentication Response message with
appropriate values and signs it.
Step 9 ACS returns Payer Authentication Response3 to MPI via shopper’s
device. ACS sends selected data to Authentication History.
Step 10 MPI receives Payer Authentication Response.
Step 11 MPI validates Payer Authentication Response signature (either by
performing the validation itself or by passing the message to a separate
Validation Server).
Step 12 Merchant proceeds with authorization exchange with its Acquirer.

Figure 2: Sample Purchase Transaction, continued

2Payer Authentication Request message may be PAReq (for cardholders using PCs) or CPRQ (for
cardholders using mobile Internet devices – see 3-D Secure: Protocol Specification – Extension for
Mobile Internet Devices).
3 Payer Authentication Response message is PARes if PAReq was received, or CPRS if CPRQ was
received. (CPRS is created using values from the PARes.)

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 26 July 16, 2002

Purchase Transaction Process Flow Description

Merchant Step 0.
Server Plug-in
– load cache To eliminate the need to query the Visa Directory for each purchase transaction (in
Step 2), the merchant should have the ability to copy the contents of the Visa
Directory into a local cache. If this capability is used, the merchant can determine
immediately from the cache if the account is part of an enrolled range. If the
merchant implements this capability, the contents of the cache must expire and be
refreshed at least every 24 hours; the cache should be requested when the Merchant
Server Plug-In is loaded and at the same time each day that follows. The request time
must not be hard-coded. (This will help ensure that every Merchant Server Plug-In
(MPI) is not requesting the card range updates simultaneously.)
a) The MPI formats a Card Range Request (CRReq) message and sends it to the
Visa Directory.
If this is the first time the cache is being loaded (or if the cache has been flushed
and needs to be reloaded), the Serial Number element is not included in the
request, which will result in the Visa Directory Server returning the entire list of
participating card ranges.
Otherwise, the MPI should include the Serial Number from the most recently
processed CRRes, which will result in the Visa Directory Server only returning
the changes since the previous CRRes.
b) The Visa Directory validates the syntax of the CRReq and returns an Error if
validation fails.
The Visa Directory authenticates the merchant as described for VEReq in
Step 3a.
The Visa Directory formats a Card Range Response (CRRes) containing the
participating ranges and sends it to the MPI.
The Visa Directory includes a serial number in the response that defines the
current state of the card range database. (The specific value is only meaningful to
the Visa Directory Server that returns it.) The MPI should retain this value to be
included with the next day’s CRReq message.
c) The MPI validates the syntax of the CRRes and should send an Error to the
Visa Directory if validation fails.
The MPI updates its cache. The list must be processed in the order returned with
ranges being added or deleted as indicated by the Action element.
Note: If CRRes indicates an error condition regarding the Serial Number, the
MPI should clear its cache and submit the CRReq without a Serial Number.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 27

Purchase Step 1.
transaction
initiation a) Cardholder visits a merchant Web site via a browser and selects items to
purchase.
b) The cardholder checks out and finalizes the purchase transaction. At this point,
the merchant has all the information required to process the purchase transaction,
including the PAN, expiration date, and address information.
The PAN must be provided to the merchant during the checkout process either
via cardholder keyboard entry or a wallet function. The expiration date must be
no earlier than the current month.

Merchant Step 2.
Server Plug-in
– query PAN This process occurs after the final “Buy” click confirmation from the cardholder
enrollment during the merchant checkout process. when The merchant software invokes the
Merchant Server Plug-in (MPI) to handle determine whether payment authentication
is available for the PAN.
a) If the Merchant Server Plug-in (MPI) has implemented caching (as discussed in
“Merchant Server Plug-in – load cache” on page 26), it checks its cache of
participating card number ranges.
If the PAN is not in one of the ranges:
• Continue with Step 12 on page 40.
b) The MPI formats a Verify Enrollment Request (VEReq) message.
c) The MPI determines whether it currently has a secure connection with the Visa
Directory.
If not, the MPI establishes an SSL connection with the Visa Directory. If the
Visa Directory configuration indicates that the merchant has been issued an SSL
client certificate, it will require the merchant to present it during the
establishment of the SSL session.
If connection cannot be established or if authentication fails, continue with
Step 12 on page 40.
d) The MPI posts the VEReq to the Visa Directory.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 28 July 16, 2002

Visa Directory Step 3.

– query ACS
This process occurs immediately after the Visa Directory receives the VEReq from
the Merchant Server Plug-in.
a) The Visa Directory validates the syntax of the VEReq and returns an Error if
validation fails.
The Visa Directory validates the VEReq data, ensuring that each of the
following is true:
• The Acquirer BIN represents a participating Acquirer.
• The Merchant ID represents a participating merchant of the Acquirer
identified by Acquirer BIN.
• If the Visa region of the Acquirer requires a merchant password for
3-D Secure:
a value for Password was received, and
it is valid for the combination of Acquirer BIN and Merchant ID.
If any of these tests fails:
• The Visa Directory formats a Verify Enrollment Response (VERes)
including:
PAN Authentication Available set to “N”
no Account Identifier, ACS URL or Payment Protocols
Invalid Request set to the corresponding value from Table 20 on
page 60.
• The Visa Directory returns the VERes to the Merchant Server Plug-in and
stops.
• Continue with Step 12 on page 40.
b) The Visa Directory searches for a record specifying a card range that includes
the Cardholder PAN that was received in the VEReq.
If not found:
• The Visa Directory formats a Verify Enrollment Response (VERes) message
including:
PAN Authentication Available set to “N”
no Account Identifier, ACS URL, Payment Protocols, or
Invalid Request
• The Visa Directory returns VERes message to the Merchant Server Plug-in
and stops.
• Continue with Step 12 on page 40.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 29

Visa Directory Step 3, continued.

– query ACS,
continued c) The Visa Directory determines whether it currently has a secure connection with
the ACS.
If not, then the Visa Directory establishes an SSL connection with the ACS. The
SSL client certificate of the Visa Directory and the server certificate of the ACS
must be presented and validated during the establishment of the SSL session.
If the first URL attempted is not available, each successive URL value (if
provided) will be attempted the Visa Directory will attempt to connect to up to
four alternate URLs that are optionally configured for each ACS.
If unsuccessful on all attempts:
• The Visa Directory formats a Verify Enrollment Response (VERes) message
including:
PAN Authentication Available set to “N”
no Account Identifier, ACS URL, Payment Protocols, or
Invalid Request
• The Visa Directory returns VERes message to the Merchant Server Plug-in
and stops.
• Continue with Step 12 on page 40.
d) The Visa Directory removes the Password field from the VEReq message and
forwards the message to the ACS URL.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 30 July 16, 2002

Access Step 4.
Control
Server – This process occurs immediately after the ACS receives the VEReq message via the
verify Visa Directory. The ACS validates the syntax of the VEReq and returns an Error if
enrollment validation fails.
Note: When it is not possible to authenticate a payment transaction, it is sometimes
possible to provide a proof of authentication attempt instead. Such processing
significantly changes the ACS processing logic, and is described in 3-D Secure:
Functional Requirements – Access Control Server, Visa publication 70002-01.
a) The ACS uses the Cardholder PAN from the VEReq message and queries the
Account Holder database to determine whether the cardholder is enrolled.
b) If the PAN was not found, the ACS formats a Verify Enrollment Response
(VERes) message including:
PAN Authentication Available set to “N”
no Account Identifier, ACS URL, Payment Protocols, or
Invalid Request
Continue with Step 4f below.
c) If Device Category is present:
• If the ACS cannot process transactions sent by the device category indicated
or if the ACS does not recognize the device category value, the ACS formats
a Verify Enrollment Response (VERes) message including:
PAN Authentication Available set to “U”
no Account Identifier, ACS URL, Payment Protocols, or
Invalid Request
Continue with Step 4f below.
d) If either Accept Headers or User Agent is present:
• If the ACS cannot process transactions sent by the cardholder device or the
user agent indicated by the values of those elements, the ACS formats a
Verify Enrollment Response (VERes) message including:
PAN Authentication Available set to “U”
no Account Identifier, ACS URL, Payment Protocols, or
Invalid Request
Continue with Step 4f below.
• If special processing is required, continue processing as described in the
appropriate document (for example, the mobile Internet extension described
in “3-D Secure Specifications” on page 3).

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 31

Access Step 4, continued.

Control
Server – e) The ACS formats a Verify Enrollment Response (VERes) message including:
verify PAN Authentication Available set to “Y”
enrollment,
continued an Account Identifier that the ACS internally associates with the
PAN (note that this identifier may must not be the PAN or any string
useful to the ACS)
the ACS URL to be used to transmit the PAReq
Payment Protocols set as defined on page 52
no Invalid Request
f) The ACS sends the VERes message to the Visa Directory.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 32 July 16, 2002

Visa Directory Step 5.

– forward
enrollment From the point of view of the Visa Directory, this process occurs immediately after
verification the Visa Directory forwards the VEReq message to the ACS URL. (From the point
of view of the ACS, it occurs immediately after the ACS sends the VERes message
to the Visa Directory.)
a) The Visa Directory reads the response, which contains the corresponding
VERes or Error. The Visa Directory validates the syntax of the VERes and
returns an Error to the ACS if validation fails.
b) If the message received from the ACS is syntactically correct, the Visa Directory
forwards the VERes or Error to the MPI.
c) If the message received from the ACS is not syntactically correct:
• The Visa Directory formats a Verify Enrollment Response (VERes) message
including:
PAN Authentication Available set to “N”
no Account Identifier, ACS URL, Payment Protocols, or
Invalid Request
• The Visa Directory returns the VERes message to the Merchant Server
Plug-in and stops.
• Continue with Step 12 on page 40.

Merchant Step 5, continued.

Server Plug-in
– receive From the point of view of the Merchant Server Plug-in, this process occurs
enrollment immediately after the MPI posts the VEReq to the Visa Directory. (From the point
verification of view of the Visa Directory, it occurs immediately after the Visa Directory
forwards the VERes to the MPI.)
a) The MPI reads the response, which contains the corresponding VERes or
Error.
b) If an Error message is received, continue with Step 12 on page 40.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 33

Merchant Step 6.
Server Plug-in
– send payer This process occurs immediately after the Merchant Server Plug-in (MPI) receives
authentication the VERes message from the Visa Directory. The MPI validates the syntax of the
request VERes and should send an Error to the Visa Directory if validation fails.
a) If the value of PAN Authentication Available is not equal to “Y”, continue
with Step 12 on page 40.
b) Examine the Payment Protocols and select the desired protocol to be used. If
that protocol is “ThreeDSecure”, continue processing; if it is a protocol other
than “ThreeDSecure”, execute the appropriate processing for the selected
protocol.
Note: The protocol selection is made based on the capabilities of the merchant
systems as well as region, Acquirer and merchant policies.
c) The MPI formats a Payer Authentication Request message (PAReq) including
the Account Identifier received in VERes.
d) The MPI deflates and Base64-encodes the PAReq as described in Appendix D
on page 91. The result is referred to as PaReq (note the case difference).

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 34 July 16, 2002

Merchant Step 6, continued.

Server Plug-in
– send payer e) The MPI constructs a form containing the following fields:
authentication
request, PaReq (note The result of the previous step.
continued case)
TermUrl The merchant URL to which the final reply must be
posted.
MD The MD (“Merchant Data”) field: merchant state
data that must be returned to the merchant.
This field is used to accommodate the different
ways merchant systems handle session state. If the
merchant system can associate the final post with
the original shopping session without any further
assistance, the MD field may be empty. If the
merchant system does not maintain state for a given
shopping session, the MD can carry whatever data
the merchant needs to continue the session.
Since the content of this field varies by merchant
implementation, the ACS must preserve it
unchanged and without assumptions about its
content.
This field must contain only ASCII characters in the
range 0x20 to 0x7E; if other data is needed, the field
must be Base64 encoded. The size of the field (after
Base64 encoding, if applicable) is limited to 1024
bytes.
If MD includes confidential data (such as the PAN),
it must be encrypted.
f) The MPI passes the PAReq through the cardholder browser to the ACS URL
received in the VERes, by causing the cardholder browser to POST the form to
the ACS. This is typically accomplished by using JavaScript. (For further detail,
see 3-D Secure: Functional Requirements – Merchant Server Plug-in.) All
connections are HTTPS to accommodate the cardholder browser.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 35

Access Step 7.
Control
Server – This process occurs immediately after the ACS receives the post including the
receive payer PAReq from the Merchant Server Plug-in. The following description applies to the
authentication case where cardholder authentication is performed using a password. Other
request methods, such as those that rely on applications on a chip card, may be used.
a) The ACS Base64-decodes and inflates the PaReq field reversing the process
described in Appendix D on page 91 to obtain the PAReq (note the case
difference). The ACS validates the syntax of the PAReq and returns an Error if
validation fails.
The ACS validates the PAReq data, ensuring that each of the following is true:
• The ACS is able to link the PAReq with a VERes in which the value of
PAN Authentication Available was “Y”.
The validation may take place through whatever mechanism the ACS
chooses, such as by comparing the Account Identifier supplied in the
two messages or by correlating the URL to which the message was
posted to a customized ACS URL supplied in VERes.
• The Merchant Country Code is a valid ISO 3166 Country Code.
• The Purchase Currency is a valid ISO 4217 numeric currency code.
• Purchase Amount equals Display Amount.
If any of these tests fails:
The ACS formats a Payer Authentication Response (PARes) message
with Transaction Status set to “N” and Invalid Request set to
appropriate values as outlined in Table 20 on page 60.
Continue with Step 8f on page 37.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 36 July 16, 2002

Access Step 8.
Control
Server – a) If the cardholder is not enrolled, display a message such as “Processing…” and
authenticate continue with Step 8d.
shopper
The ACS responds to the post with an HTML page that displays a form to the
cardholder, including items such as those listed in Table 11. (The specific contents
of the form are the choice of the Issuer, subject to any applicable regional
requirements. See Figure 3 for an example.)
From From
Data Item
ACS PAReq
Member logo X
Visa Mark or Brand logo X
Merchant name X
Total amount and currency X
Merchant date (month, day and year) X
PAN (xxx out except for last four digits) X
Note: If the Account Identifier used by the Issuer ACS in
the message exchange is not the cardholder’s PAN, The ACS
needs to correlate the identifier received in the PAReq with
the actual PAN stored in the Account Holder database.
Personal Assurance Message (PAM) X
Prompt for Cardholder Password X
Table 11: Example Fields Displayed for Cardholder Authentication

Member Bank

Volcano Coffee
Total Charge $21.90 USD Sept. 21, 2001
Card Number: XXXXXXXXXXXX6069
Personal Assurance Message: EARNESTWINHOFFER

Visa Password

? Cancel Submit

Security Help

Figure 3: Sample Authentication Form

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 37

Access Step 8, continued.

Control
Server – b) The ACS prompts the cardholder to enter the Visa Password.
authenticate
shopper, c) The ACS accepts the cardholder input and validates it against the Account
continued Holder database.
d) The ACS sets Transaction Status as described in Table 12.
condition value of Transaction Status
the password is correct Y
the password is incorrect N
it is not possible to validate the password U
(for example, because of the failure of an
ACS system component such as the
cardholder database)
Proof of authentication attempt was A
generated
Table 12: ACS Sets Transaction Status

Access Step 8, continued.

Control
Server – e) The ACS formats a Payer Authentication Response (PARes) message,
prepare payer including Transaction Status.
authentication
response If the transaction was authenticated successfully (that is, the value of
Transaction Status is “Y”) or if a proof of authentication attempt was
generated (that is, the value of Transaction Status is “A”), a Cardholder
Authentication Verification Value (cavv) is generated and included in
PARes. (See 3-D Secure: Functional Requirements – Access Control Server
for information about generating the Cardholder Authentication
Verification Value.)
If the transaction was not authenticated successfully, the ACS must return all
zeros in the PAN field.
f) The ACS digitally signs the message.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 38 July 16, 2002

Access Step 9.
Control
Server – a) The ACS deflates and Base64-encodes the PARes formatted and signed in
return payer Step 8 (or an Error message if one has been generated) as described in
authentication Appendix D on page 91. The result is referred to as PaRes (note case
response difference).
b) The ACS constructs a form containing the following fields:
PaRes (note case) The result of the previous step.
MD The exact content of the MD field as posted to the
ACS, unchanged.
The ACS passes the signed PARes through the cardholder’s browser to the
merchant’s URL (TermUrl in the post from the MPI) by causing the cardholder
browser to POST the form to the MPI. In the process, the popup is closed and
control is returned to the merchant’s browser window. This is typically
accomplished by using JavaScript. (For further detail, see 3-D Secure:
Functional Requirements – Access Control Server.)
c) The ACS formats a Payer Authentication Transaction (PATransReq) message
and sends it to the Authentication History Server. See 3-D Secure: Functional
Requirements – Access Control Server for the requirements for the data and
for its transmission.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 5: Purchase Transaction
Core Functions v1.0.2 Purchase Transaction Process Flow Description
July 16, 2002 Page 39

Merchant Step 10.

Server Plug-In
– validate This process occurs after the Merchant Server Plug-in posts the PAReq to the ACS.
payer
authentication a) The MPI reads the response, which contains the PaRes field. The MPI Base64-
response decodes and inflates the PaRes field reversing the process described in
Appendix D on page 91 to obtain the PARes (note the case difference) or
Error.
b) If an Error message is received, continue with Step 12 on page 40.
c) The MPI validates the syntax of the PARes and should send an Error to the
ACS (via the ACS URL received in the VERes) if validation fails.
Step 11.
The Validation Process validates the PARes signature using the Visa Root
Certificate. Note that this may either be an integral part of the Merchant Server
Plug-in or may be implemented as an independent Validation Server.
a) The Validation Process validates the PARes signature. If implemented using a
separate Validation Server:
• The Merchant Server Plug-in sends the PARes to the Validation Process.
• Validation Process validates the signature on the PARes using the Visa Root
Certificate.
• Validation Process returns the result of signature validation to the Merchant
Server Plug-in.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 5: Purchase Transaction 3-D Secure: Protocol Specification
Purchase Transaction Process Flow Description Core Functions v1.0.2
Page 40 July 16, 2002

Payment Step 12.

authorization
This process occurs after the previous steps have been completed.
a) Depending on the results of the previous steps, the Merchant Server Plug-In
must notify the merchant payment system of the appropriate action to take from
the following table.

If the following condition then:

applies:
If signature validation was Merchant proceeds with a normal payment
successful in Step 11 and authorization using field values from the
Transaction Status is “Y” or PARes.
“A”
If signature validation was Merchant must not process a payment
successful in Step 11 and authorization using this account. The merchant
Transaction Status is “N” may request an alternate account (as described
below).
If signature validation failed, or Merchant may proceed with a normal payment
if Transaction Status is “U” authorization (see “Electronic commerce
processing” below) or request an alternate
account (as described below).
Table 14: Merchant Payment System Follow-up

Electronic If authentication was not able to could not be performed, the merchant may proceed
commerce with a normal payment authorization using the available information from the
processing checkout process. In this case, the merchant payment system must process the
transaction as an unauthenticated electronic commerce transaction, which is out-of-
scope to this document.
Note: The Electronic Commerce Indicator must be set to a value corresponding to
the authentication results and the characteristics of the checkout process.

Alternate If the merchant is unable to process an authenticated transaction using the account
account selected by the cardholder during the checkout process, the merchant may either
abandon the transaction or give the customer the option of selecting an alternate
account.
If an alternate account is selected, the authentication process must be repeated
starting with Step 1 for that account.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 41

Chapter 6: Message Descriptions

Organization This section describes the following messages and content:

Topic Page

CRReq 46
CRRes 47
VEReq 49
VERes 51
PAReq 53
PARes 57
Invalid Request Values 60
Message Extensions 61
Error Message 63

Format All listed messages are in XML format. For details, see Appendix A on page 65.

Inclusion In the tables that follow, the Inclusion column includes the values in the following
values table:
Meaning Sender requirements Recipient requirements
R Required must include the field must check for presence of the
field and validate its contents
C Conditional must include the field if must:
the conditions are • check for presence of the
satisfied field when the conditions
are satisfied, and
• validate its contents when
present
O Optional may include the field must validate the contents
when present

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
Message Handling Core Functions v1.0.2
Page 42 July 16, 2002

Message Handling

Versioning In order to support future versions of the protocol, implementations must use (or
and parsing configure) XML parsers that do not validate strictly. Specifically, unrecognized
fields in a message must be silently ignored (unless the field has a critical attribute
with a value of “true”).
Implementations built to this specification must support messages having the
following version numbers:
• 1.0.1
• 1.0.2
In addition, components must deal with higher version numbers (for example, a
component built to these specifications must deal with any version 1.1 message it
receives) as follows:
Visa Directory The Visa Directory always forwards a VERes from the ACS
without regard to the version number of the message.
If the Visa Directory receives a request with a higher version
number than it supports:
• If the message is VEReq, the Visa Directory ignores
unrecognized elements.
• otherwise If the message is anything other than VEReq, if the
message contains any unrecognized element that has an
attribute of critical with a value of “true”, the application must
return an Error message (using the highest supported message
version) with the value of ErrorCode set to 4 (critical element
not recognized).
• The request is processed and the response (if any) is generated
using the highest supported protocol version.
If a request is received with a lower version number, the response
must conform to the version of the protocol indicated in the
request.
Note: Typically, the Visa Directory Server will be updated to the
latest version of this protocol.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 Message Handling
July 16, 2002 Page 43

Versioning Access If the ACS receives a request with a higher version number than it
and Parsing, Control supports:
continued Server
• If the message contains any unrecognized element that has an
attribute of critical with a value of “true”, the application must
return an Error message (using the highest supported message
version) with the value of ErrorCode set to 4 (critical element
not recognized).
• Otherwise, the request is processed and a response is generated
using the highest supported protocol version.
If a request is received with a lower version number, the response
must conform to the version of the protocol indicated in the
request.
Merchant The MPI may send CRReq and VEReq messages that reflect the
Server Plug-in latest version of this protocol (or any older supported version).
However, if the Visa Directory Server returns an Error message
with the value of ErrorCode set to 6, the MPI must use the
version found in the Error message for any subsequent CRReq or
VEReq messages.
In addition, if a VERes contains a lower version number, the MPI
must generate the subsequent PAReq message (if any)
conforming to the version of the protocol indicated in the VERes.

The id Request and response pairs are matched using the id attribute of the Message
attribute: element. The id attribute of a request must be generated by the sender using an
Message algorithm that is likely to generate unique ids; the id attribute of the response must
element
be copied from the corresponding request. For example:
• the MPI assigns the id of the Message element that contains VEReq, and
• the id returned by the ACS in the Message element that contains VERes
matches the id assigned by the MPI.

The id The id attribute of the PARes element is generated by the ACS and used within the
attribute: signature element to refer to the PARes. (See the signature example on page 67.)
PARes
element

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
Message Handling Core Functions v1.0.2
Page 44 July 16, 2002

HTTP POST Requests are sent via a POST using HTTPS. Messages exchanged between
3-D Secure components are either XML documents or HTML pages with forms
including fields of 3-D Secure elements. In particular:
For VEReq, VERes, CRReq, and CRRes:
• The ‘Content-Length:’ header must be present (and set to the length of the
message body).
• The ‘Content-Type:’ header must be present and contain the value:
application/xml; charset=utf-8
Note: For POSTs through the cardholder browser (merchant to ACS and ACS to
merchant), the browser automatically assigns the Content-Type (typically, the value
will be application/x-www-form-urlencoded).
Responses are formatted in a similar manner (including the Content-Length and
Content-Type) and sent in the reply to the HTTP POST.

Handling XML All XML messages transferred within 3-D Secure must use the default and
data recommended encoding of “utf-8” as described in Extensible Markup Language
(XML) W3C Recommendation (see “References” on page 3 of this document).

Digital XML digital signatures for 3-D Secure messages must be generated using the
signatures algorithms defined in Appendix A on page 66.
Note: The minimum key length for the RSA key used to generate the signature is 768
bits; however, a key length of 1024 bits is recommended.

Partial system A 3-D Secure component may experience system failures that effectively render the
outages component inoperable. For example:
• The Visa Directory may not be able to access the database containing ACS URLs.
• An ACS may not be able to access the database containing the list of enrolled
cardholders.
• An ACS may not be able to access its hardware security module providing digital
signature processing.
When such failures are detected, the component should close its TCP/IP ports and
stop accepting requests until the failure has been corrected. An Error response with
an Error Code of 98 or 99 should be sent for any outstanding requests.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 Message Handling
July 16, 2002 Page 45

Message The DTD allows multiple requests or responses to be included in a single 3-D Secure
bundling message. However, this functionality has not been extensively tested with existing
implementations of 3-D Secure. 3-D Secure components must embed exactly one
3-D Secure message (CRReq, CRRes, VEReq, etc.) in a ThreeDSecure
element.

Error Codes Future versions of this specification (including future errata) may define additional
and Invalid error and invalid request codes. All 3-D Secure components must accept any numeric
Request value in the Error Code field and the Invalid Request Code field.
Codes
If the list of Error Code values in Table 23 or the list of Invalid Request Code
values in Table 20 does not contain an entry that matches a condition detected by a
3-D Secure component, the vendor should select a reasonably close match. Requests
for new values should be submitted using the 3-D Secure change control process.
Note that new values will not be defined to provide detailed information about the
cause of a failure that is unrelated to the message received.
Detailed Error Code values are intended to give the other party information needed
to find and fix a problem in its system. For example:
• If an MPI has sent an invalid value in one of the fields of a PAReq, it needs to
know which field is at fault.
• However, if the ACS is unable to authenticate a card number for reasons that
have nothing to do with the message received (for instance, because it is unable to
access the database of enrolled cardholders, or because the cardholder canceled
the transaction), the specific reason does not matter to the merchant.

Message All 3-D Secure messages must be well formed XML and the fields of the messages
validation must conform to the requirements described on the following pages. The recipient of
a 3-D Secure message must validate that the message conforms to these
requirements. If the message does not conform to the requirements, the recipient
sends an Error message with an Error Code that corresponds to the reason for the
failure.

Version A valid 3-D Secure version number will always be in the format
numbers major.minor[.update] (such as 1.0 or 1.0.1).
When the root element of a message is ThreeDSecure, any version number less
than 1.0.1 is an error. The 3-D Secure component must return an Error message with
an Error Code of 6.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
CRReq Core Functions v1.0.2
Page 46 July 16, 2002

CRReq

Purpose The CRReq (Card Range Request) is sent from the Merchant Server Plug-in (MPI)
to the Visa Directory to request the list of participating card ranges in order to update
the MPI’s internal cache information.

CRReq fields The following table lists the defined fields for a CRReq message:

Field Name DTD Element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
Acquirer BIN Merchant. R Variable length (up to 11 digits) acquiring
acqBIN institution identification code; typically this is a
6-digit BIN assigned to the Acquirer by Visa.
Merchant ID Merchant.merID R Acquirer-defined merchant identifier, up to 24
characters:
• up to 15 byte alphanumeric Card Acceptor ID
• optionally followed by a hyphen and an up to
8 byte alphanumeric Card Acceptor Terminal
ID
Password Merchant. C 8 character alphanumeric merchant password
password (provided by Acquirer).
The requirements for use of this field will be
indicated in the Member Implementation Guide.
Serial Number serialNumber O A value returned in a previous CRRes. If this
element is present, the Visa Directory Server
returns card ranges that have been updated since
the time of the CRRes; if this element is not
present, the Visa Directory Server returns all
participating card ranges.
Maximum length is 20 digits, to hold a 64-bit
unsigned integer.
Table 13: CRReq Fields

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 CRRes
July 16, 2002 Page 47

CRRes

Purpose The CRRes (Card Range Response) is sent from the Visa Directory to the Merchant
Server Plug-in (MPI) in response to a CRReq messages. It is used to provide the
list of participating card ranges in order to update the MPI’s internal cache
information.

CRRes fields The following table lists the defined fields for a CRRes message:

Field Name DTD Element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
Card Range CR C If CRReq does not include Serial Number, a
CR element is included for each card range
populated in the Visa Directory.
If CRReq includes Serial Number:
• If the value of CRReq.serialNumber is
current, indicating that the Visa Directory
Server data has not changed since the previous
CRReq from this merchant, no CR elements
are returned.
• Otherwise, only CR elements that have been
added or deleted since the previous CRReq
are returned.
CR is absent when IReq is present.
The card range consists of three data elements as
listed below.
First Number in CR.begin R 13 – 19 digit Account Number from Visa
Card Range Directory.
Last Number in CR.end R 13 – 19 digit Account Number from Visa
Card Range Directory. (Must be the same length as First
Number in Card Range.)
Action CR.action R Indicates the action to take with the card range:
A = Add the card range to the cache.
D = Delete the card range from the cache.
The card ranges must be processed in the order
returned.
Note: If the serial number was not included in the
CRReq the action is add for all ranges returned.
Table 14: CRRes Fields

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
CRRes Core Functions v1.0.2
Page 48 July 16, 2002

Field Name DTD Element Inclusion Description

Serial Number serialNumber RC An integer indicating the current state of the card
range database. (The specific value is meaningful
only to the Visa Directory Server.) The MPI
should retain this value for submission in a future
CRReq to request only changes that have been
made to the participating card range list since this
message was generated.
Maximum length is 20 digits, to hold a 64-bit
unsigned integer.
If Invalid Request Code is included, Serial
Number should be set to zero must be omitted.
Invalid Request IReq.iReqCode C Code indicating data that is formatted correctly,
Code but which invalidates the request. This element is
included when the CRReq is syntactically
correct, but business processing cannot be
performed for one of the reasons defined in Table
20 on page 60, which also provides the possible
values.
If Invalid Request Code is included, the
Merchant Server Plug-In should ignore the
contents of Serial Number.
Invalid Request IReq.iReqDetail C May identify the specific data elements that
Detail caused the Invalid Request Code (so never
supplied if Invalid Request Code is omitted).
See Table 20 on page 60 for details.
Vendor Code IReq. O Vendor specific error code (or explanatory text)
vendorCode to be used for trouble shooting (max 256
characters). Determined by the Visa Directory.
Table 14: CRRes Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 VEReq
July 16, 2002 Page 49

VEReq

Purpose The VEReq (Verify Enrollment Request) is sent by the Merchant Server Plug-in
(MPI) to the Visa Directory to determine whether authentication is available for a
particular PAN.

VEReq fields The following table lists the defined fields for a VEReq message:

Field Name DTD Element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
Cardholder PAN pan R 13 – 19 digit Account Number; it must be the
same PAN that will be used in the authorization
request. The value may be:
• the account number on the card
• a permanent account number that’s only used
online
• produced by the wallet as a proxy
• pulled from the merchant’s local wallet
• or any other number that can be submitted for
authorization.
Acquirer BIN Merchant. R Variable length (up to 11 digits) acquiring
acqBIN institution identification code; typically this is a
6-digit BIN assigned to the Acquirer by Visa.
Merchant ID Merchant.merID R Acquirer-defined merchant identifier, up to 24
characters:
• up to 15 byte alphanumeric Card Acceptor ID
• optionally followed by a hyphen and an up to
8 byte alphanumeric Card Acceptor Terminal
ID
Password Merchant. C 8 character alphanumeric merchant password
password (provided by Acquirer).
The requirements for use of this field will be
indicated in the Member Implementation Guide.
Table 15: VEReq Fields

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
VEReq Core Functions v1.0.2
Page 50 July 16, 2002

Field Name DTD Element Inclusion Description

Device Category Browser. O Indicates the type of cardholder device. Current
deviceCategory defined values are:
0 = PC (HTML)
1 = mobile Internet device (WML)
Additional values may be defined at any time. All
components must accept any positive integer
value in this field.
If no value is provided, 0 is implied.
Accept Headers Browser.accept C The exact content of the HTTP accept header as
sent to the merchant from the cardholder’s user
agent.
Required if the cardholder’s user agent supplied a
value.
User Agent Browser. C The exact content of the HTTP user-agent header
userAgent as sent to the merchant from the cardholder’s user
agent.
Required if the cardholder’s user agent supplied a
value.
Message Extension O Any data necessary to support the requirements
Extension that are not otherwise defined in the VEReq
message must be carried in an instance of
Message Extension.
See page 61 for additional information about this
element.
Table 15: VEReq Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 VERes
July 16, 2002 Page 51

VERes

Purpose The VERes (Verify Enrollment Response) is sent

• by the ACS via the Visa Directory, or
• by the Visa Directory
to the Merchant Server Plug-in to advise the merchant whether authentication is
available for a particular PAN.

VERes fields The following table lists the defined fields for a VERes message:

Field Name DTD Element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
PAN CH.enrolled R Indicates whether the Account Identifier can be
Authentication authenticated:
Available Y = Authentication Available
N = Cardholder Not Participating
U = Unable To Authenticate
“U” applies whether the inability to authenticate
is due to technical difficulties or non-inclusion in
program.
Account CH.acctID C The content of this field is at the discretion of the
Identifier Issuer. This may be the actual PAN or an
alternative a data string useful to the ACS; it must
not reveal the PAN and must be generated using
an algorithm that is likely to generate unique
values.
Must be supplied if the value of PAN
Authentication Available is “Y”.
Up to 28 characters.
ACS URL url C Fully qualified URL of Access Control Server.
Must be supplied if the value of PAN
Authentication Available is “Y”.
Table 16: VERes Fields

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
VERes Core Functions v1.0.2
Page 52 July 16, 2002

Field Name DTD Element Inclusion Description

Payment protocol C Indicates which payment protocols are supported
Protocols by the Issuer system for the Cardholder PAN
specified in VEReq.
If the value of PAN Authentication Available
is “Y”, at least one instance of this element must
be included.
Possible values are:
ThreeDSecure indicates that the 3-D Secure
protocol is supported by the
Issuer system for this PAN
SET indicates that the SET Secure
Electronic Transaction™
protocol is supported by the
Issuer system for this PAN
Invalid Request IReq.iReqCode C Code indicating data that is formatted correctly,
Code but which invalidates the request. This element is
included when the VEReq is syntactically
correct, but business processing cannot be
performed for one of the reasons defined in Table
20 on page 60, which also provides the possible
values.
Note that when IReq is included, the value of
PAN Authentication Available is always “N”.
Invalid Request IReq.iReqDetail C May identify the specific data elements that
Detail caused the Invalid Request Code (so never
supplied if Invalid Request Code is omitted).
See Table 20 on page 60 for details.
Vendor Code IReq. O Vendor specific error code (or explanatory text)
vendorCode to be used for trouble shooting (max 256
characters). Determined by entity creating the
VERes.
Message Extension O Any data necessary to support new requirements
Extension that are not otherwise defined in the VERes
message must be carried in an instance of
Message Extension.
See page 61 for additional information about this
element.
Table 16: VERes Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 PAReq
July 16, 2002 Page 53

PAReq

Purpose The PAReq (Payer Authentication Request) message is sent by the Merchant Server
Plug-in to the ACS through the cardholder system, providing the data required to
attempt cardholder authentication.

PAReq fields The following table lists the defined fields for a PAReq message:

Field Name DTD element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
Acquirer BIN Merchant. R From VEReq.
acqBIN
Merchant ID Merchant.merID R From VEReq.
Merchant Name Merchant.name R Character String (max 25 characters), determined
by merchant.
Merchant Merchant. R Three digit ISO-3166 Country Code. Determined
Country Code country by merchant. The same value must be used in the
authorization request.
Merchant URL Merchant.url R Fully qualified URL of merchant site.
Transaction Purchase.xid R Unique transaction identifier determined by
Identifier merchant. Contains a 20 byte statistically unique
value that has been Base64 encoded, giving a 28
byte result.
Purchase Date Purchase.date R Date and time of purchase expressed in GMT in
& Time the following format:
YYYYMMDD HH:MM:SS
Display Amount Purchase. R Determined by merchant; must correspond to
amount Purchase Amount.
Character string (up to 20 characters) that is
displayable to the user.
Purchase Purchase. R Determined by merchant.
Amount purchAmount 12-digit numeric amount in minor units of
currency with all punctuation removed.
Examples:
Display Amount $123.45
Purchase Amount 12345
Table 17: PAReq Fields

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
PAReq Core Functions v1.0.2
Page 54 July 16, 2002

Field Name DTD element Inclusion Description

Purchase Purchase. R Determined by merchant. ISO 4217, 3 digit
Currency currency numeric.
Currency Purchase. R The minor units of currency specified in
Exponent exponent ISO 4217. For example, US Dollars has a value
of 2; Japanese Yen has a value of 0.
Order Purchase.desc O Brief description of items purchased, determined
Description by the merchant.
Maximum size is 125 characters, but merchant
should consider the characteristics of the
cardholder’s device when creating the field.
Recurring Purchase.Recur C A Recur element must be included if the
Payment Data merchant and cardholder have agreed to recurring
payments.
The recurring payment data consists of two data
elements as listed below.
Recurring Recur. R An integer indicating the minimum number of
Frequency frequency days between authorizations.
See “Recurring Frequency” on page 56 for
additional information.
Recurring Recur. R The date after which no further authorizations
Expiry endRecur should be performed. (YYYYMMDD format).
This date must be in the future.
See “Recurring Expiry” on page 56 for additional
information.
Installment Purchase.install C An integer greater than one indicating the
Payment Data maximum number of permitted authorizations for
installment payments.
Must be included if the merchant and cardholder
have agreed to installment payments.
Account CH.acctID R From VERes.
Identifier
Card Expiry CH.expiry R Expiration Date supplied to merchant by
Date cardholder. (YYMM).
Table 17: PAReq Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 PAReq
July 16, 2002 Page 55

Field Name DTD element Inclusion Description

Message Extension O Any data necessary to support the requirements
Extension that are not otherwise defined in the PAReq
message must be carried in an instance of
Message Extension.
See page 61 for additional information about this
element.
Table 17: PAReq Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
PAReq Core Functions v1.0.2
Page 56 July 16, 2002

Recurring The value of Recur.frequency indicates the minimum number of days between
Frequency authorizations. A frequency of monthly is indicated by a value of 28. The earliest
possible date for each authorization is based on the actual date of the prior
authorization.
Table 18 illustrates the earliest possible dates for a subsequent authorization when
the value of Recur.frequency is 28. Later authorizations are acceptable (until
Recur.endRecur).

if the most recent then the earliest possible but the next
authorization was dated: date for the next authorization typically
authorization is: occurs on:
December 31, 2000 January 28, 2001 January 31, 2001
January 28, 2001 February 25, 2001 February 28, 2001
January 31, 2001 February 28, 2001 February 28, 2001
Table 18: Recurring Frequency

Recurring It is the responsibility of the ACS software (and the cardholder software, if any) to
Expiry ensure that the value of Recur.endRecur is not later than the card expiration date.
Note: The card needs to be valid only at the time of authorization. It is not a problem
if it expires between authorization and capture.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 PARes
July 16, 2002 Page 57

PARes

Purpose The PARes (Payer Authentication Response) message is sent by the ACS in
response to the PAReq regardless of whether authentication is successful.

PARes fields The following table lists the defined fields for a PARes message:

Field Name DTD Element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
Acquirer BIN Merchant. R From PAReq.
acqBIN
Merchant ID Merchant.merID R From PAReq.
Transaction Purchase.xid R From PAReq.
Identifier
Purchase Date Purchase.date R From PAReq.
& Time
Purchase Purchase. R From PAReq.
Amount purchAmount
Purchase Purchase. R From PAReq.
Currency currency
Currency Purchase. R From PAReq.
Exponent exponent
Cardholder PAN pan R Cardholder Account Number.
Note: This is the value to be sent to the payment
system in authorization and clearing messages.
When Transaction Status is “Y” or “A”, this must
be the same as this field must include the last four
digits of the PAN supplied in the VEReq,
preceded by zeros:
• 0000000001234 (13-digit PAN)
• 0000000000001234 (16-digit PAN)
Visa regions may require that the full PAN that
was used in the associated VEReq be used.
otherwise, If authentication was unsuccessful, this
field must be all zeros: one for each digit of the
PAN.
Table 19: PARes Fields

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
PARes Core Functions v1.0.2
Page 58 July 16, 2002

Field Name DTD Element Inclusion Description

Signature Date TX.time R Date and Time PARes message was signed by
& Time ACS. Value is expressed in GMT and uses the
format YYYYMMDD HH:MM:SS.
Transaction TX.status R Indicates whether a transaction qualifies as an
Status authenticated transaction.
Y = Authentication Successful
Customer was successfully authenticated. All
data needed for clearing, including the
Cardholder Authentication Verification
Value, is included in the message.
N = Authentication Failed
Customer failed authentication. Transaction
denied.
U = Authentication Could Not Be Performed
Authentication could not be completed, due
to technical or other problems.
A = Attempts Processing Performed
Authentication could not be completed, but a
proof of authentication attempt (CAVV) was
generated.
Determined by ACS.
Cardholder TX.cavv C Determined by ACS. Contains a 20 byte value
Authentication that has been Base64 encoded, giving a 28 byte
Verification result.
Value Required when the value of Transaction
Status is “Y” or “A”.
See 3-D Secure: Functional Requirements –
Access Control Server for information about
producing this value.
Table 19: PARes Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 PARes
July 16, 2002 Page 59

Field Name DTD Element Inclusion Description

Electronic TX.eci C Value to be passed in Authorization Message
Commerce (exactly 2 decimal digits). Determined by ACS.
Indicator Required when the value of Transaction
Status is “Y” or “A”.
CAVV Algorithm TX. C A positive integer indicating the algorithm used to
cavvAlgorithm generate the Cardholder Authentication
Verification Value. Current defined values are:
0 = HMAC (as per SET™ TransStain)
1 = CVV
2 = CVV with ATN
Additional values may be defined at any time. All
components must accept any positive integer
value in this field.
Required when the value of Transaction
Status is “Y” or “A”.
Invalid Request IReq.iReqCode C Code indicating data that is formatted correctly,
Code but which invalidates the request. This element is
included when the PAReq is syntactically
correct, but business processing cannot be
performed for one of the reasons defined in Table
20 on page 60, which also provides the possible
values.
Invalid Request IReq.iReqDetail C May identify the specific data elements that
Detail caused the Invalid Request Code (so never
supplied if Invalid Request Code is omitted).
See Table 20 on page 60 for details.
Vendor Code IReq. O Vendor specific error code (or explanatory text)
vendorCode to be used for trouble shooting (max 256
characters). Determined by ACS.
Message Extension O Any data necessary to support the requirements
Extension that are not otherwise defined in the PARes
message must be carried in an instance of
Message Extension.
See page 61 for additional information about this
element.
Table 19: PARes Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
Invalid Request Values Core Functions v1.0.2
Page 60 July 16, 2002

Invalid Request Values

Table 20 lists and describes the values for Invalid Request Code (iReqCode),
and specifies the contents of Invalid Request Detail (iReqDetail) when
applicable. Vendor Code may also be included, at the discretion of the application
developer.

Invalid
Request Description Invalid Request Detail
Code
50 Acquirer not participating in 3-D Secure
(based on Acquirer BIN).
51 Merchant not participating in 3-D Secure
(based on Acquirer BIN and Merchant ID).
52 Password required, but no password was
supplied.
53 Supplied password is not valid for
combination of Acquirer BIN and
Merchant ID.
54 ISO code not valid per ISO tables (for either Name of invalid element(s); if more than
country or currency). one invalid element is detected, this is a
Note that although ISO 4217 includes values comma-delimited list.
963 (reserved for testing) and 999 (no If PAReq.Purchase.currency and
currency is involved), these values are invalid PAReq.Purchase.exponent form an
for 3-D Secure. invalid pair, list both as iReqDetail.
55 Transaction data not valid. For example: Name of invalid element(s); if more than
• purchase amount <> display amount one invalid element is detected, this is a
comma-delimited list.
• PAReq.acctid <> VERes.acctid
56 PAReq was incorrectly routed; either: Name of element(s) that caused the ACS to
• the PAReq was received by the wrong decide that the PAReq was incorrectly
ACS, or routed; if more than one invalid element is
detected, this is a comma-delimited list.
• the PAReq should never have been sent,
based on the values in the VERes.
57 Serial Number cannot be located
98 Transient system failure A description of the failure
99 Permanent system failure A description of the failure
Table 20: Invalid Request Values

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 Message Extensions
July 16, 2002 Page 61

Message Extensions

Message Requirements may emerge that cannot be supported by elements in the 3-D Secure
extensions messages; any data necessary to support these requirements must be carried in a
message extension.

Extension The party defining the message extension defines the format of the data. Examples of
data formats that might be chosen are:
• XML data
• Binary data that is Base64 encoded

Attributes The Message Extension element includes the following attributes:

Attribute Name Inclusion Description

id Required A unique identifier for the extension. See
additional description below.
critical Required A Boolean value indicating whether the recipient
must understand the contents of the extension in
order to interpret the entire message. See
additional description below.
Values are lowercase: true
false

Table 21: Message Extension Attributes

Identification Each message extension defined for use in 3-D Secure must have a unique identifier
assigned to it. Examples of unique identifiers are:
• Object identifiers (OID)
• Uniform Resource Identifiers (URI)
The party defining the message extension specifies the format of the identifier (OID,
URI, etc.) and the value.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
Message Extensions Core Functions v1.0.2
Page 62 July 16, 2002

Criticality The data in a message extension may affect the meaning of the rest of the data such
that the entire message can only be understood in the context of the extension data.
When this occurs, the extension is deemed to be critical and the value of the critical
attribute must be “true”.
When an extension is critical, recipients of the message must recognize and be able
to process the extension. If a 3-D Secure application receives a message containing a
critical extension that it does not recognize, it must respond with an Error message.
When an extension is non-critical, recipients that cannot process the extension can
safely ignore the data.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Chapter 6: Message Descriptions
Core Functions v1.0.2 Error Message
July 16, 2002 Page 63

Error Message

Purpose The Error message shall be returned when the incoming request or response cannot
be successfully processed at a protocol level (such as bad XML).
Note: Implementations may limit the number of Error messages that are sent to a
given requester in order to mitigate the effects of denial-of-service attacks.

Error The following table lists the defined fields for an Error message.
message
fields

Field Name DTD Element Inclusion Description

Message version R Version identifier; currently “1.0.2”.
Version Number
Error Code errorCode R See Table 23 on page 64.
Error errorMessage R See Table 23 on page 64.
Description
Error Detail errorDetail R See Table 23 on page 64.
Vendor Code vendorCode O Vendor specific error code (or explanatory text)
to be used for trouble shooting (max 256
characters). Determined by the entity creating the
message.
Table 22: Error Message Fields

Client may A client device may send an Error message to the server that sends it an invalid
send Error response:
message
• A Merchant Server Plug-in may post an Error message to the Visa Directory.
• A Merchant Server Plug-in or the Visa Directory may send an Error message to
an ACS, by posting it to the ACS URL.
Note: Vendors are strongly encouraged to send these Error messages.

Response to An application which receives an Error message as an HTTP post must respond
Error with an HTTP response code of "200 OK" and an empty body.
message
An application must never send an Error message in response to an Error message.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Chapter 6: Message Descriptions 3-D Secure: Protocol Specification
Error Message Core Functions v1.0.2
Page 64 July 16, 2002

Message id If the 3-D Secure component is able to determine the message id of the message in
error, it must use the same id in the Error message. If an id cannot be determined
from the message that is in error (such as when the root element is unrecognized or
the Message element is missing), the 3-D Secure component must generate an id
using an algorithm that is likely to generate unique ids.

Related
elements in
Error Error Error Description Explanation Error Detail
message Code
1 Root element invalid. Root element is not The invalid root
recognized. element.
2 Message element not Message is not CRReq, The invalid message
a defined message. CRRes, VEReq, etc., or element.
a valid message is sent to
an inappropriate
component (such as
PAReq being sent to the
Visa Directory)
3 Required element Name of required
missing. element that was
omitted.
4 Critical element not Name of critical
recognized. element that was not
recognized.
5 Format of one or For example, not numeric, Name of invalid
more elements is not in defined date format, element(s); if more
invalid according to etc. than one invalid
the specification. element is detected,
this is a comma-
delimited list.
6 Protocol version too The oldest version
old. supported.
98 Transient system For example, a queue A description of the
failure processing requests is full. failure
99 Permanent system For example, the disk A description of the
failure containing a critical failure
database cannot be
accessed.
Table 23: Error Code, Error Description, and Error Detail

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 65

Appendix A: 3-D Secure XML Message Format

Organization The following topics are included:

Topic Page

XML-Signature Syntax and Processing 66

3-D Secure Messages 68
3-D Secure DTD 74

Document “ThreeDSecure” is the document element (aka root) of all XML-based documents
element exchanged between various services and components participating in the 3-D Secure
infrastructure.

Date and Time Date and time pairs are formatted as:
format(s)
YYYYMMDD HH:MM:SS
With the exception of the Card Expiry Date, dates alone are formatted as:
YYYYMMDD
Card Expiry Date is formatted as:
YYMM

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix A: 3-D Secure XML Message Format 3-D Secure: Protocol Specification
XML-Signature Syntax and Processing Core Functions v1.0.2
Page 66 July 16, 2002

XML-Signature Syntax and Processing

Description 3-D Secure/XM uses the detached signature form where the signature is external to
the signed element (PARes) but within the same document. The signed element is
referenced by the signature using local reference (e.g., ‘#PARes11234’). The signed
element includes:
the opening angle bracket of the PARes start tag through the closing angle
bracket of the PARes end tag
Figure 4 illustrates the signature structure.

Profile The generation of 3-D Secure signatures must correspond to the requirements for
element content and algorithms specified in the tables that follow.
Note: Recipients of 3-D Secure messages should only enforce these requirements to
the extent necessary to validate the signature; for example, the presence of a
CanonicalizationMethod element should not cause the validation to fail, but the
absence of Signature.KeyInfo must cause the validation to fail.

Element Requirements
Signature One instance of KeyInfo; zero instances of Object
CanonicalizationMethod Element is EMPTY with Algorithm attribute present
SignatureMethod Element is EMPTY with Algorithm attribute present
Transforms Not present
DigestMethod Element is EMPTY with Algorithm attribute present
KeyInfo One instance of X509Data
X509Data One or more instances of X509Certificate
Table 24: XML Signature Profile
Algorithm Type Identifier
Canonicalization http://www.w3.org/TR/2001/REC-xml-c14n-
20010315
Digest http://www.w3.org/2000/09/xmldsig#sha1
Encoding http://www.w3.org/2000/09/xmldsig#base64
MAC http://www.w3.org/2000/09/xmldsig#hmac-sha1
Signature http://www.w3.org/2000/09/xmldsig#rsa-sha1
Transform none
(however, see Canonicalization requirements below)
Table 25: XML Signature Algorithms

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix A: 3-D Secure XML Message Format
Core Functions v1.0.2 XML-Signature Syntax and Processing
July 16, 2002 Page 67

Canonicaliza- Note that canonicalization is a requirement of “XML-Signature Syntax and

tion Processing W3C Candidate Recommendation”, also known as xmldsig, and listed in
requirements “References” on page 3 of this document.
Specifically, xmldsig states that the computation of a digest over a same-document
reference must use the required canonicalization method, which is also included in
the “References” on page 3 of this document.
In addition, the ACS should return the signed PARes message in canonical form
(both the PARes and SignedInfo elements).

XML The detached signature of the message must be declared with a default namespace of
namespaces "http://www.w3.org/2000/09/xmldsig#".
for signatures

Example <ThreeDSecure>
<Message id="PAReq98765">
<PARes id="PARes12345">...</PARes>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<Reference URI="#PARes12345">
…
</Reference>
<SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
<Signature>
</Message>
</ThreeDSecure>

Figure 4: Signature Structure

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix A: 3-D Secure XML Message Format 3-D Secure: Protocol Specification
3-D Secure Messages Core Functions v1.0.2
Page 68 July 16, 2002

3-D Secure Messages

Introduction Figure 5 provides an overview of 3-D Secure messages. The remaining figures in
this section illustrate the messages individually:

Message Page

CRReq 69
CRRes 69
VEReq 70
VERes 70
PAReq 71
PARes 72
Error Message 73

The DTD follows the diagrams.

Figure 5: Overview of 3-D Secure Messages

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix A: 3-D Secure XML Message Format
Core Functions v1.0.2 3-D Secure Messages
July 16, 2002 Page 69

Figure 6: CRReq

Figure 7: CRRes

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix A: 3-D Secure XML Message Format 3-D Secure: Protocol Specification
3-D Secure Messages Core Functions v1.0.2
Page 70 July 16, 2002

Figure 8: VEReq

Figure 9: VERes

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix A: 3-D Secure XML Message Format
Core Functions v1.0.2 3-D Secure Messages
July 16, 2002 Page 71

Figure 10: PAReq

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix A: 3-D Secure XML Message Format 3-D Secure: Protocol Specification
3-D Secure Messages Core Functions v1.0.2
Page 72 July 16, 2002

Figure 11: PARes

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix A: 3-D Secure XML Message Format
Core Functions v1.0.2 3-D Secure Messages
July 16, 2002 Page 73

Figure 12: Error Message

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix A: 3-D Secure XML Message Format 3-D Secure: Protocol Specification
3-D Secure DTD Core Functions v1.0.2
Page 74 July 16, 2002

3-D Secure DTD

<!--
**********************************************************************
DTD for 3-D Secure Messages
Version 1.0.2
**********************************************************************
-->
<!ELEMENT ThreeDSecure (Message)*>
<!ELEMENT Message ((CRReq | CRRes | VEReq | VERes | PAReq |
(PARes, Signature) | Error))>
<!ATTLIST Message id CDATA #REQUIRED >

<!ELEMENT CRReq (version, Merchant, serialNumber?)>

<!ELEMENT CRRes (version, CR*, serialNumber?, IReq?)>
<!ELEMENT VEReq (version, pan, Merchant, Browser?, Extension*)>
<!ELEMENT VERes (version, CH, url?, protocol*, IReq?, Extension*)>
<!ELEMENT PAReq (version, Merchant, Purchase, CH, Extension*)>
<!ELEMENT PARes (version, Merchant, Purchase, pan, TX, IReq?,
Extension*)>
<!ATTLIST PARes id CDATA #REQUIRED>
<!ELEMENT Error (version, errorCode, errorMessage, errorDetail,
vendorCode?)>

<!ELEMENT Browser (deviceCategory?, accept?, userAgent?)>

<!ELEMENT CR (begin, end, action)>
<!ELEMENT CH (enrolled?, acctID?, expiry?)>
<!ELEMENT IReq (iReqCode, iReqDetail?, vendorCode?)>
<!ELEMENT Merchant (acqBIN, merID, password?, name?, country?, url?)>
<!ELEMENT Purchase (xid, date, amount?, purchAmount, currency,
exponent,
desc?, Recur?, install?)>
<!ELEMENT Recur (frequency, endRecur)>
<!ELEMENT TX (time, status, cavv?, eci?, cavvAlgorithm?)>

<!ELEMENT Extension ANY>

<!ATTLIST Extension id CDATA #REQUIRED
critical (true | false) #REQUIRED >

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix A: 3-D Secure XML Message Format
Core Functions v1.0.2 3-D Secure DTD
July 16, 2002 Page 75

<!ELEMENT accept (#PCDATA)>

<!ELEMENT acctID (#PCDATA)>
<!ELEMENT action (#PCDATA)>
<!ELEMENT acqBIN (#PCDATA)>
<!ELEMENT amount (#PCDATA)>
<!ELEMENT begin (#PCDATA)>
<!ELEMENT cavv (#PCDATA)>
<!ELEMENT cavvAlgorithm (#PCDATA)>
<!ELEMENT country (#PCDATA)>
<!ELEMENT currency (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT desc (#PCDATA)>
<!ELEMENT deviceCategory (#PCDATA)>
<!ELEMENT eci (#PCDATA)>
<!ELEMENT end (#PCDATA)>
<!ELEMENT endRecur (#PCDATA)>
<!ELEMENT enrolled (#PCDATA)>
<!ELEMENT errorCode (#PCDATA)>
<!ELEMENT errorDetail (#PCDATA)>
<!ELEMENT errorMessage (#PCDATA)>
<!ELEMENT expiry (#PCDATA)>
<!ELEMENT exponent (#PCDATA)>
<!ELEMENT frequency (#PCDATA)>
<!ELEMENT install (#PCDATA)>
<!ELEMENT iReqCode (#PCDATA)>
<!ELEMENT iReqDetail (#PCDATA)>
<!ELEMENT merID (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT pan (#PCDATA)>
<!ELEMENT password (#PCDATA)>
<!ELEMENT protocol (#PCDATA)>
<!ELEMENT purchAmount (#PCDATA)>
<!ELEMENT serialNumber (#PCDATA)>
<!ELEMENT status (#PCDATA)>
<!ELEMENT time (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT userAgent (#PCDATA)>
<!ELEMENT vendorCode (#PCDATA)>
<!ELEMENT version (#PCDATA)>
<!ELEMENT xid (#PCDATA)>

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix A: 3-D Secure XML Message Format 3-D Secure: Protocol Specification
3-D Secure DTD Core Functions v1.0.2
Page 76 July 16, 2002

<!--
**********************************************************************

DTD for XML Signatures

http://www.w3.org/TR/2001/CR-xmldsig-core-20010419

3-D Secure XML-Signatures:

* must declare XML-Signature namespace as the default namespace
in the Signature element.
* must use detached signatures.
* must use X.509v3 certificates
* must use following algorithms:
Digest - http://www.w3.org/2000/09/xmldsig#sha1
Encoding - http://www.w3.org/2000/09/xmldsig#base64
MAC - http://www.w3.org/2000/09/xmldsig#hmac-sha1
Signature - http://www.w3.org/2000/09/xmldsig#rsa-sha1
Canonicalization - http://www.w3.org/TR/2001/REC-xml-c14n-
20010315
Transform - none
* xmlns must be set to XML-Signature namespace URI
**********************************************************************
-->

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 77

Appendix B: 3-D Secure Field Formats

This appendix combines the field definitions provided in the message descriptions
that begin on page 41.

Inclu- Message
Field Name DTD Element Description
sion
Accept Browser.accept C VEReq The exact content of the HTTP accept
Headers header as sent to the merchant from the
cardholder’s user agent.
Required if the cardholder’s user agent
supplied a value.
Account CH.acctID C VERes The content of this field is at the discretion
Identifier of the Issuer. This may be the actual PAN
or an alternative a data string useful to the
ACS; it must not reveal the PAN and must
be generated using an algorithm that is
likely to generate unique values.
Must be supplied if the value of PAN
Authentication Available is “Y”.
Up to 28 characters.
Account CH.acctID R PAReq From VERes.
Identifier
Acquirer BIN Merchant. R CRReq, Variable length (up to 11 digits) acquiring
acqBIN VEReq institution identification code; typically this
is a 6-digit BIN assigned to the Acquirer by
Visa.
Acquirer BIN Merchant. R PAReq From VEReq.
acqBIN
Acquirer BIN Merchant. R PARes From PAReq.
acqBIN
ACS URL url C VERes Fully qualified URL of Access Control
Server.
Must be supplied if the value of PAN
Authentication Available is “Y”.
Table 26: 3-D Secure Fields

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix B: 3-D Secure Field Formats 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 78 July 16, 2002

Inclu- Message
Field Name DTD Element Description
sion
Action CR.action R CRRes Indicates the action to take with the card
range:
A = Add the card range to the cache.
D = Delete the card range from the
cache.
The card ranges must be processed in the
order returned.
Note: If the serial number was not included
in the CRReq the action is add for all
ranges returned.
Card Expiry CH.expiry R PAReq Expiration Date supplied to merchant by
Date cardholder. (YYMM).
Card Range CR C CRRes If CRReq does not include Serial
Number, a CR element is included for
each card range populated in the Visa
Directory.
If CRReq includes Serial Number:
• If the value of CRReq.serialNumber
is current, indicating that the Visa
Directory Server data has not changed
since the previous CRReq from this
merchant, no CR elements are returned.
• Otherwise, only CR elements that have
been added or deleted since the previous
CRReq are returned.
CR is absent when IReq is present.
• The card range consists of three data
elements as listed below.
Table 26: 3-D Secure Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix B: 3-D Secure Field Formats
Core Functions v1.0.2
July 16, 2002 Page 79

Inclu- Message
Field Name DTD Element Description
sion
Cardholder TX.cavv C PARes Determined by ACS. Contains a 20 byte
Authentication value that has been Base64 encoded, giving
Verification a 28 byte result.
Value Required when the value of Transaction
Status is “Y” or “A”.
See 3-D Secure: Functional
Requirements – Access Control Server
for information about producing this value.
Cardholder pan R VEReq 13 – 19 digit Account Number; it must be
PAN the same PAN that will be used in the
authorization request. The value may be:
• the account number on the card
• a permanent account number that’s only
used online
• produced by the wallet as a proxy
• pulled from the merchant’s local wallet
• or any other number that can be
submitted for authorization.
Cardholder pan R PARes Cardholder Account Number.
PAN Note: This is the value to be sent to the
payment system in authorization and
clearing messages. When Transaction
Status is “Y” or “A”, this must be the same
as this field must include the last four digits
of the PAN supplied in the VEReq,
preceded by zeros:
• 0000000001234 (13-digit PAN)
• 0000000000001234 (16-digit PAN)
Visa regions may require that the full PAN
that was used in the associated VEReq be
used.
otherwise, If authentication was
unsuccessful, this field must be all zeros:
one for each digit of the PAN.
Table 26: 3-D Secure Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix B: 3-D Secure Field Formats 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 80 July 16, 2002

Inclu- Message
Field Name DTD Element Description
sion
CAVV TX. C PARes A positive integer indicating the algorithm
Algorithm cavvAlgorithm used to generate the Cardholder
Authentication Verification Value.
Current defined values are:
0 = HMAC (as per SET™ TransStain)
1 = CVV
2 = CVV with ATN
Additional values may be defined at any
time. All components must accept any
positive integer value in this field.
Required when the value of Transaction
Status is “Y” or “A”.
Currency Purchase. R PAReq The minor units of currency specified in
Exponent exponent ISO 4217. For example, US Dollars has a
value of 2; Japanese Yen has a value of 0.
Currency Purchase. R PARes From PAReq.
Exponent exponent
Device Browser. O VEReq Indicates the type of cardholder device.
Category deviceCategory Current defined values are:
0 = PC (HTML)
1 = mobile Internet device (WML)
Additional values may be defined at any
time. All components must accept any
positive integer value in this field.
If no value is provided, 0 is implied.
Display Purchase. R PAReq Determined by merchant; must correspond
Amount amount to Purchase Amount.
Character string (up to 20 characters) that is
displayable to the user.
Electronic TX.eci C PARes Value to be passed in Authorization
Commerce Message (exactly 2 decimal digits).
Indicator Determined by ACS.
Required when the value of Transaction
Status is “Y” or “A”.
Table 26: 3-D Secure Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix B: 3-D Secure Field Formats
Core Functions v1.0.2
July 16, 2002 Page 81

Inclu- Message
Field Name DTD Element Description
sion
Error errorMessage R Error See Table 23 on page 64.
Description
Error Detail errorDetail R Error See Table 23 on page 64.
Error Code errorCode R Error See Table 23 on page 64.
First Number CR.begin R CRRes 13 – 19 digit Account Number from Visa
in Card Range Directory.
Installment Purchase.install C PAReq An integer greater than one indicating the
Payment Data maximum number of permitted
authorizations for installment payments.
Must be included if the merchant and
cardholder have agreed to installment
payments.
Invalid IReq.iReqCode C VERes Code indicating data that is formatted
Request Code correctly, but which invalidates the request.
This element is included when the VEReq
is syntactically correct, but business
processing cannot be performed for one of
the reasons defined in Table 20 on page 60,
which also provides the possible values.
Note that when IReq is included, the value
of PAN Authentication Available is
always “N”.
Invalid IReq.iReqCode C CRRes Code indicating data that is formatted
Request Code correctly, but which invalidates the request.
This element is included when the CRReq
is syntactically correct, but business
processing cannot be performed for one of
the reasons defined in Table 20 on page 60,
which also provides the possible values.
If Invalid Request Code is included, the
Merchant Server Plug-In should ignore the
contents of Serial Number.
Invalid IReq.iReqCode C PARes Code indicating data that is formatted
Request Code correctly, but which invalidates the request.
This element is included when the request
is syntactically correct, but business
processing cannot be performed for one of
the reasons defined in Table 20 on page 60,
which also provides the possible values.
Table 26: 3-D Secure Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix B: 3-D Secure Field Formats 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 82 July 16, 2002

Inclu- Message
Field Name DTD Element Description
sion
Invalid IReq.iReqDetail C CRRes, May identify the specific data elements that
Request Detail VERes, caused the Invalid Request Code (so
PARes never supplied if Invalid Request Code
is omitted). See Table 20 on page 60 for
details.
Last Number CR.end R CRRes 13 – 19 digit Account Number from Visa
in Card Range Directory. (Must be the same length as First
Number in Card Range.)
Merchant Merchant. R PAReq Three digit ISO-3166 Country Code.
Country Code country Determined by merchant. The same value
must be used in the authorization request.
Merchant ID Merchant.merID R CRReq, Acquirer-defined merchant identifier, up to
VEReq 24 characters:
• up to 15 byte alphanumeric Card
Acceptor ID
• optionally followed by a hyphen and an
up to 8 byte alphanumeric Card
Acceptor Terminal ID
Merchant ID Merchant.merID R PAReq From VEReq.
Merchant ID Merchant.merID R PARes From PAReq.
Merchant Merchant.name R PAReq Character String (max 25 characters),
Name determined by merchant.
Merchant URL Merchant.url R PAReq Fully qualified URL of merchant site.
Message Extension O VEReq, Any data necessary to support the
Extension VERes, requirements that are not otherwise defined
PAReq, in the message must be carried in an
PARes instance of Message Extension.
See page 61 for additional information
about this element.
Message version R all Version identifier; currently “1.0.2”.
Version
Number
Table 26: 3-D Secure Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix B: 3-D Secure Field Formats
Core Functions v1.0.2
July 16, 2002 Page 83

Inclu- Message
Field Name DTD Element Description
sion
Order Purchase.desc O PAReq Brief description of items purchased,
Description determined by the merchant.
Maximum size is 125 characters, but
merchant should consider the characteristics
of the cardholder’s device when creating the
field.
PAN CH.enrolled R VERes Indicates whether the Account Identifier can
Authentication be authenticated:
Available Y = Authentication Available
N = Cardholder Not Participating
U = Unable To Authenticate
“U” applies whether the inability to
authenticate is due to technical difficulties or
non-inclusion in program.
Password Merchant. C CRReq, 8 character alphanumeric merchant
password VEReq password (provided by Acquirer).
The requirements for use of this field will be
indicated in the Member Implementation
Guide.
Table 26: 3-D Secure Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix B: 3-D Secure Field Formats 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 84 July 16, 2002

Inclu- Message
Field Name DTD Element Description
sion
Payment protocol C VERes Indicates which payment protocols are
Protocols supported by the Issuer system for the
Cardholder PAN specified in VEReq.
If the value of PAN Authentication
Available is “Y”, at least one instance of
this element must be included.
Possible values are:
ThreeDSecure indicates that the
3-D Secure protocol is
supported by the Issuer
system for this PAN
SET indicates that the SET
Secure Electronic
Transaction™ protocol is
supported by the Issuer
system for this PAN
Purchase Purchase. R PAReq Determined by merchant.
Amount purchAmount 12-digit numeric amount in minor units of
currency with all punctuation removed.
Examples:
Display Amount $123.45
Purchase Amount 12345
Purchase Purchase. R PARes From PAReq.
Amount purchAmount
Purchase Purchase. R PAReq Determined by merchant. ISO 4217, 3 digit
Currency currency numeric.
Purchase Purchase. R PARes From PAReq.
Currency currency
Purchase Date Purchase.date R PAReq Date and time of purchase expressed in
& Time GMT in the following format:
YYYYMMDD HH:MM:SS
Purchase Date Purchase.date R PARes From PAReq.
& Time
Table 26: 3-D Secure Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix B: 3-D Secure Field Formats
Core Functions v1.0.2
July 16, 2002 Page 85

Inclu- Message
Field Name DTD Element Description
sion
Recurring Recur. R PAReq The date after which no further
Expiry endRecur authorizations should be performed.
(YYYYMMDD format). This date must be
in the future.
See “Recurring Expiry” on page 56 for
additional information.
Recurring Recur. R PAReq An integer indicating the minimum number
Frequency frequency of days between authorizations.
See “Recurring Frequency” on page 56
for additional information.
Recurring Purchase.Recur C PAReq A Recur element must be included if the
Payment Data merchant and cardholder have agreed to
recurring payments.
The recurring payment data consists of two
data elements:
• Recurring Frequency
• Recurring Expiry
Serial Number serialNumber O CRReq A value returned in a previous CRRes. If
this element is present, the Visa Directory
Server only returns card ranges that have
been updated since the time of the CRRes;
if this element is not present, the Visa
Directory Server returns all participating
card ranges.
Maximum length is 20 digits, to hold a 64-
bit unsigned integer.
Table 26: 3-D Secure Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix B: 3-D Secure Field Formats 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 86 July 16, 2002

Inclu- Message
Field Name DTD Element Description
sion
Serial Number serialNumber RC CRRes An integer indicating the current state of the
card range database. (The specific value is
meaningful only to the Visa Directory
Server.) The MPI should retain this value
for submission in a future CRReq to
request only changes that have been made
to the participating card range list since this
message was generated.
Maximum length is 20 digits, to hold a 64-
bit unsigned integer.
If Invalid Request Code is included,
Serial Number should be set to zero must
be omitted.
Signature TX.time R PARes Date and Time PARes message was
Date & Time signed by ACS. Value is expressed in GMT
and uses the format YYYYMMDD
HH:MM:SS.
Transaction Purchase.xid R PAReq Unique transaction identifier determined by
Identifier merchant. Contains a 20 byte statistically
unique value that has been Base64 encoded,
giving a 28 byte result.
Transaction Purchase.xid R PARes From PAReq.
Identifier
Table 26: 3-D Secure Fields, continued

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Appendix B: 3-D Secure Field Formats
Core Functions v1.0.2
July 16, 2002 Page 87

Inclu- Message
Field Name DTD Element Description
sion
Transaction TX.status R PARes Indicates whether a transaction qualifies as
Status an authenticated transaction.
Y = Authentication Successful
Customer was successfully
authenticated. All data needed for
clearing, including the Cardholder
Authentication Verification Value,
is included in the message.
N = Authentication Failed
Customer failed authentication.
Transaction denied.
U = Authentication Could Not Be
Performed
Authentication could not be completed,
due to technical or other problems.
A = Attempts Processing Performed
Authentication could not be completed,
but a proof of authentication attempt
(CAVV) was generated.
Determined by ACS.
User Agent Browser. C VEReq The exact content of the HTTP user-agent
userAgent header as sent to the merchant from the
cardholder’s user agent.
Required if the cardholder’s user agent
supplied a value.
Vendor Code IReq. O CRRes, Vendor specific error code (or explanatory
vendorCode VERes, text) to be used for trouble shooting (max
PARes 256 characters). Determined by the entity
creating the response.
Vendor Code vendorCode O Error Vendor specific error code (or explanatory
text) to be used for trouble shooting (max
256 characters). Determined by the entity
creating the message.
Table 26: 3-D Secure Fields, continued

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix B: 3-D Secure Field Formats 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 88 July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 89

Appendix C: Visa Directory Elements

Table 27 lists the data elements required by the Visa Directory.

Additional information about the Visa Directory, including the method for updating
entries, will be provided in a Member Implementation Guide.

a) Business ID
b) Country Code
c) Beginning card number in range
d) Ending card number in range
e) Serial number value
f) Deleted flag
g) Fully qualified URLs of one to five Access Control Servers to validate
availability of authentication for a PAN (that is, the URLs of each ACS to
which the VEReq may be sent)
h) URL of an ACS that can generate a proof of authentication attempt

Table 27: Visa Directory Elements

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix C: Visa Directory Elements 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 90 July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 91

Appendix D: Compression

Compression PAReq and PARes are Base64 encoded prior to being inserted in the page sent to
the browser. This encoding enables the messages to transit through the browser
without interpretation and without change. Unfortunately, the encoding expands the
message sizes by a ratio of 4 to 3. To counter this expansion, the messages are
compressed prior to encoding.
The algorithm used for compression shall be the DEFLATE algorithm, as specified
in RFC1951. The resulting data stream shall be represented in the ZLIB compressed
data format, as specified by RFC1950. The compression method shall be “deflate”
and the compression level should be “default” or “most compressed.” However,
decompressors should be prepared to accept any compression level.
No other transformation or padding is to be done on the data stream. Thus in order to
send PAReq, the following sequence occurs:
1) The MPI builds the XML PAReq, in canonical format according to the DTD.
2) It passes the XML stream to an RFC1951-compliant compressor, which
produces an RFC1950-compliant output stream.
3) The output stream is Base64 encoded.
4) The Base64 data is passed to the ACS through the browser as specified earlier.
5) The ACS decodes the Base64 data into an RFC1950 compliant stream.
6) The RFC1950 stream is passed to an RFC1951 compliant de-compressor, which
generates the original XML.
PARes is returned using a similar mechanism.
The relevant RFCs are available at:
http://www.ietf.org/rfc/rfc1950.txt
http://www.ietf.org/rfc/rfc1951.txt
Additional information, including software implementations, may be found at:
http://www.info-zip.org
ftp://ftp.info-zip.org/pub/infozip/src/
http://www.gzip.org/zlib/

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Appendix D: Compression 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 92 July 16, 2002

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 93

Glossary

Overview This section includes selected terms and acronyms related to 3-D Secure.
An extensive 3-D Secure glossary is available in 3-D Secure: System Overview,
available through the “Vendors & Merchants” link on http://corporate.visa.com.

3-D Secure An e-commerce protocol that enables the secure processing of payment
card transactions in the remote environment; one of the supported
protocols of the Visa Authenticated Payment Program.
3-D Secure specifications See “References” on page 3.

Access Control Server A component that operates in the Issuer Domain, verifies whether
authentication is available for a card number, and authenticates specific
transactions.
Acquirer A Visa Member financial institution that establishes a contractual service
relationship with a merchant for the purpose of accepting Visa cards. In
3-D Secure, determines whether merchant is eligible to participate.
Performs traditional role of receiving and forwarding authorization and
settlement messages (enters transaction into interchange).
Acquirer domain Contains the systems and functions of the Acquirer and its customers,
such as merchants

ACS See Access Control Server.

Attempts functionality The process by which the proof of an authentication attempt is generated,
when payment authentication is not available. Described in 3-D Secure:
Functional Requirements – Access Control Server, Visa Publication
70002-01.

Authenticated Payment One of the programs of the Visa Secure e-Commerce Initiative, this
Program program includes two authentication protocols: 3-D Secure and 3-D SET

Authentication The process of verifying that the person making an e-commerce purchase
is entitled to use the payment card.

Authentication History Server A component that operates in the Interoperability domain; archives
authentication activity for use by Acquirers and Issuers for dispute
resolution and other purposes.
authorization A process by which an Issuer, or a processor on the Issuer’s behalf,
approves a transaction for payment.
Bank Identification Number The first 6 digits of a payment card account number that uniquely
identify the issuing financial institution.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Glossary 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 94 July 16, 2002

BIN See Bank Identification Number.

browser A client program that allows users to read hypertext documents on the
World Wide Web and navigate between them. Examples are Netscape
Navigator and Microsoft Internet Explorer.
In 3-D Secure, acts as a conduit to transport messages between the
Merchant Server Plug-in (in the Acquirer domain) and the Access
Control Server (in the Issuer domain).

cardholder Party that holds a Visa payment card, shops, provides card number, and
commits to payment.

Cardholder Authentication A cryptographic value generated by the ACS to provide a way during
Verification Value authorization processing for VisaNet to rapidly validate the integrity of
certain values copied from the Payer Authentication Response to the
authorization request and to prove that authentication occurred.

cardholder software Optional cardholder software which may supplement the abilities of the
browser. Chip card authentication, for example, requires cardholder
software sometimes referred to as terminal software.

CAVV See Cardholder Authentication Verification Value.

certificate An electronic document that contains the public key of the certificate
holder and which is attested to by a certificate authority and rendered
unforgeable by cryptographic technology (signing with the private key of
the certificate authority).

certificate authority A trusted party that issues and revokes certificates.

certificate chain An ordered grouping of digital certificates, including the Root certificate,
that are used to validate a specific certificate.
chip An integrated circuit containing memory and logic where a copy of the
VSDC application is stored and executed.

chip card A payment card with an integrated circuit chip that stores information
about the account and user.

core protocol The protocol described in this publication.

CPRQ Condensed Payer Authentication Request, used for 3-D Secure

transactions performed with mobile Internet devices.
See Payer Authentication Request.

CPRS Condensed Payer Authentication Response, used for 3-D Secure

transactions performed with mobile Internet devices.
See Payer Authentication Response.

CRReq Card Range Request

CRRes Card Range Response

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Glossary
Core Functions v1.0.2
July 16, 2002 Page 95

cryptography The process of protecting information by transforming it into an

unreadable format. The information is encrypted using a key, which
makes the data unreadable, and is later decrypted when the information
needs to be used again.

digital certificate See certificate.

digital signature An asymmetric cryptographic method whereby the recipient of the data
can prove the origin and integrity of data, thereby protecting the sender
of the data and the recipient against modification or forgery by third
parties and the sender against forgery by the recipient. Contrast with
Message Authentication Code.
digital wallet A software component that allows a user to make an electronic payment
with a financial instrument (such as a credit card) while hiding the
low-level details of executing the payment protocol, including such tasks
as entering an account number and providing shipping information and
cardholder identifying information.

Directory Server See Visa Directory.

Enrollment Server A component that operates in the Issuer domain; a server
hardware/software entity which manages cardholder enrollment in
3-D Secure, for example by presenting a series of questions via a Web
interface to be answered by the cardholder and verified by the Issuer.

HTML Hypertext Markup Language, a computer programming language used to

define pages on the World Wide Web

HTTP Hypertext Transport Protocol

HTTPS Secure Hypertext Transport Protocol, sometimes S-HTTP, uses the

SSL/TLS protocol to ensure the secure transmission of data over the
Internet

Interoperability domain Facilitates the transfer of information between the Issuer and Acquirer
domain systems.

Issuer A Visa Member financial institution that issues Visa cards, contracts with
cardholder to provide card services, determines eligibility of cardholder
to participate in 3-D Secure, and identifies card number ranges eligible to
participate in 3-D Secure.

Issuer domain Contains the systems and functions of the Issuer and its customers
(cardholders)

key In cryptography, the value needed to encrypt and/or decrypt something

key management The handling of cryptographic keys and other security parameters during
the entire lifetime of the keys, including generation, storage, entry and
use, deletion or destruction, and archiving.

MAC See Message Authentication Code.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Glossary 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 96 July 16, 2002

merchant Entity that contracts with an Acquirer to accept Visa cards. Manages the
online shopping experience with the cardholder, obtains card number,
then transfers control to the Merchant Server Plug-in, which conducts
payment authentication.

Merchant Commerce Server A server hardware/software entity which handles online transactions and
facilitates communication between the merchant application and the Visa
gateway.

Merchant Server Plug-in A component that operates in the Acquirer domain; incorporated into the
merchant’s Web storefront that performs functions related to 3-D Secure
on behalf of the merchant, such as determining whether authentication is
available for a card number and validating the digital signature in a
3-D Secure message.
Message Authentication Code A symmetric (secret key) cryptographic method that protects the sender
and recipient against modification and forgery of data by third parties.
Contrast with digital signature.

MPI See Merchant Server Plug-in.

PAReq See Payer Authentication Request.

PARes See Payer Authentication Response.

PATransReq Payer Authentication Transaction Request; a record of authentication

activity sent by the ACS to the Authentication History Server

PATransRes Payer Authentication Transaction Response; Authentication History

Server response to PATransReq

Payer Authentication Request A message sent from the Merchant Server Plug-in to the Access Control
Server via the cardholder device. Requests the Issuer to authenticate its
cardholder and contains the cardholder, merchant, and transaction-
specific information necessary to do so.
See PAReq and CPRQ.

Payer Authentication A message formatted, digitally signed, and sent from the Access Control
Response Server to the Merchant Server Plug-in (via the cardholder device)
providing the results of the Issuer’s 3-D Secure cardholder
authentication.
See PARes and CPRS.

private key Part of an asymmetric cryptographic system. The key that is kept secret
and known only to an owner.

public key Part of an asymmetric cryptographic system. The key known to all
parties.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification Glossary
Core Functions v1.0.2
July 16, 2002 Page 97

public key pair Two mathematically related keys – a public key and a private key –
which are used with a public key (asymmetric) cryptographic algorithm
to permit the secure exchange of information without the necessity for a
secure exchange of a secret.

secret key A key used in a symmetric cryptographic algorithm such as DES which,
if disclosed publicly, would compromise the security of the system.

Secure e-Commerce Initiative A Visa initiative focused on increasing e-commerce transactions,

promoting consumer confidence, and increasing Member and merchant
profitability, and including the following programs:
• Visa Account Information Security Program
• Visa Authenticated Payment Program
• Best Business Practices Program

Secure Sockets Layer SSL: A cryptographic protocol developed by Netscape Communications

Company to confidentially transmit information over open networks like
the Internet. See also Transport Layer Security.

SET SET Secure Electronic Transaction™, one of the two protocols approved
for the Authenticated Payment Program
specifications See 3-D Secure specifications.

SSL See Secure Sockets Layer.

Three-Domain Secure See 3-D Secure.

TLS See Transport Layer Security.

Transport Layer Security Successor protocol to SSL developed by the IETF (Internet Engineering
Task Force)

Uniform Resource Locator Address scheme for pages on the World Wide Web usually in the format
http://address or https://address such as http://www.visa.com

URL See Uniform Resource Locator.

Validation Usually refers to validating the cryptographic signature passed in the

message from the ACS to the merchant.

VEReq See Verify Enrollment Request.

VERes See Verify Enrollment Response.

Verify Enrollment Request Message from Merchant Server Plug-in to the Visa Directory or from
Visa Directory to ACS, asking whether authentication is available for a
particular card number

Verify Enrollment Response Message from ACS or Visa Directory, telling the Merchant Server
Plug-in whether authentication is available

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01

Glossary 3-D Secure: Protocol Specification
Core Functions v1.0.2
Page 98 July 16, 2002

Visa Directory A server hardware/software entity which is operated by Visa in the

Interoperability domain; it determines whether a specific card number is
participating in 3-D Secure, and if so, it returns the URL of the
appropriate Access Control Server to the Merchant Server Plug-in.

Visa Certificate Authority A component that operates in the Interoperability domain; generates and
distributes selected digital certificates to entities participating in
3-D Secure.

VisaNet The systems and services, including the V.I.P and BASE II systems,
through which Visa delivers online financial processing, authorization,
clearing and settlement services to Members.
wallet See digital wallet.

XML Extensible Markup Language, a computer programming language that

can serve as an extension of HTML. It is especially useful for defining
elements that may not have specific HTML tag definitions.

70000-01 Proprietary and Confidential Copyright © 2001-2002 Visa International

3-D Secure: Protocol Specification
Core Functions v1.0.2
July 16, 2002 Page 99

Revision Log
Version Date Brief Description of Change Affects
1.0 May 7, 2001 Initial issue. Throughout.
1.0 June 12, Terms and conditions of use. Legal agreements
2001
1.0.1 November 1, Incorporated all errata from version 1.0. CRReq processing by
2001 Added Invalid Request Code for Directory
invalid serial number. CRRes processing by MPI
Aligned XML signature processing with VEReq processing by
W3C and IETF publications dated Directory
20 August 2001. VEReq processing by ACS
PARes processing by ACS
PARes processing by MPI
1.0.1 July 15, 2002 Added explicit language about message May affect all message
validation and sending Error messages processing if any clarifications
in processing steps. differ from a vendor’s prior
Aligned Account Identifier handling interpretation of the intent of
in the processing steps with the the specification.
conditions described in Table 16.
Added new Invalid Request and
Error Code values.
Other general clarifications.
1.0.2 July 16, 2002 Adjusted to support generating proof of VEReq and PAReq
authentication attempt when processing by ACS
authentication is not available. PARes processing by MPI
Indicated that Account Identifier in Creation of VERes by ACS
VERes must not be the PAN.
Specified that Cardholder PAN in the PARes processing by ACS
PARes must include the last four digits PARes processing by MPI
of the PAN supplied in the VEReq,
preceded by zeros. Visa regions may
require that the full PAN be used.
Clarified that values of codes are Field tables
extensible.
Defined serialNumber as optional in DTD
CRRes; it is omitted when Invalid
Request Code is included.
Note: Revision marks indicate changes made since July 15, 2002.

Copyright © 2001-2002 Visa International Proprietary and Confidential 70000-01