3-D Secure

Protocol Specification Core

Functions Version 1.0.2
Effective: 30 September 2009

© 2008-2009 Visa. All Rights Reserved 70000-03

Visa *Confidential*
Important Note on Confidentiality
The Visa *Confidential* label in the footers indicates the information in this document is intended for use by Visa employees,
member banks, and external business partners that have signed a Nondisclosure Agreement (NDA) with Visa. This infor-
mation is not for public release.
Welcome to
3-D Secure Protocol
Specification Core
Functions Version
1.0.2
The 3-D Secure Protocol Specification Core Functions Version
1.0.2 has been updated.

The Visa *Confidential* label indicates that the information in

this document is intended for use by Visa employees, member
banks, and external business partners that have signed a
Nondisclosure Agreement (NDA) with Visa. This information is
not for public release.

Please send questions or comments to [email protected].

Effective: 30 September 2009

Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

In This Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Latest Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Future Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 3

Document Word Usage . . . . . . . . . . . . . . . . . . . . . . . . . 3

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3-D Secure Specifications . . . . . . . . . . . . . . . . . . . . . . 3

Licensed Documents . . . . . . . . . . . . . . . . . . . . . . . . 4

Compliance Testing Documents . . . . . . . . . . . . . . . . . . . . 4

Visa Implementation Guides . . . . . . . . . . . . . . . . . . . . . 4

Other Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . 5

Document Revisions Log . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 1 • Systems and Functional Overview

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1

Issuer Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1

Cardholder . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2

Cardholder Browser . . . . . . . . . . . . . . . . . . . . . . . . 1–2

Additional Cardholder Components . . . . . . . . . . . . . . . . . . 1–2

30 September 2009 Visa *Confidential* i

Contents 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Issuer Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2

Access Control Server . . . . . . . . . . . . . . . . . . . . . . . 1–2

Acquirer Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3

Merchant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3

Merchant Server Plug-in . . . . . . . . . . . . . . . . . . . . . . . 1–3

Validation Process . . . . . . . . . . . . . . . . . . . . . . . . . 1–3

Acquirer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3

Interoperability Domain . . . . . . . . . . . . . . . . . . . . . . . . . 1–4

Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4

Commercial Certificate Authority . . . . . . . . . . . . . . . . . . . 1–4

Scheme Certificate Authority . . . . . . . . . . . . . . . . . . . . . 1–4

Authentication History Server . . . . . . . . . . . . . . . . . . . . . 1–5

Authorization System . . . . . . . . . . . . . . . . . . . . . . . . 1–5

Chapter 2 • Technical Requirements

Messages Discussed in this Chapter . . . . . . . . . . . . . . . . . . . 2–1

Transport Security Requirements . . . . . . . . . . . . . . . . . . . . . 2–2

Channel Encryption . . . . . . . . . . . . . . . . . . . . . . . . 2–2

SSL Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 2–3

Issuer Domain Security . . . . . . . . . . . . . . . . . . . . . . . . . 2–4

Certificate Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2–4

Redundant Routing Requirements . . . . . . . . . . . . . . . . . . . . 2–5

HTTP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6

Persistent Sessions . . . . . . . . . . . . . . . . . . . . . . . . 2–6

3-D Secure Specification Compliance Requirements . . . . . . . . . . . . . 2–6

Compliance Testing Requirements . . . . . . . . . . . . . . . . . . . . 2–6

Cardholder Enrollment Requirements . . . . . . . . . . . . . . . . . . . 2–7

ii Visa *Confidential* 30 September 2009

3-D Secure Contents
Protocol Specification Core Functions Version 1.0.2

Chapter 3 • Issuer Setup and Cardholder Enrollment

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1

Cardholder Enrollment Overview . . . . . . . . . . . . . . . . . . . . 3–1

Cardholder 3-D Secure Enrollment Process . . . . . . . . . . . . . . 3–2

Sample Cardholder Enrollment Data . . . . . . . . . . . . . . . . . 3–3

Issuer Enrollment Data Setup . . . . . . . . . . . . . . . . . . . . 3–3

Chapter 4 • Purchase Transaction Authentication Processing

Purchase Transaction Process Flows . . . . . . . . . . . . . . . . . . 4–1

Sample Purchase Transaction: General Processing . . . . . . . . . . . 4–2

Purchase Transaction Processing Details . . . . . . . . . . . . . . . . . 4–3

Step Zero (Start): Merchant Server Plug-in—Load Cache . . . . . . . . . 4–3

Step 1: Cardholder Initiates Purchase Transaction . . . . . . . . . . . . 4–4

Step 2: Merchant Server Plug-in—Query PAN Enrollment . . . . . . . . . 4–5

Step 3: Directory Server—Query Access Control Server . . . . . . . . . . 4–5

Step 4: Access Control Server—Verify Enrollment . . . . . . . . . . . . 4–7

Step 5: Directory Server—Forward Response . . . . . . . . . . . . . . 4–8

Merchant Server Plug-in—Receive Response . . . . . . . . . . . . . . 4–9

Step 6: Merchant Server Plug-in—Send Payer Authentication Request . . . . 4–9

Step 7: Access Control Server— Receive Payer Authentication Request . . . 4–10

Step 8, Part 1: Access Control Server— Authenticate Shopper . . . . . . . 4–11

Step 8, Part 2: Access Control Server—Prepare Payer Authentication Response 4–14

Step 9: Access Control Server—Return Payer Authentication Response . . . 4–14

Steps 10 and 11: Merchant Server Plug-in—Validate Payer Authentication Response 4–15

Step 12: Payment Authorization . . . . . . . . . . . . . . . . . . . 4–16

Electronic Commerce Processing . . . . . . . . . . . . . . . . . . 4–16

Shopper Selects Alternate Account Number . . . . . . . . . . . . . . 4–16

30 September 2009 Visa *Confidential* iii

Contents 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Chapter 5 • Message Handling

3-D Secure Messages Handling . . . . . . . . . . . . . . . . . . . . . 5–1

Message Handling: Version Numbers . . . . . . . . . . . . . . . . . 5–1

Versioning and Parsing—Overview . . . . . . . . . . . . . . . . . . 5–1

Recommended Action For Messages Received . . . . . . . . . . . . . 5–2

ID Attribute—Message Element . . . . . . . . . . . . . . . . . . . . . 5–5

ID Attribute—PARes Element . . . . . . . . . . . . . . . . . . . . . . 5–5

HTTP POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

Base64 Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

XML Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

Partial System Outages . . . . . . . . . . . . . . . . . . . . . . . . 5–7

Message Bundling . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–7

Error Codes and Invalid Request Codes . . . . . . . . . . . . . . . . . . 5–7

Message Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8

3-D Secure Messages Diagrams . . . . . . . . . . . . . . . . . . . . . 5–8

Message Diagram Overview Introduction . . . . . . . . . . . . . . . . 5–8

CRReq Processing . . . . . . . . . . . . . . . . . . . . . . . . . 5–9

CRRes Processing . . . . . . . . . . . . . . . . . . . . . . . . . 5–9

VEReq Processing . . . . . . . . . . . . . . . . . . . . . . . . 5–10

VERes Processing . . . . . . . . . . . . . . . . . . . . . . . . 5–10

PAReq Processing . . . . . . . . . . . . . . . . . . . . . . . . 5–11

PARes Processing . . . . . . . . . . . . . . . . . . . . . . . . 5–12

Error Messages Processing . . . . . . . . . . . . . . . . . . . . 5–13

Appendix A • 3-D Secure XML Message Format

Document Element . . . . . . . . . . . . . . . . . . . . . . . . . . A–1

Date and Time Format(s) . . . . . . . . . . . . . . . . . . . . . . . . A–1

iv Visa *Confidential* 30 September 2009

3-D Secure Contents
Protocol Specification Core Functions Version 1.0.2

XML-Signature Syntax . . . . . . . . . . . . . . . . . . . . . . . . A–1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . A–1

Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–2

Certificate Chain . . . . . . . . . . . . . . . . . . . . . . . . . A–3

Canonicalization Requirements . . . . . . . . . . . . . . . . . . . A–3

XML Namespaces for Signatures . . . . . . . . . . . . . . . . . . A–3

Example Sample XML Code . . . . . . . . . . . . . . . . . . . A–3

Signature Structure . . . . . . . . . . . . . . . . . . . . . . A–4

3-D Secure DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . A–4

(1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–4

3-D Secure DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . A–5

(2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–5

3-D Secure DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . A–7

(3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A–7

Appendix B • 3-D Secure Field Formats

3-D Secure Field Formats . . . . . . . . . . . . . . . . . . . . . . . B–1

Appendix C • 3-D Secure Message Descriptions

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . C–1

Inclusion Values . . . . . . . . . . . . . . . . . . . . . . . . . . . C–2

Field Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . C–2

Conditions For Required Fields . . . . . . . . . . . . . . . . . . . . . C–2

Conditions For Optional Fields . . . . . . . . . . . . . . . . . . . . . C–3

Conditions For Missing Fields . . . . . . . . . . . . . . . . . . . . . C–3

CRReq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–3

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–3

Implementation Choices . . . . . . . . . . . . . . . . . . . . . . C–3

Required Field Missing . . . . . . . . . . . . . . . . . . . . . . . C–4

30 September 2009 Visa *Confidential* v

Contents 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–4

CRReq Field Descriptions . . . . . . . . . . . . . . . . . . . . . .C–4

CRRes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–6

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–6

“treat as an error” . . . . . . . . . . . . . . . . . . . . . . . . .C–6

Required Field Missing . . . . . . . . . . . . . . . . . . . . . . .C–6

Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–6

CRRes Field Descriptions . . . . . . . . . . . . . . . . . . . . . .C–7

VEReq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–8

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–8

Implementation Choices . . . . . . . . . . . . . . . . . . . . . . .C–8

Required Field Missing . . . . . . . . . . . . . . . . . . . . . . .C–9

Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . .C–9

VEReq Field Descriptions . . . . . . . . . . . . . . . . . . . . . .C–9

VERes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–12

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–12

“treat as an error” . . . . . . . . . . . . . . . . . . . . . . . . C–12

Required Field Missing . . . . . . . . . . . . . . . . . . . . . . C–13

Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . C–13

VERes Field Descriptions . . . . . . . . . . . . . . . . . . . . . C–13

PAReq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–15

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–15

Required Field Missing . . . . . . . . . . . . . . . . . . . . . . C–15

Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . C–15

Displaying Purchase Amount . . . . . . . . . . . . . . . . . . . . C–15

Recurring Frequency . . . . . . . . . . . . . . . . . . . . . . . C–16

Recurring Expiry . . . . . . . . . . . . . . . . . . . . . . . . . C–16

PAReq Field Descriptions . . . . . . . . . . . . . . . . . . . . . C–17

vi Visa *Confidential* 30 September 2009

3-D Secure Contents
Protocol Specification Core Functions Version 1.0.2

PARes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–20

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–20

Signature Validation . . . . . . . . . . . . . . . . . . . . . . . . C–20

“treat as an error” . . . . . . . . . . . . . . . . . . . . . . . . . C–20

Required Field Missing . . . . . . . . . . . . . . . . . . . . . . . C–20

Edit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . C–20

PARes Field Descriptions . . . . . . . . . . . . . . . . . . . . . . C–21

Invalid Request . . . . . . . . . . . . . . . . . . . . . . . . . . . C–24

Data Values . . . . . . . . . . . . . . . . . . . . . . . . . . . C–24

Excluded ISO Code Values . . . . . . . . . . . . . . . . . . . . . C–26

Message Extensions . . . . . . . . . . . . . . . . . . . . . . . . . C–27

Message Extension Data . . . . . . . . . . . . . . . . . . . . . . C–27

Message Extension Attributes . . . . . . . . . . . . . . . . . . . . C–27

Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . C–28

Criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–28

Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . C–29

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . C–29

Client Delivered Error . . . . . . . . . . . . . . . . . . . . . . . C–29

Response to Error Message . . . . . . . . . . . . . . . . . . . . C–29

Message ID . . . . . . . . . . . . . . . . . . . . . . . . . . . C–29

Related Elements . . . . . . . . . . . . . . . . . . . . . . . . . C–30

Error Message Field Descriptions . . . . . . . . . . . . . . . . . . C–31

Appendix D • PAReq and PARes File Compression

Impact of Base64 Encoding . . . . . . . . . . . . . . . . . . . . . . D–1

Compression Algorithms . . . . . . . . . . . . . . . . . . . . . . . D–1

Glossary

30 September 2009 Visa *Confidential* vii

Contents 3-D Secure
Protocol Specification Core Functions Version 1.0.2

viii Visa *Confidential* 30 September 2009

List of Tables

1: Document Revision Log . . . . . . . . . . . . . . . . . . . . .6

2–1: Transport Security Requirements . . . . . . . . . . . . . . . . . 2–2
2–2: Cryptographic Suites . . . . . . . . . . . . . . . . . . . . . 2–3
2–3: Certificate Requirements . . . . . . . . . . . . . . . . . . . 2–4
2–4: Redundant Routing Requirements . . . . . . . . . . . . . . . . 2–5
3–1: Sample Cardholder Enrollment Data . . . . . . . . . . . . . . . . 3–3
3–2: Enrollment Data Recommendations . . . . . . . . . . . . . . . . 3–4
4–1: Sample Purchase Transaction . . . . . . . . . . . . . . . . . . 4–2
4–2: Fields in Form MPI Sends to ACS . . . . . . . . . . . . . . . . 4–10
4–3: Example Fields Displayed for Cardholder Authentication . . . . . . . . 4–12
4–4: ACS Sets Transaction Status . . . . . . . . . . . . . . . . . 4–13
4–5: Fields in Form ACS Sends to MPI . . . . . . . . . . . . . . . . 4–14
5–1: Versioning and Parsing—Directory Server . . . . . . . . . . . . . . 5–3
5–2: Versioning and Parsing—Access Control Server . . . . . . . . . . . . 5–4
5–3: Versioning and Parsing—Merchant Server Plug-in . . . . . . . . . . . 5–4
A–1: XML Signature Profile . . . . . . . . . . . . . . . . . . . . A–2
A–2: XML Signature Algorithms . . . . . . . . . . . . . . . . . . . A–2
B–1: 3-D Secure Field Formats . . . . . . . . . . . . . . . . . . . B–1
C–1: Field Inclusion Values . . . . . . . . . . . . . . . . . . . . C–2
C–2: CRReq Field Descriptions . . . . . . . . . . . . . . . . . . . C–4
C–3: CRRes Field Descriptions . . . . . . . . . . . . . . . . . . . C–7
C–4: VEReq Field Descriptions . . . . . . . . . . . . . . . . . . . C–9
C–5: VERes Field Descriptions . . . . . . . . . . . . . . . . . . C–13
C–6: Recurring Frequency . . . . . . . . . . . . . . . . . . . . C–16
C–7: PAReq Field Descriptions . . . . . . . . . . . . . . . . . . C–17

30 September 2009 Visa *Confidential* ix

List of Tables 3-D Secure
Protocol Specification Core Functions Version 1.0.2

C–8: PARes Field Descriptions . . . . . . . . . . . . . . . . . . C–21

C–9: Invalid Request Data Values . . . . . . . . . . . . . . . . . . C–25
C–10: Excluded ISO Code Values . . . . . . . . . . . . . . . . . . C–26
C–11: Message Extension Attributes . . . . . . . . . . . . . . . . . C–27
C–12: Error Code, Error Description, and Error Detail . . . . . . . . . . . . C–30
C–13: Error Message Field Descriptions . . . . . . . . . . . . . . . . C–31

x Visa *Confidential* 30 September 2009

List of Figures

3–1: Sample Cardholder Enrollment Process . . . . . . . . . . . . . . . 3–2

4–1: Sample Purchase Transaction . . . . . . . . . . . . . . . . . . 4–1
4–2: Sample Authentication Request Page . . . . . . . . . . . . . . 4–13
5–1: Overview of 3-D Secure Messages . . . . . . . . . . . . . . . . 5–9
5–2: CRReq Processing . . . . . . . . . . . . . . . . . . . . . 5–9
5–3: CRRes Processing . . . . . . . . . . . . . . . . . . . . 5–10
5–4: VEReq Processing . . . . . . . . . . . . . . . . . . . . 5–10
5–5: VERes Processing . . . . . . . . . . . . . . . . . . . . 5–11
5–6: PAReq Processing . . . . . . . . . . . . . . . . . . . . 5–12
5–7: PARes Processing . . . . . . . . . . . . . . . . . . . . 5–13
5–8: Error Processing . . . . . . . . . . . . . . . . . . . . . 5–13
A–1: Signature Structure . . . . . . . . . . . . . . . . . . . . . A–4

30 September 2009 Visa *Confidential* xi

Preface

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

About This Guide

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.

Purpose
Payment authentication is the process of verifying cardholder account ownership during a
purchase transaction in the remote 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
payment cards and improving transaction performance.

30 September 2009 Visa *Confidential* 1

Preface 3-D Secure
Protocol Specification Core Functions Version 1.0.2

This document describes 3-D Secure, including the messages supporting payment
authentication.
As described in this document, 3-D Secure defines a base level of security.
Enhancements will be included in later versions.

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

In This Version
The major changes included in 3-D Secure version 1.0.2 are:
● 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 Payer Authentication Response must be
masked.
● Adjusted DTD to indicate that Serial Number is optional in the Card Range Request; it
is omitted when Invalid Request Code is included.
For details, see the Document Revisions Log.

All code changes pertinent for 3-D Secure Version 1.0.2 are noted with the “1.0.2 change
symbol,” as shown here in the left margin.

Latest Changes

This document version includes updates for version 1.0.2. See the Document Revisions
Log for more information.
Revision marks are included.

2 Visa *Confidential* 30 September 2009

3-D Secure Future Considerations
Protocol Specification Core Functions Version 1.0.2

Future Considerations
The base 3-D Secure protocol has been designed for the current business and market
environment. In the future, enhancements to this protocol may be defined in order to
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.

Document Word Usage

The following words are used often in this document and have specific meanings:

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.

References
The following documents provide fundamental information about 3-D Secure and 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 Specifications

Every 3-D Secure component must comply with the requirements of the core 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)

30 September 2009 Visa *Confidential* 3

Preface 3-D Secure
Protocol Specification Core Functions Version 1.0.2

● 3-D Secure: Functional Requirements – Merchant Server Plug-in, Visa Publication

70003 01 (licensed)
● 3-D Secure: Functional Requirements – Directory Server, Visa Publication 70025 01
(licensed)
Every 3-D Secure issuer component must also comply with the security requirements of
the supported Payment Schemes. The Visa requirements are described in:
● 3-D Secure: Security Requirements – Enrollment and Access Control Servers, Visa
Publication 70016-01 (licensed)
Any 3-D Secure component that supports mobile 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)
● 3-D Secure: Protocol Specification – Extension for Voice and Messaging Channels,
Visa Publication 70004 01 (licensed)
Throughout this publication suite, the requirements described in those documents are
collectively referred to as “the 3-D Secure specifications.”
For Technical Requirements, see Chapter 2, Technical Requirements.

Licensed Documents
Some 3-D Secure documents are available only to parties that have executed with 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.

Compliance Testing Documents

All software components that are developed as 3-D Secure solutions are required to
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

Visa Implementation Guides

The following documents are referenced in this specification and/or provide useful
supplementary information for Visa implementations:
●
3-D Secure: Implementation Guide – Issuer, Visa Publication 70013-01

4 Visa *Confidential* 30 September 2009

3-D Secure Document Organization
Protocol Specification Core Functions Version 1.0.2

● 3-D Secure: Implementation Guide – Acquirer, Visa Publication 70014 01

● 3-D Secure: Implementation Guide – Merchant, Visa Publication 70020 01

Other Documents
The following documents are referenced in this specification and/or provide useful
background information:
● Certificate Infrastructure Group Brand Certificate Authority – Operating Procedures,
version 1.0, dated August 1999.
● Certificate Infrastructure Group Brand Certificate Authority – Business Policies and
Procedures, version 1.0, dated August 1999.
● 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.
● Canonical XML, W3C Recommendation, version 1.0, dated 15 March 2001, available
at http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
● XML-Signature Syntax and Processing, W3C Recommendation, dated 12 February
2002, available at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ or http://
www.ietf.org/rfc/rfc3275.txt.
● Namespaces in XML, W3C Recommendation, dated 14 January 1999, available at
http://www.w3.org/TR/1999/REC-xml-names-19990114.
● The TLS [Transport Layer Security] Protocol, Version 1.0, dated January 1999,
available at http://www.ietf.org/rfc/rfc2246.txt.
● Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies, available at http://www.ietf.org/rfc/rfc2045.txt, includes the algorithm for
calculating a Base64 result.
●
Hypertext Transfer Protocol – HTTP/1.1, available at http://www.ietf.org/rfc/
rfc2068.txt, discusses chunked transfer coding.

Document Organization
The document is organized as follows:
●
Preface— this section contains an overview of the document and a list of references.
It also includes a document revision log, summarizing the changes in each production
version of the document.
● Chapter 1, Systems and Functional Overview—provides an overview of the issuer,
acquirer, and interoperability domains.
●
Chapter 2, Technical Requirements—lists and describes the technical requirements
for 3-D Secure.

30 September 2009 Visa *Confidential* 5

Preface 3-D Secure
Protocol Specification Core Functions Version 1.0.2

● Chapter 3, Issuer Setup and Cardholder Enrollment—provides an overview of issuer

setup and cardholder enrollment functions.
● Chapter 4, Purchase Transaction Authentication Processing—describes the design of
the purchase transaction.
●
Chapter 5, Message Handling—describes 3-D Secure message handling. Message
structures are also available in this chapter.
● Appendix A, 3-D Secure XML Message Format—includes the XML message format
of the 3-D Secure messages, and the DTDs.
● Appendix B, 3-D Secure Field Formats—provides a alphabetically sorted list of the
fields in all the core 3-D Secure messages, including field descriptions, DTD, and
message information. Field validation information is available in Appendix C.
● Appendix C, 3-D Secure Message Descriptions—provides complete descriptions for
all 3-D Secure fields, including field descriptions, DTD inclusion, edit criteria, and
validation information.
● Appendix D, PAReq and PARes File Compression—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.

Document Revisions Log

Table 1 lists the revisions included in this document version.

Table 1: Document Revision Log (1 of 5)

Version Date Brief Description of Change Affects

1.0 7 May 2001 Initial issue. Throughout.

1.0 12 June 2001 Terms and conditions of use. Legal agreements.

1.0.1 1 Nov 2001 Incorporated all errata from version 1.0. CRReq processing by Directory Server
Added Invalid Request Code for invalid CRRes processing by MPI
serial number.
VEReq processing by Directory Server
Aligned XML signature processing with
VEReq processing by ACS
W3C and IETF publications dated 20
August 2001. PARes processing by ACS
PARes processing by MPI

6 Visa *Confidential* 30 September 2009

3-D Secure Document Revisions Log
Protocol Specification Core Functions Version 1.0.2

Table 1: Document Revision Log (2 of 5)

Version Date Brief Description of Change Affects

1.0.1 15 July 2002 Added explicit language about message May affect all message processing if any
validation and sending Error messages clarifications differ from a developer’s
in processing steps. prior interpretation of the intent of the
specification.
Aligned Account Identifier handling in
the processing steps with the conditions
described in Table 21.
Added new Invalid Request Code and
Error Code values.
Other general clarifications.

1.0.2 16 July 2002 Adjusted to support generating proof of VEReq and PAReq processing by ACS;
authentication attempt when PARes processing by MPI.
authentication is not available.

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.

30 September 2009 Visa *Confidential* 7

Preface 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table 1: Document Revision Log (3 of 5)

Version Date Brief Description of Change Affects

1.0.2 16 Jan 2003 Combined requirements for versions Throughout

1.0.1 and 1.0.2 into a single document
for the convenience of developers.

Clarified treatment of messages with ACS handling of PAReq amount fields.

different version numbers.
Creation and processing of message
Adjusted description of Purchase extensions.
Amount. Specified that the ACS is to rely
May affect all message processing if any
only on the value of Purchase Amount
clarifications differ from a developer’s
and is not to make use of Display
prior interpretation of the intent of the
Amount.
specification.
Specified that the critical attribute for a
message extension is optional, with a
default value of “false”. Clarified
processing of critical message
extensions.
Clarified length of current certificate
chain.
Added a new Invalid Request Code
value and a new CAVV Algorithm value.
Clarified general message validation.
Specified validation required for each
field of each request or response
message.
Other general clarifications.

1.0.2 20 Jan 2004 Updated validation requirements: Chapter 6 message element tables
●
Consolidated validation rules into a Chapter 5 authentication processing
single column per message. description
● Enhanced field descriptions,
providing consistent edit criteria and
simplified validation requirements.

Clarified message handling, including id Message handling

attributes, Content-Length header, and
Base53 decoding.

Other clarifications, including signature Throughout.

white space.

8 Visa *Confidential* 30 September 2009

3-D Secure Document Revisions Log
Protocol Specification Core Functions Version 1.0.2

Table 1: Document Revision Log (4 of 5)

Version Date Brief Description of Change Affects

1.0.2 30 March 2006 Renamed and renumbered chapters Throughout.

and appendices (listed with new number
and name):
● About This Guide (was Chapter 1,
Overview).
● Chapter 1 (was chapter 2), renamed
to Systems and Functional Overview.
● Chapter 2 (was chapter 3), renamed
to Technical Requirements for
Implementation.
● Chapter 3 (was chapter 4), renamed
to Issuer Setup and Cardholder
Enrollment.
● Chapter 4 (was chapter 5), renamed
to Purchase Transaction
Authentication Processing.
● Chapter 5 (was chapter 6), renamed
to Message Handling.
● Appendix C (new, see next entry)
● Appendix D renamed to PAReq and
PARes File Compression

Chapter 5 (was chapter 6) Message Chapter 5 and Appendix C.

Handling:
● Added new section for message
diagrams.
●
Moved all message description-
related information to the new
Appendix C.

Appendix A: moved message diagrams Chapter 5

to chapter 5.

30 September 2009 Visa *Confidential* 9

Preface 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table 1: Document Revision Log (5 of 5)

Version Date Brief Description of Change Affects

1.0.2 30 March 2006 Appendix C: Created new appendix Appendix C

from content in chapter 5 (was chapter
(continued)
6):
● message descriptions
● inclusion values
● field edit criteria
● conditions for required, optional, and
missing fields
●
invalid request
● message extensions
● error message

Updated diagrams: Chapter 3 and Chapter 4

Figure 3-1, 4-1, and 4-2.

Removed all references to version 1.0.1. Throughout.

Removed errata table (replaced by end of document.

Revisions Log)

Removed all hard-coded page Throughout.

references and replaced with hypertext
links to the relevant sections.

Enhanced chapter numbering that Throughout.

restarts at each chapter (was sequential
throughout). Now the chapter/appendix
number precedes the page number
(example, page 4-12).

1.0.2 30 September 2009 Updated the document with the changes Throughout.
outlined in the 3-D Secure Technical
Bulletins issued August 15, 2009.

10 Visa *Confidential* 30 September 2009

Systems and Functional Overview 1

Purpose
This chapter describes the systems and functions necessary to implement 3-D
Secure3-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 Domain—Systems, functions, and messages that allow Issuer
Domain systems and Acquirer Domain systems to interoperate worldwide.
NOTE: Third parties may operate many of the systems in the Issuer and Acquirer
Domains on behalf of Visa Members.

Issuer Domain
This section provides descriptions for the following Issuer Domain Entities:
●
Cardholder
● Cardholder Browser
● Additional Cardholder Components
●
Issuer Domain
●
Access Control Server

30 September 2009 Visa *Confidential* 1–1

Systems and Functional Overview 3-D Secure
Protocol Specification Core Functions Version 1.0.2

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 Authentication Request Page, the
cardholder provides information needed for authentication, such as a password.

Cardholder Browser
The cardholder browser 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).

Additional Cardholder Components

Optional cardholder hardware and software may supplement the abilities of the browser.
For example, chip card implementations will require additional cardholder software and a
card reader. Implementations that use passwords to authenticate cardholders using PCs
should not require any additional cardholder hardware or software.

Issuer Domain
A Member financial institution that:
● enters into a contractual relationship with the cardholder for issuance of one or more
payment cards.
● determines the cardholder’s eligibility to participate in the 3-D Secure service.
● defines card number ranges eligible to participate in the 3-D Secure service.
● provides data about those card number ranges to the Directory Server.
● performs enrollment of the cardholder for each payment card account (via the Access
Control Server, a separate Enrollment Server, or manually).

Access Control Server

The Access Control Server (ACS) has two functions:
●
to verify whether 3-D Secure authentication (or proof of attempted authentication) is
available for a particular card number and device type.
● to authenticate the cardholder for a specific transaction or to provide proof of
attempted authentication when authentication is not available.
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.

1–2 Visa *Confidential* 30 September 2009

3-D Secure Acquirer Domain
Protocol Specification Core Functions Version 1.0.2

See the 3-D Secure Functional Requirements Access Control Server document for more
specific information.

Acquirer Domain
This section provides descriptions for the following Acquirer Domain Entities:
● Merchant
● Merchant Server Plug-in
● Validation Process
● Acquirer

Merchant
Existing merchant software handles the shopping experience, 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 Server Plug-in

The Merchant Server Plug-in (MPI) creates and processes payment authentication
messages, then returns control to the merchant 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, the acquirer, or a third party.
See the 3-D Secure Functional Requirements Merchant Server Plug-in document for
more specific information.

Validation Process
This function validates the signature received in the message from 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 Member financial institution that:
● enters into a contractual relationship with a merchant for purposes of accepting
payment cards.
● determines the merchant’s eligibility to participate in the 3-D Secure service.

30 September 2009 Visa *Confidential* 1–3

Systems and Functional Overview 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Following payment authentication, the acquirer performs its traditional role to:
● receive authorization requests from the merchant.
● forward them to the authorization system (such as VisaNet).
● provide authorization responses to the merchant.
● submit the completed transaction to the settlement system (such as VisaNet).

Interoperability Domain
This section provides descriptions for the following Acquirer Domain Entities:
● Directory Server
● Commercial Certificate Authority
● Scheme Certificate Authority
● Authentication History Server
● Authorization System

Directory Server
The Directory Server, operated by each participating Payment Scheme:
● 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 (which may
or may not provide Attempts functionality) or responds directly to the merchant.
● receives the response from the ACS indicating whether payment authentication (or
proof of attempted authentication) is available for the cardholder account.
● forwards the response to the merchant.

Commercial Certificate Authority

Generates selected certificates for the use of 3-D Secure entities, including:
● TLS/SSL client and server certificates.

Scheme Certificate Authority

Generates selected certificates for the use of 3-D Secure entities, including:
● signing certificates.
●
Root certificate required by the Payment Scheme.

1–4 Visa *Confidential* 30 September 2009

3-D Secure Interoperability Domain
Protocol Specification Core Functions Version 1.0.2

Authentication History Server

The Authentication History Server, operated by each participating Payment Scheme:
● 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.

Authorization System
Following payment authentication, the authorization system (such as 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 services to the acquirer and issuer.

30 September 2009 Visa *Confidential* 1–5

Technical Requirements 2

Messages Discussed in this Chapter

The following messages are occasionally mentioned in this chapter:
●
CRReq—Card Range Request
●
CRRes—Card Range Response
●
VEReq—Verify Enrollment Request
●
VERes—Verify Enrollment Response
●
PAReq—Payer Authentication Request
●
PARes—Payer Authentication Response
●
Error—Error message
For more information on these messages, refer to:
● Chapter 5, for 3-D Secure message structure
● Appendix C, for 3-D Secure message descriptions.
An additional message pair, which populated the Authentication History Server, is
mentioned only briefly in this document, and documented in detail in 3-D Secure:
Functional Requirements – Access Control Server:
● PATransReq—Payer Authentication Transaction Request
● PATransRes—Payer Authentication Transaction Response
NOTE: Implementations 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.

30 September 2009 Visa *Confidential* 2–1

Technical Requirements 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Transport Security Requirements

Channel Encryption
The SSL servers described in Table 2–1 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 the section “Certificate Requirements” in this
chapter, and the Functional Requirements documents listed in About This Guide, the
section “3-D Secure Specifications.

Table 2–1: Transport Security Requirements (1 of 2)

Channel Number and Type Channel Use

1. Cardholder to Merchant This channel is used:

● 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 Access Control This channel is used:

System (ACS) ● to forward the PAReq to the 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.

3. Merchant to Directory Server This channel is used to transport VEReq, VERes, CRReq, CRRes, and Error.
The Directory Server must secure this channel with an SSL session initiated
using a server certificate. The Directory Server 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 (Directory
Server and merchant) must be capable of supporting client authentication.

2–2 Visa *Confidential* 30 September 2009

3-D Secure Transport Security Requirements
Protocol Specification Core Functions Version 1.0.2

Table 2–1: Transport Security Requirements (2 of 2)

Channel Number and Type Channel Use

4. Directory Server to Access This channel is used to transport the VEReq, VERes, and 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 Directory Server.

5. Merchant to Validation Process When the validation process is implemented as a separate server, this
channel is used to transport the PARes (for 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 Access Control This channel is used to transport the Error message.
Server
The ACS must secure this channel with an SSL session initiated using a
server certificate.

SSL Cipher Suites

The security protocol used at the transport layer for 3-D Secure is the Transport 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 2–2.
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.

Table 2–2: Cryptographic Suites

TLS_RSA_WITH_3DES_EDE_CBC_SHA required

TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA required

30 September 2009 Visa *Confidential* 2–3

Technical Requirements 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Issuer Domain Security

ACS developers may need to develop enhancements to their product that provide for
enhanced issuer domain security. One example of this is the use of “encrypted cookies” to
help ensure that the authentication dialogue is being performed directly between the
issuer ACS and the cardholder’s client device. Either the issuer or the Payment Scheme
may provide such requirements.

Certificate Requirements
Table 2–3 lists the certificates that are necessary to implement 3-D Secure.
For more information regarding the Visa Certificate Authority Key Management Policies,
see the Certificate Infrastructure Group documents described in About This Guide, the
section “Other Relevant Documents.
NOTE: The Visa Root certificate is a self-signed certificate.

Table 2–3: Certificate Requirements (1 of 2)

Entity Purpose Certificates Required

Merchant server Plug-in To authenticate the merchant to SSL client certificate

the Directory Server and an
Root certificate required by the Payment Scheme
optional Validation Process
and all other certificates needed to validate the client
Server
certificate.

To protect the cardholder’s SSL server certificate

PAN data and the PAReq and
Root certificate required by the Payment Scheme
PARes data
and all other certificates needed to validate the
server certificate, if it was issued under that Root.

Directory Server To protect the VEReq and SSL server certificate

VERes data
Root certificate required by the Payment Scheme
and all other certificates needed to validate the
server certificate.

To authenticate the Directory SSL client certificate

Server to the ACS
Root certificate required by the Payment Scheme
and all other certificates needed to validate the client
certificate.

2–4 Visa *Confidential* 30 September 2009

3-D Secure Redundant Routing Requirements
Protocol Specification Core Functions Version 1.0.2

Table 2–3: Certificate Requirements (2 of 2)

Entity Purpose Certificates Required

Access Control Server To protect the VEReq, VERes, SSL server certificate
PAReq, and PARes data
(continued) Root certificate required by the Payment Scheme
and all other certificates needed to validate the
server certificate, if it was issued under that 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.

Access Control Server To sign the PARes message Signing certificate (issued to issuer)
(continued) Root certificate required by the Payment Scheme
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 Process To validate the PARes Root certificate required by the Payment Scheme
Server message signature and all other certificates needed to validate the
server certificate.

Redundant Routing Requirements

Applications must support multiple path routing to the Directory Server and Access
Control Server, as listed in Table 2–4.

Table 2–4: Redundant Routing Requirements

Entity Redundant Routing Requirements

Directory Server When the Directory Server 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.

30 September 2009 Visa *Confidential* 2–5

Technical Requirements 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table 2–4: Redundant Routing Requirements

Entity Redundant Routing Requirements

Merchant Plug-in The Merchant Server Plug-in must support the ability of
the Merchant system to implement an immediate failover
to a secondary Directory Server if it is unable to establish
a session with the primary Directory Server. Depending
on scheme requirements the location of the secondary
Directory Server may be specified by an alternate IP
address associated with the Directory Server domain
name (through a DNS lookup), or the scheme provider
may specify an alternate URL.
The requirements for alternate URLs or IP addresses will
be specified in the Implementation Guides published by
each Payment Scheme.

HTTP Connections

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

3-D Secure Specification Compliance Requirements

Every 3-D Secure component must comply with the requirements stated in the 3-D
Secure Specifications section of About This Guide. They include:
● Functional Requirements
● Security Requirements
● Specifications for the Supported Extensions.

Compliance Testing Requirements

All software components that are developed as 3-D Secure solutions are required to
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.

2–6 Visa *Confidential* 30 September 2009

3-D Secure Cardholder Enrollment Requirements
Protocol Specification Core Functions Version 1.0.2

Cardholder Enrollment Requirements

The cardholder enrollment process only requires that the Issuer establish the criteria for
the enrollment data. Sample cardholder enrollment data is available in Table 3–1, in
Chapter 3. FOr additional guidelines for cardholder enrollment, see Chapter 3, Issuer
Setup and Cardholder Enrollment.

30 September 2009 Visa *Confidential* 2–7

Issuer Setup and Cardholder Enrollment 3

Purpose
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 in this chapter are provided
as background material for the reader.

Cardholder Enrollment Overview

This section provides the process flow for setting up and enrolling a cardholder in 3-D
Secure. This two-part process includes:
●
Issuer Enrollment Data Setup
●
Cardholder 3-D Secure Enrollment Process
The overall process, as illustrated in Figure 3–1, includes:
1. Cardholder visits the Issuer’s enrollment site.
2. Cardholder provides enrollment data and establishes shared secret.
3. Issuer verifies the cardholder’s identity.
4. Enrollment information is then stored for later use in the 3-D Secure purchase
transaction authentication.
Figure 3–1 illustrates a possible architecture for cardholder enrollment.

30 September 2009 Visa *Confidential* 3–1

Issuer Setup and Cardholder Enrollment 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Figure 3–1: Sample Cardholder Enrollment Process

Cardholder 3-D Secure Enrollment Process

A possible cardholder enrollment process follows:
1. Cardholder visits the issuer’s 3-D Secure enrollment Web page and is required to
enter information, such as that listed in Table 3–1.
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.

3–2 Visa *Confidential* 30 September 2009

3-D Secure Cardholder Enrollment Overview
Protocol Specification Core Functions Version 1.0.2

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 3–1.
7. The issuer displays an appropriate completion of enrollment message to cardholder.

Sample Cardholder Enrollment Data

Table 3–1 provides the sample cardholder enrollment data.

Table 3–1: Sample Cardholder Enrollment Data

PAN

Card Expiry Date

Cardholder Name

Cardholder’s E-Mail Address

Personal Assurance Message (PAM); created by the user, displayed in the secret code
prompt window to help reduce spoofing.

Cardholder’s Password

Special question/hint

Special question/hint response

Issuer-specified authentication information

Issuer Enrollment Data Setup

The Issuer’s steps to enroll their Cardholder in 3-D Secure are:
1. Issuer loads its Enrollment Server with the data to enroll their cardholder in 3-D
Secure.
2. Issuer provides to Payment Scheme the data needed to load the Directory Server.
3. Payment Scheme updates the Directory Server.

30 September 2009 Visa *Confidential* 3–3

Issuer Setup and Cardholder Enrollment 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table 3–2 lists the enrollment data that the issuer might need.

Table 3–2: Enrollment Data Recommendations

Beginning of range (13 – 19 digits)

End of range (13 – 19 digits)

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.

The issuer’s Terms of Use and Data Privacy Policy

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

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.

3–4 Visa *Confidential* 30 September 2009

Purchase Transaction Authentication
Processing 4

Purchase Transaction Process Flows

Figure 4–1 illustrates the steps in the purchase transaction flow.
NOTE: These steps are described in the section, “Sample Purchase Transaction:
General Processing,” specifically in Table 4–1.

Figure 4–1: Sample Purchase Transaction

30 September 2009 Visa *Confidential* 4–1

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Sample Purchase Transaction: General Processing

Table 4–1 lists the 12 steps of a purchase transaction, as illustrated in Figure 4–1.

Table 4–1: Sample Purchase Transaction (1 of 2)

Step 1 Shopper browses at merchant site, adds items to shopping cart, then
finalizes purchase.
Note: Merchant now has all necessary data, including PAN and user device
information.

Step 2 Merchant Server Plug-in (MPI) sends PAN (and user device information, if
applicable) to Directory Server.

Step 3 Directory Server queries appropriate Access Control Server (ACS) to

determine whether authentication (or proof of authentication attempt) is
available for the PAN and device type.
If no appropriate ACS is available, the Directory Server creates a response
for the MPI and processing continues with Step 5.

Step 4 ACS responds to Directory Server.

Step 5 Directory Server forwards ACS response (or its own) to MPI.
If neither authentication nor proof of authentication attempt is available, 3-D
Secure processing ends, and the merchant, acquirer, or payment processor
may submit a traditional authorization request, if appropriate.

Step 6 MPI sends Payer Authentication Request to ACS via shopper’s device.
Note: The Payer 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).

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 Payer Authentication Response message with
appropriate values and signs it.
Note: The Payer Authentication Response message is PARes if PAReq
was received, or CPRS if CPRQ was received. (CPRS is created using
values from the PARes.)

Step 9 ACS returns Payer Authentication Response to MPI via shopper’s device.
ACS sends selected data to Authentication History Server.

4–2 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

Table 4–1: Sample Purchase Transaction (2 of 2)

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.

Following Step 12, acquirer processes authorization with issuer via an
authorization system such as VisaNet, then returns the results to merchant.

Purchase Transaction Processing Details

Purchase transaction processing involves these steps:
● Step Zero (Start): Merchant Server Plug-in—Load Cache
● Step 1: Cardholder Initiates Purchase Transaction
● Step 2: Merchant Server Plug-in—Query PAN Enrollment
● Step 3: Directory Server—Query Access Control Server
● Step 4: Access Control Server—Verify Enrollment
● Step 5: Directory Server—Forward Response
● Step 6: Merchant Server Plug-in—Send Payer Authentication Request
● Step 7: Access Control Server— Receive Payer Authentication Request
● Step 8, Part 1: Access Control Server— Authenticate Shopper
● Step 8, Part 2: Access Control Server—Prepare Payer Authentication Response
● Step 9: Access Control Server—Return Payer Authentication Response
●
Steps 10 and 11: Merchant Server Plug-in—Validate Payer Authentication Response
●
Step 12: Payment Authorization
The sections that immediately follow, describe these steps in greater detail.

Step Zero (Start): Merchant Server Plug-in—Load Cache

To eliminate the need to query the Directory Server (DS) for each purchase transaction (in
Step 2), the merchant should have the ability to copy the contents of the DS 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

30 September 2009 Visa *Confidential* 4–3

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

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, as described in
Appendix C, Table C–2, and sends the request to the Directory Server.
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 DS returning the entire list of participating card
ranges.
Otherwise, the MPI should include the Serial Number from the most recently
processed Card Range Response (CRRes), which will result in the DS returning
only the changes since the previous CRRes.
b. The Directory Server validates the syntax of the CRReq, as described in
Appendix C, Table C–2, and returns an Error if validation fails.
The DS authenticates the merchant as described for VEReq in Step 3a. If
authentication fails, the DS formats a CRRes with Invalid Request Data set to the
corresponding value from Appendix C, Table C–9.
The DS formats a CRRes, as described in Appendix C, Table C–3, containing the
participating ranges and sends it to the MPI. If the CRReq includes a value for
Serial Number, the DS returns only those updates made since that value of Serial
Number was current.
The DS includes a serial number in the response that defines the current state of
the card range database. (The specific value is meaningful only to the DS that
returns it.)
c. The MPI validates the syntax of the CRRes, as described in Appendix C, Table C–
3, and should send an Error to the Directory Server 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. The MPI should retain the
Serial Number value to be included with the next day’s CRReq message.

NOTE: If CRRes indicates any error condition, the MPI should clear its cache and submit
the CRReq without a Serial Number element.

Step 1: Cardholder Initiates Purchase Transaction

a. Cardholder visits a merchant Web site via a browser and selects items to
purchase.

4–4 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

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.

Step 2: Merchant Server Plug-in—Query PAN Enrollment

This process occurs after the final “Buy” confirmation from the cardholder during the
merchant checkout process. The merchant software invokes the Merchant Server Plug-in
(MPI) to determine whether payment authentication is available for the PAN and user
device information.
a. If the Merchant Server Plug-in (MPI) has implemented caching (as discussed in
Step Zero (Start): Merchant Server Plug-in—Load Cache, it checks its cache of
participating card number ranges.
If the PAN is not in one of the ranges, continue with Step 12: Payment
Authorization.
b. The MPI formats a Verify Enrollment Request (VEReq) message, as described in
Appendix C, Table C–4.
c. The MPI determines whether it currently has a secure connection with the
Directory Server.
If not, the MPI establishes an SSL connection with the Directory Server. If the
Directory Server 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: Payment Authorization.
d. The MPI posts the VEReq to the Directory Server.
See the 3-D Secure Functional Requirements Merchant Server Plug-in document for
more specific information.

Step 3: Directory Server—Query Access Control Server

This process occurs immediately after the Directory Server receives the VEReq from the
Merchant Server Plug-in.
a. The Directory Server validates the syntax of the VEReq, as described in Appendix
C, Table C–4, and returns an Error if validation fails.

30 September 2009 Visa *Confidential* 4–5

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

The Directory Server validates the VEReq data, ensuring that each of the
following is true:
● The Acquirer BIN represents a participating acquirer.
● The endpoint submitting the transaction is a valid merchant endpoint. The Merchant
ID may be used to perform this validation, by ensuring that it 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 Directory Server formats a Verify Enrollment Response (VERes) including:
– PAN Authentication Available set to “N”
– no Account Identifier, ACS URL or Payment Protocols
– Invalid Request Data set to the corresponding value from Appendix C, Table C–
9.
● The Directory Server returns the VERes to the Merchant Server Plug-in and stops.
b. The Directory Server searches for a record specifying a card range that includes
the Cardholder PAN that was received in the VEReq.
If not found:
● The Directory Server formats a Verify Enrollment Response (VERes) message, as
described in Appendix C, Table C–5, including:
– PAN Authentication Available set to “N”
– no Account Identifier, ACS URL, Payment Protocols, or Invalid Request Data
●
The Directory Server returns VERes message to the Merchant Server Plug-in and
stops.
c. The Directory Server determines whether it currently has a secure connection
with the ACS.

4–6 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

If not, then the Directory Server establishes an SSL connection with the ACS. The
SSL client certificate of the Directory Server and the server certificate of the ACS
must be presented and validated during the establishment of the SSL session.
If the Directory Server maintains alternate URLs for the ACS, and if the first URL
attempted is not available, the Directory Server will attempt to connect to one of
the alternate URLs.
If unsuccessful on all attempts:
● The Directory Server formats a Verify Enrollment Response (VERes), as described in
Appendix C, Table C–5, message including:
– PAN Authentication Available set to “N”
– no Account Identifier, ACS URL, Payment Protocols, or Invalid Request Data
● The Directory Server returns VERes message to the Merchant Server Plug-in and
stops.
d. The Directory Server removes the Password from the VEReq message and
forwards the message to the ACS URL.

Step 4: Access Control Server—Verify Enrollment

This process occurs immediately after the ACS receives the VEReq message via the
Directory Server. The ACS validates the syntax of the VEReq, as described in Appendix
C, Table C–4, and returns an Error if validation fails.

IMPORTANT
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.
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, as described in Appendix C, Table C–4 including:
●
PAN Authentication Available set to “N”
● no Account Identifier, ACS URL, Payment Protocols, or Invalid Request Data
Continue with Step 4f below.
c. If Device Category is present:

30 September 2009 Visa *Confidential* 4–7

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

● 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 Data
Continue with Step 4f.
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 Data
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 About This Guide,
the section “3-D Secure Specifications.”
e. The ACS formats a Verify Enrollment Response (VERes) message, as described
in Appendix C, Table C–5, including:
● PAN Authentication Available set to “Y”
● an Account Identifier that the ACS internally associates with the PAN (note that this
identifier must not be the PAN).
● the ACS URL to be used to transmit the PAReq
● Payment Protocols set as defined in Appendix C, Table C–5 (see Payment
Protocols)
●
no Invalid Request Data
f. The ACS sends the VERes message to the Directory Server.

Step 5: Directory Server—Forward Response

From the point of view of the Directory Server, this process occurs immediately after the
Directory Server 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
Directory Server.)
a. The Directory Server reads the response, which contains the corresponding
VERes or Error. If a VERes was received, the Directory Server validates its
syntax, as described in Appendix C, Table C–5, and returns an Error to the ACS if
validation fails.

4–8 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

b. If the message received from the ACS is syntactically correct, the Directory Server
forwards the VERes or Error to the MPI.
c. If the message received from the ACS is not syntactically correct:
● The Directory Server formats a Verify Enrollment Response (VERes) message, as
described in Appendix C, Table C–5, including:
– PAN Authentication Available set to “N”
– no Account Identifier, ACS URL, Payment Protocols, or Invalid Request Data
● The Directory Server returns the VERes message to the Merchant Server Plug-in and
stops.

Merchant Server Plug-in—Receive Response

Step 5, continued.
From the point of view of the Merchant Server Plug-in, this process occurs immediately
after the MPI posts the VEReq to the Directory Server. (From the point of view of the
Directory Server, it occurs immediately after the Directory Server 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: Payment Authorization.

Step 6: Merchant Server Plug-in—Send Payer Authentication Request

This process occurs immediately after the Merchant Server Plug-in (MPI) receives the
VERes message from the Directory Server. The MPI validates the syntax of the VERes,
as described in Appendix C, Table C–5, and should send an Error to the Directory Server
if validation fails.
a. If the value of PAN Authentication Available is not equal to “Y”, continue with
Step 12: Payment Authorization.
b. The MPI formats a Payer Authentication Request (PAReq) message, as
described in Appendix C, Table C–7, including the Account Identifier received in
VERes.
c. The MPI deflates and Base64-encodes the PAReq as described in Appendix D,
the section “Impact of Base64 Encoding.” The result is referred to as PaReq (note
the case difference).

30 September 2009 Visa *Confidential* 4–9

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

d. The MPI constructs a form containing the fields listed in Table 4–2:

Table 4–2: Fields in Form MPI Sends to ACS

Field Description

PaReq (note case) The result of Step 6d.

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.

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

Step 7: Access Control Server— Receive Payer Authentication Request

This process occurs immediately after the ACS receives the post including the PAReq
from the Merchant Server Plug-in. The following description applies to the case where
cardholder authentication is performed using a password. Other methods, such as those
that rely on applications on a chip card, may be used.

4–10 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

a. The ACS Base64-decodes and inflates the PaReq field reversing the process
described in Appendix D, the section “Impact of Base64 Encoding,” to obtain the
PAReq (note the case difference). The ACS validates the syntax of the PAReq, as
described in Appendix C, Table C–7, 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.
If any of these tests fails:
● The ACS formats a Payer Authentication Response (PARes) message, as described
in Appendix C, Table C–8, with Transaction Status set to “N” “U” and Invalid
Request Data set to appropriate values as outlined in Appendix C, Table C–9.
NOTE: The protocol specification previously permitted use of the IReq element in a
PARes message with a Transaction Status of either “N” or “U”. In order to
ensure interoperability, MPI developers must continue to permit either value
to accompany the IReq element.
● Continue with Step 8f.

Step 8, Part 1: Access Control Server— Authenticate Shopper

a. If proof of authentication attempt will be generated, display a message such as

“Processing…” and continue with Step 8d.

30 September 2009 Visa *Confidential* 4–11

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

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 4–3. (The specific
contents of the form are the choice of the issuer, subject to any applicable regional
requirements. See Figure 4–2 for an example.
)

Table 4–3: Example Fields Displayed for Cardholder Authentication

Data Item From From

ACS PAReq

Member logo X

Visa Mark or Payment Scheme logo X

Merchant name X

Total amount and currency X

Note: See Appendix C, the section “Displaying Purchase
Amount,” for an explanation of how to display amount and
currency.

Merchant date (month, day and year) X

PAN (xxx out except for last four digits) X

Note: The ACS needs to correlate the Account 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

4–12 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

Figure 4–2 shows the Authentication Request page.

Figure 4–2: Sample Authentication Request Page

Step 8, continued.
b. The ACS prompts the cardholder to enter the password.
c. The ACS accepts the cardholder input and validates it against the Account Holder
database.
d. The ACS sets Transaction Status as described in Table 4–4.

Table 4–4: ACS Sets Transaction Status (1 of 2)

Condition Value of Transaction Status

Customer was successfully authenticated. Y

Customer failed or cancelled authentication. N

Transaction denied.

Authentication could not be completed, due to U

technical or other problem, as indicated in
PARes.IReq.

30 September 2009 Visa *Confidential* 4–13

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table 4–4: ACS Sets Transaction Status (2 of 2)

Condition Value of Transaction Status

Proof of authentication attempt was generated. A

Step 8, Part 2: Access Control Server—Prepare Payer Authentication

Response
e. The ACS formats a Payer Authentication Response (PARes) message, as
described in Appendix C, Table C–8, including Transaction Status.

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.

Step 9: Access Control Server—Return Payer Authentication Response

a. The ACS deflates and Base64-encodes the PARes formatted and signed in Step
8 (or an Error message if one has been generated) as described in Appendix D,
the section “Impact of Base64 Encoding.” The result is referred to as PaRes (note
case difference).
b. The ACS constructs a form containing the fields listed in Table 4–5:

Table 4–5: Fields in Form ACS Sends to MPI

Field Description

PaReq (note case) The result of Step 9a.

MD The exact content of the MD field as posted to the ACS,

unchanged.

4–14 Visa *Confidential* 30 September 2009

3-D Secure Purchase Transaction Processing Details
Protocol Specification Core Functions Version 1.0.2

c. 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, 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.)
d. 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.

Steps 10 and 11: Merchant Server Plug-in—Validate Payer Authentication

Response
The Step 10 process occurs after the Merchant Server Plug-in posts the PAReq to the
ACS.
a. The MPI reads the response, which contains the PaRes field. The MPI Base64-
decodes and inflates the PaRes field reversing the process described in Appendix
D, the section “Impact of Base64 Encoding,” to obtain the PARes (note the case
difference) or Error.
b. If an Error message is received, continue with Step 12: Payment Authorization.
c. The MPI validates the syntax of the PARes, as described in Appendix C, Table C–
8, and should send an Error to the ACS (via the ACS URL received in the
VERes) if validation fails.
Step 11 is the validation process. The Validation Process validates the PARes signature
using the Root Certificate required by the Payment Scheme. Note that this may either be
an integral part of the Merchant Server Plug-in or may be implemented as an independent
Validation Server.
NOTE: Digital signature validation must fully comply with the underlying digital signature
specification. In particular, the PARes signature must be validated over the entire
contents of the SignedInfo element, including any inter-element white space.
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 Root certificate
required by the Payment Scheme.
●
Validation Process returns the result of signature validation to the Merchant Server
Plug-in.

30 September 2009 Visa *Confidential* 4–15

Purchase Transaction Authentication Processing 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Step 12: Payment Authorization

This process occurs after Step 11 has been completed.
The Merchant Server Plug-in notifies the merchant payment system of the results of the
authentication attempt, and provides data needed for further processing.

Electronic Commerce Processing

If authentication could not be performed, the merchant may proceed with a normal
payment authorization using the available information from the 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.

Shopper Selects Alternate Account Number

If the merchant is unable to process an authenticated transaction using the 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.

4–16 Visa *Confidential* 30 September 2009

Message Handling 5

3-D Secure Messages Handling

Message Handling: Version Numbers

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

Versioning and Parsing—Overview

In order to support future versions of the protocol, implementations must use (or
configure) XML parsers that do not validate strictly. In particular:
●
The ACS must silently ignore unrecognized elements in the VEReq message.
● All entities must silently ignore unrecognized non-critical Extension elements (that is,
any Extension element that does not have a critical attribute with a value of “true”).
● All entities must silently ignore unrecognized child elements of any non critical
Extension element.

IMPORTANT
Implementations built to this specification must support messages
having the version number 1.0.2.

30 September 2009 Visa *Confidential* 5–1

Message Handling 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Recommended Action For Messages Received

In addition, components must deal with other version numbers (for example, a component
built to these specifications must deal with any version 1.1 message it receives) as
described in the following tables:
● Table 5–1, Versioning and Parsing for Directory Server
● Table 5–2, Versioning and Parsing for Access Control Server
● Table 5–3, Versioning and Parsing for Merchant Server Plug-in
NOTE: Typically, the Directory Server is updated with the latest version of this protocol.

5–2 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Messages Handling
Protocol Specification Core Functions Version 1.0.2

Table 5–1: Versioning and Parsing—Directory Server

Message Received If version number is: then:

(Directory Server)

CRReq higher than DS sup- If the message contains any unrecognized Extension element
ports that has an attribute of critical with a value of “true”, return an
Error message (using the highest supported message ver-
sion) with the value of errorCode set to 4 (critical element not
recognized).
Otherwise, process the request and generate the response us-
ing the highest supported protocol version.

supported version If the message contains any unrecognized Extension element

that has an attribute of critical with a value of “true”, return an
Error message with the value of errorCode set to 4 (critical el-
ement not recognized).
Otherwise, process the request and generate the response us-
ing the version of the protocol indicated in the request.

lower than DS supports Return an Error message with Error Code = 6.

VEReq higher than DS sup- Ignore unrecognized elements, including unrecognized Exten-
ports sion elements. As appropriate, either forward the request to
the ACS, or process the request and generate the response
using the highest supported protocol version.

supported version Ignore unrecognized elements, including unrecognized Exten-

sion elements. As appropriate, either forward the request to
the ACS, or process the request and generate response using
the version of the protocol indicated in the request.

lower than DS supports Return an Error message with Error Code = 6.

VERes any Forward without regard to version number.

Error any Forward without regard to version number.

NOTE: These are the default actions for a DS to support the protocol. The Payment
Scheme may specify other validations or actions in order to meet scheme-
specific requirements.

30 September 2009 Visa *Confidential* 5–3

Message Handling 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table 5–2: Versioning and Parsing—Access Control Server

Message Received If version number is: then:

(Access Control
Server)

VEReq higher than DS sup- Process the request and generate a response using the high-
ports est supported protocol version. Any element not defined for the
highest supported version must be ignored (provided it is not a
“critical” extension as discussed in Appendix C, the section
“Criticality.”

supported version Generate response using the version of the protocol indicated
in the request. Any non-critical Extension element not sup-
ported by the ACS must be ignored.

PAReq equal to version num- Process the request and generate a response under the speci-
ber returned in VERes fied protocol version. Any non-critical Extension element not
supported by the ACS must be ignored.

different version num- Send PARes with iReqCode = 55.

ber
If the PAReq version number is higher than supported, format
the PARes using the highest supported version; otherwise, use
the version number of the PAReq.

Table 5–3: Versioning and Parsing—Merchant Server Plug-in

Message Received If version number is: then:

(Merchant Server
Plug-in)

VERes supported version Generate subsequent PAReq message (if any) using the ver-
sion of the protocol indicated in the VERes. Any non-critical
Extension element not recognized by the MPI must be ig-
nored.

Error any If the Directory Server returns an Error message with the val-
ue of ErrorCode set to 6, the MPI must use the version found
in the Error message for any subsequent CRReq or VEReq
messages.

5–4 Visa *Confidential* 30 September 2009

3-D Secure ID Attribute—Message Element
Protocol Specification Core Functions Version 1.0.2

ID Attribute—Message Element
Request and response pairs are matched using the id attribute of the Message element.
The id attribute of a request must be generated by the sender using an algorithm that is
likely to generate unique ids; the id attribute of the response must 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 value of the id attribute in the request must be no longer than 128 characters. The
ACS must be able to accept and process any Message.id up to 128 characters in length.
If the value exceeds 128 characters, the ACS must respond with an Error message with
Error Code = 5. The Message.id of the Error message must contain the first 128 bytes of
the received Message.id.
The MPI must generate id values that meet the requirements of the ID data type as
defined in Extensible Markup Language (XML), W3C Recommendation.

ID Attribute—PARes Element
The id attribute of the PARes element is generated by the ACS and used within the
signature element to refer to the PARes. (See Appendix A, the section XML Namespaces
for Signatures).
The PARes.id value must be no longer than 128 characters. The MPI must be able to
accept and process any PARes.id up to 128 characters in length. If the value exceeds
128 characters, the MPI must treat this as an error (as defined in Appendix C, the section
“treat as an error”).
The ACS must generate PARes.id values that meet the requirements of the ID data type
as defined in Extensible Markup Language (XML), W3C Recommendation. Failure to do
so may result in the MPI being unable to validate the Signature of the PARes.
IMPORTANT
The PARes.id value is used as a reference in the PARes Signature,
and therefore the value of the PARes.id must meet the requirements
for the ID data type as defined in the W3C XML Recommendation. At
http://www.w3.org/TR/2000/REC-xml-20001006#sec-attribute-types,
the Recommendation specifies that the value of an attribute of type ID
must match the Name production, which is defined at http://
www.w3.org/TR/2000/REC-xml-20001006#sec-common-syn.

30 September 2009 Visa *Confidential* 5–5

Message Handling 3-D Secure
Protocol Specification Core Functions Version 1.0.2

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 messages passed as XML documents – VEReq, VERes, CRReq, CRRes, and Error
messages sent in response to one of those:
● If chunked transfer coding is not used, the ‘Content-Length:’ header must be present
(and set to the length of the message body).
NOTE: Hypertext Transfer Protocol – HTTP/1.1 discusses chunked transfer coding.
● The ‘Content-Type:’ header must be present and contain the value:
application/xml; charset=utf-8
NOTE: As defined in IETF RFC 2045, utf-8 and "utf-8" are completely equivalent.
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.

Base64 Decoding
As specified in section 6.8 of the IETF RFC 2045, Multipurpose Internet Mail Extensions
(MIME) Part One, Base64 decoding software must ignore any white space (such as
carriage returns or line ends) within Base64 encoded data, and must not treat the
presence of such characters as an error.

XML Data
All XML messages transferred within 3-D Secure must use the default and recommended
encoding of “utf-8” as described in Extensible Markup Language (XML) W3C
Recommendation (see Preface, the section Other Documents).

Digital Signatures
XML digital signatures for 3-D Secure messages must be generated using the algorithms
defined in Appendix A, Table A–2.
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.

5–6 Visa *Confidential* 30 September 2009

3-D Secure Partial System Outages
Protocol Specification Core Functions Version 1.0.2

Partial System Outages

A 3-D Secure component may experience system failures that effectively render the
component inoperable. For example:
●
The Directory Server 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.
See Appendix C, the section Error Message.

Message Bundling
The DTD allows multiple requests or responses to be included in a single 3-D Secure
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 and Invalid Request Codes

Future versions of this specification (including future errata) may define additional error
and invalid request codes. All 3-D Secure components must accept any value in the Error
Code field and the Invalid Request Code field.
If the list of Error Code values in Appendix C, Table C–12, or the list of Invalid Request
Code values in Table C–9 does not contain an entry that matches a condition detected by
a 3-D Secure component, the developer should select a reasonably close match.
Requests for new values should be submitted using the 3-D Secure change control
process.
NOTE: 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), the specific reason does not matter to the
merchant.

30 September 2009 Visa *Confidential* 5–7

Message Handling 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Message Validation
The recipient of a 3-D Secure message must validate that:
● The XML message is well-formed.
● The Root Element is “ThreeDSecure.”
● There is a “Message” Element inside of the Root Element.
● There is an appropriate message in the “Message” Element.
EXAMPLE
For example, a Directory Server expects to receive the following
messages: CRReq, VEReq, VERes, or Error. Any other message is
treated as an error.
● Each required field is present.
● For responses: Message ID matches that of request.
The recipient of a 3-D Secure message should perform only those validations necessary
to ensure that the message can be correctly processed. This includes validations
necessary to ensure that the business context of the transaction is valid and those
necessary to ensure that the message meets applicable technical requirements. The
tables that follow define the required and optional validations for each data element.

3-D Secure Messages Diagrams

The 3-D Secure messages are generated as a result of executing the XML in Appendix A,
the section 3-D Secure DTD.

Message Diagram Overview Introduction

Figure 5–1 illustrates the 3-D Secure parent-child relationship between 3-D Secure and
the messages it generates.
The remaining figures in this section illustrate the messages individually.
NOTE: The dashed lines in each of the figures indicate the active component.

5–8 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Messages Diagrams
Protocol Specification Core Functions Version 1.0.2

Figure 5–1: Overview of 3-D Secure Messages

CRReq Processing
Figure 5–2 illustrates the CRReq message processing.

Figure 5–2: CRReq Processing

CRRes Processing
Figure 5–3 illustrates the CRRes message processing.

30 September 2009 Visa *Confidential* 5–9

Message Handling 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Figure 5–3: CRRes Processing

VEReq Processing
Figure 5–4 illustrates the VEReq message processing.

Figure 5–4: VEReq Processing

VERes Processing
Figure 5–5 illustrates the VERes message processing.

5–10 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Messages Diagrams
Protocol Specification Core Functions Version 1.0.2

Figure 5–5: VERes Processing

PAReq Processing
Figure 5–6 illustrates the PAReq message processing.

30 September 2009 Visa *Confidential* 5–11

Message Handling 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Figure 5–6: PAReq Processing

PARes Processing
Figure 5–7 illustrates the PARes message processing.

5–12 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Messages Diagrams
Protocol Specification Core Functions Version 1.0.2

Figure 5–7: PARes Processing

Error Messages Processing

Figure 5–8 illustrates the Error message processing.

Figure 5–8: Error Processing

30 September 2009 Visa *Confidential* 5–13

3-D Secure XML Message Format A

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

Date and Time Format(s)

Date and time pairs are formatted as:
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

XML-Signature Syntax

Description
The 3-D Secure protocol 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 using a local reference (for example, ‘#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 A–1 in the section “Signature Structure” illustrates the signature structure.

30 September 2009 Visa *Confidential* A–1

3-D Secure XML Message Format 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Profile
The generation of 3-D Secure signatures must correspond to the requirements for
element content and algorithms specified in the tables that follow.
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.
Table A–1 lists the requirements for the XML signature profile.

Table A–1: XML Signature Profile

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 instance of X509Certificate for each certificate

to be included (see the section “Certificate Chain.”

Table A–2 lists the requirements for the XML signature algorithms.

Table A–2: XML Signature Algorithms

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

A–2 Visa *Confidential* 30 September 2009

3-D Secure XML-Signature Syntax
Protocol Specification Core Functions Version 1.0.2

Table A–2: XML Signature Algorithms

Algorithm Type Identifier

Signature http://www.w3.org/2000/09/xmldsig#rsa-sha1

Transform none (see the section “Canonicalization

Requirements”).

Certificate Chain
The ACS must include the entire chain of certificates, and not just the signing certificate,
in the Signature.
At this time both Visa, MasterCard and JCB all use a three-level certificate hierarchy, so
there must be three (3) instances of X509Certificate, containing:
● the root certificate,
● one intermediate certificate, and
● the signing certificate.
Each participating Payment Scheme will determine requirements regarding certificate key
sizes. Refer to the Payment Scheme documentation for more information.

Canonicalization Requirements
Note that canonicalization is a requirement of “XML-Signature Syntax and Processing,
W3C Recommendation”, also known as xmldsig, and listed in About This Guide, the
section “Other Relevant Documents.”
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 About
This Guide, the section “Other Relevant Documents.”
In addition, the ACS should return the signed PARes message in canonical form (both the
PARes and SignedInfo elements).

XML Namespaces for Signatures

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

Example Sample XML Code

<ThreeDSecure>
<Message id="PAReq98765">

30 September 2009 Visa *Confidential* A–3

3-D Secure XML Message Format 3-D Secure
Protocol Specification Core Functions Version 1.0.2

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

Signature Structure
Figure A–1 illustrates the Signature structure.

Figure A–1: Signature Structure

NOTE: The dashed line indicate the active component.

3-D Secure DTD

(1 of 3)
The 3-D Secure messages illustrated in Chapter 5, the section “3-D Secure Messages
Diagrams,” are created as a result of executing this DTD.
3-D Secure Message Descriptions are available in Appendix C.

A–4 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure DTD
Protocol Specification Core Functions Version 1.0.2

Following is a sample 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 ID #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 ID #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,

3-D Secure DTD

(2 of 3)
desc?, Recur?, install?)>
<!ELEMENT Recur (frequency, endRecur)>
<!ELEMENT TX (time, status, cavv?, eci?, cavvAlgorithm?)>

30 September 2009 Visa *Confidential* A–5

3-D Secure XML Message Format 3-D Secure
Protocol Specification Core Functions Version 1.0.2

<!ELEMENT Extension ANY>

<!ATTLIST Extension id CDATA #REQUIRED
critical (true | false) #REQUIRED >
<!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)>

A–6 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure DTD
Protocol Specification Core Functions Version 1.0.2

3-D Secure DTD

(3 of 3)
<!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)>

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

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

30 September 2009 Visa *Confidential* A–7

3-D Secure XML Message Format 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Canonicalization - http://www.w3.org/TR/2001/REC-xml-c14n-
20010315
Transform - none
* xmlns must be set to XML-Signature namespace URI
**********************************************************************
-->

A–8 Visa *Confidential* 30 September 2009

3-D Secure Field Formats B

3-D Secure Field Formats

This appendix combines the field definitions provided in the message descriptions
Appendix C, 3-D Secure Message Descriptions.
NOTE: Validation requirements for each field are discussed in Appendix C, and are not
duplicated in this appendix.
Table B–1 provides the field formats for 3-D Secure.

Table B–1: 3-D Secure Field Formats (1 of 20)

Field Name DTD Element Inclusion Messag Description

e

Accept Headers Browser.accept C VEReq The exact content of the HTTP accept
VEReq header as sent to the merchant from
the cardholder’s user agent.
Required if the cardholder’s user
agent supplied a value.
Edit Criteria:
Length: 0-2048 characters
Format: any characters
Note: If the total length of the accept
header sent by the browser exceeds
2048 characters, the MPI must
truncate the excess portion.

30 September 2009 Visa *Confidential* B–1

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (2 of 20)

Field Name DTD Element Inclusion Messag Description

e

Account Identifier CH.acctID C VERes The content of this field is 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, even if the same PAN
is being presented.
Edit Criteria:
Length: 1-28 characters
Format: any characters
Required if the value of PAN
Authentication Available is “Y”;
omitted otherwise.

Account Identifier CH.acctID R PAReq From VERes.

Edit Criteria
● Length: 1-28 characters
● Format: any character

Acquirer BIN Merchant.acqBIN R CRReq Acquiring institution identification

code.
VEReq
Edit Criteria:
Length: 1-11 characters
Format: numeric digits
Note: For Visa transactions, this is
typically a 6 digit BIN assigned to the
acquirer by Visa.

Acquirer BIN Merchant.acqBIN R PAReq From VEReq.

Edit Criteria
● Length: 1-11 characters
● Value: Same value as
VEReq.Merchant.acqBIN

Acquirer BIN Merchant.acqBIN R PAReq From PAReq.

B–2 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (3 of 20)

Field Name DTD Element Inclusion Messag Description

e

ACS URL url C VERes URL of Access Control Server to

which PAReq must be sent.
Edit Criteria
● Length: 1-2048 characters
● Format: fully qualified https URL
(https://domainname…)
Required if the value of PAN
Authentication Available is “Y”.

Action CR.action R CRRes Indicates the action to take with the

card range.
Edit Criteria
● Length: 1 character
● Value: must be one of the
following:
– 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 Date CH.expiry R PAReq Expiration Date supplied to merchant

by cardholder (YYMM).
Edit Criteria
● Length: 4 characters
● Format: numeric digits

30 September 2009 Visa *Confidential* B–3

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (4 of 20)

Field Name DTD Element Inclusion Messag Description

e

Card Range CR C CRRes If CRReq does not include Serial

Number, a CR element is included for
each card range populated in the
Directory Server.
If CRReq includes Serial Number:
● If the value of
CRReq.serialNumber is current,
indicating that the 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
required data elements:
● First Number in Card Range –
CR.begin
● Last Number in Card Range –
CR.end
● Action – CR.action

Cardholder TX.cavv C PARes Contains a 20 byte value that has

Authentication been Base64 encoded, giving a 28
Verification Value byte result.
Edit Criteria:
● Length: 28 characters
● Format: Base64-encoded data
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.

B–4 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (5 of 20)

Field Name DTD Element Inclusion Messag Description

e

Cardholder PAN pan R VEReq 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
is 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.
Edit Criteria:
● Length: 13-19 characters
● Format: numeric digits

Cardholder PAN pan R PARes Cardholder Account Number.

Edit Criteria:
● Length: 13-19 characters
● Format: numeric digits
● Value:
When Transaction Status is “Y” or
“A”, 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)
When Transaction Status = “N” or “U”,
this field must be all zeros: one for
each digit of the original PAN in the
VEReq.

30 September 2009 Visa *Confidential* B–5

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (6 of 20)

Field Name DTD Element Inclusion Messag Description

e

CAVV Algorithm TX.cavvAlgorithm C PARes Indicates the algorithm used to

generate the Cardholder
Authentication Verification Value.
If the CAVV field is included, the CAVV
algorithm field must also be included.
If the CAVV field is missing, the CAVV
algorithm field must also be missing.
Value must be one of the following:
● 0 =HMAC (as per SET™
TransStain) (no longer in use for
version 1.0.2)
● 1 =CVV (no longer in use for
version 1.0.2)
● 2 =CVV with ATN
● 3 =MasterCard SPA algorithm
Edit Criteria:
● Length: 0-1 character

Currency Exponent Purchase.expone R PAReq The minor units of currency specified

nt in ISO 4217. For example, US Dollars
has a value of 2; Japanese Yen has a
value of 0.
Edit Criteria:
● Length: 1 character
●
Format: numeric digit
●
Value: exponent defined for
currency code in ISO 4217

Currency Exponent Purchase.expone R PARes From PAReq.

nt

B–6 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (7 of 20)

Field Name DTD Element Inclusion Messag Description

e

Device Category Browser.deviceCa O VEReq Indicates the type of device or channel

tegory being used for shopping.
Edit Criteria:
● Length: 0-2 characters
● Value: must be one of the
following:
– 0 =The client environment is
such that the full size messages
(PAReq/PARes) will be used
and the core protocol
specification governs. For
example, PC (HTML). (Default
value)
– 1 =The client is a constrained
device, such as WAP phone,
where the condensed messages
(CPRQ/CPRS) will be used and
the Extension for Mobile Internet
Devices must be followed.
– 2 =The client uses two-way
messaging (SMS or USSD) and
the Extension for Voice and
Messaging Channels must be
followed.
– 3 =The client uses the voice
channel and the Extension for
Voice and Messaging Channels
must be followed.
If this element is omitted, a value of 0
is implied.

Display Amount Purchase.amount R PAReq This element must be present in the

message (to ensure compatibility with
the existing DTD). The content of this
element is not used, and it may be
empty.
Edit Criteria:
● Length: 0-20 characters
●
Format: any characters

30 September 2009 Visa *Confidential* B–7

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (8 of 20)

Field Name DTD Element Inclusion Messag Description

e

Electronic Commerce TX.eci C PARes This Payment Scheme specific

Indicator element represents the value of the
ECI, as determined by the ACS.
Edit Criteria:
● Length: 0 or 2 characters
● Value: numeric digits
Required for Visa, MasterCard and
JCB transactions when the value of
Transaction Status is “Y” or “A”.

Error Code errorCode R Error Code indicating the problem identified

in the message. Must be one of the
values listed in Appendix C,
Table C–12.
Edit Criteria:
● Length: 1-2 characters
Note: Additional values may be
defined at any time. All components
must accept any value.

Error Description errorMessage R Error Text describing the problem identified

in the message. Appendix C,
Table C–12.
Edit Criteria:
● Length: 0-2048 characters
●
Format: any characters

Error Detail errorDetail R Error May identify the specific data elements
that caused the Error Code. See
Appendix C, Table C–12.

First Number in Card CR.begin R CRRes Starting Account Number from

Range Directory Server.
Edit Criteria:
● Length: 13-19 characters
●
Format: numeric digits

B–8 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (9 of 20)

Field Name DTD Element Inclusion Messag Description

e

Installment Payment Purchase.install C PAReq Indicates the maximum number of

Data permitted authorizations for
installment payments.
Required if the merchant and
cardholder have agreed to installment
payments.
Edit Criteria:
● Length: 0-3 characters
● Format: numeric digits
● Value: must be >1 (if not empty)

Invalid Request Code IReq.iReqCode R CRRes Code indicating the problem identified
in the request message. Must be one
VERes
of the values listed in Appendix C,
PARes Table C–9.
Edit Criteria:
● Length: 1-3 characters

Invalid Request Data IReq C CRRes Required if the CRReq is syntactically

correct, but business processing
cannot be performed for one of the
reasons defined in Appendix C,
Table C–9.
Invalid Request Data consists of one
required, one conditional, and one
optional element:
●
Invalid Request Code –
IReq.iReqCode
● Invalid Request Detail –
IReq.iReqDetail
● Vendor Code – IReq.vendorCode

30 September 2009 Visa *Confidential* B–9

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (10 of 20)

Field Name DTD Element Inclusion Messag Description

e

Invalid Request Data IReq C VERes Required if the VEReq is syntactically

correct, but business processing
cannot be performed for one of the
reasons defined in Appendix C,
Table C–9.
Note: When IReq is included, the
value of PAN Authentication
Available is always “N”.
Invalid Request Data consists of one
required, one conditional, and one
optional element:
● Invalid Request Code –
IReq.iReqCode
● Invalid Request Detail –
IReq.iReqDetail
● Vendor Code – IReq.vendorCode

Invalid Request Data IReq C PARes Required if the PAReq is syntactically

correct, but business processing
cannot be performed for one of the
reasons defined in Appendix C,
Table C–9.
Note: When IReq is included, the
value of Transaction Status is always
“U”.
Invalid Request Data consists of one
required, one conditional, and one
optional element:
● Invalid Request Code –
IReq.iReqCode
●
Invalid Request Detail –
IReq.iReqDetail
● Vendor Code – IReq.vendorCode

B–10 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (11 of 20)

Field Name DTD Element Inclusion Messag Description

e

Invalid Request Detail IReq.iReqDetail C CRRes May provide supporting detail, such as
the specific data elements that caused
VERes
the Invalid Request Code. Appendix
PARes C, Table C–9 defines standard
contents to be used.
Edit Criteria:
● Length: 0-2048 characters
● Format: any characters

Last Number in Card CR.end R CRRes Ending Account Number from

Range Directory Server.
Edit Criteria:
● Length: same length as First
Number in Card Range
● Format: numeric digits

Merchant Country Merchant.country R PAReq Country Code of the Merchant. The

Code same value must be used in the
authorization request.
Edit Criteria:
● Length: 3 characters
● Format: numeric digits
● Value: ISO 3166 three digit country
code, other than those listed in
Appendix C, Table C–9.

30 September 2009 Visa *Confidential* B–11

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (12 of 20)

Field Name DTD Element Inclusion Messag Description

e

Merchant ID Merchant.merID R CRReq Acquirer-defined merchant identifier.

VEReq Edit Criteria:
● Length: 1-24 characters
● Format: any characters
Note: Individual Payment Schemes
may impose specific format and
character requirements on the
contents of this field.
For Visa, these requirements are
defined in the acquirer Implementation
Guide (see About This Guide, the
section “Visa Implementation Guides”)
and are enforced at the time that the
Merchant ID is populated into the DS.

Merchant ID Merchant.merID R PAReq From VEReq.

Edit Criteria:
● Length: 1-24 characters
● Value: Same value as
VEReq.Merchant.merID

Merchant ID Merchant.merID R PARes From PAReq.

Merchant Name Merchant.name R PAReq Merchant name to be displayed on

Authentication Request Page.
Edit Criteria:
●
Length: 1-25 characters
● Format: any characters

Merchant URL Merchant.url R PAReq Fully qualified URL of merchant Web

site or customer care site (http(s)://
domainname…).
Edit Criteria:
● Length: 1-2048 characters
● Format: any characters

B–12 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (13 of 20)

Field Name DTD Element Inclusion Messag Description

e

Message Extension Extension O VEReq Any data necessary to support the

requirements that are not otherwise
VERes
defined in the message must be
PAReq carried in an instance of Message
PARes Extension.
See Appendix C, the section
“Message Extensions” for additional
information about this element.

Merchant Version version R all Version identifier; “1.0.2”.

Number
Edit Criteria:
● Length: 3 or more characters
● Format:
n+.n+[.n+]* where:
● “n” represents a numeric digit
● “+”represents “one or more”
● “*”represents “zero or more”
The square bracket is not part of the
format, but encloses the optional
portion of the string.

Order Description Purchase.desc O PAReq Brief description of items purchased.

Edit Criteria:
● Length: 0-125 characters
●
Format: any characters

30 September 2009 Visa *Confidential* B–13

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (14 of 20)

Field Name DTD Element Inclusion Messag Description

e

PAN Authentication CH.enrolled R VERes Indicates whether the Account

Available Identifier can be authenticated.
Edit Criteria:
● Length: 1 character
● Value: must be one of the
following:
– Y = Authentication Available
– N = Cardholder Not Participating
– U = Unable To Authenticate
“U” is used whether the Issuer’s
inability to authenticate the account is
due to technical difficulties or business
reasons.

Password Merchant.passwor C CRReq Merchant password provided by

d merchant’s acquirer.
VEReq
Edit Criteria:
● Length: 8 characters
● Format: alphanumeric
Required if Merchant ID and
Password is used as the
authentication methodology, and
omitted otherwise.
The requirements for use of this field
will be specific to the Payment
Scheme. The Visa requirements are
indicated in the acquirer
Implementation Guide.

B–14 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (15 of 20)

Field Name DTD Element Inclusion Messag Description

e

Payment Protocols protocol C VERes Indicates which payment protocols are

supported by the issuer system for the
Cardholder PAN specified in VEReq.
The only defined value is
“ThreeDSecure”.
If the value of PAN Authentication
Available is “Y”, one instance of this
element must be included. Otherwise,
the presence of this element is
optional.
Edit Criteria:
● Length: 0-12 characters
● Format: any characters

Purchase Amount Purchase.purchA R PAReq Purchase amount in minor units of

mount currency with all punctuation removed.
Example: If the purchase is for USD
123.45, the purchAmount element
will contain the value 12345.
Edit Criteria:
● Length: 1-12 characters
● Format: numeric digits

Purchase Amount Purchase.purchA R PARes From PAReq.

mount

Purchase Currency Purchase.currenc R PAReq Currency in which purchase amount is

y expressed.
Edit Criteria:
● Length: 3 characters
●
Format: numeric digits
● Value: ISO 4217 three digit
currency code, other than those
listed in Appendix C, Table C–9.

Purchase Currency Purchase.currenc R PARes From PAReq.

y

30 September 2009 Visa *Confidential* B–15

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (16 of 20)

Field Name DTD Element Inclusion Messag Description

e

Purchase Date & Purchase.date R PAReq Date and time of purchase expressed
Time in GMT.
Edit Criteria:
● Length: 17 characters
● Format:
YYYYMMDD HH:MM:SS where:
– YYYY = 4 numeric digits
– MM = 2 numeric digits with value
01-12
– DD = 2 numeric digits with value
01-31
– a single space follows the date
– HH = 2 numeric digits with value
00 24, followed by a colon (“:”)
– MM = 2 numeric digits with value
00 59, followed by a colon (“:”)
– SS = 2 numeric digits with value
00 59

Purchase Date & Purchase.date R PARes From PAReq.

Time

Recurring Expiry Recur.endRecur R PAReq The date after which no further

authorizations should be performed.
This date must be in the future.
Edit Criteria:
● Length: 0 or 8 characters
●
Format:
YYYYMMDD where:
– YYYY4 numeric digits
– MM2 numeric digits with value
01-12
– DD2 numeric digits with value
01-31
See Appendix C, the section
“Recurring Expiry” for additional
information.

B–16 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (17 of 20)

Field Name DTD Element Inclusion Messag Description

e

Recurring Frequency Recur.frequency R PAReq Indicates the minimum number of

days between authorizations.
Edit Criteria:
● Length: 0-4 characters
● Format: numeric digits
See Appendix C, the section
“Recurring Frequency” for additional
information.

Recurring Payment Purchase.Recur C PAReq Required if the merchant and

Data cardholder have agreed to recurring
payments.
The recurring payment data consists
of two required data elements:
● Recurring Frequency –
Recur.frequency
● Recurring Expiry –
Recur.endRecur
Edit Criteria:
● Both child elements must be
present.
● Either both child elements must be
empty, or both must contain valid
contents.

Serial Number serialNumber O CRReq A value returned in a previous CRRes.

If this element is present, the Directory
Server returns card ranges that have
been updated since the time of the
CRRes; if this element is absent, the
Directory Server returns all
participating card ranges.
Edit Criteria:
●
Length: 1-20 characters
● Format: numeric digits
(representing a maximum 64 bit
unsigned integer)

30 September 2009 Visa *Confidential* B–17

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (18 of 20)

Field Name DTD Element Inclusion Messag Description

e

Serial Number serialNumber C CRRes Indicates the current state of the card
range database. (The specific value is
meaningful only to the 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.
Edit Criteria:
● Length: 1-20 characters
● Format: numeric digits
(representing a maximum 64-bit
unsigned integer)
If Invalid Request Code is included,
Serial Number element must be
omitted.

Signature Date & TX.time R PARes Date and Time PARes message was
Time signed by ACS.
Value is expressed in GMT.
Edit Criteria:
● Length: 17 characters
● Format:
YYYYMMDD HH:MM:SS where:
– YYYY = 4 numeric digits
– MM = 2 numeric digits with value
01-12
– DD = 2 numeric digits with value
01-31
– a single space follows the date
– HH = 2 numeric digits with
values between 00 24, followed
by a colon (“:”)
– MM = 2 numeric digits with
values between 00 59, followed
by a colon (“:”)
– SS = 2 numeric digits with
values between 00 59

B–18 Visa *Confidential* 30 September 2009

3-D Secure 3-D Secure Field Formats
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (19 of 20)

Field Name DTD Element Inclusion Messag Description

e

Transaction Identifier Purchase.xid R PAReq Transaction identifier determined by

merchant. Contains a 20 byte value
that has been Base64 encoded, giving
a 28 byte result.
Edit Criteria:
● Length: 28 characters
● Format: any character

Transaction Identifier Purchase.xid R PARes From PAReq.

Transaction Status TX.status R PARes Indicates whether a transaction

qualifies as an authenticated
transaction.
Edit Criteria:
● Length: 1 character
● Value: must be one of the
following:
– 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 problem, as
indicated in PARes.IReq.
– A = Attempts Processing
Performed. Authentication could
not be completed, but a proof of
authentication attempt (CAVV)
was generated.

30 September 2009 Visa *Confidential* B–19

3-D Secure Field Formats 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table B–1: 3-D Secure Field Formats (20 of 20)

Field Name DTD Element Inclusion Messag Description

e

User Agent Browser.userAgen C VEReq The exact content of the HTTP user-
t agent header as sent to the merchant
from the cardholder’s user agent.
Required if the cardholder’s user
agent supplied a value.
Edit Criteria:
● Length: 0-256 characters
● Format: any characters
Note: If the total length of the user
agent header sent by the browser
exceeds 256 characters, the MPI must
truncate the excess portion.

Vendor Code IReq.vendorCode O CRRes Error code (or explanatory text) to be

used for trouble shooting.
VERes
Edit Criteria:
PARes
● Length: 0-256 characters
● Format: any characters

Vendor Code vendorCode O Error Error code (or explanatory text) to be

used for trouble shooting.
Edit Criteria:
● Length: 0-256 characters
● Format: any characters

B–20 Visa *Confidential* 30 September 2009

3-D Secure Message Descriptions C

Message Format
All messages listed in this appendix are in XML format. For XML message format, see
Appendix A, 3-D Secure XML Message Format.
This appendix provides complete descriptions for all 3-D Secure Messages, as listed:
●
CRReq
●
CRRes
●
VEReq
●
VERes
●
PAReq
●
PARes
●
Invalid Request
● Message Extensions
●
Error Message
Field-by-field descriptions for each message are listed at the end of each message
section. See Chapter 5, the section “3-D Secure Messages Diagrams,” for information
about message structure.

30 September 2009 Visa *Confidential* C–1

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Inclusion Values
Table C–1 provides the definition for the Inclusion column in the field descriptions tables
throughout this appendix.

Table C–1: Field Inclusion Values

Inclusion Meaning Sender Requirements Recipient Requirements

Value

R Required must include the field must check for presence of

the field and validate its
contents

C Conditional must include the field if the must:

conditions are satisfied ● check for presence of
the field when the
conditions are satisfied,
and
● validate its contents
when present

O Optional may include the field must validate the contents

when present

Field Edit Criteria

Only the specified validations are to be performed. Do not reject a message based on any
validation that is not listed in the tables in this appendix.
NOTE: The term "character" in the Length Edit Criteria in the following tables refers to
one Unicode character.

Conditions For Required Fields

A field is required if either:
● the element is always required (as denoted by an R in the Inclusion column), or...
●
the element is conditional (as denoted by a C in the Inclusion column), but required in
this instance because the contents of the message meet conditions specified in the
table.
Unless explicitly noted otherwise in the following tables, if a field is required, then the tags
must be present and the element must not be empty.

C–2 Visa *Confidential* 30 September 2009

3-D Secure Conditions For Optional Fields
Protocol Specification Core Functions Version 1.0.2

Conditions For Optional Fields

When no data is to be sent for an optional element (including a conditional element that is
not required based on the contents of the message), the element may be either absent, or
present and empty.
For example, a normal one-time purchase does not require (and should not contain) any
installment payment information in the PAReq message. In this case, the MPI may omit
the install element entirely from the message. Alternatively, the MPI may include an
empty element:
<install></install>

Conditions For Missing Fields

A data field is missing either if the element tags are absent, or if the element is present
and empty.
Unless explicitly noted otherwise in the following tables, an empty element must be
treated in the same manner as if the element tags were absent. For example, field c is
missing in both of the following XML instances.
<a><b>some data</b></a>
<a><b>some data</b><c></c></a>
NOTE: Note that an empty element is not equivalent to an element with white space as
content (such as <tag> </tag>).
Field c is also missing in the following XML instance:
<a><b>some data</b><c/></a>
However, section 3.1 of the W3C XML Recommendation discourages the use of
the empty tag (e.g., <c/>), for interoperability reasons.

CRReq

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

Implementation Choices
Table 18 outlines the default validation requirements for the CRReq message. The
Payment Scheme may specify other Directory Server validations or actions in order to
meet scheme specific requirements.

30 September 2009 Visa *Confidential* C–3

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Required Field Missing

Unless explicitly noted otherwise in the table, if a required CRReq field is missing, the
Directory Server will return an Error message with Error Code = 3. This applies whether
the field is always required or conditionally required
See the section “Conditions For Missing Fields” for details.

Edit Criteria
If a CRReq field is present but its value does not conform to the edit criteria specified in
the table, the Directory Server will return an Error message with Error Code = 5.

CRReq Field Descriptions

Table C–2 outlines the default validation requirements for the CRReq message. The
Payment Scheme may specify other Directory Server validations or actions in order to
meet scheme specific requirements.

Table C–2: CRReq Field Descriptions (1 of 2)

Field Name DTD Element Inclusi Description Directory Server Edit Criteria
on
●
Message Version version R Version identifier; “1.0.2”. Length: 3 or more characters
Number ●
Format:
n+.n+[.n+]* where:
●
“n” represents a numeric digit
●
“+”represents “one or more”
●
“*”represents “zero or more”
The square bracket is not part of the for-
mat, but encloses the optional portion of
the string.
Additional requirements are defined in
Chapter 5, Message Handling, the sec-
tion “Versioning and Parsing—Overview.”
Acquirer BIN Merchant.acqBIN R Acquiring institution identification code. ●
Length: 1-11 characters
Note: For Visa transactions, this is typi- ● Format: numeric digits
cally a 6 digit BIN assigned to the
If the value does not represent a partici-
acquirer by Visa.
pating acquirer, DS must send a CRRes
with iReqCode = 50.

C–4 Visa *Confidential* 30 September 2009

3-D Secure CRReq
Protocol Specification Core Functions Version 1.0.2

Table C–2: CRReq Field Descriptions (2 of 2)

Field Name DTD Element Inclusi Description Directory Server Edit Criteria
on
●
Merchant ID Merchant.merID R Acquirer-defined merchant identifier. Length: 1-24 characters
● Format: any characters
Note: Individual Payment Schemes may
impose specific format and character
requirements on the contents of this field.
For Visa, these requirements are defined
in the acquirer Implementation Guide
(see About This Guide, the section “Visa
Implementation Guides”) and are
enforced at the time that the Merchant ID
is populated into the DS.
If the Payment Scheme or regional orga-
nization uses Merchant ID and Password
for merchant authentication, DS must
validate against values previously popu-
lated in the DS by the merchant’s acquir-
er. If so, and if the value does not
represent a participating merchant of
Merchant.acqBIN, then DS must send a
CRRes with iReqCode = 51.
Password Merchant.pass- C Merchant password provided by mer- ●
Length: 8 characters
word chant’s acquirer. ●
Format: alphanumeric
Required if Merchant ID and Password is If the Payment Scheme or regional orga-
used as the authentication methodology;
nization uses Merchant ID and Password
omitted otherwise.
for merchant authentication, DS must
The requirements for use of this field will validate against values previously popu-
be specific to the Payment Scheme. The lated in the DS by the merchant’s acquir-
Visa requirements are indicated in the er. If the password is invalid, the DS must
acquirer Implementation Guide. send a CRRes with CH.enrolled = N
and:
●
If the element is missing when re-
quired, iReqCode = 52.
●
If the password is not valid for the
combination of Merchant.acqBIN
and Merchant.merID, iReqCode =
53.
Serial Number serialNumber O A value returned in a previous CRRes. If Edit Criteria:
this element is present, the Directory ● Length: 1-20 characters
Server returns card ranges that have
●
been updated since the time of the Format: numeric digits (representing
CRRes; if this element is absent, the Di- a maximum 64 bit unsigned integer)
rectory Server returns all participating
card ranges.
If the value cannot be located (for exam-
ple, if value is too old), DS must send a
CRRes with iReqCode = 57.

30 September 2009 Visa *Confidential* C–5

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

CRRes

Purpose
The CRRes (Card Range Response) is sent from the Directory Server 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.

“treat as an error”
For CRRes, the term “treat as an error” indicates that the MPI:
● must not store the contents of the CRRes, and
● may optionally send an Error message to the Directory Server.

Required Field Missing

Unless explicitly noted otherwise in the table, if a required CRRes field is missing, the MPI
must treat it as an error. This applies whether the field is always required or conditionally
required.
If the MPI sends an Error message in this situation, the Error Code must be 3.
See the section “Conditions For Missing Fields” for details.

Edit Criteria
If a CRRes field is present but its value does not conform to the edit criteria specified in
the table, the MPI must treat it as an error.
If the MPI sends an Error message in this situation, the Error Code must be 5.

C–6 Visa *Confidential* 30 September 2009

3-D Secure CRRes
Protocol Specification Core Functions Version 1.0.2

CRRes Field Descriptions

Table C–3 lists the defined fields for a CRRes message.

Table C–3: CRRes Field Descriptions (1 of 2)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria

Message Version version R Version identifier; “1.0.2”. ●

Length: 3 or more characters
Number ● Format:
n+.n+[.n+]* where:
“n” represents a numeric digit
“+”represents “one or more”
“*”represents “zero or more”
The square bracket is not part of the for-
mat, but encloses the optional portion of
the string.
Additional requirements are defined in
Chapter 5, the section “Versioning and
Parsing—Overview.”
Card Range CR C CR is absent when IReq is present. If CRReq does not include Serial Num-
ber, a CR element is included for each
The card range must include the required
card range populated in the Directory
data elements that immediately follow
Server.
this field.
If CRReq includes Serial Number:
●
If the value of CRReq.serialNumber
is current, indicating that the Directo-
ry Server data has not changed since
the previous CRReq from this mer-
chant, no CR elements are returned.
●
Otherwise, only CR elements that
have been added or deleted since the
previous CRReq are returned.
First Number in CR.begin R Starting Account Number from Directory ●
Length: 13-19 characters
Card Range Server. ●
Format: numeric digits
●
Last Number in CR.end R Ending Account Number from Directory Length: same length as First Number
Card Range Server. in Card Range
●
Format: numeric digits
●
Action CR.action R Indicates the action to take with the card Length: 1 character
range. ● Value: must be one of the following:
The card ranges must be processed in
– A = Add the card range to the
the order returned. cache.
Note: If the serial number was not – D = Delete the card range from
included in the CRReq the action is add the cache.
for all ranges returned.

30 September 2009 Visa *Confidential* C–7

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–3: CRRes Field Descriptions (2 of 2)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
Serial Number serialNumber C Indicates the current state of the card Length: 1-20 characters
range database. (The specific value is ●
Format: numeric digits (representing
meaningful only to the Directory Server.)
a maximum 64-bit unsigned integer)
The MPI should retain this value for sub-
mission in a future CRReq to request
only changes that have been made to the
participating card range list since this
message was generated.
If Invalid Request Code is included, Seri-
al Number element must be omitted.
Invalid Request IReq C Invalid Request Data consists of one re- If present, MPI must not store the con-
Data quired, one conditional, and one optional tents of the CRRes.
element, as listed below.
Required if the CRReq is syntactically
correct, but business processing cannot
be performed for one of the reasons de-
fined in Table C–9.
Invalid Request IReq.IReqCode R Code indicating the problem identified in ●
Length: 1-3 characters
Code the CRReq. Must be one of the values Additional values may be defined at any
listed in “Invalid Request Data Values” in
time. The MPI must accept any value.
Table C–9.
●
Invalid Request IReq.IReqDetail C May provide supporting detail, such as Length: 0-2048 characters
Detail the specific data elements that caused ●
Format: any characters
the Invalid Request Code.
Table C–9 defines standard contents for
this field.
●
Vendor Code IReq.vendorCode O Error code (or explanatory text) to use for Length: 0-256 characters
troubleshooting. ●
Format: any characters

VEReq

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

Implementation Choices
Table 20 outlines the default validation requirements for the VEReq message. The
Payment Scheme may specify other Directory Server validations or actions in order to
meet scheme specific requirements.

C–8 Visa *Confidential* 30 September 2009

3-D Secure VEReq
Protocol Specification Core Functions Version 1.0.2

Required Field Missing

Unless explicitly noted otherwise in the table, if a required VEReq field is missing, the
receiving entity must return an Error message with Error Code = 3. This applies whether
the field is always required or conditionally required.
See the section “Conditions For Missing Fields” for details.

Edit Criteria
If a VEReq field is present but its value does not conform to the edit criteria specified in
the table, the receiving entity must return an Error message with Error Code = 5.

VEReq Field Descriptions

Table C–4 lists the defined fields for a VEReq message.

Table C–4: VEReq Field Descriptions (1 of 4)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
Message Version version R Version identifier; “1.0.2”. Length: 3 or more characters
Number ●
Format: n+.n+[.n+]* where:
– “n” represents a numeric digit
– “+”represents “one or more”
– “*”represents “zero or more”
The square bracket is not part of the for-
mat, but encloses the optional portion of
the string.
Additional requirements are defined in
Chapter 5, the section “Versioning and
Parsing—Overview.”
●
Cardholder PAN pan R Account Number; it must be the same Length: 13-19 characters
PAN that will be used in the authorization ●
Format: numeric digits
request.
If the PAN is not part of a participating
The value may be:
range, the DS must send a VERes with
● the account number on the card CH.enrolled = N.
● a permanent account number that is If the PAN is not enrolled in the Payment
only used online Scheme’s 3-D Secure program, the ACS
● must send a VERes with CH.enrolled =
produced by the wallet as a proxy
N.
●
pulled from the merchant’s local wal-
If the message has been misrouted (the
let
PAN does not belong to one of the issu-
●
or any other number that can be sub- er’s card ranges), the ACS must send a
mitted for authorization. VERes with CH.enrolled = N and iReq-
Code = 56.

30 September 2009 Visa *Confidential* C–9

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–4: VEReq Field Descriptions (2 of 4)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
Acquirer BIN Merchant.acqBIN R Acquiring institution identification code. Length: 1-11 characters
●
Note: For Visa transactions, this is typi- Format: numeric digits
cally a 6 digit BIN assigned to the
If the value does not represent a partici-
acquirer by Visa. pating acquirer, DS must send a VERes
with CH.enrolled = N and iReqCode =
50.
ACS must store value for subsequent
PAReq processing.
Merchant ID Merchant.merID R Acquirer-defined merchant identifier. Edit Criteria:
Individual Payment Schemes may im- ●
Length: 1-24 characters
pose specific format and character re- ● Format: any characters
quirements on the contents of this field.
For Visa, these requirements are defined If the Payment Scheme or regional orga-
in the acquirer Implementation Guide nization uses Merchant ID and Password
(see “Visa Implementation Guides” in for merchant authentication, DS must
About This Guide) and are enforced at validate against values previously popu-
the time that the Merchant ID is populat- lated in the DS by the merchant’s acquir-
ed into the DS. er. If so, and if the value does not
represent a participating merchant of
Merchant.acqBIN, then DS must send a
VERes with CH.enrolled = N and iReq-
Code = 51.
No ACS validation of content.

C–10 Visa *Confidential* 30 September 2009

3-D Secure VEReq
Protocol Specification Core Functions Version 1.0.2

Table C–4: VEReq Field Descriptions (3 of 4)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
Password Merchant.pass- C Merchant password provided by mer- Length: 8 characters
word chant’s acquirer. ●
Format: alphanumeric
Required if Merchant ID and Password is
If the Payment Scheme or regional orga-
used as the authentication methodology, nization uses Merchant ID and Password
and omitted otherwise.
for merchant authentication, DS must
The requirements for use of this field will validate against values previously popu-
be specific to the Payment Scheme. The lated in the DS by the merchant’s acquir-
Visa requirements are indicated in the er. If the password is invalid, the DS must
acquirer Implementation Guide. send a VERes with CH.enrolled = N
and:
● If the element is missing when re-
quired, iReqCode = 52.
● If it is not a valid password for the
combination of Merchant.acqBIN
and Merchant.merID, iReqCode =
53.
The DS validates the Merchant pass-
word. The ACS does not.
Unless specifically stated otherwise for a
Payment Scheme implementation, the
DS must remove the Password before
forwarding the VEReq to the ACS. (The
DS may remove the field by any method
defined by the Payment Scheme, such
as removing element tags entirely, re-
moving the value leaving an empty ele-
ment, or replacing the contents with
spaces or other masking characters.)
The ACS must not reject the transaction
on the basis of this element.
Device Category Browser.device- O Indicates the type of device or channel ●
Length: 0-2 characters
Category being used for shopping. ●
Value: must be one of the following:
If the ACS does not support the device – 0 = The client environment is such
category indicated, ACS must send a that the full size messages
VERes with PAN Authentication Avail- (PAReq/PARes) will be used and
able = U. the core protocol specification
governs. For example, PC
(HTML). (Default value)
– 1 = The client is a constrained
device, such as WAP phone,
where the condensed messages
(CPRQ/CPRS) will be used and
the Extension for Mobile Inter-
net Devices must be followed.
– 2 = The client uses two-way mes-
saging (SMS or USSD) and the
Extension for Voice and Mes-
saging Channels must be fol-
lowed.
– 3 = The client uses the voice
channel and the Extension for
Voice and Messaging Channels
must be followed.
If this element is omitted, a value of 0 is
implied.

30 September 2009 Visa *Confidential* C–11

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–4: VEReq Field Descriptions (4 of 4)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
Accept Headers Browser.accept C The exact content of the HTTP accept Length: 0-2048 characters
header as sent to the merchant from the ●
Format: any characters
cardholder’s user agent.
Note: If the total length of the accept
Required if the cardholder’s user agent header sent by the browser exceeds
supplied a value.
2048 characters, the MPI must truncate
ACS may use the contents to determine the excess portion.
whether authentication is available, and
the appropriate ACS URL to return.
User Agent Browser.user- C The exact content of the HTTP user- ●
Length: 0-256 characters
Agent agent header as sent to the merchant ● Format: any characters
from the cardholder’s user agent.
Note: If the total length of the user agent
Required if the cardholder’s user agent
header sent by the browser exceeds 256
supplied a value. characters, the MPI must truncate the
ACS may use the contents to determine excess portion.
whether authentication is available, and
the appropriate ACS URL to return.
Message Exten- Extension O Any data necessary to support the re- ACS must process as defined in the sec-
sion quirements that are not otherwise de- tion, “Message Extensions” and in appli-
fined in the VEReq message must be cable protocol extension.
carried in an instance of Message Ex- Currently only 3-D Secure: Protocol
tension. Specification – Extension for Voice and
See the section, “Message Extensions” Messaging Channels defines extensions
for additional information about this ele- in the VEReq.
ment.

VERes

Purpose
The VERes (Verify Enrollment Response) is sent
● by the ACS via the Directory Server, or
●
by the Directory Server
to the Merchant Server Plug-in to advise the merchant whether authentication is available
for a particular PAN.

“treat as an error”
For VERes, the term “treat as an error” indicates the following behavior:
If the Directory Server discovers the error, it must:
● return an Error message to the ACS, and
● create a new VERes with PAN Authentication Available = “N” and send it to the MPI.
If the MPI discovers the error, it must:

C–12 Visa *Confidential* 30 September 2009

3-D Secure VERes
Protocol Specification Core Functions Version 1.0.2

● end transaction processing,

● indicate the error condition to the merchant, and
● optionally send an Error message to the Directory Server.

Required Field Missing

Unless explicitly noted otherwise in the table, if a required VERes field is missing, the
recipient must treat as an error. This applies whether the field is always required or
conditionally required.
If an Error message is returned in this situation, it must have Error Code = 3.
See the section “Conditions For Missing Fields” for details.

Edit Criteria
If a VERes field is present but its value does not conform to the edit criteria specified in
the table, the recipient should treat as an error.
If an Error message is returned in this situation, it must have Error Code = 5.

VERes Field Descriptions

Table C–5 lists the defined fields for a VERes message.

Table C–5: VERes Field Descriptions (1 of 3)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria

Message Version version R Version identifier; “1.0.2”. ●

Length: 3 or more characters
Number ●
Format:
n+.n+[.n+]* where:
● “n” represents a numeric digit
●
“+”represents “one or more”
●
“*”represents “zero or more”
The square bracket is not part of the for-
mat, but encloses the optional portion of
the string.
If the MPI does not support the returned
version number, must treat as an error.
Additional requirements are defined in
Chapter 5, the section “Versioning and
Parsing—Overview.”

30 September 2009 Visa *Confidential* C–13

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–5: VERes Field Descriptions (2 of 3)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
PAN Authentica- CH.enrolled R Indicates whether the Account Identifi- Length: 1 character
tion Available er can be authenticated. ●
Value: must be one of the following:
● Y = Authentication Available
●
N = Cardholder Not Participating
●
U = Unable To Authenticate
Note: “U” is used whether the Issuer’s
inability to authenticate the account is
due to technical difficulties or business
reasons.
If the value is not “Y”, MPI must not cre-
ate a PAReq.
Account Identifier CH.acctID C The content of this field is a data string ●
Length: 1-28 characters
useful to the ACS; it must not reveal the ● Format: any characters
PAN and must be generated using an al-
gorithm that is likely to generate unique Required if the value of PAN Authentica-
values, even if the same PAN is being tion Available is “Y”; omitted otherwise.
presented. If absent when PAN Authentication
Available = “Y”, MPI must treat as an er-
ror.
ACS URL url C URL of Access Control Server to which ●
Length: 1-2048 characters
PAReq must be sent. ●
Format: fully qualified https URL (ht-
Required if the value of PAN Authentica- tps://domainname…com)
tion Available is “Y”.
If absent or not usable when PAN Au-
thentication Available = “Y”, MPI must
treat as an error.
Payment Proto- protocol C Indicates which payment protocols are ●
Length: 0-12 characters
cols supported by the issuer system for the ●
Format: any characters
Cardholder PAN specified in VEReq.
The only defined value is “ThreeDSe-
cure”.
If the value of PAN Authentication
Available is “Y”, one instance of this ele-
ment must be included. Otherwise, the
presence of this element is optional.
Invalid Request IReq C Required if the VEReq is syntactically If present, MPI must not create a PAReq.
Data correct, but business processing cannot
be performed for one of the reasons de-
fined in Table C–9.
Note: When IReq is included, the value
of PAN Authentication Available is
always “N”.
Invalid Request Data consists of one re-
quired, one conditional, and one optional
element as listed in the fields that imme-
diately follow this field.
Invalid Request IReq.iReqCode R Code indicating the problem identified in ● Length: 1-3 characters.
Code the VEReq. Must be one of the values Additional values may be defined at any
listed in “Invalid Request Data Values” in
time. The recipient must accept any val-
Table C–9.
ue.

C–14 Visa *Confidential* 30 September 2009

3-D Secure PAReq
Protocol Specification Core Functions Version 1.0.2

Table C–5: VERes Field Descriptions (3 of 3)

Field Name DTD Element Inclusion Field Description Directory Server Edit Criteria
●
Invalid Request IReq.iReqDetail C May provide supporting detail, such as Length: 0-2048 characters
Detail the specific data elements that caused ●
Format: any characters
the Invalid Request Code. Table C–9
defines standard contents to be used.
●
Vendor Code IReq.vendorCode O Error code (or explanatory text) to be Length: 0-256 characters
used for troubleshooting. ● Format: any characters
Message Exten- Extension O Any data necessary to support require- MPI must process as defined in the sec-
sion ments that are not otherwise defined in tion “Message Extensions” and in appli-
the VERes message must be carried in cable protocol specification.
an instance of Message Extension.
See the section “Message Extensions”
for additional information about this ele-
ment.

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.

Required Field Missing

Unless explicitly noted otherwise in the table, if a required PAReq field is missing, the
ACS must return an Error message with Error Code = 3. This applies whether the field is
always required or conditionally required.
See the section “Conditions For Missing Fields” for details.

Edit Criteria
If a PAReq field is present but its value does not conform to the edit criteria specified in
the table, the ACS must return an Error message with Error Code = 5.

Displaying Purchase Amount

The ACS must format the transaction amount for display to the cardholder in the
Authentication Request Page. The ACS must not use the Display Amount element
(Purchase.amount).
In order to format the transaction amount for display, the ACS must use the Purchase
Amount element and the associated currency code and exponent elements:
Purchase.purchAmount, Purchase.currency, and Purchase.exponent.

30 September 2009 Visa *Confidential* C–15

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

The decimal position is indicated by the exponent. If, for example, the value of exponent
is “2”, this indicates that there are two minor units of currency.
The currency element contains the ISO numeric currency code. The ACS may either
convert this to one of the ISO alphabetic currency code (using the published ISO 4217
tables), or may use a standard currency symbol where appropriate (such as $, , or ¥).
EXAMPLE
If the value of purchAmount is “12345”, currency is “826”, and
exponent is “2”, the ACS could display this as “GBP 123.45” or
“£123.45”.
NOTE: The ACS must validate Purchase Currency to ensure that it is a valid ISO 4217
numeric currency code, as described in Chapter 4, the section “Step 7: Access
Control Server— Receive Payer Authentication Request.”

Recurring Frequency
The value of Recur.frequency indicates the minimum number of days between
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 C–6 illustrates the earliest possible dates for a subsequent authorization when the
value of Recur.frequency is 28. Later authorizations are acceptable (until
Recur.endRecur).

Table C–6: Recurring Frequency

If the most recent Au- ...then the earliest date However, the next au-
thorization was dated: for the next authoriza- thorization typically oc-
tion is: curs on:

31 December 2005 28 January 2006 31 January 2006

28 January 2006 25 February 2006 28 February 2006

31 January 2006 28 February 2006 28 February 2006

Recurring Expiry
It is the responsibility of the ACS software (and the cardholder software, if any) to 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.

C–16 Visa *Confidential* 30 September 2009

3-D Secure PAReq
Protocol Specification Core Functions Version 1.0.2

PAReq Field Descriptions

Table C–7 lists the defined fields for a PAReq message.

Table C–7: PAReq Field Descriptions (1 of 3)

Field Name DTD Element Inclusion Field Description Access Control Server Edit Criteria

Message Version version R Version identifier; “1.0.2”. ●

Length: 3 or more characters
Number ● Format: n+.n+[.n+]* where:
– “n” represents a numeric digit
– “+”represents “one or more”
– “*”represents “zero or more”
The square bracket is not part of the for-
mat, but encloses the optional portion of
the string.
If not the version number specified in the
VERes, ACS must send PARes with
iReqCode = 55.
●
Acquirer BIN Merchant.acqBIN R From VEReq. Length: 1-11 characters
●
Value: Same value as VEReq.Mer-
chant.acqBIN
If value does not match corresponding
VEReq (as identified by Account Identi-
fier), ACS must send iReqCode = 55.
Merchant ID Merchant.merID R From VEReq. Length: 1-24 characters
Value: Same value as VEReq.Mer-
chant.merID
If value does not match corresponding
VEReq (as identified by Account Identi-
fier), ACS must send iReqCode = 55.
Merchant Name Merchant.name R Merchant name to be displayed on Au- ●
Length: 1-25 characters
thentication Request Page. ●
Format: any characters
ACS must include value in Authentication
Request Page.
●
Merchant Coun- Merchant.Country R Country Code of the Merchant. The Length: 3 characters
try Code same value must be used in the authori- ● Format: numeric digits
zation request.
● Value: ISO 3166 three digit country
code, other than those listed in
Table C–9.
If not a valid three digit ISO country code,
ACS must send a PARes with iReqCode
= 54.
Merchant URL Merchant.URL R Fully qualified URL of the merchant Web ●
Length: 1-2048 characters
site or customer care site, either: http:// ● Format: any characters
domainname…com or, https://domain-
name…com.
Transaction Identi- Purchase.xld R Transaction identifier determined by mer- ● Length: 28 characters
fier chant. Contains a 20 byte value that has ● Format: any character
been Base64 encoded, giving a 28 byte
result.

30 September 2009 Visa *Confidential* C–17

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–7: PAReq Field Descriptions (2 of 3)

Field Name DTD Element Inclusion Field Description Access Control Server Edit Criteria
●
Purchase Date & Purchase.date R Date and time of purchase expressed in Length: 17 characters
Time GMT. ●
Format: YYYYMMDD HH:MM:SS
where:
– YYYY = 4 numeric digits
– MM = 2 numeric digits with value
01-12
– DD = 2 numeric digits with value
01-31
– a single space follows the date
– HH = 2 numeric digits with value
00 24, followed by a colon (“:”)
– MM = 2 numeric digits with value
00 59, followed by a colon (“:”)
– SS = 2 numeric digits with value
00 59
ACS should show value in Authentication
Request Page.
●
Display Amount Purchase.amount R This element must be present in the Length: 0-20 characters
message (to ensure compatibility with ● Format: any characters
the existing DTD). The content of this el-
ement is not used, and it may be empty. ACS must not use the contents of this
field in any way.
Purchase Amount Purchase.purchA- R Purchase amount in minor units of cur- ●
Length: 1-12 characters
mount rency with all punctuation removed. ●
Format: numeric digits
Example: If the purchase is for USD
ACS must use content in Authentication
123.45, the purchAmount element will Request Page, as described in the sec-
contain the value 12345.
tion “Displaying Purchase Amount.”
Purchase Curren- Purchase.curren- R Currency in which purchase amount is ●
Length: 3 characters
cy cy expressed. ●
Format: numeric digits
●
Value: ISO 4217 three digit currency
code, other than those listed in
Table C–9.
If not a valid ISO currency code, ACS
must send a PARes with iReqCode =
54.
ACS must use value to display Purchase
Amount, as described in the section
“Displaying Purchase Amount.”
Currency Expo- Purchase.expo- R The minor units of currency specified in ● Length: 1 character
nent nent ISO 4217. For example, US Dollars has a ●
Format: numeric digit
value of 2; Japanese Yen has a value of
● Value: exponent defined for currency
0.
code in ISO 4217
If not a valid exponent for Purchase.cur-
rency per ISO 4217, ACS must send a
PARes with iReqCode = 55.
ACS must use value to display Purchase
Amount, as described in the section
“Displaying Purchase Amount.”
Order Description Purchase.desc O Brief description of items purchased. ● Length: 0-125 characters
●
Format: any characters

C–18 Visa *Confidential* 30 September 2009

3-D Secure PAReq
Protocol Specification Core Functions Version 1.0.2

Table C–7: PAReq Field Descriptions (3 of 3)

Field Name DTD Element Inclusion Field Description Access Control Server Edit Criteria
●
Recurring Pay- Purchase.Recur C Required if the merchant and cardholder Both child elements must be present.
ment Data have agreed to recurring payments. ●
Either both child elements must be
The recurring payment data consists of empty, or both must contain valid con-
two required data elements as listed in tents.
the fields immediately following this field..
Recurring Fre- Recur.frequency R Indicates the minimum number of days ● Length: 0-4 characters
quency between authorizations. ●
Format: numeric digits
See the section “Recurring Frequency”
for additional information.
●
Recurring Expiry Recur.endRecur R The date after which no further authori- Length: 0 or 8 characters
zations should be performed. ●
Format: YYYYMMDD where:
This date must be in the future. – YYYY = 4 numeric digits
See “Recurring Frequency” for additional – MM = 2 numeric digits with value
information. 01-12
– DD = 2 numeric digits with value
01-31
●
Installment Pay- Purchase.install C Indicates the maximum number of per- Length: 0-3 characters
ment Data mitted authorizations for installment pay- ●
Format: numeric digits
ments.
●
Value: must be >1 (if not empty)
Required if the merchant and cardholder
have agreed to installment payments.
Account Identifier CH.acctID R From VERes. Length: 1-28 characters
Format: any characters
If does not match a previous available
VEReq, ACS must send a PARes with
Transaction Status = “U” and iReq-
Code = 55 or 56.
Note: If ACS is unable to sign the PARes
(for example, because ACS responds on
behalf of multiple issuers and therefore
cannot select the correct signing certifi-
cate), ACS must send Error message
with errorCode = 5.
Card Expiry Date CH.expiry R Expiration Date supplied to merchant by ●
Length: 4 characters
cardholder (YYMM). ●
Format: numeric digits
Message Exten- Extension O Any data necessary to support the re- ACS must process as defined in “Mes-
sion quirements that are not otherwise de- sage Extensions” and in applicable pro-
fined in the PAReq message must be tocol specification.
carried in an instance of Message Ex-
tension.
See the section “Message Extensions”
for additional information about this ele-
ment.

30 September 2009 Visa *Confidential* C–19

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

PARes

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

Signature Validation
The MPI must alert the merchant if the signature on the PARes cannot be validated using
the Root certificate required by the Payment Scheme. This condition should be
considered the same as a failed authentication.

“treat as an error”
In the “Validation” column of Table C–8, the term “treat as an error” indicates that the MPI
must:
● end transaction processing,
● indicate the error condition to the merchant, and
● optionally send an Error message to the ACS.

Required Field Missing

Unless explicitly noted otherwise in the table, if a required PARes field is missing, the MPI
should return an Error message with Error Code = 3. This applies whether the field is
always required or conditionally required.
See the section “Conditions For Missing Fields.”

Edit Criteria
If a PARes field is present but its value does not conform to the edit criteria specified in
the table, the MPI should return an Error message with Error Code = 5.

C–20 Visa *Confidential* 30 September 2009

3-D Secure PARes
Protocol Specification Core Functions Version 1.0.2

PARes Field Descriptions

Table C–8 lists the defined fields for a PARes message.

Table C–8: PARes Field Descriptions (1 of 4)

Field Name DTD Element Inclusion Field Description Merchant Plug-in Edit Criteria

Message Version version R Version identifier; “1.0.2”. ●

Length: 3 or more characters
Number ● Format: n+.n+[.n+]* where:
– “n” represents a numeric digit
– “+”represents “one or more”
– “*”represents “zero or more”
The square bracket is not part of the for-
mat, but encloses the optional portion of
the string.
If the returned version number does not
match that from PAReq, MPI must treat
as an error.
Acquirer BIN Merchant.acqBIN R From PAReq. If the field does not match PAReq, MPI
cannot rely on the contents of the
PARes, and must treat as an error.
Merchant ID Merchant.merID R From PAReq. If the field does not match PAReq, MPI
cannot rely on the contents of the
PARes, and must treat as an error.
Transaction Identi- Purchase.xld R From PAReq. If the field does not match PAReq, MPI
fier cannot rely on the contents of the
PARes, and must treat as an error.
Purchase Date & Purchase.date R From PAReq. If the field does not match PAReq, MPI
Time cannot rely on the contents of the
PARes, and must treat as an error.
Purchase Amount Purchase.purchA- R From PAReq. If the field does not match PAReq, MPI
mount cannot rely on the contents of the
PARes, and must treat as an error.
Purchase Curren- Purchase.curren- R From PAReq. If the field does not match PAReq, MPI
cy cy cannot rely on the contents of the
PARes, and must treat as an error.
Currency Expo- Purchase.expo- R From PAReq. If the field does not match PAReq, MPI
nent nent cannot rely on the contents of the
PARes, and must treat as an error.

30 September 2009 Visa *Confidential* C–21

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–8: PARes Field Descriptions (2 of 4)

Field Name DTD Element Inclusion Field Description Merchant Plug-in Edit Criteria
●
Cardholder PAN pan R Cardholder Account Number. Length: 13-19 characters
●
Format: numeric digits
● Value:
When Transaction Status is “Y” or “A”,
this field must include the last four digits
of the PAN supplied in the VEReq, pre-
ceded by zeros:
●
0000000001234(13 digit PAN)
● 0000000000001234(16 digit PAN)
When Transaction Status = “N” or “U”,
this field must be all zeros: one for each
digit of the original PAN in the VEReq.
If Transaction Status is “Y” or “A” and
the last four digits do not match the PAN
supplied in the VEReq, MPI must treat as
an error.
In some regional or Payment Scheme im-
plementations, the full PAN may be pro-
vided without overlaying any of the digits.
Signature Date & TX.time R Date and Time PARes message was ●
Length: 17 characters
Time signed by ACS. ●
Format: YYYYMMDD HH:MM:SS
Value is expressed in GMT. where:
– YYYY = 4 numeric digits
– MM = 2 numeric digits with value
01-12
– DD = 2 numeric digits with value
01-31
– a single space follows the date
– HH = 2 numeric digits with values
between 00 24, followed by a
colon (“:”)
– MM = 2 numeric digits with values
between 00 59, followed by a
colon (“:”)
– SS = 2 numeric digits with values
between 00 59

C–22 Visa *Confidential* 30 September 2009

3-D Secure PARes
Protocol Specification Core Functions Version 1.0.2

Table C–8: PARes Field Descriptions (3 of 4)

Field Name DTD Element Inclusion Field Description Merchant Plug-in Edit Criteria
●
Transaction Sta- TX.status R Indicates whether a transaction qualifies Length: 1 character
tus as an authenticated transaction. ●
Value: must be one of the following:
– Y =Authentication Successful.
Customer was successfully
authenticated. All data needed for
clearing, including the Card-
holder Authentication Verifica-
tion Value, is included in the
message.
– N =Authentication Failed
– Customer failed or cancelled
authentication. Transaction
denied.
– U = Authentication Could Not Be
Performed. Authentication could
not be completed, due to technical
or other problem, as indicated in
PARes.IReq.
– A = Attempts Processing Per-
formed. Authentication could not
be completed, but a proof of
authentication attempt (CAVV)
was generated.
●
Cardholder Au- TX.cavv C Contains a 20 byte value that has been Length: 28 characters
thentication Verifi- Base64 encoded, giving a 28 byte result. ●
Format: Base64-encoded data
cation Value
See 3-D Secure: Functional Require- Required when the value of Transaction
ments – Access Control Server for infor-
Status is “Y” or “A”.
mation about producing this value.
Note: MPI must make this data available
to the merchant/acquirer. The merchant
and acquirer may need to include the
CAVV in the authorization in order to
demonstrate that authentication
occurred.
Electronic Com- TX.eci C This Payment Scheme specific element ●
Length: 0 or 2 characters
merce Indicator represents the value of the ECI, as deter- ●
Value: numeric digits
mined by the ACS.
Required for Visa, MasterCard and JCB
transactions when the value of Transac-
tion Status is “Y” or “A”.
Required for Visa, MasterCard and JCB
transactions when the value of Transac-
tion Status is “Y” or “A”.
●
CAVV Algorithm TX.cavvAlgorithm C Indicates the algorithm used to generate Length: 0-1 character
the Cardholder Authentication Verifica- Value must be one of the following:
tion Value.
● 0 = HMAC (as per SET™ TransStain)
If the CAVV field is included, the CAVV (no longer in use for version 1.0.2)
algorithm field must also be included.
● 1 = CVV (no longer in use for version
If the CAVV field is missing, the CAVV al- 1.0.2)
gorithm field must also be missing.
● 2 = CVV with ATN
● 3 = MasterCard SPA algorithm

30 September 2009 Visa *Confidential* C–23

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–8: PARes Field Descriptions (4 of 4)

Field Name DTD Element Inclusion Field Description Merchant Plug-in Edit Criteria

Invalid Request IReq C Invalid Request Data consists of one re- Required if the PAReq is syntactically
Data quired, one conditional, and one optional correct, but business processing cannot
element as listed below. be performed for one of the reasons de-
fined in Table C–9.
Note: When IReq is included, the value
of Transaction Status is always “U”.
Invalid Request IReq.iReqCode R Code indicating the problem identified in ●
Length: 1-3 characters
Code the PAReq.
Must be one of the values listed in “In-
valid Request Data Values” in Table C–9.
Note: Additional values may be defined
at any time. The MPI must accept any
value.
Invalid Request IReq.iReqDetail C May provide supporting detail, such as ●
Length: 0-2048 characters
Detail the specific data elements that caused ●
Format: any characters
the Invalid Request Code. Table C–9
defines standard contents to be used. The contents of this field may be used for
problem resolution.
●
Vendor Code IReq.vendorCode O Error code (or explanatory text) to be Length: 0-256 characters
used for trouble shooting. ● Format: any characters
The contents of this field may be used for
problem resolution, if necessary, by the
operators of the ACS.
Message Exten- Extension O Any data necessary to support require- MPI must process as defined in “Mes-
sion ments that are not otherwise defined in sage Extensions” and in applicable pro-
the PARes message must be carried in tocol specification.
an instance of Message Extension.
See the section “Message Extensions”
for additional information about this ele-
ment.

Invalid Request

Data Values
Table C–9 lists and describes the currently defined 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.

C–24 Visa *Confidential* 30 September 2009

3-D Secure Invalid Request
Protocol Specification Core Functions Version 1.0.2

Note that additional iReqCode values may be defined at any time. All components must
accept any value.

Table C–9: Invalid Request Data Values (1 of 2)

Invalid Description Invalid Request Detail

Re-
quest
Code

50 Acquirer not participating in 3-D Secure (based on None available.

Acquirer BIN). Issued only by the Directory Serv-
er (DS).

51 Merchant not participating in 3-D Secure (based None available.

on Acquirer BIN and Merchant ID). Issued only
by the DS.

52 Password required, but no password was sup- None available.

plied. Issued only by the DS.

53 Supplied password is not valid for combination of None available.

Acquirer BIN and Merchant ID. Issued only by
the DS.

54 ISO code not valid per ISO tables (for either coun- Name of invalid element(s); if more than one in-
try or currency), or code is one of the excluded valid element is detected, this is a comma-delimit-
values listed in Table C–10. ed list.
If PAReq.Purchase.currency and PAReq.Pur-
chase.exponent form an invalid pair, list both as
iReqDetail.

55 Transaction data not valid. For example: Name of invalid element(s); if more than one in-
●
valid element is detected, this is a comma-delimit-
PAReq.acctid <> VERes.acctid
ed list.
●
PAReq.version <> VERes.version

56 If in response to a VEReq: Cardholder PAN is not Name of element(s) that caused the ACS to de-
in a range belonging to issuer. cide that the VEReq or PAReq was incorrectly
routed; if more than one invalid element is detect-
If in response to a PAReq: PAReq was incorrectly
ed, this is a comma-delimited list.
routed; either:
● the PAReq was received by the wrong ACS, or
● the PAReq should never have been sent,
based on the values in the VERes, or
●
a PAReq with this Account Identifier has al-
ready been received and processed.

30 September 2009 Visa *Confidential* C–25

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–9: Invalid Request Data Values (2 of 2)

Invalid Description Invalid Request Detail

Re-
quest
Code

57 Serial Number cannot be located. Issued only by

the Directory Server.

58 Issued only by the Directory Server. “Access denied, invalid endpoint.”

98 Transient system failure. A description of the failure

99 Permanent system failure. A description of the failure

Excluded ISO Code Values

Table C–10 lists exclusions for the ISO code values.

Table C–10: Excluded ISO Code Values (1 of 2)

ISO Code Value Not Permitted Definition

for 3-D Secure

ISO 4217 955 European Composite Unit

956 European Monetary Unit

957 European Unit of Account-9

958 European Unit of Account-17

959 Gold

960 I.M.F.

961 Silver

962 Platinum

963 reserved for testing

C–26 Visa *Confidential* 30 September 2009

3-D Secure Message Extensions
Protocol Specification Core Functions Version 1.0.2

Table C–10: Excluded ISO Code Values (2 of 2)

ISO Code Value Not Permitted Definition

for 3-D Secure

964 Palladium

999 no currency is involved

ISO 3166 900-999 reserved by ISO to designate country names

not otherwise defined

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

Message Extension Data

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

Message Extension Attributes

Table C–11 provides attributes for the Message Extension element:

Table C–11: Message Extension Attributes

Attribute Name Inclusion Description

id Required A unique identifier for the extension. See addi-

tional description below.

30 September 2009 Visa *Confidential* C–27

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–11: Message Extension Attributes

Attribute Name Inclusion Description

critical Optional A Boolean value indicating whether the recipi-

ent must understand the contents of the exten-
sion in order to interpret the entire message.
See additional description below.
Values are lowercase:

true
false

The recipient of a message may treat this as an

optional attribute. If the attribute is missing from
an extension, it may be assumed to have a
default value of “false”.
To ensure interoperability, the sender of the
message must include this attribute even when
the value is “false”.

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.

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 other than the DS receives a message
containing a critical extension that it does not recognize, it must treat the message as
invalid.
NOTE: Directory Server requirements for responding to an unrecognized critical
Extension element are described in Table 5–1.

C–28 Visa *Confidential* 30 September 2009

3-D Secure Error Message
Protocol Specification Core Functions Version 1.0.2

When an extension is non-critical, recipients that cannot process the extension must
ignore the data.

Error Message

Purpose
The Error message must 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.

Client Delivered Error

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

Response to Error Message

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

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.

30 September 2009 Visa *Confidential* C–29

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Related Elements
Table C–12 lists and describes the currently defined values for Error Code, and specifies
the contents of Error Detail when applicable.
NOTE: Additional Error Code values may be defined at any time. All components must
accept any value.

Table C–12: Error Code, Error Description, and Error Detail

Error Code Error Description Explanation Error Detail

1 Root element invalid. Root element is not recog- The invalid root element.
nized.

2 Message element not a de- Message is not CRReq, The invalid message element.
fined message. CRRes, VEReq, etc., or a val-
id message is sent to an inap-
propriate component (such as
PAReq being sent to the Di-
rectory Server)

3 Required element missing. None required. Name of required element that

was omitted.

4 Critical element not recog- None required. Name of critical element that
nized. was not recognized.

5 Format of one or more ele- For example, not numeric, not Name of invalid element(s); if
ments is invalid according to in defined date format, etc. more than one invalid ele-
the specification. ment is detected, this is a
comma-delimited list.

6 Protocol version too old. Only version 1.0.2 is support- The oldest version supported.
ed.

50 Acquirer not participating

51 Merchant not participating

52 Password Missing

53 Incorrect password

58 Incorrect Common Name val- DNS URL/IP mismatch or

ue in Client Certificate lookup failure

C–30 Visa *Confidential* 30 September 2009

3-D Secure Error Message
Protocol Specification Core Functions Version 1.0.2

Table C–12: Error Code, Error Description, and Error Detail

Error Code Error Description Explanation Error Detail

98 Transient system failure For example, a queue pro- A description of the failure.
cessing requests is full.

99 Permanent system failure For example, the disk contain- A description of the failure.
ing a critical database cannot
be accessed.

Error Message Field Descriptions

Table C–13 lists the defined fields for an Error message.

Table C–13: Error Message Field Descriptions (1 of 2)

Field Name DTD Element Inclusion Field Description

Message Version version R Version identifier; “1.0.2”.

Number
Edit Criteria:
● Length: 3 or more characters
● Format: n+.n+[.n+]* where:
– “n” represents a numeric digit
– “+”represents “one or more”
– “*”represents “zero or more”
The square bracket is not part of the format, but encloses the
optional portion of the string.

Error Code errorCode R Code indicating the problem identified in the message. Must
be one of the values listed in Table C–12.
Edit Criteria:
● Length: 1-2 characters
Note: Additional values may be defined at any time. All com-
ponents must accept any value.

Error Description errorMessage R Text describing the problem identified in the message. See
Table C–12.
Edit Criteria:
● Length: 0-2048 characters
● Format: any characters

30 September 2009 Visa *Confidential* C–31

3-D Secure Message Descriptions 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Table C–13: Error Message Field Descriptions (2 of 2)

Field Name DTD Element Inclusion Field Description

Error Detail errorDetail R May identify the specific data elements that caused the Error
Code. See Table C–12.

Vendor Code vendorCode O Error code (or explanatory text) to be used for trouble shooting.
Edit Criteria:
● Length: 0-256 characters
● Format: any characters

C–32 Visa *Confidential* 30 September 2009

PAReq and PARes File Compression D

Impact of Base64 Encoding

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. (Base64 encoding is defined in IETF RFC 2045.
See About This Guide, the section “Other Relevant Documents” for more information.

Compression Algorithms
The algorithm used for compression must be the DEFLATE algorithm, as specified in
RFC1951. The resulting data stream must be represented in the ZLIB compressed data
format, as specified by RFC1950. The compression method must 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.

30 September 2009 Visa *Confidential* D–1

PAReq and PARes File Compression 3-D Secure
Protocol Specification Core Functions Version 1.0.2

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/

D–2 Visa *Confidential* 30 September 2009

Glossary

This section includes selected terms and acronyms related to 3-D Secure.
A more 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 About This Guide, the section “References.”

absent
An element is absent if its tags do not occur in the message. For example, element c is absent
from the following XML instance:
<a><b>some data</b></a>
Contrast empty. See also missing.

Access Control Server

A component that operates in the Issuer Domain, verifies whether authentication is available
for a card number and device type, and authenticates specific transactions.

acquirer
A Member financial institution that establishes a contractual service relationship with a
merchant for the purpose of accepting payment 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).

30 September 2009 Visa *Confidential* Glossary–1

Glossary 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Acquirer Domain
Contains the systems and functions of the acquirer and its customers, such as merchants.

ACS
See Access Control Server.

AHS
See Authentication History Server.

ATN
See Authentication Tracking Number.

Attempts functionality
For Visa implementations: 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. Effective with 3-D Secure
protocol version 1.0.2.

Authenticated Payment Program

One of the programs of the Visa Secure e Commerce Initiative.

authentication
In the context of 3-D Secure, 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.

Authentication Tracking Number

A 16-digit number generated by the ACS to identify the transaction; used in creating the CAVV.

authorization
A process by which an issuer, or a processor on the issuer’s behalf, approves a transaction for
payment.

authorization system
The systems and services through which a Payment Scheme delivers online financial
processing, authorization, clearing and settlement services to Members.
See, for example, VisaNet.

Bank Identification Number

The first six digits of a payment card account number that uniquely identify the issuing financial
institution.

Glossary–2 Visa *Confidential* 30 September 2009

3-D Secure Base64
Protocol Specification Core Functions Version 1.0.2

Base64
Encoding applied to the PAReq and PARes messages before they are passed through the
browser, and defined in RFC 2045.

BIN
See Bank Identification Number.

Brand Certificate Authority

See Scheme Certificate Authority.

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

Card Range Request

Message from the Merchant Server Plug-in to the Directory Server, requesting the list of
participating card ranges in order to update the MPI’s internal cache information.

Card Range Response

Message from the Directory Server to the Merchant Server Plug-in, providing the list of
participating card ranges.

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

Cardholder Authentication Verification Value

A cryptographic value generated by the ACS to provide a way during authorization processing
for the authorization system 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 not forgeable by cryptographic technology
(signing with the private key of the certificate authority).

30 September 2009 Visa *Confidential* Glossary–3

Glossary 3-D Secure
Protocol Specification Core Functions Version 1.0.2

certificate authority
A trusted party that issues and revokes certificates.
See also Scheme Certificate Authority.

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.

compression
In the context of 3-D Secure, refers to the use of the DEFLATE algorithm to decrease the size
of the PAReq or PARes before Base64 encoding. See Appendix D for details.

core protocol
The protocol described in this publication.

CPRQ
Condensed Payer Authentication Request, used for 3-D Secure transactions performed with
mobile Internet devices. Described in 3-D Secure: Protocol Specification – Extension for Mobile
Internet Devices, Visa Publication 70006 01.
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
See Card Range Request.

CRRes
See Card Range Response.

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.

Glossary–4 Visa *Confidential* 30 September 2009

3-D Secure digital certificate
Protocol Specification Core Functions Version 1.0.2

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
A server hardware/software entity operated in the Interoperability Domain; it maintains lists of
card ranges for which authentication may be available and coordinates communication
between Merchant Server Plug-ins and Access Control Servers, to determine whether
authentication is available for a particular card number and device type.

empty
An element is empty if its tags occur in a message, but no content is defined. For example,
element c is empty in the following XML instance:
<a><b>some data</b><c></c></a>
Contrast absent. See also missing.

EMV
The EMV Integrated Circuit Card Specifications for Payment Systems developed jointly by
Europay, MasterCard, and Visa.

Enrollment Server
A server hardware/software entity operated in the Issuer Domain; it 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.

30 September 2009 Visa *Confidential* Glossary–5

Glossary 3-D Secure
Protocol Specification Core Functions Version 1.0.2

HTTPS
Hypertext Transport Protocol, Secure, uses the TLS/SSL protocol to ensure the secure
transmission of data over the Internet. Also called S HTTP.

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

issuer
A Member financial institution that issues payment cards, contracts with cardholder to provide
card services, determines eligibility of cardholder to participate in 3-D Secure, and identifies for
the Directory Server card number ranges eligible to participate in 3-D Secure.

Issuer Authentication Server

See Access Control Server.

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 a value.

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.

merchant
Entity that contracts with an acquirer to accept payment 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 that handles online transactions and facilitates
communication between the merchant application and the Payment Scheme gateway.

Merchant Server Plug-in

A component that operates in the Acquirer Domain; incorporated into the merchant’s Web
storefront, it 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.

Glossary–6 Visa *Confidential* 30 September 2009

3-D Secure Message Authentication Code
Protocol Specification Core Functions Version 1.0.2

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.

missing
An element is missing either if it is absent (that is, its tags do not occur in the message) or if it is
present and empty. For example, element c is missing in both of the following XML instances:
<a><b>some data</b></a>[element absent]
<a><b>some data</b><c></c></a>[element empty]

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
Refer to the 3-D Secure: Functional Requirements – Access Control Server for additional
details.

PATransRes
Payer Authentication Transaction Response; Authentication History Server response to
PATransReq
Refer to the 3-D Secure: Functional Requirements – Access Control Server for additional
details.

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 perform
authentication.
See PAReq and CPRQ.

30 September 2009 Visa *Confidential* Glossary–7

Glossary 3-D Secure
Protocol Specification Core Functions Version 1.0.2

Payer Authentication Response

A message formatted, digitally signed, and sent from the Access Control 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.

Payment Scheme
A payment card system which defines the operating rules and conditions, and specifies the
requirements for card issuance and merchant acceptance.

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

proof of attempt
See Attempts functionality.

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

public key pair

Two mathematically related keys – a public key and a private key – that 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.

Scheme Certificate Authority

A component that operates in the Interoperability Domain on behalf of the Payment Scheme;
generates and distributes selected digital certificates to entities participating in 3-D Secure.

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

Glossary–8 Visa *Confidential* 30 September 2009

3-D Secure Secure Sockets Layer
Protocol Specification Core Functions Version 1.0.2

Secure Sockets Layer

A cryptographic protocol developed by Netscape Communications Company to confidentially
transmit information over open networks, such as the Internet.
See also Transport Layer Security.

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.

VEReq
See Verify Enrollment Request.

VERes
See Verify Enrollment Response.

Verify Enrollment Request

Message from Merchant Server Plug-in to Directory Server or from Directory Server to ACS,
asking whether authentication is available for a particular card number and device type.

Verify Enrollment Response

Message from ACS or Directory Server, telling Merchant Server Plug-in whether authentication
is available.

30 September 2009 Visa *Confidential* Glossary–9

Glossary 3-D Secure
Protocol Specification Core Functions Version 1.0.2

VIS
Visa Integrated Circuit Card Specification.

Visa Directory
See Directory Server.

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.
VisaNet is a specific authorization system.

VSDC
Visa Smart Debit and Credit. The Visa service offerings for chip based debit and credit
programs which are based on EMV and VIS specifications and are support by VisaNet
processing, as well as by Visa rules and regulations.

wallet
See digital wallet.

XML
Extensible Markup Language.

Glossary–10 Visa *Confidential* 30 September 2009