Welcome to

Visa Integrated Circuit Card Terminal Specification
The Visa Integrated Circuit Card (ICC) Terminal Specification has been updated. Please see the Chapter 1, Section 1.6, “Impact Summary” for information on what has changed from Visa ICC Specification (VIS) version 1.3.2. This document is the final copy of the Visa ICC Specification version 1.4.0. It reflects changes from the copy published on the Visa website in April 2001. These changes are noted in a separate changes list available on the Visa website. It is important that Visa staff, members, and vendors review the changes list. If you have any comments regarding this manual, please contact your regional representative. Your opinion is important to us.

Effective: 31 October 2001

Visa Integrated Circuit Card

Terminal Specification Version 1.4.0
Effective: 31 October 2001

 Visa International 1998, 1999, 2001
Visa Public

5103-03

 1998, 1999, 2001 Visa International Service Association. All rights reserved. Permission to copy and implement the
material contained herein is granted subject to the conditions that (i) any copy or re-publication must bear this legend in full, (ii) any derivative work must bear a notice that it is not the Visa Integrated Circuit Card Specification published by Visa, and (iii) Visa shall have no responsibility or liability whatsoever to any other party arising from the use or publication of the material contained herein. Visa makes no representation or warranty regarding whether any particular physical implementation of any part of this Specification does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual property of third parties, and thus any person who implements any part of this Specification should consult an intellectual property attorney before any such implementation. Any party seeking to implement this Specification is solely responsible for determining whether their activities require a license to any technology including, but not limited to, patents on public key encryption technology. Visa International Service Association shall not be liable for any party’s infringement of any intellectual property right.

Printed on recycled paper.

Contents
Chapter 1 • About This Specification
1.1 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2 1.2 VIS Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2

1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–3 1.3.1 Mandatory/Required/Recommended/Optional 1.3.2 Card/Integrated Circuit . . . . . . . . . . . 1–3

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

1.3.3 Terminated Transactions . . . . . . . . . . . . . . . . . . . . 1–3 1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . 1–4 1.4.1 Volume Overview 1.4.2 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . 1–4 . . . . . . . . . . . . . . . . . . . . . . 1–4

1.4.3 Subheading Overview . . . . . . . . . . . . . . . . . . . . . 1–6 1.5 Revisions to This Specification . . . . . . . . . . . . . . . . . . . . 1–6 1.6 Impact Summary . . . . . . . . . . . . . . . . . . . . . . . . . 1–7 1.6.1 Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7 1.6.1.1 Mandatory . . . . . . . . . . . . . . . . . . . . . . . 1–7 1.6.1.2 Optional . . . . . . . . . . . . . . . . . . . . . . . . 1–7 1.6.2 Card . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8

1.6.2.1 Mandatory . . . . . . . . . . . . . . . . . . . . . . . 1–8 1.6.2.2 Optional . . . . . . . . . . . . . . . . . . . . . . . . 1–8

Draft 12/18/00
31 Oct 2001
Visa Public

i

Contents

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.7 Reference Materials

. . . . . . . . . . . . . . . . . . . . . . . 1–10

1.7.1 International Organisation for Standardisation (ISO) Documents . . . . 1–10 1.7.2 EMV Documents 1.7.3 Visa Documents . . . . . . . . . . . . . . . . . . . . . . 1–11 . . . . . . . . . . . . . . . . . . . . . . 1–11

Chapter 2 • Processing Overview
2.1 Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . 2–1

2.1.1 Application Selection (mandatory) . . . . . . . . . . . . . . . . . 2–1 2.1.2 Initiate Application Processing/Read Application Data (mandatory) . . . . 2–2 2.1.3 Offline Data Authentication . . . . . . . . . . . . . . . . . . . 2–2

2.1.4 Processing Restrictions (mandatory) . . . . . . . . . . . . . . . . 2–3 2.1.5 Cardholder Verification (mandatory) . . . . . . . . . . . . . . . . 2–3 2.1.6 Terminal Risk Management (mandatory) . . . . . . . . . . . . . . 2–3 2.1.7 Terminal Action Analysis (mandatory) . . . . . . . . . . . . . . . 2–4

2.1.8 Card Action Analysis (mandatory) . . . . . . . . . . . . . . . . . 2–4 2.1.9 Online Processing . . . . . . . . . . . . . . . . . . . . . . . 2–4 2.1.10 Issuer-to-Card Script Processing . . . . . . . . . . . . . . . . . 2–5 2.1.11 Completion (mandatory) . . . . . . . . . . . . . . . . . . . . 2–5 2.2 Terminal Mandatory and Optional Functionality . . . . . . . . . . . . . . 2–7 2.2.1 Command Support Requirements . . . . . . . . . . . . . . . . . 2–9

Chapter 3 • Application Selection
3.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2

3.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4 3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–5 3.4 Building the Candidate List . . . . . . . . . . . . . . . . . . . . . . 3–6 3.4.1 Directory Selection Method 3.4.2 List of AIDs Method . . . . . . . . . . . . . . . . . . . 3–7

. . . . . . . . . . . . . . . . . . . . . . 3–9

Draft 12/18/00
ii
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Contents

3.5 Identifying and Selecting the Application . . . . . . . . . . . . . . . . 3–10 3.5.1 Terminal Makes Application Selection Decision . . . . . . . . . . . 3–10 3.5.2 Cardholder Makes Account Selection Decision . . . . . . . . . . . 3–10 3.5.2.1 Terminal Supports Cardholder Confirmation . . . . . . . . . . 3–10 3.5.2.2 Terminal Supports Cardholder Selection . . . . . . . . . . . 3–11 3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12 3.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 3–15

Chapter 4 • Initiate Application Processing
4.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2 4.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3

4.3 GET PROCESSING OPTIONS Command . . . . . . . . . . . . . . . 4–3 4.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4

4.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 4–6 4.6 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 4–6

Chapter 5 • Read Application Data
5.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2 5.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2

5.3 READ RECORD Command . . . . . . . . . . . . . . . . . . . . . 5–3 5.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–3

5.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 5–5 5.6 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 5–5

Chapter 6 • Offline Data Authentication
6.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . . 6–3 6.1.1 Support for Offline Data Authentication . . . . . . . . . . . . . . 6–3 6.1.2 Visa Certificate Authority (CA) . . . . . . . . . . . . . . . . . 6–3

Draft 12/18/00
31 Oct 2001
Visa Public

iii

Contents

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.1.3 RSA Key Pairs

. . . . . . . . . . . . . . . . . . . . . . . . 6–3

6.1.4 Security Requirements . . . . . . . . . . . . . . . . . . . . . 6–4 6.2 Determining Whether to Perform SDA or DDA 6.2.1 Terminal Data . . . . . . . . . . . . . . 6–4

. . . . . . . . . . . . . . . . . . . . . . . . 6–4

6.2.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6–5 6.2.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6–5

6.2.4 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–5 6.3 Static Data Authentication (SDA) . . . . . . . . . . . . . . . . . . . 6–7

6.3.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . 6–7 6.3.2 Terminal Data 6.3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . 6–8 . . . . . . . . . . . . . . . . . . . . . . . . . 6–8

6.3.4 SDA Process . . . . . . . . . . . . . . . . . . . . . . . . . 6–9 6.4 Dynamic Data Authentication (DDA) . . . . . . . . . . . . . . . . . 6–12 6.4.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . 6–12 6.4.2 Terminal Data 6.4.3 Commands . . . . . . . . . . . . . . . . . . . . . . . 6–13 . . . . . . . . . . . . . . . . . . . . . . . . 6–14

6.4.3.1 INTERNAL AUTHENTICATE Command . . . . . . . . . . . 6–14 6.4.3.2 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . 6–14 6.4.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . 6–14 6.4.4.1 Standard DDA . . . . . . . . . . . . . . . . . . . . . 6–15 6.4.4.2 Combined DDA/AC Generation 6.5 Prior Related Processing . . . . . . . . . . . . . . 6–18

. . . . . . . . . . . . . . . . . . . . . 6–23

6.6 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 6–23

Chapter 7 • Processing Restrictions
7.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2

7.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–3 7.3 Application Version Number . . . . . . . . . . . . . . . . . . . . . 7–3

7.4 Application Usage Control . . . . . . . . . . . . . . . . . . . . . . 7–4

Draft 12/18/00
iv
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Contents

7.5 Application Effective Date . . . . . . . . . . . . . . . . . . . . . . 7–6 7.6 Application Expiration Date . . . . . . . . . . . . . . . . . . . . . 7–6 7.7 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 7–8 7.8 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 7–8

Chapter 8 • Cardholder Verification
8.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . . 8–3 8.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–3 8.3 Terminal Data 8.4 Commands 8.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8–7

. . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–9

8.5.1 CVM List Processing . . . . . . . . . . . . . . . . . . . . . 8–9 8.5.2 CVM Processing . . . . . . . . . . . . . . . . . . . . . . . 8–13 8.5.2.1 Offline Plaintext PIN . . . . . . . . . . . . . . . . . . . 8–13 8.5.2.2 Offline Enciphered PIN . . . . . . . . . . . . . . . . . . 8–19 8.5.2.3 Online PIN . . . . . . . . . . . . . . . . . . . . . . . 8–21 8.5.2.4 Signature . . . . . . . . . . . . . . . . . . . . . . . 8–21

8.5.2.5 Signature and Offline PIN . . . . . . . . . . . . . . . . . 8–22 8.5.2.6 Fail CVM . . . . . . . . . . . . . . . . . . . . . . . 8–22

8.5.2.7 No CVM Required . . . . . . . . . . . . . . . . . . . . 8–23 8.6 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . . 8–23 8.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . . . 8–24

Chapter 9 • Terminal Risk Management
9.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–3 9.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 9–4

9.3 GET DATA Command . . . . . . . . . . . . . . . . . . . . . . . 9–5 9.4 Terminal Exception File . . . . . . . . . . . . . . . . . . . . . . 9–5 . . . . . . . . . . . . . . . . . 9–5

9.5 Merchant Forced Transaction Online

Draft 12/18/00
31 Oct 2001
Visa Public

v

Contents

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

9.6 Floor Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9–5 9.7 Random Transaction Selection . . . . . . . . . . . . . . . . . . . . 9–6

9.8 Terminal Velocity Checking . . . . . . . . . . . . . . . . . . . . . . 9–7 9.9 New Card Check . . . . . . . . . . . . . . . . . . . . . . . . . . 9–8 9.10 End Terminal Risk Management . . . . . . . . . . . . . . . . . . . 9–8 9.11 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 9–11 9.12 Subsequent Related Processing . . . . . . . . . . . . . . . . . . 9–11

Chapter 10 • Terminal Action Analysis
10.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 10–2 10.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 10–3

10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . . . . . 10–5 10.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 10–6

10.4.1 Review Offline Processing Results . . . . . . . . . . . . . . . 10–6 10.4.2 Request Application Cryptogram . . . . . . . . . . . . . . . . 10–9 10.4.3 Process Flow . . . . . . . . . . . . . . . . . . . . . . . 10–10

10.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 10–11 10.6 Subsequent Related Processing . . . . . . . . . . . . . . . . . . 10–11

Chapter 11 • Card Action Analysis
11.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 11–2 11.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 11–3

11.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command . . . . . . . 11–3 11.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 11–4

11.4.1 Response to GENERATE AC for Combined DDA/AC Generation . . . 11–4 11.4.2 Standard Response to GENERATE AC . . . . . . . . . . . . . 11–5 11.5 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 11–5 11.6 Subsequent Related Processing . . . . . . . . . . . . . . . . . . 11–5

Draft 12/18/00
vi
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Contents

Chapter 12 • Online Processing
12.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . 12–2 12.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2 . . . . . . . . . . . . . . . . 12–2

12.2.1 GENERATE AC Response Data 12.2.2 Other Card Data

. . . . . . . . . . . . . . . . . . . . . . 12–3

12.3 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 12–3 12.3.1 Online Request Message Data . . . . . . . . . . . . . . . . . 12–4 12.3.2 Online Response Data . . . . . . . . . . . . . . . . . . . . 12–5 12.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6 12.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–6 12.5.1 Online Request . . . . . . . . . . . . . . . . . . . . . . . 12–6 12.5.1.1 Combined DDA/AC Generation Processing 12.5.1.2 Standard Online Processing . . . . . . . . . 12–6

. . . . . . . . . . . . . . . 12–7

12.5.2 Online Response . . . . . . . . . . . . . . . . . . . . . . 12–8 12.5.3 Issuer Authentication . . . . . . . . . . . . . . . . . . . . . 12–8 12.5.4 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–9 12.6 Prior Related Processing . . . . . . . . . . . . . . . . . . . . 12–10 . . . . . . . . . . . . . . . . . 12–10

12.7 Subsequent Related Processing

Chapter 13 • Completion
13.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13–2

13.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13–4 13.3 GENERATE AC Command . . . . . . . . . . . . . . . . . . . . . 13–4 13.4 Transaction Authorized Offline . . . . . . . . . . . . . . . . . . . 13–5

Draft 12/18/00
31 Oct 2001
Visa Public

vii

Contents

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.5 Transaction Authorized Online . . . . . . . . . . . . . . . . . . . 13–6 13.5.1 Transmit Final GENERATE AC to the Card . . . . . . . . . . . . 13–6 13.5.2 Terminal Receives Final GENERATE AC Response . . . . . . . . 13–6 13.5.2.1 Issuer-to-Card Script Processing . . . . . . . . . . . . . 13–6

13.5.2.2 Terminal Requested an AAC in the Final GENERATE AC . . . . 13–7 13.5.2.3 Terminal Requested a TC in the Final GENERATE AC . . . . . 13–7 13.6 Online Processing Requested, Transaction Was Not Sent Online . . . . . 13–8

13.6.1 Check IAC and TAC-Default Settings . . . . . . . . . . . . . . 13–8 13.6.2 Issue Final GENERATE AC Command . . . . . . . . . . . . . 13–8

13.6.3 Terminal Completes Transaction . . . . . . . . . . . . . . . . 13–8 13.6.3.1 Terminal Requested AAC in Final GENERATE AC . . . . . . 13–8

13.6.3.2 Terminal Requested TC in Final GENERATE AC . . . . . . . 13–9 13.7 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 13–11

Chapter 14 • Issuer-to-Card Script Processing
14.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–2 14.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . 14–2

14.3 Online Response Data . . . . . . . . . . . . . . . . . . . . . . 14–3 14.4 Commands 14.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 14–3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14–4

14.5.1 Issuer Scripts . . . . . . . . . . . . . . . . . . . . . . . 14–4 14.5.2 Multiple Commands . . . . . . . . . . . . . . . . . . . . . 14–4 14.5.3 Script Errors . . . . . . . . . . . . . . . . . . . . . . . . 14–5 14.5.4 Multiple Scripts . . . . . . . . . . . . . . . . . . . . . . 14–5

14.5.5 Issuer Script with Tag “71” . . . . . . . . . . . . . . . . . . 14–5 14.5.6 Terminal Messages . . . . . . . . . . . . . . . . . . . . . 14–5 14.5.7 Issuer Notification 14.5.8 Process Flow . . . . . . . . . . . . . . . . . . . . . 14–5

. . . . . . . . . . . . . . . . . . . . . . . 14–5

14.6 Prior Related Processing . . . . . . . . . . . . . . . . . . . . . 14–7

Draft 12/18/00
viii
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Contents

Appendix A • Terminal and Acquirer Data Elements
A.1 Terminal and Acquirer Data Elements Table A.2 Terminal Data Element Tags . . . . . . . . . . . . . . A–1

. . . . . . . . . . . . . . . . . . . . A–22

Appendix B • Commands for Financial Transactions
B.1 Basic Processing Rules for Issuer Script Commands . . . . . . . . . . . B–2 B.2 EXTERNAL AUTHENTICATE Command—Response APDUs . . . . . . . B–2

B.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command Response APDUs . . . . . . . . . . . . . . . . . . . . . . . . B–3 B.4 GET CHALLENGE Command—Response APDUs . . . . . . . . . . . . B–3 B.5 GET DATA Command—Response APDUs . . . . . . . . . . . . . . . B–4 B.6 GET PROCESSING OPTIONS Command—Response APDUs . . . . . . . B–5 B.7 INTERNAL AUTHENTICATE Command—Response APDUs . . . . . . . . B–5 B.8 READ RECORD Command—Response APDUs . . . . . . . . . . . . . B–5 B.9 SELECT Command—Response APDUs . . . . . . . . . . . . . . . . B–6 B.10 VERIFY Command—Response APDUs . . . . . . . . . . . . . . . B–7

Appendix C • General Terminal Requirements
C.1 Terminal Types and Capabilities . . . . . . . . . . . . . . . . . . . C–1 C.1.1 Advice Creation . . . . . . . . . . . . . . . . . . . . . . . C–2 C.1.2 Amount Entry and Management . . . . . . . . . . . . . . . . . C–2 C.1.3 Card Reading . . . . . . . . . . . . . . . . . . . . . . . . C–3 C.2 Physical Characteristics . . . . . . . . . . . . . . . . . . . . . . C–4 C.3 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . C–4 C.4 Data Management . . . . . . . . . . . . . . . . . . . . . . . . C–4

C.5 Cardholder and Attendant Interface . . . . . . . . . . . . . . . . . . C–5 C.5.1 Receipt . . . . . . . . . . . . . . . . . . . . . . . . . . C–5

C.6 Acquirer Interface . . . . . . . . . . . . . . . . . . . . . . . . . C–5

Draft 12/18/00
31 Oct 2001
Visa Public

ix

Contents

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Appendix D • Terminal Requirements for Visa Low-Value Payment Feature
D.1 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . .D–2

D.2 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . .D–3 D.3 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . .D–4 D.4 VLP Purchase Transaction Process . . . . . . . . . . . . . . . . . .D–4

D.4.1 VLP Transaction With VLP-Capable Card at a VLP-Capable Terminal . . . . . . . . . . . . . . . . . . . . . . . . . .D–4 D.4.2 VSDC Transaction With a Non-VLP-Capable Card at a VLP-Capable Terminal . . . . . . . . . . . . . . . . . . . . .D–9 D.5 VLP Reset Transaction Processing D.5.1 VSDC Online-Capable Terminal . . . . . . . . . . . . . . . . . .D–9 . . . . . . . . . . . . . . . . .D–9

D.5.2 Dedicated Online Unattended Terminal—VLP Reset-Capable . . . . . .D–9

Appendix E • Acronyms Glossary Index

Draft 12/18/00
x
Visa Public

31 Oct 2001

Figures
2–1: 3–1: 3–2: 3–3: 3–4: 4–1: 5–1: 6–1: 6–2: 6–3: 6–4: 6–5: 7–1: 8–1: 8–2: 8–3: 8–4: 8–5: 8–6: 8–7: 8–8: 9–1: 9–2: Sample Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6 . 3–8 3–12 3–13 3–14 . 4–5 . 5–4 . 6–6 6–11 6–20 6–21 6–22 . 7–7 8–12 8–15 8–18 8–20 8–21 8–22 8–22 8–23 . 9–9 9–10

Directory Selection Method Example .

Application Selection Processing Flow (1 of 3) . Application Selection Processing Flow (2 of 3) . Application Selection Processing Flow (3 of 3) . Initiate Application Processing Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Read Application Data Processing Flow . SDA or DDA Determination . SDA Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DDA Flow (1 of 3) . DDA Flow (2 of 2) . DDA Flow (3 of 3) .

Processing Restrictions Flow CVM List Processing . . .

PIN Try Counter Checking . Offline PIN Processing . .

Offline Enciphered PIN Processing Online PIN Processing Signature Processing Fail CVM Processing . . . . . . . . . . . . . .

No CVM Required Processing .

Terminal Risk Management Processing Flow (1 of 2) . Terminal Risk Management Processing Flow (2 of 2) . . . . . . . . . . . . . . . . . . .

10–1: Terminal Action Analysis . 12–1: Online Processing . . .

. 10–10 . 12–9

Draft 12/18/00
31 Oct 2001
Visa Public

xi

Figures

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13–1: Completion Processing Flow .

.

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. 13–10 . 14–6 . D–8

14–1: Issuer-to-Card Script Processing D–1: VLP Transaction Flow . . . .

Draft 12/18/00
xii
Visa Public

31 Oct 2001

Tables
2–1: 2–2: 3–1: 3–2: 3–3: 3–4: 4–1: 4–2: 5–1: 5–2: 6–1: 6–2: 6–3: 6–4: 6–5: 6–6: 6–7: 7–1: 7–2: 7–3: 8–1: 8–2: 8–3: 8–4: Terminal Functional Requirements Command Support Requirements . Application Selection—Card Data . Application Selection—Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7 . 2–9 . 3–2 . 3–4 . 3–6 . 3–9 . 4–2 . 4–3 . 5–2 . 5–2 . 6–4 . 6–5 . 6–7 . 6–8 6–12 6–13 6–13 . 7–2 . 7–3 . 7–5 . 8–3 . 8–5 . 8–5 . 8–6

Application Selection Indicator Matching Criteria . Sample AIDs Matching . . . . . . . . . . . . . .

Initiate Application Processing—Card Data .

Initiate Application Processing—Terminal Data . Read Application Data—Card Data Read Application Data—Card Files . . . . . . . .

Terminal Data Used in SDA or DDA Determination Card Data Used in SDA or DDA Determination Offline Data Authentication—SDA Card Data

Offline Data Authentication—SDA Terminal Data . Offline Data Authentication—DDA Card Data . .

Offline Data Authentication—DDA Card Data in INTERNAL AUTHENTICATE Response . . . . . . . . . . Offline Data Authentication—DDA Terminal Data . Processing Restrictions—Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Processing Restrictions—Terminal Data . Application Usage Control (AUC) . CVM List Processing—Card Data . Offline PIN—Card Data . . . . . . . . . . . .

Offline Enciphered PIN—Card Data . Offline PIN Processing—Card Data .

Draft 12/18/00
31 Oct 2001
Visa Public

xiii

Tables

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8–5: 8–6: 9–1: 9–2: 9–3:

CVM Processing—Terminal Data

.

.

. .

. . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

8–7 8–8 9–3 9–4 9–6

Offline Enciphered PIN—Terminal Data

Terminal Risk Management—Card Data .

Terminal Risk Management—Terminal Data . Example Terminal Parameters . . . . . . .

10–1: Offline Processing Results—Card Data

. 10–2 . 10–3 . 10–3 . 10–5 . 11–2 . 11–2 . 11–3 . 11–4 . 12–2 . 12–3 . 12–3 . 12–4 . 12–5 . 13–2 . 13–3 . 13–4 . 13–5 . 13–8 . 14–2 . 14–3 . A–2

10–2: Request Application Cryptogram—Card Data 10–3: Offline Processing Results—Terminal Data .

10–4: Request Application Cryptogram—Terminal Data 11–1: Card Action Analysis—Card Data . . . . . . .

11–2: GENERATE AC Command Response Data . 11–3: Card Action Analysis—Terminal Data . . .

11–4: Card’s Response to First GENERATE AC Command .

12–1: Online Processing—GENERATE AC Response Card Data 12–2: Online Processing—Other Card Data . 12–3: Online Processing—Terminal Data . . . . . . . . . . . . . .

12–4: Visa Smart Debit Credit (VSDC) Data Objects Required in Online Message . 12–5: New Authorization/Financial Transaction Response Data Elements 13–1: Completion—Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13–2: Completion—Final GENERATE AC Response Data 13–3: Completion—Terminal Data . . . . . . . . . . . . . .

13–4: Offline Transaction Disposition Response 13–5: Online Transaction Disposition Response

14–1: Issuer-to-Card Script Processing—Terminal Data .

14–2: Issuer-to-Card Script Processing—Online Response Data A–1: A–2: B–1: B–2: D–1: D–2: D–3: Terminal and Acquirer Data Elements . Terminal Data Element Tags . Data Retrieval Using GET DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. A–22 . . . . . B–4 B–5 D–2 D–3 D–6

Data Retrieval With GET PROCESSING OPTIONS Initiate Application Processing—Card Data . Initiate Application Processing—Card Data . Terminal TACs for VLP . . . . . . . . . .

Draft 12/18/00
xiv
Visa Public

31 Oct 2001

About This Specification

1

The Visa Integrated Circuit Card Specification (VIS) provides the technical details of chip card and terminal functionality related to Visa Smart Debit and Visa Smart Credit (VSDC) transactions, Visa’s chip-based credit and debit programs. It focuses on the functions performed by the chip card and terminal as well as the interaction between the chip card and terminal at the point of transaction. The objective of the Visa Integrated Circuit Card Specification is to:
q

Communicate the implementation details of Europay, MasterCard, and Visa (EMV) specifications to ease vendor development efforts Aid members and vendors in understanding the changes that chip brings to the credit and debit payment services, especially in terms of the processing taking place between the chip card and terminal at the point of transaction Provide Visa’s minimum requirements for chip-based credit and debit programs Identify options that members and vendors can implement to meet market needs Support Visa’s payment service rules and International Operating Regulations for Visa Smart Debit and Visa Smart Credit (VSDC) Define Visa’s implementation of optional EMV features

q

q

q

q

q

Because VIS is based on EMV, the two specifications should be used together for reference and development purposes. However, VIS builds on the EMV requirements in order to support the Visa payment service rules. To facilitate understanding of the differences between these two specifications, please refer to Chapter 2, Processing Overview.

Draft 12/18/00
31 Oct 2001
Visa Public

1–1

About This Specification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.1 Audience
This document is intended for members, vendors, and readers seeking a technical understanding of the functionality of chip cards and terminals supporting Visa Smart Debit and Visa Smart Credit programs.

1.2 VIS Update
This document serves as an update to VIS 1.3.2. The update includes changes reflecting EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, enhancements to VSDC functionality, and corrections and clarifications to VIS 1.3.2. An impacts summary highlighting the differences between VIS 1.3.2 and the current version, VIS 1.4.0, is provided later in this chapter.

Draft 12/18/00
1–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.3 Terminology

1.3 Terminology
This section provides clarification on several terms used throughout the specification.

1.3.1 Mandatory/Required/Recommended/Optional
Visa’s philosophy is to facilitate market requirements while ensuring global interoperability. To this end, Visa’s minimum requirements reflect the EMV mandatory items in addition to specific requirements outlined in the Visa payment service rules or International Operating Regulations. All other functionality is optional and not required. Visa’s minimum requirements are designated using the terms “mandatory”, “required”, and “shall.” Recommended functionality is designated in the document using the term “should.” Elective data elements and functions are designated using the terms “optional” or “may.” Markets can customize their programs beyond the minimum requirements through adoption of the optional functions and through proprietary processing. Proprietary processing, however, must not interfere with global interoperability.

1.3.2 Card/Integrated Circuit
In general, the term “card” is used to describe functions performed by the VSDC application on the card. When it is necessary to distinguish between the chip itself and another card feature such as the magnetic stripe, the term “integrated circuit” may be used.

1.3.3 Terminated Transactions
When the term “terminal terminates transaction” is used, it includes the processing to end the transaction and the display of the message to the cardholder and merchant indicating why the transaction cannot be completed.

Draft 12/18/00
31 Oct 2001
Visa Public

1–3

About This Specification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.4 Document Structure
This section provides an overview of the structure of the Visa Integrated Circuit Card Specification. It begins with an overview of the three volumes, is followed by an overview of each chapter, and concludes with the sub-heading structure of each chapter.

1.4.1 Volume Overview
The document is organized into three volumes:
q

Application Volume—This volume provides a technical overview of the processing between the card and terminal. This volume may be used as an overview to understand the processing and sequence of events involved in a VSDC transaction flow. Card Volume—This volume specifies the technical details of EMV related to the data and processing performed by the card. It also includes additional Visa specific requirements for card functionality. Vendors involved in the creation of the VSDC card application should focus on this document for their development efforts. Terminal Volume—This volume specifies the technical details of EMV related to the data and processing performed by the terminal. It also includes additional Visa specific requirements for terminal functionality. Vendors involved in the creation of the VSDC terminal application should focus on this document for their development efforts.

q

q

To provide clarity, requirements from EMV may be restated in the various volumes and, where necessary, information is replicated in the three volumes to provide comprehensive information. Each volume includes a list of acronyms, a glossary, and an index.

1.4.2 Chapter Overview
This guide is organized according to the functions that occur during VSDC transaction flow and is divided into the following sections: Chapter 1, About This Specification—This chapter provides an overview of the VIS specification, VIS terminology, a summary of revisions for this version of the VIS documents, and a list of reference materials. Chapter 2, Processing Overview—This chapter provides an overview of the each function and highlights whether the function is mandatory or optional. Chapter 3, Application Selection—This function determines which of the applications, supported by both the card and terminal, will be used to conduct the transaction.

Draft 12/18/00
1–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.4 Document Structure

Chapter 4, Initiate Application Processing—During this function, the card receives any terminal data which was requested by the card during Application Selection. Chapter 5, Read Application Data—During this function, the terminal reads the data records necessary for the transaction from the card. Chapter 6, Offline Data Authentication—During this function, the terminal authenticates data from the card using RSA public key technology. Chapter 7, Processing Restrictions—During this function, application version checks, effective and expiration dates checks, and other checks are performed by the terminal at the point of transaction. Chapter 8, Cardholder Verification—During this function, the terminal determines the Cardholder Verification Method (CVM) to be used and performs the selected CVM. Chapter 9, Terminal Risk Management—During this function, the terminal ensures that higher-value transactions are sent online and that chip read transactions go online periodically. This risk management check protects against threats that might be undetectable in an offline environment. Chapter 10, Terminal Action Analysis—During this function, the terminal applies rules set by the issuer in the card and by the acquirer in the terminal to the results of offline processing. This analysis determines whether the transaction should be approved offline, declined offline, or sent online for an authorization. Chapter 11, Card Action Analysis—During this function, velocity checking and other risk management, internal to the card, is performed. Chapter 12, Online Processing—During this function, the issuer’s host computer reviews and authorizes or rejects transactions using the issuer’s host-based risk parameters. Chapter 13, Completion—During this function, the card and the terminal conclude transaction processing. Chapter 14, Issuer-to-Card Script Processing—During this function, the card applies post-issuance changes sent from the issuer. Appendix A, Data Elements—This appendix defines the data elements used in processing the VSDC application from a terminal perspective. Appendix B, Commands for Financial Transactions—This appendix outlines the commands used during transaction processing. Appendix C, General Terminal Requirements—This appendix lists the requirements for VSDC terminals, which are in addition to the requirements listed in the functional chapters.

Draft 12/18/00
31 Oct 2001
Visa Public

1–5

About This Specification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Appendix D, Terminal Requirements for Visa Low-Value Payment Feature (VLP)—This appendix describes terminal requirements for an optional source of pre-authorized spending power on the card for rapid processing of low-value payments. Appendix E, Acronyms—This appendix lists acronyms and their meanings. This document also contains a glossary and an index.

1.4.3 Subheading Overview
For ease of use, the main chapters are structured in the same manner:
q

Card Data—Provides the mandatory and optional data elements required on the card to support the function. Data element tags are listed when multiple tags are associated with a single data element name. Terminal Data—Provides the mandatory and optional data elements needed in the terminal to support the function. Data element tags are listed when multiple tags are associated with a single data element name. Commands—Provides the requirements for the commands used to support the function. Processing—Provides the technical details of the function. If there are several functions within a process, they may be listed separately. NOTE: Flowcharts are representative of processing and may not include all steps that may be performed.

q

q

q

q

Prior Related Processing—Outlines prior processing to aid in understanding previous activities related to this function. Subsequent Related Processing—Outlines subsequent processing to aid in understanding future activities related to this function.

q

1.5 Revisions to This Specification
Revisions to this specification may be required to accommodate future EMV changes, Visa payment service rules, or market needs. The impacts of these changes will be communicated in the VIS changes list or in an update to this document.

Draft 12/18/00
1–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.6 Impact Summary

1.6 Impact Summary
The following is an outline of changes and additional functionality from both a card and terminal perspective for VIS 1.4.0 (April 2001).

1.6.1 Terminal
This section includes mandatory and optional changes. The testing of terminals to support mandatory changes shall be aligned with the EMV 2000, Version 4.0, migration requirements. Refer to the EMVCo website for information on testing schedules.

1.6.1.1 Mandatory
q

If the Directory method of Application Selection fails, the terminal shall switch to the List of AIDs method. The terminal shall not allow Partial Selection during Application Selection if the terminal indicators show it is not supported for the AID. During SDA and DDA, the terminal shall save the Data Authentication Code (if present) and ICC Dynamic Number after recovery. If the SDA Tag List is one of the data elements read from the card, the terminal shall validate that the only tag it contains is the tag for the AIP. ATMs supporting Offline PIN shall support CVM List processing.

q

q

q

q

1.6.1.2 Optional
q

Visa Operating Regulations may permit the terminal to eliminate certain common applications from consideration during Application Selection. The EMV Combined DDA/Generate AC option is included as a terminal option. The public key encipherment used in the Offline Enciphered PIN processing may occur either in the PIN pad or in the card reader. Secure transfer of the PIN from the PIN pad to the card reader is required. Terminal support for Visa Low-value Payment feature of VSDC.

q

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

1–7

About This Specification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.6.2 Card
This section includes mandatory and optional changes. Contact the CAA for information on testing schedules. Changes are backward compatible and cards tested under versions 1.3.1 and 1.3.2 will continue to work in the new devices.

1.6.2.1 Mandatory
q

If a card is personalized with an SDA Tag List, the only tag in the list must be “82”, the tag for the Application Interchange Profile. Prior to adding this requirement to EMV a survey was conducted to determine if the SDA tag list was being used. The results indicated that it was not in use and that the requirement could be added to EMV. To ensure interoperability and backward compatibility, cards should begin compliance immediately. An SDA tag list that does not comply will result in Offline Data Authentication failure in EMV 4.0 terminals. Support of Cardholder Verification must be indicated in the Application Interchange Profile, and a CVM List is required. Cumulative amounts are no longer incremented for offline declines. The Online Authorization Indicator is no longer reset after offline approval.

q

q

q

1.6.2.2 Optional
q

The Issuer Public Key length may equal that of the corresponding Visa CA Public Key. The ICC Public Key length may equal that of the corresponding Issuer Public Key. The EMV Combined DDA/Generate AC option is included as a VSDC card option. The EMV optional session key generation method is referenced as a VIS option. A new cryptogram generation method, Cryptogram Version 14, is referenced as a VIS option. NOTE: Cryptogram Version 14 is not currently supported in VisaNet systems and Issuers wishing to implement this option must be aware that they will not be eligible for VisaNet Authentication Services.

q

q

q

q

Draft 12/18/00
1–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.6 Impact Summary

q

The Online Authorization indicator is optional in the card unless Issuer Authentication or Issuer Script processing is supported. The Visa Low-value Payment feature of VSDC has been added. A Cumulative Total Transaction Amount Upper Limit has been added. An Application Default Action bit has been added to allow issuers to send transactions online if issuer script processing failed on a previous transaction. An Application Default Action bit has been added to allow issuers to decline transactions and block the application if the PIN Try Limit was exceeded on a previous transaction.

q

q

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

1–9

About This Specification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.7 Reference Materials
The following documents contain additional information on Visa Smart Debit and Visa Smart Credit. The websites for obtaining these documents or information on obtaining them are listed below. For additional information, contact your Visa member representative.

1.7.1 International Organisation for Standardisation (ISO) Documents
Information on ordering these documents is available on http://www.iso.ch
q

ISO 639:1988. Codes for the Representation of Names and Languages. ISO 3166:1997. Codes for the Representation of Names of Countries. ISO 4217:1995. Codes for the Representation of Currencies and Funds. ISO/IEC 7810:1995. Identification Cards—Physical Characteristics. ISO/IEC 7811:1995. Identification Cards—Recording Technique. ISO/IEC 7812:1994. Identification Cards—Identification of Issuers. ISO/IEC 7813:1995. Identification Cards—Financial Transaction Cards ISO/IEC 7816-4:1995. Identification Cards—Integrated Circuit Cards with Contacts—Part 4: Interindustry Commands for Interchange. ISO/IEC 7816-5:1994. Identification Cards—Integrated Circuit Cards with Contacts—Part 5: Numbering System and Registration Procedure for Application Identifiers. ISO 8583:1987. Bank Card Originated Messages—Interchange Message Specifications—Content for Financial Transactions. ISO 8583:1993. Financial Transaction Card Originated Messages—Interchange Message Specifications. ISO 8859:1987. Information Processing—8-bit Single-Byte Coded Graphic Character Sets. ISO 9564:1991. Banking—Personal Identification Number Management and Security.

q

q

q

q

q

q

q

q

q

q

q

q

Draft 12/18/00
1–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.7 Reference Materials

1.7.2 EMV Documents
Available on the EMVCo Website: http://www.emvco.com/specifications.cfm
q

EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, Book 1, Application Independent ICC to Terminal Interface Requirements, December, 2000. EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, Book 2, Security and Key Management, December, 2000. EMV 2000 Integrated Circuit Card Specifications for Payment Systems, Version 4.0, Book 3, Application Specification, December, 2000. EMV 2000 Integrated Circuit Card Specifications for Payment Systems, Version 4.0, Book 4, Cardholder, Attendant and Acquirer Interface Requirements, December, 2000.

q

q

q

1.7.3 Visa Documents
Available on the Visa website: http://wwws2.visa.com/nt/chip/visdownload.html
q

Visa Integrated Card Specification (Application Overview, Card Specification, and Terminal Specification) (VIS - versions 1.3.2 and 1.4.0) VIS Corrections and Updates

q

Available on the Visa website: http://visa.com/nt/suppliers/vendor
q

Chip Card Products: Submission Requirements—Describes Visa International requirements for approval of new and upgraded chip card products. Visa supports and recognizes approvals by EMVCo, LLC for EMV level 1 (Interface Module) and EMV level 2 (device application). EMVCo is the owner of the EMV Integrated Circuit Card Specifications for Payment Systems. EMVCo specifications, type approval administrative documentation, test requirements and test cases for EMV levels 1 and 2 may be obtained through the EMVCo website www.emvco.com.

q

Chip Card Products: Testing and Approval Requirements—Describes Visa International requirements for approval of new and upgraded chip card products. It summarized Visa’s present testing services, policies, and pricing.

Draft 12/18/00
31 Oct 2001
Visa Public

1–11

About This Specification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

q

Common Personalization—A guide to a common approach to personalization of all applications. NOTE: This guide is the final authority for non-application specific requirements.

Available on Visa InSite Global Products eLibrary: (http://insite/global/Consumer Platform Search/content) or through a regional representative:
q

Certificate Authority User’s Guide—Visa Smart Debit and Visa Smart Credit, Visa Cash—Information and procedures related to the Visa Certificate Authority including Visa Certificate Authority Public Keys and Issuer Public Key Certificates. Common Personalization for Visa Smart Debit and Credit (VSDC)—A guide to personalization of VSDC Applications using the Common Personalization Approach. NOTE: The Visa Smart Debit and Visa Smart Credit Personalization Templates have been added to this document.

q

q

Visa Smart Debit and Visa Smart Credit Certification Authority Key Revocation Visa Policies and Procedures—The Visa-specific policies and procedures related to key revocation. Visa Smart Debit and Visa Smart Credit Member Implementation Guide for Acquirers—Describes best practices, suggestions, considerations, and step-by-step activities to assist with implementation for VSDC Acquirers. Visa Smart Debit and Visa Smart Credit Member Implementation Guide for Issuers—Describes best practices, suggestions, considerations, and step-by-step activities to assist with implementation for VSDC Acquirers. Visa Smart Debit and Visa Smart Credit Planning Guide—A reference guide and roadmap for Acquirers and Issuers implementing Visa Smart Debit or Visa Smart Credit programs. It describes the components and decisions necessary for program implementation and focuses on what is new and different about implementing a Visa Smart Debit or Visa Smart Credit program. VSDC Service Activation Guide (SAG)—Describes planning considerations, business aspects, technical aspects and other regional tasks associated with completing a member implementation of VSCD. Visa Smart Debit/Visa Smart Credit Service Description—A document focusing on the features and benefits of the service.

q

q

q

q

q

Draft 12/18/00
1–12
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

1.7 Reference Materials

Available on Visa InSite or through a Visa regional representative: http://insite/ref/docs
q

Card Acceptance Device Reference Guide: Requirements and Best Practices Version 5.0—Provides vendors with insight towards designing their card acceptance devices to meet current and future industry and Visa scheme specific requirements and best practices. Visa Certification Management Service (VCMS) Testing and Certification Guide-VIP System, Member Version—A guide for the VIP System component of the VisaNet Certification Management System. Visa Certification Management Service (VCMS) User’s Manual-BASE II System—A guide for the BASE II System component of the VisaNet Certification Management System. VisaNet Card Technology Standards Manual—The standards applied to PINs, PIN-related security, and the management of cryptographic keys as well as the guidelines for encoding account and cardholder data on Track 1 and Track 2 of the magnetic stripe of a Visa card.

q

q

q

Available on Visa InSite or through a Visa regional representative: http://insite/dept/buspubs1/library/vsmart/techlet.pdf
q

Visa Smart Debit and Visa Smart Credit System Technical Manual—A document that describes the changes to VisaNet to support VSDC.

Available on Visa InSite or through a Visa regional representative: http://insite/dynaweb/opregs
q

Visa International Operating Regulations—Specifies standards all Members must meet to operate and participate in Visa Payment Services (Volumes I-IV).

Available through Visa regional representative:
q

Visa Smart Debit/Credit Certificate Authority Internal Procedures—Describes guidelines for enrolling the Visa Certificate Authority and is intended for use by Regional staff supporting VSDC. Visa Smart Payment Operating Principles Guide—Board-approved payment service principles for Visa Smart Debit and Visa Smart Credit.

q

Available by request to the VSDC Hotline:
q

Visa Smart Debit/Visa Smart Credit Early & Full Data Options for Host Systems—Provide Member center managers with an overview of the Early and Full options for their host systems.

Draft 12/18/00
31 Oct 2001
Visa Public

1–13

Processing Overview

2

This chapter provides an overview of a Visa Smart Debit and Visa Smart Credit (VSDC) transaction. This is followed by a transaction flow showing the order in which these functions may be performed and the commands sent by the terminal to the card for communications. Charts at the end of the chapter show functional and command support requirements for cards and terminals. Regions may have additional restrictions and requirements.

2.1 Functional Overview
The following functions are used in VSDC transaction processing. Functions marked as mandatory are performed for all transactions. Some steps within these mandatory functions may be optional. Functions not marked mandatory are optional and are performed based upon parameters in the card or terminal, or both.

2.1.1 Application Selection (mandatory)
When a VSDC card is presented to a terminal, the terminal determines which applications are supported by both the card and terminal. The terminal displays all mutually supported applications to the cardholder, and the cardholder selects the application to be used for payment. If these applications cannot be displayed, the terminal selects the highest priority application as designated by the issuer during card personalization.

Draft 12/18/00
31 Oct 2001
Visa Public

2–1

Processing Overview

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

2.1.2 Initiate Application Processing/Read Application Data (mandatory)
If a VSDC application is selected, the terminal requests that the card indicate the data to be used for that application and the functions supported. The card may indicate different data or different support functions based upon characteristics of the transaction such as being domestic or international. The terminal reads the data indicated by the card and uses the supported function list to determine the processing to perform.

2.1.3 Offline Data Authentication
The terminal determines whether it should authenticate the card offline using either offline static or dynamic data authentication based upon the card and terminal support for these methods. Offline Static Data Authentication (SDA) validates that important application data has not been fraudulently altered since card personalization. The terminal validates static (unchanging) data from the card using the card’s Issuer Public Key, which is stored on the card inside a public key certificate and a digital signature, which contains a hash of important application data encrypted with the Issuer Private Key. A match of the recovered hash with a generated hash of the actual application data proves that the data has not been altered. Offline Dynamic Data Authentication (DDA) validates that the card data has not been fraudulently altered and that the card is genuine. DDA has two forms: Standard DDA and Combined DDA/Generate AC. In both forms, the terminal verifies the card static data in a similar manner to SDA. With Standard DDA, the terminal requests that the card generate a cryptogram using dynamic (transaction unique) data from the card and terminal and an ICC Private Key. The terminal decrypts this dynamic signature using the ICC Public Key recovered from card data. A match of the recovered data to the original data verifies that the card is not a counterfeit card created with data skimmed (copied) from a legitimate card. With Combined DDA/Generate AC, the generation of the dynamic signature is combined with the generation of the card’s Application Cryptogram during Card Action Analysis to assure that the Application Cryptogram came from the valid card.

Draft 12/18/00
2–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

2.1 Functional Overview

2.1.4 Processing Restrictions (mandatory)
The terminal performs Processing Restrictions to see whether the transaction should be allowed. The terminal checks whether the effective date for the card has been reached, whether the card is expired, whether the application versions of the card and terminal match, and whether any Application Usage Control restrictions are in effect. An issuer may use Application Usage Controls to restrict a card’s use for domestic or international, cash, goods, services, or cashback.

2.1.5 Cardholder Verification (mandatory)
Cardholder verification may be used to ensure that the cardholder is legitimate and the card is not lost or stolen. The terminal uses a Card Verification Method (CVM) List from the card to determine the type of verification to be performed. The CVM List establishes a priority of cardholder verification methods, which consider the capabilities of the terminal and characteristics of the transaction to prompt the cardholder for a specific cardholder verification method. If the CVM is offline PIN, the terminal prompts the cardholder for a PIN and transmits the cardholder-entered PIN to the card, which compares it to a Reference PIN stored secretly in the card. The CVM List may also specify online PIN, signature, or no cardholder verification required. The terminal may use a default CVM as defined by Visa International Operating Regulations if the card does not support CVM processing, no CVM list is present or the last CVM processed in the card list is no CVM required.

2.1.6 Terminal Risk Management (mandatory)
Terminal Risk Management checks whether the transaction is over the merchant floor limit, the account number is on an optional terminal exception file, the limit for consecutive offline transactions has been exceeded, the card is a new card, or the merchant has forced the transaction online. Some transactions are randomly selected for online processing. Terminal Risk Management also includes optional velocity checking by the terminal using data elements from the card. The card data elements used are those defined by EMV. Terminal velocity checking results are considered during Terminal Action Analysis. Visa recommends support for velocity checking by the card and the data elements used card velocity checks are defined by Visa. Card velocity checking results are considered during Card Action Analysis.

Draft 12/18/00
31 Oct 2001
Visa Public

2–3

Processing Overview

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

2.1.7 Terminal Action Analysis (mandatory)
Terminal Action Analysis uses the results of Offline Data Authentication, Processing Restrictions, Terminal Risk Management, and Cardholder Verification and rules set in the card and terminal to determine whether the transaction should be approved offline, sent online for authorization, or declined offline. The card rules are set in fields called Issuer Action Codes (IACs) sent to the terminal by the card and the terminal rules are in Terminal Action Codes (TACs). After determining the transaction disposition, the terminal requests an application cryptogram from the card. The type of application cryptogram is based upon the transaction disposition with a Transaction Certificate (TC) for an approval, an Authorization Request Cryptogram (ARQC) for online, and an Application Authentication Cryptogram (AAC) for a decline. The terminal includes an indicator in the request message to the card if Combined DDA/AC Generation is to be performed and the card has not requested Terminal Capabilities data from the terminal.

2.1.8 Card Action Analysis (mandatory)
Upon receiving the application cryptogram request from the terminal, the card performs Card Action Analysis where Card Risk Management checks may be performed to determine whether to change the transaction disposition set by the terminal. These may include checks for prior incomplete online transactions, failure of Issuer Authentication or offline data authentication failure on a previous transaction, and count or amount velocity checking limits being reached. The card may convert a terminal request for an offline approval to an online transaction or an offline decline, and the card may convert an online request to an offline decline. After completion of the checks, the card generates the application cryptogram using application data and a secret DES key stored on the card. It returns this cryptogram to the terminal. For offline approved transactions, the TC and the data used to generate it are transmitted in the clearing message for future cardholder disputes, or chargeback purposes, or both. The TC may be used as a ‘proof ’ of transaction when a cardholder disputes a transaction and to verify that the transaction data has not been changed by the merchant or acquirer. For offline declined transactions, the cryptogram type is an AAC.

2.1.9 Online Processing
If the card and terminal determine that the transaction requires an online authorization, the terminal transmits an online authorization message to the issuer if the terminal has online capability. This message includes the ARQC cryptogram, the data used to generate the ARQC, and indicators showing offline processing results. During online processing, the issuer validates the

Draft 12/18/00
2–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

2.1 Functional Overview

ARQC to authenticate the card in a process called Online Card Authentication (CAM). The issuer may consider these CAM results and the offline processing results in its authorization decision. The authorization response message transmitted back to the terminal may include an issuer-generated Authorization Response Cryptogram (ARPC) (generated from the ARQC, the Authorization Response Code, and the card’s secret DES key). The response may also include post-issuance updates to the card called Issuer Scripts. If the authorization response contains an ARPC and the card supports Issuer Authentication, the card performs Issuer Authentication by validating the ARPC to verify that the response came from the genuine issuer (or its agent). Successful Issuer Authentication may be required for resetting certain security-related parameters in the card. This prevents criminals from circumventing the card’s security features by simulating online processing and fraudulently approving a transaction to reset counters and indicators. If Issuer Authentication fails, subsequent transactions for the card will be sent online for authorization until Issuer Authentication is successful.

2.1.10 Issuer-to-Card Script Processing
If the issuer includes script updates in the authorization response message, the terminal passes the script commands to the card. Prior to applying the updates, the card performs security checking to assure that the script came from the valid issuer and was not altered in transit. Supported script commands allow updating offline processing parameters, blocking and unblocking the application, blocking the card, resetting the Offline PIN Try Counter, and changing the Offline PIN value.

2.1.11 Completion (mandatory)
The card and terminal perform final processing to complete the transaction. An issuer-approved transaction may be converted to a decline based upon Issuer Authentication results and issuer-encoded parameters in the card. The card uses the transaction disposition, Issuer Authentication results, and issuer-encoded rules to determine whether to reset card-based counters and indicators. The card generates a TC for approved transactions and an AAC for declined transactions. If the terminal transmits a clearing message subsequent to an authorization message, the TC is transmitted in the clearing message. With single message systems or systems involving acquirer host data capture of approved transactions, the terminal must generate a reversal for issuer-approved transactions which are subsequently declined by the card.

Draft 12/18/00
31 Oct 2001
Visa Public

2–5

Processing Overview

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 2–1:

Sample Transaction Flow
KEY

Card SELECT Command/Response READ RECORD Command/Response GET PROCESSING OPTIONS Command/Response

Terminal

Mandatory process

List of Supported Applications

Application Selection

Mandatory process w/ optional steps

Supported Functions & Pointers to Application Data

Initiate Application Processing

Optional process

Provide Application Records

READ RECORD Commands/Responses

Read Application Data

1 - If DDA 2 - If Offline Enciphered PIN 3 - Optional for Offline PIN 4 - If Offline PIN

Generate Dynamic Cryptogram

INTERNAL AUTHENTICATE Command/Response

1

Offline Data Authentication SDA or DDA

Processing Restrictions Generate Unpred. Number PIN Try Counter Validate PIN Last Online Application Transaction Counter (ATC) Register

GET CHALLENGE Command/Response GET DATA Command/Response VERIFY Command/Response
4 3

2

Cardholder Verification

GET DATA Command/Response

Terminal Risk Management

GENERATE APPLICATION CRYPTOGRAM Command Perform Card Action Analysis & generate Application Cryptogram

Terminal Action Analysis

GENERATE APPLICATION CRYPTOGRAM Response

Online Transaction?

Y Online Processing N Validate ARPC Cryptogram EXTERNAL AUTHENTICATE Command/Response Issuer Authentication

Perform final checks & generate final cryptogram

GENERATE APPLICATION CRYPTOGRAM Command/Response

Completion

Apply Script

Issuer-to-Card Script Commands/Responses

Issuer-to-Card Script Processing

Draft 12/18/00
2–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

2.2 Terminal Mandatory and Optional Functionality

2.2 Terminal Mandatory and Optional Functionality
VSDC terminals are required to support the following mandatory functions. Optional functions may be supported at the merchant or acquirer’s discretion or may be required by market, regional, or Visa operating regulations. Support for conditional functions is required if the associated condition is true. Terminal functional requirements are shown in Table 2–1.
Table 2–1: Terminal Functional Requirements (1 of 2)

Function
Application Selection
q

Terminal Support
Mandatory Optional (EMV) Mandatory (EMV) Not used for financial interchange (EMV) Mandatory (EMV) Conditional—If offline capable (EMV) Conditional—If offline capable terminal (EMV) of if DDA supported (EMV) Optional (EMV) Conditional—If Combined DDA/AC Generation supported (VIS) (VIS recommends Standard DDA for offline capable terminals)

Directory Method Explicit Selection Method Implicit Selection Method

q

q

Initiate Application Processing Offline Data Authentication
q

SDA Standard DDA

q

q

Combined DDA/AC Generation

Optional (EMV) Mandatory (EMV) Mandatory (EMV) Mandatory (EMV) Mandatory (EMV) Mandatory (EMV) Mandatory (EMV) with Operating Regulation exceptions (VIS) Mandatory (EMV) Mandatory (EMV) Optional (EMV) Conditional with Operating Regulation exceptions (VIS)

Processing Restrictions
q

Application Version Number Application Usage Control Effective Date Checking Expiration Date Checking

q

q

q

Cardholder Verification
q

No CVM Required Fail CVM Processing Other CVMs (Offline PIN, Online PIN, signature, etc.)

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

2–7

Processing Overview

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table 2–1:

Terminal Functional Requirements (2 of 2)

Function
Terminal Risk Management

Terminal Support
Conditional—If merchant controlled terminal (EMV) Some functions do not apply for online-only or offline-only terminals (EMV)

q

Terminal Exception File Merchant Force Online Floor Limits Transaction Log Random Selection Velocity Checking New Card

Optional (EMV) Optional (EMV) Mandatory (EMV) Optional (EMV) Conditional—If both online & offline capable (EMV) Conditional—If offline capable (EMV) Mandatory—(EMV) Mandatory (EMV) n/a (card function)

q

q

q

q

q

q

Terminal Action Analysis Card Action Analysis Online Processing
q

Online Capability Advice Messages Issuer Authentication

Optional (EMV and VIS) Optional (EMV and VIS) Conditional—If online capable Mandatory

q

q

Completion Miscellaneous Functions
q

Cardholder amount validation Voice Referrals Card initiated referrals Merchant forced acceptance Chip card informational advices Prompt for chip read

Recommended (EMV) Recommended Not supported (VIS) Optional (EMV) Optional (EMV) Conditional—At discretion of country or region (VIS) Mandatory (EMV)

q

q

q

q

q

Draft 12/18/00
2–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

2.2 Terminal Mandatory and Optional Functionality

2.2.1 Command Support Requirements
Terminal support for the VSDC commands is shown in Table 2–2.
Table 2–2:
Command
EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM (AC) GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE READ RECORD Issuer Script Commands
q

Command Support Requirements
Terminal Support
Conditional—If online-capable (EMV) Mandatory (EMV)

Conditional—If Offline Enciphered PIN supported (EMV) Conditional—If ATM or merchant controlled device (EMV) Mandatory (EMV) Conditional—If DDA supported (EMV) Mandatory (EMV) If sent from the Issuer, terminal must parse the script into commands and send them to the card one at a time. The terminal has no knowledge of what command is being sent. (EMV)

APPLICATION BLOCK (EMV) APPLICATION UNBLOCK (EMV) CARD BLOCK (EMV) PUT DATA (VIS) UPDATE RECORD (VIS) PIN CHANGE/UNBLOCK (EMV)

q

q

q

q

q

SELECT VERIFY

Mandatory (EMV) Conditional—If Offline PIN supported (EMV)

Draft 12/18/00
31 Oct 2001
Visa Public

2–9

Application Selection

3

Application Selection is the process of determining which of the applications that are supported by both the card and terminal will be used to conduct the transaction. This process takes place in two steps: 1. 2. The terminal builds a candidate list of mutually supported applications. A single application from this list is identified and selected to process the transaction.

Application Selection shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 1, Section 8, and Book 4, Section 7. This chapter is organized into the following sections: 3.1 Card Data 3.2 Terminal Data 3.3 Commands 3.4 Building the Candidate List 3.5 Identifying and Selecting the Application 3.6 Flow 3.7 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

3–1

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.1 Card Data
The card data elements used in Application Selection are listed and described in Table 3–1. For a detailed description of these data elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 3–1: Application Selection—Card Data (1 of 2)

Data Element
Application Definition File (ADF)

Description
The ADF is a file, which is the entry point to application elementary files (AEF), which contain data elements for the application. The ADF may contain information about the application such as language preference and application priority. It may also contain a Processing Options Data Objects List (PDOL) of terminal data elements requested by the card for processing. AEF contains data elements used by the application in processing.

Application Elementary Files (AEF) Application Identifier (AID)

The AID is composed of the Registered Application Provider Identifier (RID) and the Proprietary Application Identifier Extension (PIX). It identifies the application as described in ISO/IEC 7816-5. All Visa AIDs shall begin with a RID expressed as hexadecimal A000000003. The Visa RID is concatenated with a Visa assigned PIX to identify the application.
q

1010—Visa Debit and Visa Credit 2010—Visa Electron 3010—Interlink 8010—Plus 999910—Proprietary ATM applications

q

q

q

q

The card AID shall have a suffix if more than one Visa debit or credit application is present on a single card. For example, a card with both a Visa credit and a Visa debit application might use the suffix as follows: Example: A000000003101001—first Visa application (for Visa Credit) A000000003101002—second Visa application (for Visa Debit) Application Label Mnemonic associated with AID according to ISO/IEC 7816-5. Used in application selection. Application Label is required in the File Control Information (FCI) of an Application Definition File (ADF) and mandatory in an ADF directory entry. It will become mandatory in the ADF according to the EMVCo migration plan.

Draft 12/18/00
3–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table 3–1: Application Selection—Card Data (2 of 2)

3.1 Card Data

Data Element
Application Preferred Name

Description
Mnemonic associated with AID. If the Application Preferred Name is present and the Issuer Code Table Index entry is supported by the terminal, the Application Preferred Name rather than the Application Label is displayed to the cardholder during Application Selection. Indicates the priority of a given application or group of applications in a directory. The DDF file is a file, which defines the directory structure beneath it. The FCI for a DDF contains a pointer to a Directory File. A directory file is a file listing DDFs and ADFs contained within the directory. It is accessed by the READ RECORD command. For detailed information on directory files, refer to the EMV 4.0, Book 1, Section 8.

Application Priority Indicator Directory Definition File (DDF)

Directory File

File Control Information (FCI)

The FCI is provided in response to the SELECT command. This information varies depending on the type of file selected. Indicates the code table (character set) support, according to International Organisation for Standardisation (ISO) 8859, required in the terminal to display the Application Preferred Name. The PSE begins with a DDF given the name “1PAY.SYS.DDF01”. The directory file associated with this DDF is known as the Payment Systems Directory. The PDOL is a list of tags and lengths for terminal-resident data objects requested by the card and provided by the terminal in the GET PROCESSING OPTIONS command during Initiate Application Processing. The SFI is a pointer to elementary files (EF).
q

Issuer Code Table Index

Payment Systems Environment (PSE) Processing Options Data Objects List (PDOL)

Short File Identifier (SFI)

1–10 Reserved for EMV 11–20 Payment system specific 21–30 Issuer specific

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

3–3

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.2 Terminal Data
The terminal data elements used in Application Selection are listed and described in Table 3–2. For a detailed description of these data elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 3–2: Application Selection—Terminal Data

Data Element
Application Identifier (AID)

Description
The AID, tag “9F06” in the terminal, is composed of the Registered Application Provider Identifier (RID), and the Proprietary Application Identifier Extension (PIX). It identifies the application as described in ISO/IEC 7816-5. All Visa AIDs shall begin with a RID expressed as hexadecimal A000000003. The Visa RID is concatenated with a Visa-assigned PIX to identify the application.
q

1010—Visa Debit and Visa Credit 2010—Visa Electron 3010—Interlink 8010—Plus 999910—Proprietary ATM applications

q

q

q

q

Application Selection Indicator

Indicates whether the associated AID in the terminal must match the AID in the card exactly including the length of the AID (Partial Selection is not supported), or only up to the length of the AID in the terminal (Partial Selection is supported). There is only one Application Selection Indicator per AID in the terminal and its format is at the discretion of the terminal vendor. Application Selection Indicators for Visa AIDs must indicate support for Partial Selection.

List of supported applications

The terminal shall maintain a list of applications supported by the terminal and their respective AIDs. The name of the PSE (1PAY.SYS.DDF01) is used in Application Selection if the terminal supports directory selection.

PSE File Name

Draft 12/18/00
3–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.3 Commands

3.3 Commands
SELECT The SELECT command shall be performed as described in the EMV 4.0, Book 1, Section 7.3. The terminal sends the SELECT command to the card to obtain information from the card on which applications are supported by the card and issuer preferences such as the priority in which the application is selected, name of the application, and language preference. The command either contains the name of the Payment Systems Environment (used for the directory selection method), a DDF name or a requested AID (used for the List of the AIDs method). The P1 parameter of the SELECT command indicates whether the application is being selected by name. The P2 parameter indicates whether additional applications with the same AID are being requested in support of AID suffixes (where multiple applications with the same AID are supported by the card). The command response may have the following SW1 SW2 return codes:
q

9000—Successful return from SELECT 6A81—Card is blocked or command not supported 6A82—Selected file not found – – PSE not found (Directory Selection Method not supported by the card) Last file when P2 parameter specified additional applications with the same AID (command contains AID)

q

q

q

6283—Application is blocked

The card’s response includes the PDOL, if present on the card. The PDOL will be used during Initiate Application Processing. READ RECORD The READ RECORD command shall be performed as described in the EMV 4.0, Book 1, Section 7.2. In the Directory Selection Method, the terminal reads the directory, an Elementary File associated with the PSE, which lists all of the EMV payment applications on the card and the card returns the requested record in the response. The command includes the Short File Identifier (SFI) of the file to be read and the record number of the record within the file.

Draft 12/18/00
31 Oct 2001
Visa Public

3–5

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.4 Building the Candidate List
Two approaches are used by the terminal to build a list of mutually supported applications: 1. Directory Selection Method—Optional for cards and terminals, but if supported by the terminal, it is attempted first. In the Directory Selection Method, the terminal reads a directory (associated with the PSE) from the card. This directory is a list of the applications supported by the card. The terminal adds any applications listed both in the card list and in the terminal list on the candidate list. List of AIDs Method—Mandatory for cards and terminals. In List of AIDs Method, the terminal issues a SELECT command for each terminal-supported application. If the card response indicates that the application is supported by the card, the terminal adds the application to the candidate list.

2.

NOTE: Terminals shall include all common applications in the final candidate list except in certain conditions specified in Visa Operating Principles and Regulations. In either of the approaches described above, the terminal must check the Application Selection Indicator to determine which of the matching criteria are to be used for this application:
q

Option 1—The AID from the card must exactly match the AID from the terminal including the length (Partial Selection is not supported). Option 2—The AID from the card must exactly match the AID only up to the length of the AID in the terminal and may be longer (Partial Selection is supported).

q

The Application Selection Indicator for Visa AIDs shall indicate Option 2. Table 3–3 shows AIDs that would not match for Option 1, but are considered matches for Option 2.
Table 3–3: Application Selection Indicator Matching Criteria

Terminal AID
A0000000031010 A0000000031010

Card AID
A000000003101001 A000000003101002

Match Option 1
N N

Match Option 2
Y Y

Note: The suffixes “01” and “02” make the AIDs unique. They are simply labels and need not be in order.

Draft 12/18/00
3–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.4 Building the Candidate List

3.4.1 Directory Selection Method
Directory Selection Method processing includes the following steps: 1. 2. The terminal selects the PSE, which is a special DDF, using the SELECT command. The name of the PSE file is 1PAY.SYS.DDF01. If the card responds with any code other than “9000” or “6A81”, the terminal attempts to build the candidate list using the List of AIDs Method. If the card responds with SW1 SW2 “6181”, the session is terminated. If the PSE is found and the card responds to the terminal with SW1 SW2 = “9000”, the FCI for the PSE is included in the response to SELECT. The FCI contains an SFI for the Payment Systems Directory. Each record in this directory lists an application (or another directory containing applications). The terminal reads the Payment Systems Directory using the SFI for the Payment Systems Directory to identify the file to be read. The terminal uses the READ RECORD command to read each record in the Payment Systems Directory until the card responds that there are no more records (SW1 SW2 = “6A83”). If the candidate list is empty and there are no more records, the terminal attempts to build the candidate list using the List of AIDs Method. 6. Records are comprised of entries, which may be directories (DDFs) or applications (ADFs). The terminal processes each entry in the record in the order in which they occur. If the entry in the record is an ADF, the terminal compares the AID in that record to the AIDs supported by the terminal. If they match the terminal adds the card AID to the candidate list. If the entry in the record is a DDF, the terminal selects the DDF using the SELECT command with the DDF name to obtain the SFI for the directory file for that DDF. The terminal reads and processes the records in that directory file until there are no more entries (card responds with SW1 SW2 = “6A83”). The terminal then reads the next record in the Payment Systems Directory as described in Step 5.

3. 4.

5.

7.

Draft 12/18/00
31 Oct 2001
Visa Public

3–7

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

In the example in Figure 3–1, the terminal: 1. 2. 3. 4. 5. 6. 7. 8. 9. Reads Record 1 from the Payment Systems Directory. Checks to see if either of the AIDs for the ADF Entry 1 or 2 match terminal AIDs. Reads Record 2 from the Payment Systems Directory. Selects the DDF directory indicated in Entry 1 of Record 2. Reads Record 1 from the DDF Directory. Checks to see if either of the AIDs for the ADF Entry 1 or 2 match terminal AIDs. If they match, it is added to the candidate list. Returns to processing entries and records from the previous directory, when card responds that there are no more records in the directory. Checks to see if Entry 2, Record 2 from the Payment System Directory matches a terminal AID. If they match, it is added to the candidate list. Completes the candidate list when the card responds that there are no more records in the Payment Systems Directory. If the candidate list is empty, terminal attempts List of AIDs method.

Figure 3–1:

Directory Selection Method Example
Payment Systems Directory

PSE

Record 1

Record 2

Entry 1 ADF

Entry 2 ADF

Entry 1 DDF

Entry 2 ADF

DDF

DDF Directory

Record 1

Entry 1 ADF

Entry 2 ADF

Draft 12/18/00
3–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.4 Building the Candidate List

3.4.2 List of AIDs Method
List of AIDs Method processing includes the following steps: 1. 2. The terminal retrieves the AID of an application from a list of applications supported by the terminal. The terminal attempts to select the application using the SELECT command. The AID of the application to be selected is sent to the card in the SELECT command. If the card AID matches the terminal AID, the card responds to the SELECT command, indicating that the application is supported by the card (SW1 SW2 = “9000”). If the card does not find a matching AID, the card responds with SW1 SW2 = “6A82”, indicating that the application was not found. If the card responds that the application is supported (SW1 SW2 = “9000”), the terminal adds the application to the candidate list. The AID (DF Name) returned by the card may be longer than the AID used by the terminal to select the application. When this occurs, the AID returned by the card is placed in the candidate list. If the DF Name returned by the card is longer, the terminal selects the next application of the same name by indicating next occurrence in P2 and adds it to the candidate list until the card indicates in its response (SW1 SW2 = “6A82”) that all matching applications have been selected.

3.

4.

5.

Figure 3–4 shows sample matching AIDs.
Table 3–4: Sample AIDs Matching

Terminal AID
A0000000031010 A0000000031010

Terminal Application
Visa Visa

Card AID
A000000003101001 A000000003101002

Card Application
Visa Credit Visa Credit

The SELECT command is used with the terminal AID and parameter P2 set to “02” to indicate that the card should provide the next application with the same terminal AID. Steps 1–5 are repeated until the terminal has attempted to select all of the applications it supports.

Draft 12/18/00
31 Oct 2001
Visa Public

3–9

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.5 Identifying and Selecting the Application
If there are no mutually supported applications, the transaction is terminated. If there is at least one mutually supported application, the processing is as follows.

3.5.1 Terminal Makes Application Selection Decision
A terminal that does not support cardholder selection or confirmation shall issue a SELECT command to the highest priority application, indicated by the Application Priority Indicator on the card, which does not require confirmation. If more than one application has the highest priority, the terminal may issue a SELECT command for either application. If the Directory Selection Method was used to build the list of applications, the card may respond to the SELECT command with SW1 SW2 other than “9000”, indicating that the transaction cannot be performed with the selected application. If this occurs, and there are more available applications on the list of available applications, the terminal should issue a SELECT command to the application with the next highest priority.

3.5.2 Cardholder Makes Account Selection Decision
3.5.2.1 Terminal Supports Cardholder Confirmation
A terminal that does not support cardholder selection from a list of displayed accounts, but supports cardholder confirmation of an account, shall request cardholder confirmation for the highest priority application as indicated by the Application Priority Indicator on the card. If more than one application has the same priority, the terminal may process in the order encountered or choose one of the applications. If the cardholder confirms the choice, the terminal uses the SELECT command to select the application. If the cardholder does not confirm, the terminal offers the next highest priority application until the cardholder confirms or there are no more available applications. If the Directory Selection Method was used to build the list of applications, the card may respond to the SELECT command with SW1 SW2 other than “9000”, indicating that the transaction cannot be performed with the selected application. If this occurs, and there are more available applications on the list, the terminal should remove the rejected application from the list of available applications and request confirmation of the next available application.

Draft 12/18/00
3–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.5 Identifying and Selecting the Application

3.5.2.2 Terminal Supports Cardholder Selection
A terminal that supports cardholder selection shall present a list of applications in priority order to the cardholder for selection. If more than one application has the same priority, the terminal may display them to the cardholder in the order encountered or decide the order. The cardholder selects the application from the list and the terminal uses the SELECT command to select the application. If the Directory Selection Method was used to build the list of applications, the card’s response to the SELECT command may indicate that the application is blocked. If this occurs, and there are more available applications on the list, the terminal should display “Try Again” and display the list of available applications excluding the rejected application. If the cardholder does not select an application, the terminal terminates the transaction.

Draft 12/18/00
31 Oct 2001
Visa Public

3–11

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.6 Flow
Figure 3–2: Application Selection Processing Flow (1 of 3)

Card

Application Selection - Directory Selection Method

Terminal

Terminal supports PSE Card responds with FCI and “9000” if (card not blocked and PSE found and not blocked) or (card not blocked and DDF found) B Y Terminal clears the candidate list and issues SELECT with DFNAME = 1PAY.SYS.DDF01

N

List of AIDs Method

A Y Place current directory and resumption information on directory stack

SELECT command

Y

SELECT response

Card blocked? Y Terminate transaction

N

SW1&2= 9000?

N

DDF= PSE?

Terminal issues SELECT with DFNAME of DDF

N Y C Get SFI for Directory from FCI and set record # to 1 B

Card responds with Directory Entry and “9000” if found

READ RECORD command

Terminal issues READ RECORD

READ RECORD response

Record Found?

N

Directory stack empty?

Y

Candidate List Empty?

Y N Get entry Get previous directory from list and continue processing

N
Choose Application and SELECT

A

N

ADF? Y Y Terminal supports? Y Add to candidate list N

C

Another entry in record?

N

Increment record number

C

Draft 12/18/00
3–12
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Figure 3–3: Application Selection Processing Flow (2 of 3)

3.6 Flow

Card

List of AIDs Selection Method

Terminal

Get first AID from terminal list of AIDs B Card responds with FCI or error message SELECT command Issue SELECT command with DF Name = AID.

SELECT response

Card Blocked? (SW1SW2 = 6A81) N File found for AID? (SW1SW2 NE 6A82) Y Application blocked? (SW1SW2 = 6283)? N Add Application to Candidate List

Y

Terminal terminates card session

N

Y

Name in FCI exact match?

Y

Another AID in terminal list?

N

Choose Application and SELECT

N N Name in FCI partial match? Y

Y Partial Selection supported for AID? Y Set P2 in SELECT to “02” indicating select next application with same DFNAME

N

Get next AID from terminal list of AIDs

B

B

Draft 12/18/00
31 Oct 2001
Visa Public

3–13

Application Selection

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 3–4:

Application Selection Processing Flow (3 of 3)

Card

Choose Application & SELECT

Terminal
T

B

Any mutually supported applications?

N

Terminal terminates the transaction

Terminal confirmation support?

Y

Terminal displays highest priority application on list for confirmation

Cardholder confirms?

N

Terminal supports selection?

Y

Terminal displays applications by priority and asks cardholder to select

Application selected?

N Terminal identifies highest priority application not requiring confirmation

Applications available without confirmation? N

Y

Y Y N

T

N

Card responds with FCI for requested AID and “9000” (selection successful) or “6283” (application blocked)

SELECT command

Terminal issues SELECT command with the identified application

SELECT response

Successful SELECT (“9000”)? N Terminal proceeds to Initiate Application Processing

Y

Terminal removes application from list

B

Draft 12/18/00
3–14
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.7 Subsequent Related Processing

3.7 Subsequent Related Processing
Initiate Application Processing The GET PROCESSING OPTIONS command sent to the card by the terminal includes any terminal data specified in the PDOL. If supported, the PDOL was included in the SELECT command response during Application Selection. If Geographic Restrictions do not permit the selected application to be initiated, the terminal terminates the transaction and returns to Application Selection for selection of another application.

Draft 12/18/00
31 Oct 2001
Visa Public

3–15

Initiate Application Processing

4

During Initiate Application Processing, the terminal signals to the card that transaction processing is beginning. The terminal accomplishes this by sending the GET PROCESSING OPTIONS command to the card. When issuing this command, the terminal supplies the card with any data elements requested by the card in a Processing Options Data Objects List (PDOL). The PDOL (a list of tags and lengths of data elements) is optionally provided by the card to the terminal during Application Selection. The card responds to the GET PROCESSING OPTIONS command with the Application File Locator (AFL), a list of files and records, which the terminal needs to read from the card. The card also provides the Application Interchange Profile (AIP), a list of functions to be performed in processing the transaction. Initiate Application Processing shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.1, and Book 4, Section 2.3.1. This chapter is organized into the following sections: 4.1 Card Data 4.2 Terminal Data 4.3 GET PROCESSING OPTIONS Command 4.4 Processing 4.5 Prior Related Processing 4.6 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

4–1

Initiate Application Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

4.1 Card Data
The card data elements used in Initiate Application Processing are listed and described in Table 4–1. For a detailed description of these data elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Card and Issuer Data Element Tables.
Table 4–1: Initiate Application Processing—Card Data

Data Element
File Control Information (FCI)

Description
Information such as file name and language preference provided by card in response to the SELECT command issued by the terminal. The PDOL is a list of tags and lengths for terminal-resident data objects needed by the card in processing the GET PROCESSING OPTIONS command during Initiate Application Processing (Chapter 3, Application Selection). A data element, which indicates the capability of the card to support specific functions in the application (SDA, DDA, Cardholder Verification, and Issuer Authentication). Indicates the file location and range of records, which contain card data to be read by the terminal for use in transaction processing. For each file to be read, the AFL contains the following information:
q

Processing Options Data Object List (PDOL)

Application Interchange Profile (AIP)

Application File Locator (AFL)

Byte 1—Short File Identifier (a numeric file label) Byte 2—Record number of the first record to be read Byte 3—Record number of the last record to be read Byte 4—Number of consecutive records containing data to be used in Offline Data Authentication beginning with the first record to be read as indicated in Byte 2.

q

q

q

Draft 12/18/00
4–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

4.2 Terminal Data

4.2 Terminal Data
The terminal data elements used in Initiate Application Processing are listed and described in Table 4–2. For a detailed description of these data elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 4–2: Initiate Application Processing—Terminal Data

Data Element
Terminal Country Code

Description
Terminal data indicating the country of the terminal. It is provided to the card in the GET PROCESSING OPTIONS command if requested by the card in the PDOL. A terminal data element indicating the results of offline processing from a terminal perspective. This data element is transmitted in online authorization and clearing messages. Indicates the functions performed by the terminal. This data element is not provided in the online authorization and clearing messages.

Terminal Verification Results (TVR)

Transaction Status Information (TSI)

4.3 GET PROCESSING OPTIONS Command
The GET PROCESSING OPTIONS command from the terminal signals the card that transaction processing is beginning. The command is described in the EMV 4.0, Book 3, Section 2.5.8 and Appendix B, Commands for Financial Transactions, of this volume. The data portion of the command contains the terminal data elements requested by the card in the optional PDOL. The data portion of the response contains the Application Interchange Profile (AIP) and the Application File Locator (AFL).

Draft 12/18/00
31 Oct 2001
Visa Public

4–3

Initiate Application Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

4.4 Processing
The terminal initiates application processing by sending the GET PROCESSING OPTIONS command to the card. The terminal: 1. 2. 3. 4. Extracts the PDOL (if present) from the FCI provided by the card in response to the SELECT command. Sets the Transaction Status Information (TSI) to zero. Sets the Terminal Verification Results (TVR) to zero. Sends the GET PROCESSING OPTIONS command to the card. Any data elements requested in the PDOL are passed to the card in this command. Refer to EMV 4.0, Book 3, Section 1.4, Rules for Using a Data Object List (DOL). Receives the card response to the GET PROCESSING OPTIONS command. If Geographic Restrictions apply, the card responds with “Conditions of use not satisfied” (SW1 SW2 = “6985”), the terminal removes the application from the list of candidate applications for this transaction and returns to Application Selection processing. If the card responds with the AFL and the AIP, the terminal proceeds to Read Application Data.

5. 6.

7.

Draft 12/18/00
4–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

4.4 Processing

Figure 4–1 shows the Initiate Application Processing flow.
Figure 4–1: Initiate Application Processing Flow

Card
Terminal completes Application Selection (Chapter 3)

Terminal

Terminal sets TSI and TVR to zero

Terminal uses PDOL (if provided by card during Application Selection) to determine terminal data elements to include in GET PROCESSING OPTIONS command.

GET PROCESSING OPTIONS command Card receives command, does internal processing & responds with “9000”, AIP, & AFL or error code GET PROCESSING OPTIONS response

Terminal issues GET PROCESSING OPTIONS (includes data requested by card in PDOL)

Card response = conditions of use not satisfied (SW1SW2 6985)?

Y

Terminal eliminates application from list of eligible applications and returns to Application Selection (Chapter 3)

N

Terminal proceeds to Read Application Data (Chapter 5)

Draft 12/18/00
31 Oct 2001
Visa Public

4–5

Initiate Application Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

4.5 Prior Related Processing
Application Selection The card supplies the PDOL (if present) to the terminal as part of the FCI provided in response to the SELECT command. The terminal returns to Application Selection if the card indicates that the conditions of use are not satisfied.

4.6 Subsequent Related Processing
Read Application Data The AFL provided by the card in response to the GET PROCESSING OPTIONS command is used by the terminal to determine what application data to read from the card and what data is used in Online Data Authentication if supported. Offline Data Authentication The AIP provided by the card in response to the GET PROCESSING OPTIONS command is used by the terminal to determine if the card supports Offline Data Authentication. Cardholder Verification The AIP provided by the card in response to the GET PROCESSING OPTIONS command is used by the terminal to determine if the card supports Cardholder Verification. Online Processing The AIP provided by the card in response to the GET PROCESSING OPTIONS command is used by the terminal to determine if the card supports Issuer Authentication.

Draft 12/18/00
4–6
Visa Public

31 Oct 2001

Read Application Data

5

During Read Application Data, the terminal reads the card data necessary to process the transaction and determines the data to be authenticated during Static Data Authentication (SDA) or Dynamic Data Authentication (DDA). Read Application Data shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.2. This chapter is organized into the following sections: 5.1 Card Data 5.2 Terminal Data 5.3 READ RECORD Command 5.4 Processing 5.5 Prior Related Processing 5.6 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

5–1

Read Application Data

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

5.1 Card Data
During Read Application Data, the terminal uses the data element (described in Table 5–1), which was received from the card during Initiate Application Processing.
Table 5–1: Read Application Data—Card Data

Data Element
Application File Locator (AFL)

Description
In Initiate Application Processing, the card sent the terminal the AFL, which contains an entry for each file to be read. Each entry designates:
q

The Short File Identifier (SFI) of the file The numbers of the first and last record to be read from the file The number of records beginning with the first record read in the file to be used for authentication during SDA and DDA

q

q

Read Application Data reads records from the card’s Application Elementary Files (AEF) described in Table 5–2.
Table 5–2: Read Application Data—Card Files

Data Element

Description

Application Elementary Files (AEF)

Card data files containing data used for application processing. An AEF consists of a sequence of records, which are addressed by record number. Each AEF is identified by a unique Short File Identifier (SFI). The terminal reads these records using the READ RECORD command containing a designation of the SFI and record number to be read.

5.2 Terminal Data
No terminal data is used in Read Application Data.

Draft 12/18/00
5–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

5.3 READ RECORD Command

5.3 READ RECORD Command
The READ RECORD command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.11. The terminal uses a READ RECORD command to request a record from the card:
q

P2 includes the Short File Identifier (SFI) of the file to be read P1 is the record number within the file

q

Details are shown in Tables II-21 and II-22 in the EMV 4.0, Book 3. The command response contains the requested record when SW1 SW2 = “9000”.

5.4 Processing
The terminal uses the Application File Locator (AFL) to determine which records to request from the card. For each entry in the AFL, the terminal uses the READ RECORD command to request the first record number specified in the AFL entry from the file specified by the SFI in this entry. After receiving the requested record, the terminal requests subsequent records until the last record specified in the AFL entry is received. The terminal processes the next entry in the AFL in the same manner until all AFL entries are processed. The AFL entry specifies how many records from the AEF are used for offline data authentication. Beginning with the first record read from the Application Elementary Files (AEF), the terminal shall put the record read into the list of static data to be authenticated until the number of records specified in the AFL entry has been put into the list. The terminal shall store all recognized data objects for later use in processing the transaction. Unrecognized data objects shall not be stored. The terminal shall terminate the transaction under any of these conditions:
q

More than one occurrence of a single primitive data object is encountered while reading data from the ICC The completion code (SW1 SW2) returned by the card in the READ RECORD response is not “9000” All mandatory data objects are not received. Mandatory data objects are shown in the Visa Integrated Circuit Card Specification, Appendix A, Terminal and Acquirer Data Elements.

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

5–3

Read Application Data

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

The terminal could perform Read Application Data as shown in Figure 5–1.
Figure 5–1: Read Application Data Processing Flow

Card
Terminal completes Initiate Appl. Processing

Terminal
Terminal stores data for later use

Terminal selects first entry from AFL N SDA Count = count in AFL entry

P1 = last record number in AFL entry? Y

Any more AFL entries? P1 = first record number in AFL P2 = SFI Y

Card passes record to terminal

READ RECORD command

Terminal sends READ RECORD command to card

Terminal increments P1 (record number)

Terminal selects next AFL entry

Requested record in READ RECORD response

SW1 SW2 = 9000 (successful read)? Y

N

SDA Count = 0?

N

N Puts data in a list of SDA data Y Decrement SDA Count by 1 Y Any data element tags already received? Terminal proceeds to Offline Data Authentication (Chapter 6) All mandatory data received? N

N

Y

Terminal terminates transaction

Draft 12/18/00
5–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

5.5 Prior Related Processing

5.5 Prior Related Processing
Initiate Application Processing The terminal gets the AFL from the card in the GET PROCESSING OPTIONS response for use during Read Application Data.

5.6 Subsequent Related Processing
Other functions use the data saved during Read Application Data for processing. Offline Data Authentication The terminal uses the list of static data to be authenticated built during Read Application Data for validation of the Signed Static Application Data during SDA or the ICC Public Key Certificate during DDA.

Draft 12/18/00
31 Oct 2001
Visa Public

5–5

Offline Data Authentication

6

Offline Data Authentication is the process by which the terminal authenticates data from the card using RSA public key technology. Offline Data Authentication has two forms:
q

Static Data Authentication (SDA) Dynamic Data Authentication (DDA)

q

During SDA processing, the terminal authenticates static (unchanging) data from the card. SDA ensures that issuer-selected card data elements have not been changed since the card was personalized. During DDA processing the terminal authenticates the static card data and also authenticates a cryptogram, which the card generates using transaction-unique data. DDA ensures that issuer-selected card data elements have not been altered since the card was personalized. DDA also confirms that the card is genuine and has not been created by copying data from a valid card to a counterfeit card (skimming). DDA can be either Standard DDA or Combined DDA/Application Cryptogram (AC) Generation. Offline Data Authentication results are considered in the card and terminal’s decision of whether to approve offline, go online for authorization, or decline offline. Online authorization systems may use the results of Offline Data Authentication in their authorization response decision. Offline Data Authentication shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 2, Sections 5 and 6. All offline-capable terminals shall support Offline Data Authentication. Offline Data Authentication support is optional for cards.

Draft 12/18/00
31 Oct 2001
Visa Public

6–1

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

This chapter is organized into the following sections: 6.1 Terminal Requirements 6.2 Determining Whether to Perform SDA or DDA 6.3 Static Data Authentication (SDA) 6.4 Dynamic Data Authentication (DDA) 6.5 Prior Related Processing 6.6 Subsequent Related Processing

Draft 12/18/00
6–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.1 Terminal Requirements

6.1 Terminal Requirements
Terminals shall support the following requirements for Offline Data Authentication.

6.1.1 Support for Offline Data Authentication
Offline-capable terminals shall support SDA and should support DDA. Online-only terminals such as ATMs are not required to support offline data authentication.

6.1.2 Visa Certificate Authority (CA)
SDA and DDA use RSA public/private key pairs, which require the implementation of a Visa Certificate Authority (CA). The Visa CA provides public key cryptographic services for the initialization and support of Offline Data Authentication. The Visa CA functions in a secure environment to ensure the security and integrity of all processes, keys, and related data. The terminal-related services provided by the Visa CA:
q

Generate all Visa RSA key pairs. Distribute the Visa Public Keys to acquirers. Notify acquirers of revocation and introduction of keys as outlined in the EMV 4.0, Book 2, Section 10.

q

q

6.1.3 RSA Key Pairs
To enable the use of the Visa RSA key pairs that are used in both SDA and DDA, the following shall occur:
q

The Visa CA shall generate one or more Visa RSA key pairs The Visa CA shall convey the Visa CA Public Key components of the Visa key pairs to acquirers Acquirers shall be responsible for the distribution of the Visa CA Public Keys to all terminals that support SDA or DDA and for the deletion of keys that have been revoked

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

6–3

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.1.4 Security Requirements
To ensure a sufficient level of support for RSA key backup, key recovery, and key migration, all terminals shall be capable of securely storing six Visa CA Public Keys and their associated data elements. Each of these six keys is between 768 and 1984 bits in length, and all six key storage slots shall be available for use at the same time. Terminals shall support the Visa and EMV requirements for withdrawal and introduction of the Visa CA Public Keys. EMV requirements for key handling in the terminal are shown in the EMV 4.0, Book 2, Sections 10 and 11.

6.2 Determining Whether to Perform SDA or DDA
6.2.1 Terminal Data
The terminal uses the terminal data (described in Table 6–1) when determining whether to perform SDA or DDA.
Table 6–1: Terminal Data Used in SDA or DDA Determination

Data Element
Terminal Capabilities

Description
Contains flags indicating the terminal’s support for SDA and DDA which may be used in deciding whether to perform SDA or DDA
q

SDA supported Standard DDA supported Combined DDA/AC Generation Supported

q

q

Transaction Status Information (TSI) Terminal Verification Results (TVR)

Contains a flag that is set when SDA or DDA is performed

Contains a flag that is set when neither SDA or DDA is performed

Draft 12/18/00
6–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.2 Determining Whether to Perform SDA or DDA

6.2.2 Card Data
The terminal uses the data (described in Table 6–2) from the card when determining whether to perform SDA or DDA.
Table 6–2: Card Data Used in SDA or DDA Determination

Data Element
Application Interchange Profile (AIP)

Description
Contains flags indicating the card’s support for SDA and DDA:
q

SDA supported DDA supported Combined DDA/AC Generation supported

q

q

6.2.3 Commands
No commands are used to determine whether to perform SDA or DDA.

6.2.4 Process
Only one offline data authentication method is performed in a single transaction. Combined DDA/AC Generation receives priority over Standard DDA and Standard DDA receives priority over SDA. If the card and terminal do not support a common authentication method, offline data authentication is not performed. Card support for SDA and DDA is shown in the Application Interchange Profile (AIP). Terminal support for SDA and DDA is shown in Terminal Capabilities, but the terminal may use other means to determine whether it supports these methods. The terminal uses the following rules to determine whether to perform SDA, Standard DDA or Combined DDA/AC Generation:
q

If both the card and the terminal support Combined DDA/AC Generation, the terminal shall perform Combined DDA/AC Generation Otherwise, if both the card and the terminal support Standard DDA, the terminal shall perform Standard DDA Otherwise, if both support SDA, the terminal shall perform SDA If none of the previous conditions are satisfied, the terminal shall not perform SDA or DDA and shall set the Offline Data Authentication was Not Performed bit to “1” in the TVR

q

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

6–5

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 6–1 illustrates how the terminal could determine whether to perform SDA, Standard DDA, or Combined DDA/AC Generation.
Figure 6–1: SDA or DDA Determination

Combined DDA/AC Generation supported bit set to “1” in AIP?

N

Offline DDA is supported set to “1” in AIP?

N

Offline SDA supported set to “1” in AIP?

Y

Y N Terminal supports Standard DDA?

N

Y
Terminal supports SDA?

N
N

Terminal supports Combined DDA/ AC Generation?

Y
Method used is Combined DDA AC Generation Method used is Standard DDA

Y
Y Terminal sets Offline Data Auth. was Not Performed bit to “1” in TVR.

Terminal proceeds to DDA processing (Section 6.4)

Terminal proceeds to SDA processing (Section 6.3)

Terminal proceeds to Processing Restrictions (Chapter 7)

Draft 12/18/00
6–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.3 Static Data Authentication (SDA)

6.3 Static Data Authentication (SDA)
When SDA is performed, the terminal validates static (unchanging) application data from the card using RSA public key technology. The validation process involves recovering the Issuer Public Key from a certificate on the card and validating static card data using a signature from the card. SDA ensures that the card data has not been fraudulently altered since personalization.

6.3.1 Card Data
During SDA, the terminal uses the data (described in Table 6–3) that was received from the card in previous steps.
Table 6–3: Offline Data Authentication—SDA Card Data (1 of 2)

Data
Certificate Authority Public Key Index (PKI) Issuer Public Key (PK) Certificate

Description
Used with the RID to designate which Visa CA Public Key to use for offline data authentication. A certificate that has been signed with the Visa Private Key and includes the Issuer Public Key. The format is shown in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 2, Section 5, Table 4. The certificate includes the following subfields:
q

The Issuer Public Key Length—Must be less than or equal to the length of the Visa CA Public Key The Issuer Public Key or the leftmost digits of the Issuer PK if the entire PK does not fit in the certificate The hash result from hashing the Issuer PK and other data elements specified in the EMV 4.0, Book 2, Section 5, Table 1

q

q

Issuer Public Key Exponent Issuer Public Key Remainder

Used in the RSA decryption algorithm. If necessary, it contains the portion of the Issuer Public Key that does not fit within the Issuer Public Key Certificate. A portion of the Application Identifier (AID) that identifies the card scheme. The RID is used with the PKI to designate the Visa CA Public Key to use for offline data authentication. Visa’s RID is A000000003. Used in the validation of the card’s static data during SDA. The SAD is signed with the Issuer Private Key and includes a hash of the card static data. The SAD format is shown in the EMV 4.0, Book 2, Section 5, Table 5. The format of the data to be hashed is in Table IV-2 of the same document.

Registered Application Identifier (RID)

Signed Static Application Data (SAD)

Draft 12/18/00
31 Oct 2001
Visa Public

6–7

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table 6–3:

Offline Data Authentication—SDA Card Data (2 of 2)

Data
Static Data Authentication Tag List Static Data to be Authenticated

Description
Optional field containing the tag of the AIP (tag “82”). If other tags are present, SDA processing fails. The data fields from the card to be used in the validation of the SAD. It consists of the data in the records identified in the AFL as being used for data authentication and the data identified in the optional Static Data Authentication Tag List. If present it contains the tag for the AIP (“82”). The terminal checks that this is the only tag present in the SDA Tag List.

6.3.2 Terminal Data
The terminal data elements described in Table 6–4 are required if the terminal supports SDA.
Table 6–4: Offline Data Authentication—SDA Terminal Data

Data
Certificate Authority Public Key Index (PKI)

Description
Each Visa CA Public Key used for offline data authentication in SDA and DDA is identified by the PKI in conjunction with the Registered Application Identifier (RID) of the Application Identifier (AID). The public keys stored in terminal for use in Issuer PK Certificate recovery. The Visa RID and a PKI unique within the Visa RID are associated with each Visa CA Public Key. Additional requirements are in Section 6.1.3 RSA Key Pairs, and Section 6.1.4 Security Requirements, in this chapter. Contains a flag that is used to indicate SDA failure.

The Visa CA Public Keys

Terminal Verification Results (TVR) Registered Application Provider Identifier (RID)

Identifies the scheme-specific list of public keys in the terminal. Used in conjunction with the PKI to identify the Visa CA Public Key to use of offline data authentication. Visa’s RID is A000000003.

6.3.3 Commands
No commands are used in SDA.

Draft 12/18/00
6–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.3 Static Data Authentication (SDA)

6.3.4 SDA Process
SDA shall be performed by the terminal as described in the EMV 4.0, Book 2, Section 5, and Book 3, Section 6.3. The following summarizes this SDA processing: 1. Retrieval of the Visa CA Public Key The terminal uses the Certificate Authority PKI and the RID from the card to retrieve the terminal-stored Visa CA Public Key and related information. 2. Retrieval of the Issuer Public Key The terminal performs the following actions: a. Validates that the Issuer Public Key Certificate is the same length as the Visa CA Public Key Modulus. b. Recovers the data from the Issuer Public Key Certificate using the Visa CA Public Key. The recovered data includes the Issuer Public Key. c. Checks the recovered data for:
s

A valid data trailer A valid data header A valid certificate format An Issuer Identification Number which corresponds to the Application PAN A non-expired expiration date A valid Issuer Public Key algorithm

s

s

s

s

s

d. Generates a hash from the certificate data and compares it to the recovered hash. e. Reconstructs the Issuer Public Key Modulus from the recovered data and the Issuer Public Key Remainder, if present. NOTE: Validation of the Certificate Serial Number (optional step 10 in EMV) is not currently supported by VIS.

Draft 12/18/00
31 Oct 2001
Visa Public

6–9

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.

Verification of the Signed Static Application Data (SAD) The terminal performs the following actions: a. Validates that the SAD is the same length as the Issuer Public Key Modulus. b. Recovers the data from SAD using the Issuer Public Key. c. Checks the recovered data for
s

A valid data trailer A valid data header A valid data format

s

s

d. Concatenates data from the recovered SAD, the static data identified by the Application File Locator (AFL), and the data identified in the Static Data Application Tag List. If the SDA Tag List is present, the terminal checks that the only tag it contains is the tag for the Application Interchange Profile (“82”). If any other tags are found, SDA has failed. The rules for formatting this authentication data are in the EMV 4.0, Book 2, Section 5. If the input list cannot be built, SDA has failed. e. Calculates a hash from the concatenated data. f. 4. Compares the calculated hash with the hash recovered from SAD. If they are not the same, SDA fails.

SDA Results If all of steps above execute successfully, SDA passes. If SDA fails, the Offline Static Data Authentication Failed bit shall be set to “1” in the TVR. The Offline Data Authentication was Performed bit in the Transaction Status Information (TSI) shall be set to “1” if SDA is performed.

Draft 12/18/00
6–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.3 Static Data Authentication (SDA)

Figure 6–2 illustrates how SDA could be performed.
Figure 6–2: SDA Flow

Card data to support SDA present?

N

Terminal sets ICC Data Missing bit to “1” in TVR

Y

Terminal data to support SDA present?

N

Y Terminal uses Visa CA PK to recover Issuer PK from Issuer PK Certificate and Issuer PK Remainder

Recovered certificate passes validity checking?

N

Y Terminal uses Issuer PK to recover SAD, which includes a hash of static data

Recovered data passes validity checking?

N

Y Terminal concatenates data recovered from SAD and static data to be authenticated & calculates a hash from concatenation result N Terminal sets Offline Static Data Auth. Failed bit to “1” in TVR

Calculated hash equals hash recovered from SAD?

Terminal sets Offline Data Auth. was Performed bit to “1” in TSI Y

Terminal proceeds to Processing Restrictions (See Chapter 7)

Draft 12/18/00
31 Oct 2001
Visa Public

6–11

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4 Dynamic Data Authentication (DDA)
If DDA is to be performed, the terminal validates static application data from the card using RSA public key technology in a manner similar, but not identical, to SDA. After validating the static data, the terminal asks the card to generate a dynamic signature using dynamic data from the terminal and card. The terminal validates this dynamic signature. The DDA process verifies that the card is genuine, that the card has not been created from skimmed data, and that the data on the card has not been fraudulently altered.

6.4.1 Card Data
During DDA, the terminal uses the data elements that were used for SDA except for the Signed Static Application Data (SAD). In addition DDA requires the card data described in Table 6–5.
Table 6–5: Offline Data Authentication—DDA Card Data

Data Elements
ICC Public Key (PK) Certificate

Description
Contains the ICC Public Key and a hash of the static data. This data is signed with the Issuer Private Key. Contains the exponent to be used by the RSA algorithm that recovers the ICC PK Certificate. If necessary, contains that part of the ICC Public Key that did not fit in the ICC PK Certificate. Contains the tags and lengths of the terminal data to be included in the INTERNAL AUTHENTICATE command requesting a dynamic signature.

ICC Public Key Exponent

ICC Public Key Remainder

Dynamic Data Authentication Data Object List (DDOL)

Draft 12/18/00
6–12
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4 Dynamic Data Authentication (DDA)

During DDA, the terminal receives the data (described in Table 6–6) from the card in the INTERNAL AUTHENTICATE response.
Table 6–6: Offline Data Authentication—DDA Card Data in INTERNAL AUTHENTICATE Response

Data Elements
Signed Dynamic Application Data

Description
Signed Dynamic Application DataThe dynamic signature generated by the card. The data signed in the Signed Dynamic Application Data includes:
q

The ICC Dynamic Data—Dynamic data from the card used in the hash algorithm A hash result-which was generated from the ICC Dynamic Data and the terminal dynamic data passed with the INTERNAL AUTHENTICATE command

q

The format of the Signed Dynamic Application Data is shown in the EMV 4.0, Book 2, Section 6, Table 13.

6.4.2 Terminal Data
The same terminal data elements that are used by SDA are also used by DDA. In addition, the data elements described in Table 6–7 are required for DDA.
Table 6–7: Offline Data Authentication—DDA Terminal Data

Data Elements
Default Dynamic Data Authentication Data Object List (Default DDOL)

Description
Indicates the data to include in the command requesting a dynamic signature if a DDOL is not received from the card. The Default DDOL shall contain only the tag and length for the Unpredictable Number. No other data objects shall be referenced in the Default DDOL. Contains an indicator set when DDA fails.

Terminal Verification Results (TVR) Unpredictable Number

An unpredictable transaction-unique number generated by the terminal and included in the INTERNAL AUTHENTICATE command.

Draft 12/18/00
31 Oct 2001
Visa Public

6–13

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4.3 Commands
6.4.3.1 INTERNAL AUTHENTICATE Command
The terminal sends the INTERNAL AUTHENTICATE command to the card during DDA to request a dynamic signature. The command includes the terminal dynamic data specified by the DDOL from the card or by the terminal’s Default DDOL if a DDOL was not received from the card. The INTERNAL AUTHENTICATE response includes the Signed Dynamic Application Data.

6.4.3.2 GENERATE APPLICATION CRYPTOGRAM (AC) Command
The terminal issues the first GENERATE AC command during Terminal Action Analysis processing. If the transaction is eligible for Combined DDA/AC Generation and the tag for Terminal Capabilities is not present in CDOL1, bit 6 in the P1 byte (Reference Control Parameter) in the GENERATE AC command is set to “1”. When CDOL1 from the card contains the tag for Terminal Capabilities, the terminal returns Terminal Capabilities in the GENERATE AC Command data. The card and terminal consider the transaction eligible for Combined DDA/AC Generation if the following conditions are met:
q

Byte 3 bit 5 of the Terminal Capabilities = “1”, indicating that the terminal can perform Combined DDA/AC Generation Byte 1 bit 2 of the card's AIP equals “1”, indicating that the card can perform Combined DDA/AC Generation

q

If the transaction is eligible for Combined DDA/AC Generation, the card shall return a TC or an ARQC within the DDA cryptographic envelope as described in the EMV 4.0, Book 2, Section 6.6.1.

6.4.4 Processing
During DDA processing, the terminal uses RSA public key decryption technology to recover and validate the Issuer PK Certificate, the ICC PK Certificate and the Signed Dynamic Application Data (the dynamic signature) from the card. The only functions performed by the card during DDA processing are the generation of the dynamic signature and setting of the CVR bit to indicate that Offline Dynamic Data Authentication has occurred.

Draft 12/18/00
6–14
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4 Dynamic Data Authentication (DDA)

Standard DDA shall be performed by the terminal as described in the EMV 4.0, Book 2, Sections 6 and 6.5. Combined DDA/AC Generation shall be performed by the terminal as described in the EMV 4.0, Book 2, Sections 6 and 6.6.

6.4.4.1 Standard DDA
Standard DDA processing requires the following steps: 1. Retrieval of the Certificate Authority Public Key The terminal uses the Certificate Authority Public Key Index and the RID previously received from the card to retrieve the terminal-stored Visa CA Public Key and related information. 2. Retrieval of the Issuer Public Key The terminal performs the following actions: a. Validates that the Issuer Public Key Certificate is the same length as the Visa CA Public Key Modulus. b. Recovers the data from Issuer Public Key Certificate using the Visa CA Public Key. The recovered data includes the Issuer Public Key. c. Checks the recovered data for:
s

A valid data trailer A valid data header A valid certificate format An Issuer Identification Number which corresponds to the Application PAN A non-expired expiration date A valid Issuer Public Key algorithm

s

s

s

s

s

d. Calculates a hash from the data elements recovered from the certificate, the Issuer PK Remainder, and the Issuer PK Exponent. e. Compares the calculated hash to the hash recovered from the Issuer Public Key Certificate. f. Reconstructs the Issuer Public Key Modulus from the recovered Issuer Public Key and the Issuer Public Key Remainder, if present.

NOTE: Validation of the Certificate Serial Number (optional Step 10 in EMV) is not currently supported by VIS.

Draft 12/18/00
31 Oct 2001
Visa Public

6–15

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

3.

Retrieval of the ICC Public Key The terminal performs the following actions: a. Validates that the ICC Public Key Certificate is the same length as the Issuer Public Key Modulus. b. Recovers the data from ICC Public Key Certificate using the Issuer Public Key. c. Checks the recovered data for:
s

A valid data trailer A valid data header A valid data format A non-expired expiration date A valid Issuer Public Key algorithm A recovered PAN which matches the Application PAN from the card

s

s

s

s

s

d. Calculates a hash from the recovered certificate data and the static data to be authenticated (from the records identified by the AFL and the data elements in the Static Data Authentication Tag List). The rules for formatting this authentication data are in the EMV 4.0, Book 3, Section 6.3. If the input list cannot be built, DDA has failed. e. Compares the calculated hash result with the hash recovered from ICC PK Certificate. If they are not the same, DDA has failed. 4. Dynamic Signature Generation The terminal issues an INTERNAL AUTHENTICATE command that includes a concatenation of the data elements specified by the DDOL. If a DDOL was not received from the card, the Default DDOL from the terminal is used. If the DDOL used does not contain the tag for the Unpredictable Number, DDA fails. The card generates Signed Dynamic Application Data by signing the terminal dynamic data from the INTERNAL AUTHENTICATE command and dynamic data from the card with the ICC Private Key stored on the card. The Signed Dynamic Application Data is passed to the terminal in the INTERNAL AUTHENTICATE response.

Draft 12/18/00
6–16
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4 Dynamic Data Authentication (DDA)

5.

Dynamic Signature Verification The terminal: a. Validates that the Signed Dynamic Application Data is the same length as the ICC Public Key Modulus. b. Recovers the Signed Dynamic Application Data using the ICC Public Key. c. Checks the recovered data for:
s

A valid data trailer A valid data header A valid data format

s

s

d. Concatenates the data recovered from the Signed Dynamic Application Data and the DDOL data and calculates a hash from this concatenated data. e. Compares the calculated hash result with the hash recovered from Signed Dynamic Application Data. If they are not the same, DDA has failed. 6. DDA Results If all of the steps above execute successfully, Standard DDA has passed. If DDA fails, Offline Dynamic Data Authentication Failed bit shall be set to “1” in the TVR. The Transaction Status Information (TSI) shall be updated to indicate that offline data authentication was performed. The DDA steps described above are illustrated in Figure 6–3.

Draft 12/18/00
31 Oct 2001
Visa Public

6–17

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4.4.2 Combined DDA/AC Generation
Combined DDA/AC Generation processing is the same as Standard DDA in Steps 1 through 3 as described below. Combined DDA/AC Generation processing includes the following steps: 1. Retrieval of the Certificate Authority Public Key The terminal uses the Certificate Authority Public Key Index and the RID previously received from the card to retrieve the terminal-stored Visa CA Public Key and related information. 2. Retrieval of the Issuer Public Key The terminal: a. Validates that the Issuer Public Key Certificate is the same length as the Visa CA Public Key Modulus. b. Recovers the data from Issuer Public Key Certificate using the Visa CA Public Key. The recovered data includes the Issuer Public Key. c. Checks the recovered data for:
s

A valid data trailer A valid data header A valid certificate format An Issuer Identification Number which corresponds to the Application PAN A non-expired expiration date A valid Issuer Public Key algorithm

s

s

s

s

s

d. Calculates a hash from the data elements recovered from the certificate, the Issuer PK Remainder, and the Issuer PK Exponent. e. Compares the calculated hash to the hash recovered from the Issuer Public Key Certificate. f. Reconstructs the Issuer Public Key Modulus from the recovered Issuer Public Key and the Issuer Public Key Remainder, if present.

NOTE: Validation of the Certificate Serial Number (optional Step 10 in EMV) is not currently supported by VIS.

Draft 12/18/00
6–18
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.4 Dynamic Data Authentication (DDA)

3.

Retrieval of the ICC Public Key The terminal: a. Validates that the ICC Public Key Certificate is the same length as the Issuer Public Key Modulus. b. Recovers the data from ICC Public Key Certificate using the Issuer Public Key. c. Checks the recovered data for:
s

A valid data trailer A valid data header A valid data format A non-expired expiration date A valid Issuer Public Key algorithm A recovered PAN which matches the Application PAN from the card

s

s

s

s

s

d. Calculates a hash from the recovered certificate data and the static data to be authenticated (from the records identified by the AFL and the data elements in the Static Data Authentication Tag List). The rules for formatting this authentication data are in the EMV 4.0, Book 3, Section 6.3. If the input list cannot be built, DDA has failed. e. Compares the calculated hash result with the hash recovered from ICC PK Certificate. If they are not the same, DDA has failed. The remaining processing for Combined DDA/AC Generation takes place during Card Action Analysis done by the card and Terminal Action Analysis and Online Processing done by the terminal.

Draft 12/18/00
31 Oct 2001
Visa Public

6–19

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 6–3:

DDA Flow (1 of 3)

Card

Retrieval of Certificate Authority Public Key Data required to authenticate ICC PK available? Y Retrieve Terminal CA PK using RID/CA PK Index

Terminal
N Set ICC Data Missing bit to “1” in TVR

A

CA PK found for RID/CA PK Index?

N Issuer ID Number = first digits of PAN?

Y Retrieval of Issuer Public Key Issuer PK Certificate & CA PK same length? Y

N

N

Y

Y

Issuer PK Certificate expired?

Recover data in Issuer PK Certificate using CA PK N Concatenate certificate's Issuer PK and Issuer PK Remainder to get Issuer PK Modulus N

Recovered data has valid header, trailer, format and PK Algorithm Indicator?

Y Concatenate recovered certificate data, Issuer PK Remainder, and Issuer PK Exponent

B

Calculate hash from concatenated data

Recovered hash = calculated hash? Y

N

Terminal proceeds to DDA failure

C A

Draft 12/18/00
6–20
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Figure 6–4: DDA Flow (2 of 2)

6.4 Dynamic Data Authentication (DDA)

Card
Retrieval of ICC Public Key

B

Terminal

ICC PK Certificate and Issuer PK Modulus same length? Y Recover data in ICC PK Certificate using Issuer PK

N

Recovered data has valid header, trailer, format, and PK algorithm indicator?

N

Y Concatenate certificate data elements, ICC PK Remainder, ICC PK Exponent, and static data to be authenticated

Apply hashing algorithm to result of concatenation

Calculated hash = recovered hash? Y Recovered PAN = Application PAN? Y

N

N

Certificate expired?

Y

DDA Failed Standard DDA?

Y
Concatenate certificate’s ICC PK and ICC PK Remainder to form ICC PK Modulus

N

C

D

Proceed to Processing Restrictions

Draft 12/18/00
31 Oct 2001
Visa Public

6–21

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 6–5:

DDA Flow (3 of 3)

Card
(Standard DDA Only)

Dynamic Signature Generation

D

Terminal
(Standard DDA Only)

DDOL received from Card?

G
N

Y Use Terminal’s Default DDOL

Use Card DDOL

Recovered data has valid header, trailer, & format? DDOL includes Unpredictable Number? N Y Y INTERNAL AUTHENTICATE Command Terminal issues INTERNAL AUTHENTICATE command with DDOL data elements Concatenate recovered data from Signed Dynamic Application Data with DDOL data

Card generates dynamic signature using ICC Private Key and returns response to terminal SW1 SW2 = 9000 (INTERNAL AUTHENTICATE successful)? Dynamic Signature Verification

Calculate hash from concatenated data

INTERNAL AUTHENTICATE response with dynamic signature

N N Recovered hash = calculated hash?

Y

DDA Success
Y N

Signed Dynamic Application Data & ICC PK Modulus same length?

Y Recover data in Signed Dynamic Application Data using ICC PK

C

Set Offline Data Authentication was Performed in TSI.

DDA Failure
Set Offline Dynamic Data Authentication Failed to “1” in TVR.

Proceed to Processing Restrictions (Chapter 7)

G

Draft 12/18/00
6–22
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

6.5 Prior Related Processing

6.5 Prior Related Processing
Initiate Application Processing The Application Interchange (AIP) is received from the card showing whether card support for SDA and DDA. Read Application Data The terminal reads data from the card that includes the data elements required for the offline data authentication methods supported by the card. Static data to be authenticated is included in the records identified in the AFL as participating in offline data authentication.

6.6 Subsequent Related Processing
Terminal Action Analysis The TVR bits for Offline Data Authentication was Not Performed, Offline Static Data Authentication Failure, Offline Dynamic Data Authentication Failure are considered in deciding if the transaction should be declined offline or sent online. The terminal indicates in the GENERATE AC Command to the card if Combined DDA/AC Generation is to be performed. Online Processing If Combined DDA/AC Generation was requested and the card response to the first GENERATE AC was an ARQC or a TC, the terminal performs the remaining processing for Combined DDA/AC Generation. If the process of validating the dynamic signature is successful, the terminal continues processing. If the dynamic signature is not valid and a TC was returned, the terminal declines the transaction with a Z1 response code. Completion
q

SDA and Standard DDA After an online authorization, the card may reset the SDA Failure Indicator and DDA Failure Indicator to “0” based upon Issuer Authentication options and results. If SDA or DDA failed and the transaction is to be declined offline because an online authorization could not be completed, the SDA Failure Indicator or DDA Failure Indicator is set to “1”.

Draft 12/18/00
31 Oct 2001
Visa Public

6–23

Offline Data Authentication

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

q

Combined DDA/AC Generation If Combined DDA/Generate AC was performed and failed, the terminal processes as follows: – – If a TC was returned in the first GENERATE AC, the terminal issues an offline decline. If an ARQC was returned in the first GENERATE AC, the terminal requests an AAC in the final GENERATE AC (transaction is declined offline).

Draft 12/18/00
6–24
Visa Public

31 Oct 2001

Processing Restrictions

7

The Processing Restrictions function is performed by the terminal using data elements from the terminal and the card. It includes checks on application versions, effective and expiration dates, and conditions at the point of transaction. Processing Restrictions shall be performed as specified in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.4, and Book 4, Part I, Section 2.3.3. This chapter contains the following sections: 7.1 Card Data 7.2 Terminal Data 7.3 Application Version Number 7.4 Application Usage Control 7.5 Application Effective Date 7.6 Application Expiration Date 7.7 Prior Related Processing 7.8 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

7–1

Processing Restrictions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

7.1 Card Data
The card data elements used in Processing Restrictions are listed and described in Table 7–1. For a detailed description of these elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Card and Issuer Data Element Tables.
Table 7–1: Processing Restrictions—Card Data

Data Element
Application Effective Date

Description
The Application Effective Date is the date when the application becomes activated for use. The Application Expiration Date is the date after which the application is no longer available for use. The AUC indicates any restrictions set forth by the issuer on the geographic usage and services permitted for the card application. If present, it is used in Application Usage Control checking by the terminal. This data element (card tag “9F08”) indicates the version of the application on the card. It is used in Application Version Number checking by the terminal. Cards complying with this specification should use 140. The Issuer Country Code is an EMV data element (tag “5F28”) indicating the country of card issuance. If present, it is used in Application Usage Control checking by the terminal.

Application Expiration Date

Application Usage Control (AUC)

Application Version Number

Issuer Country Code

Draft 12/18/00
7–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

7.2 Terminal Data

7.2 Terminal Data
The terminal data elements used in Processing Restrictions are listed and described in Table 7–2. For a detailed description of these elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 7–2: Processing Restrictions—Terminal Data

Data Element
Application Version Number

Description
This data element, (tag “9F09”), indicates the version of the application in the terminal. Terminals complying with this specification should use 140. This data element indicates the country in which the terminal is located. It is used in Application Usage Control checking by the terminal. Contains bits, which are set to “1” based on the results of Processing Restrictions.

Terminal Country Code

Terminal Verification Results (TVR) Transaction Date

This is the local date (in the terminal) on which the transaction processing is taking place. It is used by the terminal in effective and expiration date checking. This data element indicates the type of financial transaction. (It is represented by the first two digits of International Organisation for Standardisation (ISO) 8583-1987, Processing Code.) It is used in Application Usage Control checking by the terminal.

Transaction Type

7.3 Application Version Number
The terminal compares the Application Version Number in the card to the Application Version Number in the terminal to see if they are the same. If they are not the same, the terminal indicates in the Terminal Verification Results (TVR) that the application versions differ.

Draft 12/18/00
31 Oct 2001
Visa Public

7–3

Processing Restrictions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

7.4 Application Usage Control
Application Usage Control checking is a process in which the terminal checks various conditions at the point of transaction to determine if processing should continue. If the Application Usage Control (AUC) and the Issuer Country Code are present on the card, the terminal shall check the following application restrictions: 1. The terminal compares Issuer Country Code to the Terminal Country Code. a. If they are equal, the transaction is considered domestic. If the transaction is domestic, the appropriate indicator shall be set to “1” in the AUC on the card depending on Transaction Type, in order to proceed with the transaction. The terminal validates that the appropriate indicator is set in the AUC. For example, if the Transaction Type indicates a cash transaction, the terminal validates that the indicator “Valid for domestic cash transactions” is set in the AUC. b. If they are not equal, the transaction is considered international. If the transaction is international, the appropriate indicator shall be set to “1” in the AUC (card), depending on Transaction Type, in order to proceed with the transaction. The terminal validates that the appropriate indicator for the transaction type is set in the AUC. For example, if the Transaction Type indicates a cash transaction, the terminal validates that the indicator “Valid for international cash transactions” is set in the AUC. 2. 3. To process the transaction at an ATM, the indicator for “Valid at ATMs” shall be “1” in the AUC. To process a transaction at a card acceptance device other than an ATM, the indicator “Valid at terminals other than ATMs” shall be “1” in the AUC.

Draft 12/18/00
7–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

7.4 Application Usage Control

If any of the above checks fail, the terminal indicates that the “Requested Service is not Allowed for Card Product” in the TVR. Figure 7–3 illustrates how the AUC from the card is used in this processing. If the indicated bit has a value of “1”, that usage or capability is supported. NOTE: The dashes in this chart indicate that the setting of this bit is not applicable. When this data element is coded, all bits are either “0” or “1”.
Table 7–3: Application Usage Control (AUC)

Byte
1 1

b8
1 -

b7
1

b6
-

b5
-

b4
-

b3
-

b2b
-

b1
-

Usage
Valid for domestic cash transactions Valid for international cash transactions Valid for domestic goods Valid for international goods Valid for domestic services Valid for international services Valid at ATMs Valid at terminals other than ATMs Domestic cashback allowed International cashback allowed

1 1 1 1 1 1 2 2

1 -

1

1 -

1 -

1 -

1 -

1 -

1 -

Draft 12/18/00
31 Oct 2001
Visa Public

7–5

Processing Restrictions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

7.5 Application Effective Date
Issuer-optional Application Effective Date checking ensures that the application is active by validating that the Application Effective Date from the card is less than or equal to the Terminal Transaction Date (local to the terminal). If the Application Effective Date is greater than the terminal’s Transaction Date, the terminal indicates in the TVR that the application is not yet effective.

7.6 Application Expiration Date
Application Expiration Date checking is mandatory. The terminal validates that the application has not expired by checking whether the Application Expiration Date from the card is greater than or equal to the Terminal Transaction Date (local to the terminal). If the Application Expiration Date is less than the Terminal Transaction Date, the terminal indicates in the TVR that the application has expired.

Draft 12/18/00
7–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Figure 7–1: Processing Restrictions Flow

7.6 Application Expiration Date

Card

Terminal
Application Version Number for card and terminal present?

B

ATM Device?

N

AUC indicates transaction allowed at other than ATM Devices?

Y
Application Version Numbers identical? N Set ICC and Terminal Have Different Application Versions bit to “1” in TVR

Y Y AUC indicates ATM Transaction Allowed?

N

N

N

Set Requested Service not Allowed for Card Product bit to “1” in TVR

Y

Y

AUC and Issuer Country Code present? Y Issuer Country Code = Terminal Country Code? Y N N AUC indicates Transaction Type allowed for domestic transactions? N Set Requested Service Not Allowed for Card Product to “1” in TVR AUC indicates Transaction Type allowed for Internat’l transactions? Y

Application Effective Date < Current Date N Set Application not yet Effective bit to “1” in the TVR

N

Y

Application Expiration Date > Current Date? N Set Application has Expired bit to “1” in the TVR

Y

Y

B
Terminal proceeds to Cardholder Verification (Chapter 8)

Draft 12/18/00
31 Oct 2001
Visa Public

7–7

Processing Restrictions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

7.7 Prior Related Processing
Read Application Data The terminal uses the READ RECORD command to obtain the Application Version Number and Application Expiration Date from the card. The AUC and Application Effective Date are also read from the card, if present.

7.8 Subsequent Related Processing
Terminal Action Analysis During Terminal Action Analysis, the terminal compares the TVR with the Issuer Action Codes (IACs) and Terminal Action Codes (TACs) to determine the action to be taken if application versions differ, cards are not yet effective or expired, or requested service not allowed for card product.

Draft 12/18/00
7–8
Visa Public

31 Oct 2001

Cardholder Verification

8

Cardholder Verification is used to ensure that the cardholder is legitimate and the card is not lost or stolen. In Cardholder Verification, the terminal determines the Cardholder Verification Method (CVM) to be used and performs the selected CVM. The results of CVM processing play a role in later processing. CVMs supported are:
q

Offline Plaintext PIN Offline Enciphered PIN Online PIN Signature

q

q

q

Signature may be combined with the Offline PIN validation methods. CVM processing is designed to support additional CVMs such as biometric methods as they are adopted. With the Offline PIN methods, the validation of the PIN is done within the card. The terminal uses rules in a CVM List from the card to select the CVM to be used. The selection criteria in the CVM List can include the type of transaction (cash or purchase), the transaction amount, and the capabilities of the terminal. The CVM List also specifies the terminal action if the CVM fails. Cardholder Verification shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 2.5.12 and Section 6.5.

Draft 12/18/00
31 Oct 2001
Visa Public

8–1

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

This chapter is organized into the following sections: 8.1 Terminal Requirements 8.2 Card Data 8.3 Terminal Data 8.4 Commands 8.5 Processing 8.6 Prior Related Processing 8.7 Subsequent Related Processing

Draft 12/18/00
8–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.1 Terminal Requirements

8.1 Terminal Requirements
Terminals shall comply with the following Cardholder Verification requirements:
q

PIN Pad Support—The terminal shall be designed and constructed to facilitate the addition of a PIN pad, if one is not already present. CVM List Processing—If the card supports CVM processing, POS terminals shall use the card’s CVM List to determine appropriate cardholder verification processing for the transaction. Certain terminal types as defined by Visa (for example, ATMs) shall be allowed to request Online PIN entry even though it is not supported by the CVM List. If the card does not support CVM processing, the terminal shall perform the cardholder verification specified for Visa magnetic stripe transactions.

q

q

Standard Terminal Messages—The terminal should support the following Visa proprietary message: – 32—LAST PIN TRY: Indicates that there is one PIN try remaining for the application.

8.2 Card Data
The data from the card (described in Table 8–1) is used by the terminal during CVM List processing. For a detailed description of these data elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Card and Issuer Data Element Tables.
Table 8–1: CVM List Processing—Card Data (1 of 2)

Data Element
Application Currency Code Application Interchange Profile (AIP)

Description
Used to determine whether the CVM Conditions involving amounts can be used. Contains an indicator showing whether the card supports cardholder verification.

Draft 12/18/00
31 Oct 2001
Visa Public

8–3

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table 8–1:

CVM List Processing—Card Data (2 of 2)

Data Element
Cardholder Verification Method (CVM) List

Description
Identifies a prioritized list of methods of cardholder verification for the card application. A CVM List contains the following subfields:
q

Amount X—Amount used in some CVM Conditions Amount Y—Second amount used in some CVM Conditions CVM entry—The CVM List may contain multiple entries. Each entry contains the following subfields: Subfield CVM Code Description Designates the action to take if the CVM fails. Choices are process the next CVM entry or fail CVM processing. The type of CVM to perform:
q

q

q

CVM Type

Plaintext PIN verified offline Enciphered PIN verified online Plaintext PIN verified offline and signature Signature Enciphered PIN verified offline Enciphered PIN verified offline and signature No CVM required (CVM processing is considered successful with no additional CVM processing) Fail CVM processing (CVM processing is considered a failure with no additional CVM processing)

q

q

q

q

q

q

q

CVM Conditions

Conditions when this CVM entry should be used:
q

Always If transaction is cash or quasi-cash If the terminal supports the CVM If transaction amount is less than Amount X If transaction amount is more than Amount X If transaction amount is less than Amount Y If transaction amount is more than Amount Y

q

q

q

q

q

q

Note: The last 4 conditions require that the transaction be in the card’s Application Currency. For an example of a CVM List., refer to the Visa Integrated Circuit Card Specification, Chapter 8, Cardholder Verification.

Draft 12/18/00
8–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.2 Card Data

If Offline PIN is performed, the terminal may request the PIN Try Counter (described in Table 8–2) from the card.
Table 8–2: Offline PIN—Card Data

Data Element
PIN Try Counter

Description
Designates the number of PIN tries remaining. The card decrements the PIN Try Counter with each unsuccessful VERIFY command received and resets it to the PIN Try Limit if the Transaction PIN matches the Reference PIN or when a script command to reset the counter is processed.

If the card supports Offline Enciphered PIN, the issuer may generate an ICC PIN Encipherment public/private key pair to use solely for PIN encipherment or may use the ICC key pair used for DDA. The card shall have the data elements (described in Table 8–3) for whichever key pair is used.
Table 8–3: Offline Enciphered PIN—Card Data (1 of 2)

Data Element
Certificate Authority Public Key Index (PKI) ICC PIN Encipherment or ICC Public Key (PK) Certificate ICC PIN Encipherment or ICC Public Key Remainder ICC PIN Encipherment or ICC Private Key ICC PIN Encipherment or ICC Public Key Exponent Issuer Public Key (PK) Certificate

Description
With the Registered Application Provider Identifier (RID), designates the Visa CA Public Key to use to decipher the Issuer PK Certificate. Encrypted with the Issuer Private Key and contains the public key to be used in PIN encipherment. Contains the portion, if necessary, of the public key, which does not fit into the public key certificate. Stored in a secure location on the card. Used to decipher the enciphered PIN after it is received at the card. Used in the algorithm to decipher the enciphered PIN.

Encrypted with the Visa Private Key and contains the Issuer public key to be used to decipher the ICC PIN Encipherment or ICC PK Certificate. This is the same certificate used for DDA and SDA. Contains the portion, if necessary, of the public key, which does not fit into the public key certificate.

Issuer Public Key Remainder

Draft 12/18/00
31 Oct 2001
Visa Public

8–5

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table 8–3:

Offline Enciphered PIN—Card Data (2 of 2)

Data Element
Issuer Public Key Exponent

Description
Used in the algorithm to decipher the ICC PIN Encipherment or ICC PK Certificate. The portion of the Application Identifier (AID), which Identifies the scheme. With the PKI, the RID designates the Visa CA Public Key to use to decipher the Issuer PK Certificate during Offline Enciphered PIN processing.

Registered Application Provider Identifier (RID)

The card data described in Table 8–4 is used internally by the card during Offline PIN processing.
Table 8–4: Offline PIN Processing—Card Data

Data Element
Card Verification Results (CVR) PIN Try Limit Reference PIN

Description
Contains indicators set by the card to reflect Cardholder Verification processing. Issuer-specified maximum number of consecutive incorrect PIN tries allowed. The cardholder PIN that is stored in a secure location on the card.

Draft 12/18/00
8–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.3 Terminal Data

8.3 Terminal Data
The terminal data (described in Table 8–5) is used during CVM processing. For a detailed description of these data elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 8–5: CVM Processing—Terminal Data

Data Element
Amount, Authorized

Description
The amount of the transaction in the transaction currency. Also referred to as the transaction amount. Indicates the results of the last CVM performed.

Cardholder Verification Method (CVM) Results Enciphered PIN Data

Transaction PIN enciphered at the PIN pad for online verification or for offline verification if the PIN pad and card reader do not share a tamper-evident device. Secret DES key used by the PIN pad during Offline Plaintext PIN processing to encipher the keyed PIN and by the card reader to decipher the enciphered PIN. This key is required if the card reader and PIN pad do not reside in a single tamper-evident device. This key is not used for Offline Enciphered PIN encipherment. Indicates the cardholder verification methods supported by the terminal. Indicators are set in the TVR for the following conditions:
q

PIN Pad Secret Key

Terminal Capabilities Terminal Verification Results (TVR)

Cardholder verification was not successful Unrecognized CVM PIN Try Limit exceeded (on current or previous transaction) PIN entry required and PIN pad not present or not working PIN entry required, PIN pad present, but PIN was not entered Online PIN entered

q

q

q

q

q

Transaction Currency Code Transaction PIN Transaction Status Information (TSI)

The currency in which the transaction is initiated. Contains value keyed by the cardholder for PIN verification. Contains an indicator, which is set when Cardholder Verification is performed.

Draft 12/18/00
31 Oct 2001
Visa Public

8–7

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

If the terminal supports Offline Enciphered PIN, it shall have data (described in Table 8–6) which is the same data used for SDA and DDA.
Table 8–6: Offline Enciphered PIN—Terminal Data

Data Element
Certificate Authority Public Key Index (PKI) Registered Application Provider Identifier (RID) Visa CA Public Keys

Description
A unique index is associated with each Visa CA Public Key. It is used to identify the public key to use for PIN encipherment. Used with the PKI to identify the public keys associated with the scheme. Visa’s RID is A000000003. The terminal uses the selected key to decrypt the Issuer PK Certificate from the card.

8.4 Commands
The following commands are used for Offline PIN processing. GET DATA May be used by the terminal during Offline PIN processing to obtain the PIN Try Counter from the card in order to determine whether the PIN Try Limit was exceeded on a previous transaction or is close to being exceeded. This retrieval of the PIN Try Counter is optional for the terminal. The data portion of the command contains the tag for the PIN Try Counter. The card returns an SW1 SW2 other than “9000” from the GET DATA command if the PIN Try Counter is a proprietary data element. In this case, the terminal shall bypass the checking of the PIN Try Counter and continue with Offline PIN processing. GET CHALLENGE The GET CHALLENGE command is used to obtain an unpredictable number from the card for use with Offline Enciphered PIN. The terminal shall support the GET CHALLENGE command if the terminal supports Offline Enciphered PIN. The response data field contains the unpredictable number generated by the card.

Draft 12/18/00
8–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

VERIFY Used for Offline Enciphered PIN and Offline Plaintext PIN. The VERIFY command initiates the card comparison of the Transaction PIN and the Reference PIN. The terminal shall support the VERIFY command if the terminal supports offline CVM verification. The P2 parameter in the VERIFY command shall be:
q

“80” if the CVM is Offline Plaintext PIN. “88” if the CVM is Offline Enciphered PIN.

q

The valid SW1 SW2 values in the VERIFY response are:
q

“9000” if the keyed Transaction PIN matches the Reference PIN. “63Cx” if the PINs do not match. The “x” value representing the number of PIN tries remaining. “63C0” means the PIN Try Limit was exceeded during the VERIFY command processing. “6983” or “6984” if the PIN Try Limit was exceeded on a previous transaction or a previous VERIFY command.

q

q

8.5 Processing
Cardholder verification involves the following two functions:
q

CVM List processing—The terminal determines the CVM to use. CVM processing—The terminal performs the CVM selected in CVM List processing.

q

8.5.1 CVM List Processing
The purpose of CVM List Processing is to determine the CVM to use for the transaction based on rules set by the issuer (the CVM List), the capabilities of the terminal, and characteristics of the transaction. If the Application Interchange Profile (AIP) indicates that CVM processing is not supported, the terminal shall perform the CVM designated for Visa magnetic stripe transactions. If the AIP indicates that CVM processing is supported but no CVM List is received from the card, the terminal shall set the ICC data Missing bit in the TVR to “1” and terminate Cardholder Verification without setting the Cardholder Verification was Performed bit in the TSI.

Draft 12/18/00
31 Oct 2001
Visa Public

8–9

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

If a CVM List is received from the card and the card’s Application Interchange Profile (AIP) indicates that CVM processing is supported, the terminal shall process the CVM List. The terminal shall process each CVM List entry in the order in which it appears in the CVM List. 1. Selecting the CVM Entry The terminal shall select the CVM entry when all of the following are true: – – The CVM Condition Code is understood by the terminal. The card data required by the condition is present (for example, Application Currency Code when the CVM list includes a CVM Condition with an amount check). The condition in the CVM Condition Code is satisfied. The “Terminal Supports CVM” condition is satisfied if Terminal Capabilities indicates that the CVM is supported. The conditions involving amounts require that the Transaction Currency Code equals the Application Currency Code.

Otherwise, the terminal shall go to the next entry. 2. Processing the CVM Entry If the conditions expressed in the CVM Condition Code are satisfied, the terminal shall attempt to perform the CVM. If the terminal does not recognize the CVM, the terminal shall set Unrecognized CVM bit to “1” in the TVR and perform the action designated in the CVM Code. Details on processing specific CVMs are described in the next section of this chapter. 3. CVM Success If the CVM is performed successfully, Cardholder Verification is complete and successful. 4. CVM Failure If the CVM fails, the terminal shall check the CVM Code to see whether the terminal should fail CVM processing or go to the next CVM entry: – If the CVM Code indicates “Fail CVM,” the terminal shall set the Cardholder Verification was not Successful bit to “1” in the TVR. Cardholder Verification is complete. If the CVM Code indicates “Apply Succeeding CVM,” the terminal shall process the CVM entry if one is present.

Draft 12/18/00
8–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

5.

No More CVM Entries If the terminal reaches the end of the CVM List, Cardholder Verification has failed and the terminal shall set Cardholder Verification was Not Successful bit to “1” in the TVR.

6.

Completion of Cardholder Verification Cardholder Verification is complete if any one of the following occurs: – – – Any one CVM passes A CVM fails and the CVM entry’s CVM Code indicates “Fail CVM” The CVM List is exhausted

If the last CVM processed was “No CVM Required”, the terminal shall perform the Visa-specified method of cardholder verification for the terminal type if one has been specified. For example, if Visa has specified signature as the default cardholder verification method for the POS terminal, the POS terminal shall print a signature line on the receipt. When CVM List processing completed, the terminal shall set Cardholder Verification was Performed to “1” in the Transaction Status Information (TSI).

Draft 12/18/00
31 Oct 2001
Visa Public

8–11

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 8–1 illustrates how a terminal could perform CVM List processing.
Figure 8–1: CVM List Processing

Card’s AIP shows card supports CVM?
Y

N

Terminal performs Visa magnetic stripe CVM processing

Terminal proceeds to Terminal Risk Management

A

CVM List present? Y

N

Terminal sets ICC Data Missing in the TVR

N

Terminal recognizes CVM?

Y

Terminal selects first CVM in CVM List

Terminal sets “Unrecog. CVM” in TVR

Terminal supports CVM? N Y

N

Terminal understands CVM Condition?

N

CVM = PIN?

Y Y CVM Condition data available? Y Terminal sets “ PIN entry required but PIN pad not present or not working” in TVR Terminal performs processing for specified CVM

N

CVM Condition satisfied? N

Y

A

N

CVM Successful?

Y

CVM Code= Apply Succeeding CVM Entry? N CVM Code = Fail CVM

Y Terminal sets Cardholder Verification was Performed in TSI.

Any more CVM entries?

N

Y

Terminal sets “cardholder verification not successful” in TVR.

Y

Visa specified default CVM for terminal?

Y

CVM was No CVM Req’d?

Terminal selects next CVM in CMV List. N Terminal performs mag stripe CVM

N

Terminal completes Cardholder Verification Processing

Draft 12/18/00
8–12
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

8.5.2 CVM Processing
The terminal processes CVM entries according to the rules for the individual CVM.

8.5.2.1 Offline Plaintext PIN
The following requirements apply when the CVM is Offline Plaintext PIN. With Offline Plaintext PIN the Transaction PIN is sent in the clear to the card. For PIN security, the terminal may encipher the PIN at the PIN pad with the PIN Pad Secret Key and decipher it at the card reader using the same key. If the terminal does not support Offline PIN or if the PIN pad is malfunctioning, the terminal shall:
q

Set PIN Entry Required and PIN Pad not Present or not Working to “1” in the TVR. Proceed as though the CVM failed (that is, perform the action specified in the CVM Code of the CVM List entry).

q

If the merchant or cardholder directs the terminal to bypass PIN entry, the terminal shall:
q

Set PIN Entry Required, PIN Pad Present, but PIN was not Entered to “1” in the TVR. Consider the CVM unsuccessful. Continue with the action specified in CVM Code in the card’s CVM List entry. PIN Try Limit Exceeded shall not be set to “1” in the TVR.

q

q

q

When the terminal determines that an offline PIN is to be entered, the terminal shall either prompt immediately for PIN entry or shall check the card’s PIN Try Counter. 1. Checking the PIN Try Counter If the terminal is to check the PIN Try Counter, the terminal issues a GET DATA command to the card. The GET DATA response from the card either contains the value of the PIN Try Counter or is an error response with no PIN Try Counter. a. GET DATA Error Response A response other than “9000” indicates that the PIN Try Counter is a proprietary data element, which is not available to the terminal. If a response other than “9000” is received, the terminal shall bypass PIN Try Counter checking and prompt for PIN Entry.

Draft 12/18/00
31 Oct 2001
Visa Public

8–13

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

b. No PIN Tries Remaining If the PIN Try Counter is zero indicating no remaining PIN tries, the terminal shall:
s

Not allow offline PIN entry. Set PIN Try Limit Exceeded to “1” in the TVR. Not display any message regarding PINs. Perform the action specified in the CVM List entry’s CVM Code.

s

s

s

c. PIN Tries Remaining If the response to the GET DATA command contains PIN Try Counter value of “1” indicating one remaining PIN try, the terminal should display the Visa proprietary message of “Last PIN Try” as described in the Terminal Requirements section of this chapter. The terminal shall display “Enter PIN” to prompt for PIN entry.

Draft 12/18/00
8–14
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

Figure 8–2 shows how Checking the PIN Try Counter could be performed.
Figure 8–2: PIN Try Counter Checking

CARD
Receive GET DATA and respond with PIN try counter if card allows GET DATA command Issue GET DATA for PIN Try Counter

TERMINAL

GET DATA response

SW1 SW2 = 9000?

N

Y

PIN Try Counter = 0?

N

PIN Try Counter = 1?

Y

Y

Set PIN Try Limit Exceeded in TVR.

Display “Last PIN Try”

N

Do not display any PIN messages

Display “Enter PIN”

Perform CVM Code action.

Proceed to PIN Checking

2.

Enciphering the PIN If the card reader and PIN pad are integrated into a single tamper-evident device and the CVM is Offline Plaintext PIN, no encipherment of the Transaction PIN is performed. The plaintext PIN is passed from the PIN pad to the card reader. If the card reader and PIN pad are in separate devices and the CVM is Offline Plaintext PIN, the PIN pad shall encipher the Transaction PIN with the PIN Pad Secret Key according to the International Organisation for Standardisation (ISO) 9564-1 prior to passing it to the card reader. The card reader shall decipher the PIN when received. The PIN is passed in the clear from the card reader to the card.

Draft 12/18/00
31 Oct 2001
Visa Public

8–15

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

If the CVM is Offline Enciphered PIN, the PIN may be RSA enciphered at the PIN pad or may be enciphered using other means between the PIN pad and the ICC reader and RSA enciphered at the card reader and passed to the card in enciphered format. 3. PIN Checking using VERIFY command When the offline PIN is entered, the terminal shall transmit a VERIFY command containing the Transaction PIN to the card. The VERIFY P2 parameter shall be “80” to indicate Offline Plaintext PIN. a. PIN Verification (performed by the card)
s

If the card’s PIN Try Counter is zero, the card does no PIN compare and returns a VERIFY response with SW1 SW2 equal to “6983” or “6984”. If the Transaction PIN and the card’s Reference PIN are not equal, the card decrements its PIN Try Counter and returns SW1 SW2 equal to “63Cx” where x is the number of PIN tries remaining. If the PINs are equal, the card resets the PIN Try Counter to the PIN Try Limit and returns SW1 SW2 of “9000”.

s

s

b. PINs Match If the Transaction PIN matched the Reference PIN (SW1 SW2 equal “9000”), the terminal should display the “PIN OK” message. c. PIN Try Limit Exceeded on Previous Transaction If the PIN Try Limit was exceeded on a previous transaction (SW1 SW2 equal “6983” or “6984”), the terminal shall:
s

Set PIN Try Limit Exceeded to “1” in the TVR. Perform the action specified in CVM Code of the CVM List entry.

s

Draft 12/18/00
8–16
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

d. Non-Matching PINs If the PINs did not match (SW1 SW2 equal “63Cx”), the terminal action is based upon the value of “x”, which represents the number of PIN tries remaining.
s

If zero PIN tries remain, the terminal: – – – Should display the “Incorrect PIN” message. Shall set PIN Try Limit Exceeded to “1” in the TVR. Shall not transmit any further VERIFY command messages to the card.

s

If the PIN tries remaining is nonzero, the terminal: – – Should display the “Incorrect PIN” message followed by the “Enter PIN” message to prompt for PIN entry. If the PIN tries remaining is one, should display the Visa proprietary message of “Last PIN Try” between these two messages. After PIN entry, shall issue another VERIFY command to the card and repeat the Offline PIN process.

If PIN verification is successful prior to the PIN Try Counter being decremented to zero, the terminal should display the “PIN OK” message.

Draft 12/18/00
31 Oct 2001
Visa Public

8–17

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 8–3 illustrates how the terminal could perform Offline PIN processing.
Figure 8–3: Offline PIN Processing

Card

Offline PIN Processing

Terminal

A

Display “Enter PIN”

Cardholder enters PIN

Encriphered PIN?

Y

Enciphered PIN processing

N Terminal Issues VERIFY command with Entered PIN. PINs Matched Terminal proceeds to Terminal Risk Management

Card receives Verify comand and responds

VERIFY command

VERIFY command response

SW1 SW2 = 9000?

Y

Display “PIN OK”

N

PIN Try Limit Exceeded Previously Set PIN Try Limit Exceeded to “1” in TVR Terminal performs action specified in CVM Code of CVM List entry.

SW1 SW2 = 6983 or 6984?

Y

N

Invalid Response from VERIFY Command Terminate transaction

SW1 SW2 = 63Cx?

N

Y Display “Incorrect PIN” PIN Try Limit Exceeded on This Transaction PIN Tries Remaining = 0? N PIN Tries Remaining =1? N Terminal sets “PIN Try Limit Exceeded” in TVR. Terminal performs action specified in CVM Code of CMV List entry.

Y

More PIN Tries Remaining Display “Last PIN Try”

Y

A

Draft 12/18/00
8–18
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

8.5.2.2 Offline Enciphered PIN
The steps for processing for Offline Enciphered PIN are the same as for Offline Plaintext PIN except for the following differences, which are detailed in the EMV 4.0, Book 2, Chapter 7. NOTE: Step numbers correspond to those in Section 8.5.2.1. 2. Enciphering the PIN If the CVM is Offline Enciphered PIN, the PIN may be RSA enciphered at the PIN pad or may be enciphered using other means between the PIN pad and the ICC reader and RSA enciphered at the card reader and passed to the card in enciphered format. If the terminal has obtained the ICC PIN Encipherment Key data from the card, the terminal recovers the ICC PIN Encipherment Public Key in the same manner that the ICC Public Key is recovered during DDA (See Chapter 6, Offline Data Authentication, for details). If the ICC PIN Encipherment Key data was not received from the card during Read Application Data, the terminal recovers the ICC Public Key in this same manner. If the data for either key recovery is not available, the CVM shall fail. The terminal shall issue a GET CHALLENGE command to the card to request an unpredictable number. Upon receiving the GET CHALLENGE response containing the unpredictable number from the card, the terminal shall: – Concatenate the Transaction PIN (in PIN Block format), the unpredictable number from the card, and a terminal-generated Random Pad Pattern as shown in the EMV 4.0, Book 2, Section 7.2, Table 21. Encipher the concatenated data with the ICC PIN Encipherment Public Key previously recovered from the ICC PIN Encipherment PK Certificate, or the ICC Public Key if the ICC PIN Encipherment Public Key is not available.

3.

PIN Checking using the VERIFY command The terminal sets the P2 parameter of the VERIFY command to “88” to indicate that the PIN is enciphered. Upon receiving the VERIFY command with P2 equal to “88”, the card deciphers the Transaction PIN using the ICC Data Encipherment Private Key, if present, or if not present, the ICC Private Key.

4.

Processing After the PIN is deciphered, PIN checking continues in the same manner as with Offline Plaintext PIN described in Section 8.5.2.1, Step 3.

Draft 12/18/00
31 Oct 2001
Visa Public

8–19

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

The processing for Offline Enciphered PIN is shown in Figure 8–4.
Figure 8–4: Offline Enciphered PIN Processing

Card
Enciphered PIN Processing

Terminal

ICC Enciphered PIN PK Certificate available?

N

ICC PK Certificate available?

N

Fail CVM Processing

Y

Y

Use ICC Enciphered PIN PK Certificate.

Use ICC PK Certificate.

Recover Public Key (See DDA section of Chapter 6)

Generate ICC Unpredictable Number

GET CHALLENGE command

Issue GET CHALLENGE command

GET CHALLENGE response w/ICC Unpredictable Number

Concatenate data (ICC Unpred. Number, PIN, etc)

Encipher concatenated data with public key.

Set P2 to “88” in VERIFY command.

VERIFY command

Issue VERIFY command and continue processing as with Offline Plaintext PIN.

Draft 12/18/00
8–20
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.5 Processing

8.5.2.3 Online PIN
The following requirements apply when the selected CVM is Online PIN:
q

If the terminal does not support Online PIN or if the PIN pad is malfunctioning, the terminal shall: – – Set PIN Entry Required and PIN Pad not Present or not Working to “1” in the TVR. Perform the action specified in CVM Code for the CVM List entry.

q

If the merchant or cardholder directs the terminal to bypass PIN entry, the terminal shall: – – Set PIN Entry Required, PIN Pad Present, but PIN was not Entered to “1” in the TVR. Perform the action specified in CVM Code of the CVM List entry.

q

The terminal shall allow a PIN to be entered for Online PIN verification even if the card’s PIN Try Limit is exceeded. If the Online PIN is successfully entered, the terminal shall set Online PIN Entered to “1” in the TVR. The CVM is considered to have passed.

q

The processing for Online PIN is shown in Figure 8–5.
Figure 8–5: Online PIN Processing

Online PIN

Encipher PIN according to current standards.

Set Online PIN Entered to 1 in TVR.

Terminal proceeds to Terminal Risk Management (Chapter 9)

Enciphered PIN is included in online authorization (Chapter 10)

8.5.2.4 Signature
When the CVM is signature and the terminal supports the signature process, the CVM is considered to have passed and Cardholder Verification is complete. At the end of the transaction, the terminal shall print a receipt with a line for the cardholder’s signature. If the terminal does not support the signature process, the terminal shall proceed to the action specified in the CVM Code for the CVM List entry.

Draft 12/18/00
31 Oct 2001
Visa Public

8–21

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

The processing for Signature is shown in Figure 8–6.
Figure 8–6: Signature Processing
Terminal supports signature? Y Terminal proceeds to Terminal Risk Management. Terminal performs action specified in CVM Code of CVM List entry.

SIGNATURE

N

8.5.2.5 Signature and Offline PIN
If the CVM combines Signature with Offline PIN or Offline Enciphered PIN, both methods in the CVM must be successful for Cardholder Verification to be considered successful.

8.5.2.6 Fail CVM
When the CVM is “Fail CVM Processing,” the CVM is considered to have failed. The processing for Fail CVM is shown in Figure 8–7.
Figure 8–7: Fail CVM Processing

Fail CVM

Terminal performs action specified in CVM Code of CVM List entry.

Draft 12/18/00
8–22
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.6 Prior Related Processing

8.5.2.7 No CVM Required
If the CVM is “No CVM Required,” the CVM is considered to have passed. Cardholder Verification is complete. The processing for No CVM Required is shown in Figure 8–8.
Figure 8–8: No CVM Required Processing

NO CVM REQUIRED

Terminal has Visa Specified Default CVM?

Y

Perform Default CVM

N
Terminal proceeds to Terminal Risk Management (Chapter 9)

8.6 Prior Related Processing
Initiate Application Processing The terminal receives the Application Interchange Profile (AIP) from the card, which indicates whether the card supports Cardholder Verification. Read Application Data The terminal reads the CVM List and other data used for Cardholder Verification from the card.

Draft 12/18/00
31 Oct 2001
Visa Public

8–23

Cardholder Verification

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

8.7 Subsequent Related Processing
Terminal Action Analysis The terminal uses TVR indicators including Cardholder Verification indicators along with rules from the card (IACs) and terminal (TACs) in its decision on whether to approve offline, go online for an authorization, or decline offline. Card Action Analysis The card uses Cardholder Verification results in its decision on whether to approve offline, go online for an authorization, or decline offline. The card considers whether the PIN Try Limit was exceeded on a previous transaction in its decision on whether to go online or decline offline. The Application Default Action (ADA) provides the card rules for the action to take. Completion After a failed attempt to go online for an authorization for a transaction where the PIN Try Limit was exceeded on a previous transaction, the card uses parameters in ADA to determine whether to decline the transaction. Issuer-to-Card Script Processing The PIN CHANGE/UNBLOCK command can be used to reset the PIN Try Counter to equal the PIN Try Limit. The Reference PIN may also be changed with this command. The APPLICATION UNBLOCK command can be used to unblock an application which was blocked during CVM processing.

Draft 12/18/00
8–24
Visa Public

31 Oct 2001

Terminal Risk Management

9

Terminal Risk Management provides issuer authorization for higher-value transactions and ensures that transactions initiated from cards go online periodically to protect against threats that might be undetectable in an offline environment. Although Issuers are mandated to set the Terminal Risk Management is to be Performed bit to “1” in the Application Interchange Profile (AIP) to trigger Terminal Risk Management, terminals shall perform Terminal Risk Management regardless of the card settings. Terminal Risk Management shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.6, and Book 4, Sections 2.3.5 and 2.4.

Draft 12/18/00
31 Oct 2001
Visa Public

9–1

Terminal Risk Management

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

This chapter is organized into the following sections: 9.1 Card Data 9.2 Terminal Data 9.3 GET DATA Command 9.4 Terminal Exception File 9.5 Merchant Forced Transaction Online 9.6 Floor Limits 9.7 Random Transaction Selection 9.8 Terminal Velocity Checking 9.9 New Card Check 9.10 End Terminal Risk Management 9.11 Prior Related Processing 9.12 Subsequent Related Processing

Draft 12/18/00
9–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

9.1 Card Data

9.1 Card Data
The card data elements used in Terminal Risk Management are listed and described in Table 9–1. For a detailed description of these elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Terminal and Acquirer Data Elements.
Table 9–1: Terminal Risk Management—Card Data

Data Element
Application Identifier (AID) Application Primary Account Number (PAN) Application Transaction Counter (ATC) Last Online Application Transaction (ATC) Register

Description
Identifies the Terminal Floor Limit to be used during Terminal Risk Management Cardholder account number used in terminal exception file checking.

A counter of the number of transaction processed by the card since the application was put on the card and is used in terminal velocity checking. The ATC value of the last transaction that went online. If terminal velocity checking or new card checking by the terminal is required by the card, this data element and both of the data elements listed below must be present. This data element (tag “9F14”) is the issuer-specified preference for the maximum number of consecutive offline transactions allowed before a transaction must be sent online if the terminal is online capable. It is used in terminal velocity checking. This data element (tag “9F23”) is the issuer-specified preference for the maximum number of consecutive offline transactions allowed before transactions must be declined offline. It is used in terminal velocity checking.

Lower Consecutive Offline Limit

Upper Consecutive Offline Limit

Draft 12/18/00
31 Oct 2001
Visa Public

9–3

Terminal Risk Management

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

9.2 Terminal Data
The terminal data elements used in Terminal Risk Management are listed and described in Table 9–2. For a detailed description of these elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 9–2: Terminal Risk Management—Terminal Data

Data Element
Amount, Authorized

Description
This numeric data element (tag “9F02”) stores the amount (excluding adjustments) for the current transaction. It is used in floor limit checking. Value used in terminal risk management for random selection of transactions for online processing.

Maximum Target Percentage to be used for Biased Random Selection Target Percentage to be used for Random Selection Terminal Floor Limit

Value used in terminal risk management for random selection of transactions for online processing. This data element (tag “9F1B”) indicates the floor limit in the terminal in conjunction with the Application Identifier for the application. It is used in floor limit checking and random selection of transactions for online processing. A series of indicators in which the results of offline processing from a terminal perspective are recorded. It is used to record the results of all terminal risk management checks. Value used in terminal risk management for random selection of transactions for online processing. To prevent the use of split sales to bypass floor limits, the terminal may have a transaction log of approved transactions. This log, minimally contains the Application PAN and transaction amount, and optionally contains the Application PAN Sequence Number and Transaction Date. The number of transactions to be stored and maintenance of the log is outside the scope of this specification. This log, if present, may be used in terminal floor limit checking. Indicates the terminal functions performed during the transaction. This data element is not provided in the online authorization and clearing messages, but is used by the terminal to indicate that terminal risk management was performed.

Terminal Verification Results (TVR)

Threshold Value for Biased Random Selection Transaction Log

Transaction Status Information (TSI)

Draft 12/18/00
9–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

9.3 GET DATA Command

9.3 GET DATA Command
The GET DATA command is used by the terminal to read the Last Online ATC Register and the Application Transaction Counter (ATC), if not already present in the terminal, from the card. This information is used to support terminal velocity checking and new card checking by the terminal. See Appendix B, Commands for Financial Transactions, for details on use of the GET DATA command. SW1 SW2 is “9000” in the command response when the requested data is returned.

9.4 Terminal Exception File
If a terminal exception file is present, the terminal checks whether the Application Primary Account Number (PAN) on the card is listed on the exception file. If the card is listed on the exception file, the terminal sets the Card Appears on Terminal Exception File bit to “1” in the TVR.

9.5 Merchant Forced Transaction Online
At online-capable terminals, the merchant may indicate to the terminal that the transaction should be processed online. If the merchant forces the transaction online, the terminal sets the Merchant Forced Transaction Online bit to “1” in the TVR.

9.6 Floor Limits
Floor limit checking is performed so that transactions with amounts above the terminal floor limit are sent online for authorization. The terminal compares the Amount, Authorized to the Terminal Floor Limit. If the transaction amount is greater than or equal to the floor limit, the terminal sets the Transaction Exceeds Floor Limit bit to “1” in the TVR. Even when the floor limit is zero, the terminal performs this check and sets the Transaction Exceeds Floor Limit bit to “1” in the TVR. If the terminal supports a transaction log, the terminal checks to see if there is a log entry with the same Application PAN, and optionally, the same Application PAN Sequence Number. If there are multiple entries with the same PAN, the terminal selects the most recent entry. The terminal adds the amount for the current transaction to the amount stored in the log for that entry.

Draft 12/18/00
31 Oct 2001
Visa Public

9–5

Terminal Risk Management

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

If the sum of the current Amount, Authorized and the previous amount is greater than or equal to the Terminal Floor Limit, the terminal sets the Transaction Exceeds Floor Limit bit to “1” in the TVR.

9.7 Random Transaction Selection
Terminals capable of supporting offline and online transactions shall randomly select transactions for online processing. If the Amount, Authorized is less than the Threshold Value for Biased Random Selection, Random Selection is performed. The terminal generates a random number in the range of 1 to 99. If this random number is less than or equal to the Target Percentage to be Used for Random Selection, the transaction will be selected for online processing. If the transaction is selected, the terminal sets the Transaction Selected Randomly for Online Processing bit to “1” in the TVR. To assist in understanding the random transaction selection process described in the EMV 4.0, Book 3, Section 6.6.2, three examples are provided in this section. Assume that the terminal contains the parameters to be used for random transaction selection (shown in Table 9–3) and the terminal has generated a random number of 25.
Table 9–3: Example Terminal Parameters
100 25 40 20% 50%

Terminal floor limit Terminal random number Threshold for Biased Random Selection Target percentage for Random Selection Maximum target percentage for Biased Random Selection

EXAMPLE 1 The transaction amount is 20. Since the transaction amount (20) is less than the threshold for Biased Random Selection, random selection is performed. The terminal random number (25) is compared to the target percentage (20%), and because the random number is higher the transaction is not selected for online processing.

Draft 12/18/00
9–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

9.8 Terminal Velocity Checking

EXAMPLE 2 The transaction amount is 60. This is above the threshold for Biased Random Selection but below the terminal floor limit, so biased random selection is performed. The transaction amount is 20 above the threshold, which is one-third of the difference between the terminal floor limit and the threshold for biased random selection (100 - 40 = 60). Therefore, one-third of the difference between the maximum target percentage and the target percentage (50% - 20% = 30% x 1/3 = 10%) is added to the target percentage to result in a target for this transaction value of 30% (10% + 20%). The terminal’s random number is 25 (less than the target of 30), so the transaction is selected for online processing. EXAMPLE 3 The transaction amount is 150. Because this is above the terminal floor limit, the transaction is not subjected to random selection. It is selected for online processing by the terminal’s floor limit checking function.

9.8 Terminal Velocity Checking
Velocity checking permits issuers to request online processing after a specified number of consecutive offline transactions. Terminal Velocity Checking shall be supported by offline-capable terminals. Issuers may elect not to support velocity checking by the terminal. If both the Lower Consecutive Offline Limit (“9F14”) and Upper Consecutive Offline Limit (“9F23”) have been provided by the card in Read Application Data processing, the terminal shall perform velocity checking. If either of these data objects is not present in the card, the terminal shall bypass this processing. The terminal sends a GET DATA command to the card requesting the Last Online ATC Register and the ATC. The card returns these data elements in the command response. The terminal compares the ATC and the Last Online ATC Register:
q

If the ATC minus the Last Online ATC Register is greater than the Lower Consecutive Offline Limit, the terminal sets the Lower Consecutive Offline Limit Exceeded bit to “1” in the TVR.

Draft 12/18/00
31 Oct 2001
Visa Public

9–7

Terminal Risk Management

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

q

If the ATC minus the Last Online ATC Register is greater than the Upper Consecutive Offline Limit, the terminal sets the Upper Consecutive Offline Limit Exceeded bit to “1” in the TVR.

NOTE: Similar velocity checks may be performed by the card during Card Action Analysis. The TVR bits for Lower and Upper Consecutive Offline Limit Exceeded are not set during the Card Action Analysis checks.

9.9 New Card Check
New card checking by the terminal is performed if the Upper and Lower Consecutive Offline Limits are present in the card and the Last Online ATC Register is provided to the terminal in the response to GET DATA. This register is reset during Completion after an online approval based on Issuer Authentication results and card parameters. The terminal sends the GET DATA command to the card requesting the Last Online ATC Register (if this data element is not already present in the terminal). The card responds to the GET DATA command with the Last Online ATC Register. The terminal checks the Last Online ATC Register. If the register is zero, the terminal sets the New Card bit to “1” in the TVR. NOTE: A new card check similar to this may be performed by the card during Card Action Analysis. The TVR bit for New Card is not set during the Card Action Analysis checks.

9.10 End Terminal Risk Management
Upon completion of Terminal Risk Management, the terminal shall set the Terminal Risk Management was Performed bit to “1” in the Transaction Status Information (TSI).

Draft 12/18/00
9–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Figure 9–1: Terminal Risk Management Processing Flow (1 of 2)

9.10 End Terminal Risk Management

A

Terminal
Transaction log present in terminal?

Terminal exception file present?

Y
Y

N
Card appears on exception file?

N

Log Entry Present which matches current transaction

Y

Amount, authorized + amount in log > terminal floor limit

N
Y
Terminal sets Card Appears on Terminal Exception File bit to “1” in TVR

Y
Terminal sets Transaction Exceeds Floor Limit bit to “1” in TVR

N
Transaction amount > terminal floor limit

Y

N

N

Merchant elected to force transaction online?

Terminal randomly selects transaction for online processing

Y

Terminal sets Transaction Seleted Randomly for Online Processsing bit to “1” in TVR

Y N
Terminal sets Merchant Forced Transactions Online bit to “1” in TVR

N B

A

Draft 12/18/00
31 Oct 2001
Visa Public

9–9

Terminal Risk Management

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 9–2:

Terminal Risk Management Processing Flow (2 of 2)

B

Terminal
Lower and Upper Consecutive Offline Limits read by terminal?

N

Y Terminal issues GET DATA to obtain ATC and Last Online ATC Register

Both ATC and Last Online ATC Register returned?

N

Terminal sets ICC Data Missing bit to “1” in TVR

Y Terminal sets both Lower Consecutive Offline Limit Exceeded and Upper Consecutive Offline Limit Exceeded bits to “1” in TVR

(ATC-Last Online ATC Register) > Lower Consecutive Offline Limit?

Y Terminal sets Lower Consecutive Offline Limit Exceede bit to “1” in TVR

(ATCLast Online ATC Register) > Upper Consecutive Offline Limit Y Terminal sets Upper Consecutive Offline Limit Exceeded bit to “1” in TVR

N

N

Last Online ATC Register = 0
Y

N

Terminal proceeds to Terminal Action Analysis (Chapter 10)

Terminal sets “new card” bit in CVR

Draft 12/18/00
9–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

9.11 Prior Related Processing

9.11 Prior Related Processing
Read Application Data The following data is read from the card:
q

Primary Account Number, used in checking the terminal exception file Upper and Lower Consecutive Limits, used in Terminal Velocity Checking, if present on the card

q

9.12 Subsequent Related Processing
Terminal Action Analysis Based on card and terminal settings, the terminal determines what action to take if:
q

Card was on terminal exception file Merchant forced transaction online Floor Limits exceeded Transaction randomly selected for online processing Velocity Checking amounts or counters exceeded New card

q

q

q

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

9–11

Terminal Action Analysis

10

In Terminal Action Analysis, the terminal applies rules set by the issuer in the card and by the acquirer in the terminal to the results of offline processing to determine whether the transaction should be approved offline, declined offline, or sent online for an authorization. Terminal Action Analysis involves two steps: 1. Review Offline Processing Results—The terminal reviews the results of offline processing recorded in the TVR to determine whether the transaction should go online, be approved offline, or be declined offline. This process considers issuer-defined criteria from the card called Issuer Action Codes (IACs) and Visa-defined criteria in the terminal called Terminal Action Codes (TACs). Request Cryptogram Processing—The terminal requests a cryptogram from the card.

2.

Terminal Action Analysis shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.7, and Book 4, Section 2.3.6. This chapter is organized into the following sections: 10.1 Card Data 10.2 Terminal Data 10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command 10.4 Processing 10.5 Prior Related Processing 10.6 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

10–1

Terminal Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.1 Card Data
The card data elements described in Table 10–1 were previously received from the card and are used during Terminal Action Analysis. For a detailed description of card data elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Terminal and Acquirer Data Elements.
Table 10–1: Offline Processing Results—Card Data

Data Elements
Issuer Action Codes (IACs)

Description
Each IAC contains a series of bits, defined during issuer personalization, which correspond to the bits in the Terminal Verification Results (TVR). The three IACs are:
q

IAC—Denial The bits, which correspond to the TVR conditions for which the issuer would like an offline decline. If the terminal does not receive an IAC—Denial from the card, the terminal uses all “0”s.

q

IAC—Online The bits, which correspond to the TVR conditions for which the issuer would like to go online for an authorization. If the terminal does not receive an IAC—Online from the card, the terminal uses all “1”s.

q

IAC—Default The bits, which correspond to the TVR conditions for which the issuer would like an offline decline if online processing is not available. If the terminal does not receive an IAC—Default from the card, the terminal uses all “1”s.

Draft 12/18/00
10–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.2 Terminal Data

The card data described in Table 10–2 is used during the Request Application Cryptogram phase.
Table 10–2: Request Application Cryptogram—Card Data

Data Elements
Card Data Management Object List 1 (CDOL1)

Description
The CDOL1 contains the tags and lengths for the terminal data objects, which are needed by the card to generate the first application cryptogram, and for other processing.

10.2 Terminal Data
The terminal data elements described in Table 10–3 are used in the review of offline processing results. For a detailed description of these terminals and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 10–3: Offline Processing Results—Terminal Data (1 of 2)

Data Elements
Authorization Response Code Terminal Action Codes (TAC)

Description
Indicates the terminal’s requested disposition for the transaction. The TACs are Visa-defined bit-strings, which are similar to the card’s Issuer Action Codes (IACs) except that they are stored in the terminal. The TACs are three data elements which each consist a series of bits, which correspond to the bits in the TVR. The TACs are:
q

TAC—Denial The acquirer sets the bits, which correspond to the TVR conditions, which should cause an offline decline. The TAC—Denial shall contain a value of X'0010000000'. This TAC value causes a decline for the Service Not Allowed condition. Note: Acquirers not supporting all of the VSDC data in the authorization request shall decline transactions offline if DDA fails using a TAC—Denial value of X'0810000000'.

Draft 12/18/00
31 Oct 2001
Visa Public

10–3

Terminal Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table 10–3:

Offline Processing Results—Terminal Data (2 of 2)

Data Elements
Terminal Action Codes (TAC) (continued)

Description
q

TAC—Online The acquirer sets the bits, which correspond to the TVR conditions, which should generate an online authorization. The TAC—Online shall contain a value of X'D84004F800'. This TAC value generates an online authorization when: – – – – – – – – Offline data authentication is not performed or failed The PAN is on the terminal exception file The application is expired An Online PIN is entered The transaction exceeds the floor limit The upper (“9F23”) or lower consecutive offline limit (“9F14”) is exceeded The transaction is randomly selected for online processing The merchant forced the transaction online

q

TAC—Default The acquirer sets the bits, which correspond to the TVR conditions for which the transaction defaults to an offline decline if online processing is not available. The terminal shall contain the value of “D84000A800”. This TAC value generates a decline if the transaction cannot be sent online for authorization when: – – – – – – Offline data authentication is not performed or failed The PAN is on the terminal exception file The application is expired The transaction exceeds the floor limit The Upper Consecutive Offline Limit (“9F23”) is exceeded The merchant forced the transaction online

Note: Markets not supporting offline data authentication in cards may remove the TAC—Online and TAC—Default settings for offline data authentication not performed resulting in a TAC—Online value of X'584004F800' and a TAC—Default of value of X'584000A800'. A means for updating the TACs by the acquirer shall be supported as defined in the EMV 4.0 Book 4, Section 6.2. Terminal Verification Results (TVR) The TVR is a series of bits which are set during transaction processing to represent transaction processing status as seen from the perspective of the terminal.

Draft 12/18/00
10–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command

The terminal data described in Table 10–4 is used during the Request Application Cryptogram phase.
Table 10–4: Request Application Cryptogram—Terminal Data

Data Elements
Data Objects specified in CDOL1 by the issuer

Description
The terminal includes the data objects specified by the issuer in the CDOL1 in the GENERATE APPLICATION CRYPTOGRAM (AC) command.

10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command
In the Request Application Cryptogram step, the terminal issues the card a GENERATE APPLICATION CRYPTOGRAM (AC) command. The terminal indicates in P1, the reference control parameter of this command, if Combined DDA/AC Generation is to be performed. The specific requirements for the GENERATE AC command are in Appendix B, Commands for Financial Transactions, and in the EMV 4.0, Book 3, Section 2.5.5. The data portion of this command contains the terminal data requested by the card in CDOL1. The P1 parameter of the command designates the type of cryptogram being requested as shown in the EMV 4.0, Book 3, Table I–10. If the TC Hash Value is to be input to the Application Cryptogram algorithm, the card will have referenced the TC Hash Value in CDOL1, and the terminal shall generate and transmit the TC Hash Value in the GENERATE AC command along with the other data elements referenced in the CDOL1.

Draft 12/18/00
31 Oct 2001
Visa Public

10–5

Terminal Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.4 Processing
Terminal Action Analysis consists of two steps:
q

Review of Offline Processing Results Generate Cryptogram Processing

q

10.4.1 Review Offline Processing Results
The review of offline processing results is performed after Terminal Risk Management but also may be performed earlier to eliminate the need for unnecessary processing. For example, Terminal Action Analysis could be performed after Static Data Authorization (SDA) to eliminate the need for Cardholder Verification when SDA failure results in an offline decline. This review is performed entirely within the terminal using processing rules called IACs, which were previously received, from the card and rules from the terminal called TACs. During processing the terminal compares bits in the IACs and TACs to the corresponding bits in the Terminal Verification Results (TVR). If corresponding bits in the TVR and the IAC or TAC are both set to “1”, the disposition for the IAC or TAC is used.

Draft 12/18/00
10–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.4 Processing

The following example illustrates how the comparisons work. EXAMPLE: IAC USAGE EXAMPLE The issuer wishes to decline transactions offline if Offline Dynamic Data Authentication fails or if the PIN Try Limit is exceeded so the IAC—Denial bits from the card are set as below: Offline DDA Failed PIN Try Limit Exceeded

IAC—Denial 00001000 00000000 00100000 00000000 00000000 The terminal records offline processing results in the TVR. In the following transactions, the application is expired. In Transaction 2, Offline DDA has also failed. Transaction 1: The application is expired so the TVR is set to: Expired Application


TVR 00000000 01000000 00000000 00000000 00000000 IAC—Denial 00001000 00000000 00100000 00000000 00000000 Decline offline is not set here because the TVR and IAC—Denial have no corresponding bits that are set to “1”.

Transaction 2: Offline DDA has failed and the application is expired so the TVR is set to: Offline DDA Failed Expired Application ¯ ¯


TVR

00001000 01000000 00000000 00000000 00000000

IAC-Denial 00001000 00000000 00100000 00000000 00000000 Offline DDA Failed is set to “1” in the IAC—Denial and the TVR so the transaction disposition is set to decline offline. Similar comparisons are done with the other IACs and the TACs.

Draft 12/18/00
31 Oct 2001
Visa Public

10–7

Terminal Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

The processing steps taken by the terminal are: 1. The terminal compares the IAC—Denial to the TVR. If no IAC—Denial is present, the terminal uses a default value of X'0000000000'. If any corresponding bits in the IAC—Denial and the TVR are both “1”, the terminal: – – – 2. Sets the Authorization Response Code to “Z1” (Offline Decline). Sets the cryptogram type in the P1 parameter of the GENERATE AC command to an Application Authentication Cryptogram (AAC). Proceeds to the Request Application Cryptogram step.

The terminal does a similar compare with the TAC—Denial and the TVR. If no TAC—Denial is present, the terminal uses a default value of X'00000000'. If any corresponding bits are set to “1”, the same actions as done for the IAC—Denial should be performed. NOTE: Programs could perform the IAC and TAC comparisons to the TVR with the following logic: If ((IAC—Denial) OR (TAC—Denial) AND TVR) not = zeros, Then decline the transaction Similar logic could be used for the Online and Default conditions.

3.

If the terminal has online capabilities, it compares the IAC—Online and TAC—Online to the TVR. If no IAC—Online is present, the terminal uses a default value of X'11111111'. If no TAC—Online is present, the terminal uses a default value of X'00000000'. If any corresponding bits in the IAC—Online and TVR are both “1”, the terminal: – Sets the cryptogram type in the GENERATE AC P1 parameter to an Authorization Request Cryptogram (ARQC) to request an online cryptogram. Proceeds to the Request Application Cryptogram step.

Draft 12/18/00
10–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.4 Processing

4.

If the terminal does not have online capabilities, it compares the IAC—Default and the TAC—Default to the TVR. If no IAC—Default is present, the terminal uses a default value of X'11111111'. If no TAC—Default is present, the terminal uses a default value of X'00000000'. If any corresponding bits are both set to “1”, the terminal: – – – Sets the Authorization Response Code to “Z3” (Offline Decline Unable To Go Online). Sets the cryptogram type to AAC in the P1 parameter of the GENERATE AC command. Proceeds to the Request Application Cryptogram step.

5.

If none of the previous compares found corresponding bits which were both “1”, the terminal: – – – Sets the Authorization Response Code to “Y1” (Offline Approve). Sets the cryptogram type in the P1 parameter of the GENERATE AC command to a Transaction Certificate (TC). Proceeds to the Request Application Cryptogram step.

10.4.2 Request Application Cryptogram
The second phase of Terminal Action Analysis is requesting a TC, ARQC or AAC from the card depending upon the outcome of the review of the offline processing results. The terminal formats the GENERATE AC command and issues it to the card. The terminal indicates in P1 (sets bit 6 to 1) of this command if Combined DDA/AC Generation is to be performed.

Draft 12/18/00
31 Oct 2001
Visa Public

10–9

Terminal Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.4.3 Process Flow
Figure 10–1 shows how Terminal Action Analysis might be performed.
Figure 10–1: Terminal Action Analysis

IAC-Denial present?

N

Terminal uses IACDenial default value of all bits set to “0”

Y Terminal uses TACDenial default value of all bits set to “0”

TAC-Denial present?

N

Y

Are any corresponding bits set in both TVR and the IAC-Denial or TAC-Denial?

N

Y Terminal uses IACOnline default value of all bits set to “1”

Online capable terminal?

N Terminal uses IACDefault default value of all bits set to “1”

N

IAC-Online present?

IAC-Default present?

N

Y Terminal uses TAC-Online default value of all bits set to “0”

Y Terminal uses TACDefault default value of all bits set to “0”

N

TAC-Online present?

TAC-Default present?

N

Y Y Are any corresponding bits set in both TVR & IAC-Default or TAC-Default? N

Y

Are any corresponding bits set in TVR & IAC-Online or TAC-Online? Y P1 (Cryptogram type) in GEN AC = ARQC (Send Online)

N

Terminal sets Auth Resp Code to Z (offline approved) P1 (Cryptogram type) in GEN AC = TC (Approve)

Terminal sets Auth Resp Code to Z3 (offline declined)

Card
Proceed to Card Action Analysis (See Chapter 11)

DDA/ AC Generation to be done?

Y N

Terminal sets P1 in GENERATE AC indicating DDA/AC Generation req'd

P1 (Cryptogram type) in GEN AC = AAC (Decline)

GENERATE AC command

Terminal issues 1st Generate AC

Draft 12/18/00
10–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

10.5 Prior Related Processing

10.5 Prior Related Processing
Read Application Data The terminal reads application data from the card, which includes the CDOL1 and Issuer Action Codes if they are present on the card. Offline Data Authentication, Processing Restrictions, Cardholder Verification, and Terminal Risk Management These offline functions set bits in the TVR based upon the results of processing. Terminal Action Analysis compares these TVR bits to the bits in the IACs and TACs to determine transaction disposition. During Offline Data Authentication, the terminal determines if Combined DDA/AC Generation is to be performed. If so, the terminal saves this information so that the Reference Control parameter of the first GENERATE AC command can be updated.

10.6 Subsequent Related Processing
Card Action Analysis During Card Action Analysis performs additional risk management to determine whether it will override the terminal’s Terminal Action Analysis decision to approve offline, decline offline, or send online.

Draft 12/18/00
31 Oct 2001
Visa Public

10–11

Card Action Analysis

11

Card Action Analysis allows issuers to perform velocity checking and other risk management, which is internal to the card. Visa proprietary card risk management features described in this section include checking:
q

Activity on previous transactions If card is a new card Velocity counters

q

q

Card Action Analysis shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.8. This chapter is organized into the following sections: 11.1 Card Data 11.2 Terminal Data 11.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command 11.4 Processing 11.5 Prior Related Processing 11.6 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

11–1

Card Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

11.1 Card Data
The card data elements used in Card Action Analysis are listed and described in Table 11–1. For a detailed description of these elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Terminal and Acquirer Data Elements.
Table 11–1: Card Action Analysis—Card Data

Data Element
Card Risk Management Data Object List 1 (CDOL1)

Description
List of data objects with their associated labels (tags) and lengths, to be passed from the terminal to the card application with the first GENERATE APPLICATION CRYPTOGRAM (AC) command.

The GENERATE AC Command Response data elements are listed and described in Table 11–2.
Table 11–2: GENERATE AC Command Response Data

Data Element
Application Cryptogram Application Transaction Counter (ATC) Cryptogram Information Data

Description
The value of the cryptogram. A counter of the number of transactions initiated since the application was put on the card. Contains indicators for:
q

The type of cryptogram returned by the card: – An Application Authentication Cryptogram (AAC) for a decline – A Transaction Certificate (TC) for an approval – An Authorization Request Cryptogram (ARQC) for online processing (first GENERATE AC only)

q

Other status information including Service Not Allowed.

Issuer Application Data

Contains proprietary application data for transmission to the Issuer. This includes the CVR. A Visa proprietary data element containing indicators, which are set, based upon the results of offline processing for current and previous transactions.

Card Verification Results

Draft 12/18/00
11–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

11.2 Terminal Data

11.2 Terminal Data
The terminal data element used in Card Action Analysis is listed and described in Table 11–3.
Table 11–3: Card Action Analysis—Terminal Data

Data Element
Data Requested in CDOL1

Description
The terminal provides the data requested by the card in the CDOL1. For a list of data required, refer to the Visa Integrated Circuit Card Specification, Appendix E, Cryptogram Versions Supported.

11.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command
The GENERATE APPLICATION CRYPTOGRAM (AC) command response is returned by the card at the end of Card Action Analysis. It contains the data shown in Table 11–3. See Appendix B, Commands for Financial Transactions, for detail on use of the GENERATE AC Command. This command may indicate if Combined DDA/AC Generation is to be performed.

Draft 12/18/00
31 Oct 2001
Visa Public

11–3

Card Action Analysis

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

11.4 Processing
The terminal does no processing during Card Action Analysis. The GENERATE AC command, which the card receives from the terminal, contains a parameter indicating the cryptogram type, which the terminal is requesting. This cryptogram type indicates the terminal’s transaction decision (approve offline, decline offline, send online). Based on the results of this Card Risk Management performed by the card (including checking activity on previous transactions, if card is a new card, and velocity counters), the card determines a transaction response. The card’s response may override the terminal’s decision indicated by the Cryptogram Type:
q

The card may override the terminal’s decision to approve offline by deciding to either send online or decline offline. The card may override the terminal’s decision to go online by deciding to decline offline.

q

These decision rules are shown in Table 11–4.
Table 11–4: Card’s Response to First GENERATE AC Command

Card Responds

AAC
Terminal Requests

ARQC
— Go Decline Go Decline

TC
— — Approve

AAC ARQC TC

Decline Decline Decline

11.4.1 Response to GENERATE AC for Combined DDA/AC Generation
If the terminal has indicated in the GENERATE AC command that Combined DDA/AC Generation is to be performed and the card is returning a TC or an ARQC, the card generates a dynamic signature and returns it in the response to GENERATE AC.

Draft 12/18/00
11–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

11.5 Prior Related Processing

11.4.2 Standard Response to GENERATE AC
The card returns a cryptogram and indicates the response decision by the cryptogram type.

11.5 Prior Related Processing
Read Application Data The terminal reads the Card Risk Management Data Object List 1 (CDOL1) from the card. Terminal Action Analysis At the end of Terminal Action Analysis, the terminal issues the first GENERATE AC command to the card to request an Application Cryptogram and to provide data requested by the card in CDOL1.

11.6 Subsequent Related Processing
Online Processing At the beginning of Online Processing, the terminal receives the response to the first GENERATE AC command returned by the card during Card Action Analysis. Online Processing uses the cryptogram type received from the card in this response to determine whether the transaction should be declined or approved offline or whether an online authorization should be performed. Completion If online processing was requested, but the terminal was unable to send the transaction online, additional card and terminal processing is performed.
q

The terminal performs additional analysis (similar to Terminal Action Analysis) using the Issuer Action Code (IAC) Denial and Terminal Action Code (TAC) Denial to determine which cryptogram (AAC or TC) to request in the final GENERATE AC command. The card performs additional Card Risk Management checks to determine final transaction disposition.

q

Draft 12/18/00
31 Oct 2001
Visa Public

11–5

Online Processing

12

Online Processing allows the issuer’s host computer to review and authorize or decline transactions using the issuer’s host-based risk management parameters. In addition to performing traditional online fraud and credit checks, host authorization systems may perform Online Card Authentication using a card-generated dynamic cryptogram and may consider offline processing results in the authorization decision. The response from the issuer may include post-issuance updates to the card and an issuer-generated cryptogram, which the card can validate to ensure that the response came from the valid issuer or both. This validation is called Issuer Authentication. This chapter describes the terminal online processing functions, which are new with Visa Smart Debit and Visa Smart Credit (VSDC). Online processing functions, which are also performed with magnetic, stripe-read, and key-entered transactions are not described. Online processing shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Part II, Section 6.9, and Book 4, Part I, Section 2.3.8. This chapter is organized in the following manner: 12.1 Terminal Requirements 12.2 Card Data 12.3 Terminal Data 12.4 Commands 12.5 Processing 12.6 Prior Related Processing 12.7 Subsequent Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

12–1

Online Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.1 Terminal Requirements
Online processing may be requested by the terminal or the card.

12.2 Card Data
The card data described in this section is used by the terminal during Online Processing.

12.2.1 GENERATE AC Response Data
The GENERATE AC response received from the card is coded according to Format 1 or Format 2 as described in the EMV 4.0, Book 3, Part I, Section 2.5.5.4. If the response is Format 1, the value field in the response consists of a concatenation of the value portion of the data listed and described in Table 12–1.
Table 12–1: Online Processing—GENERATE AC Response Card Data

Data Elements
Application Cryptogram Application Transaction Counter (ATC) Cryptogram Information Data

Description
The cryptogram value from the card. A counter of the number of transactions initiated since the application was put on the card. Contains an indicator of the type of cryptogram. An Authorization Request Cryptogram (ARQC) is designated by b'10' in the first two bits (bits 8–7). Issuer Application Data is a Visa-mandatory field used to transmit Visa discretionary data to the terminal for input to the online request message or clearing record. The terminal passes this data through to the issuer.

Issuer Application Data

If the response is Format 2, the response data is present as BER-TLV data elements within tag “77”. If the Format 2 response contains tag “9F4B” (Signed Dynamic Application Data), the Application Cryptogram is contained within this data element and the terminal shall validate the dynamic signature.

Draft 12/18/00
12–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.3 Terminal Data

12.2.2 Other Card Data
The terminal also uses the card data element listed and described in Table 12–2 during Online Processing.
Table 12–2: Online Processing—Other Card Data

Data Elements
Application Interchange Profile (AIP)

Description
The AIP contains a flag, which indicates whether the card supports Issuer Authentication. The AIP is received during Initiate Application Processing from the card in the GET PROCESSING OPTIONS response.

12.3 Terminal Data
The data from the terminal used during the Issuer Authentication portion of Online Processing is listed and described in Table 12–3.
Table 12–3: Online Processing—Terminal Data

Data Elements
Transaction Status Information (TSI) Terminal Verification Results (TVR)

Description
Contains a bit for Issuer Authentication was Performed which the terminal sets to “1” when Issuer Authentication is performed. Contains a bit indicating whether Issuer Authentication Was Unsuccessful which the terminal sets to “1” when Issuer Authentication fails.

Draft 12/18/00
31 Oct 2001
Visa Public

12–3

Online Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.3.1 Online Request Message Data
In addition to the data elements required for magnetic stripe initiated transaction, as a minimum, the terminal shall provide the VSDC data objects listed in Table 12–4 in the online message in support of Cryptogram Version 10 and 14 and VSDC processing at the host computer.
Table 12–4: Visa Smart Debit Credit (VSDC) Data Objects Required in Online Message

Data Objects
Amount, Authorized Amount, Other

Source
Transaction amount from terminal Portion of transaction amount that is cashback from terminal (if present) Authorization Request Cryptogram (ARQC) received from card in GENERATE APPLICATION CRYPTOGRAM (AC) response Received from card during Initiate Application Processing Received from card during Read Application Data Received from card in GENERATE AC response From terminal or acquirer (optional) Received from card in GENERATE AC response From terminal or acquirer From terminal Transaction data from terminal From terminal From terminal Transaction data from terminal Transaction data from terminal

Application Cryptogram

Application Interchange Profile (AIP) Application PAN Sequence Number Application Transaction Counter (ATC) Interface Device (IFD) Serial Number Issuer Application Data Terminal Capabilities Terminal Country Code Terminal Verification Results (TVR) Transaction Currency Code Transaction Date Transaction Type Unpredictable Number

Draft 12/18/00
12–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.3 Terminal Data

The format of the online message from the terminal is outside the scope of the Visa Integrated Circuit Card Specification. The VisaNet online message format is described in the Visa Smart Debit/Credit System Technical Manual. The VSDC data elements in the online message may be considered in the issuer host decision to decline or approve the transaction. This issuer decision logic is outside the scope of the Visa Integrated Circuit Card Specification.

12.3.2 Online Response Data
The data elements listed in Table 12–5 are optional in the response message from the issuer to the acquirer. If present, these data elements shall be transmitted by the acquirer to the terminal.
Table 12–5: New Authorization/Financial Transaction Response Data Elements

Data Elements
Issuer Authentication Data

Description
Contains the following subfields:
q

Authorization Response Cryptogram (ARPC)—cryptogram generated by issuer host Authorization Response Code—response code used in generation of ARPC

q

Issuer Script

Contains command data from the issuer to be used to update the card application.

The Authorization Response Code in Table 12–5 is the code generated by the issuer during online processing and used in the generation of the Authorization Response Cryptogram (ARPC). This code shall not change in transmission from the issuer to the terminal. The terminal shall transmit this Authorization Response Code to the card as part of the Issuer Authentication Data.

Draft 12/18/00
31 Oct 2001
Visa Public

12–5

Online Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.4 Commands
Online Processing uses the GENERATE APPLICATION CRYPTOGRAM (AC) command response and the EXTERNAL AUTHENTICATE command and response. GENERATE APPLICATION CRYPTOGRAM (AC) response Prior to sending the online request, the terminal receives the card’s response to the GENERATE AC command. The command response is described in the EMV 4.0, Book 3, Part I, Section 2.5.5.4, and in Appendix B, Commands for Financial Transactions. EXTERNAL AUTHENTICATE If Issuer Authentication is to be performed after the online response is received, the terminal issues an EXTERNAL AUTHENTICATE command to ask the card to perform Issuer Authentication. The command is described in the EMV 4.0, Book 3, Part I, Section 2.5.4 and Appendix B, Commands for Financial Transactions. The command contains the Issuer Authentication Data shown in Table 12–5. The command response SW1 SW2 is “9000” if Issuer Authentication was successful.

12.5 Processing
Online Processing includes processing the online request, processing the online response, and optionally performing Issuer Authentication.

12.5.1 Online Request
After receiving the response to the first GENERATE AC command from the card, the terminal performs either Standard Online Processing only or Combined DDA/AC Generation Processing.

12.5.1.1 Combined DDA/AC Generation Processing
If Combined DDA/AC Generation was indicated in the GENERATE AC command and the response to GENERATE AC is an ARQC or TC, the terminal performs the processing indicated in the EMV 4.0, Book 2, Section 6.6. This includes the following processing: 1. 2. Uses the ICC Public Key to unlock the dynamic signature (Signed Dynamic Application Data) and recover the hash of data elements. Checks that the Cryptogram Information Data recovered matches the Cryptogram Information Data received in the clear in the GENERATE AC response.

Draft 12/18/00
12–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.5 Processing

3. 4.

Calculates a hash from the dynamic data elements that are in the clear. Checks that the calculated hash matches the hash recovered from the Signed Dynamic Application Data.

If any of the above steps fail, the terminal indicates Combined DDA/AC Generation failed in the TVR and proceeds to Completion. If all of the above steps are successful, Combined DDA/AC Generation has passed and the terminal continues processing as described in the next section.

12.5.1.2 Standard Online Processing
If Standard Online Processing is to be performed: 1. 2. Set the Card Risk Management Was Performed bit in the TSI to “1”. The terminal shall transmit an online request message if all of these conditions are true: – The terminal requested a Transaction Certificate (TC) or an Authorization Request Cryptogram (ARQC) in the GENERATE AC command The Cryptogram Information Data in the card’s response indicates an ARQC is being returned Combined DDA/AC Generation did not fail The terminal has online capability

– – – 3.

The terminal shall terminate the transaction if any of the following conditions occur: – – The terminal requested an Application Authentication Cryptogram (AAC) and the card returns an ARQC or a TC The terminal requested an ARQC and the card returns a TC

4.

The terminal shall proceed to the Completion function described in Chapter 13, Completion, if any of the following conditions occurs: – – – Combined DDA/AC Generation was performed and failed The card responds with an AAC or TC The card responds with an ARQC but the terminal is unable to process the transaction online

Draft 12/18/00
31 Oct 2001
Visa Public

12–7

Online Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.5.2 Online Response
During Online Response processing, the terminal receives the online response from the issuer host and determines whether Issuer Authentication should be performed. The terminal proceeds to:
q

The Issuer Authentication step described below in Section 12.5.3 if both of the following conditions are met: – – The authorization response contains the Issuer Authentication Data The card supports Issuer Authentication, as shown in the Application Interchange Profile (AIP)

q

The Completion function described in Chapter 13, Completion, if either of the following conditions occurs: – – The authorization response does not contain Issuer Authentication Data The card does not support Issuer Authentication, as shown in the AIP

12.5.3 Issuer Authentication
If Issuer Authentication is to be performed: 1. 2. 3. The terminal shall set the Issuer Authentication was Performed bit to “1” in the Transaction Status Information (TSI). The terminal shall transmit an EXTERNAL AUTHENTICATE command to the card. The card performs Issuer Authentication and transmits the EXTERNAL AUTHENTICATE command response to the terminal indicating whether Issuer Authentication was successful or failed. If the EXTERNAL AUTHENTICATE response indicates that Issuer Authentication failed (SW1 SW2 not equal to “9000”), the terminal shall set the Issuer Authentication was Unsuccessful bit to “1” in the Terminal Verification Results (TVR). The terminal shall then proceed to the Completion function described in Chapter 13, Completion.

4.

5.

Draft 12/18/00
12–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.5 Processing

12.5.4 Flow
The Online Processing flow is shown in Figure 12–1.
Figure 12–1: Online Processing
Terminal
GENERATE AC response Set Card Risk Management Performed to “1” in TSI Combined DDA/AC requested and TC or ARQC? Terminal validates dynamic signature & hash of static data

Card
Card Action Analysis Card returns response from first GENERATE AC

Issuer

Y

N
ARQC & terminal can process online?

Y

Valid?

N
N A If AAC returned or dynamic signature is not valid, the terminal indicates DDA/AC Generation failed in TVR Authorization Request with ARQC Issuer returns authorization response

Y
Terminal transmits online auth. request to issuer through acquirer

Terminal receives authorization response

Authorization Response with optional ARPC and/or issuer script

Issuer Authentication Data in response? N Y AIP shows card supports Issuer Authentication? Y Card performs Issuer Authentication (validates ARPC) EXTERNAL AUTHENTICATE command Terminal issues EXTERNAL AUTHENTICATE command Terminal receives EXTERNAL AUTHENTICATE response

N

Terminal proceeds to Completion. (See Chapter 13)

EXTERNAL AUTHENTICATE response

Terminal sets Issuer Auth. Performed to “1” in TSI

Response shows Issuer Authentication passed? Y Terminal proceeds to Completion (See Chapter 13)

N

Set Issuer Authentication was Unsuccessful to “1” in TVR

A

Draft 12/18/00
31 Oct 2001
Visa Public

12–9

Online Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

12.6 Prior Related Processing
Card Action Analysis In Card Action Analysis, the card sets Cryptogram Information Data (CID) to indicate the cryptogram type. An ARQC is used if the transaction should be sent online for authorization. The CID is returned to the terminal in the GENERATE AC response.

12.7 Subsequent Related Processing
Completion The card uses the Issuer Authentication results to determine the disposition of the transaction and whether to reset certain counters and indicators. If Combined DDA/AC Generation was performed and failed and the response to the first GENERATE AC was:
q

Approve (TC), the transaction shall be declined with a Z1. Go Online (ARQC), the terminal shall issue a second GENERATE AC requesting an AAC.

q

Issuer-to-Card Script Processing If the online response contained an Issuer Script, the card may consider the results of Issuer Authentication determine whether these updates may be applied.

Draft 12/18/00
12–10
Visa Public

31 Oct 2001

Completion

13

Completion is performed by the terminal and the card to conclude the transaction processing. Completion includes the following processing:
q

If online processing was requested and the terminal did not support online processing or the online authorization was unable to complete, the terminal and card perform additional analysis to determine whether the transaction should be approved or declined offline. If Combined DDA/Generate AC was performed and failed, the terminal processes as follows: – – If a TC was returned in the first GENERATE AC, the terminal issues an offline decline If an ARQC was returned in the first GENERATE AC, the terminal requests an AAC in the second GENERATE AC

q

q

An issuer’s online approval may be changed to a decline based upon Issuer Authentication results and card options. Indicators and counters are set to reflect what has occurred during transaction processing. After an online authorization, indicators and counters may be reset based upon Issuer Authentication status and card options.

q

q

The terminal may perform additional functions subsequent to completion, such as allowing the cardholder signature to be verified, printing a receipt, and capturing data for clearing. Additional Completion functions may be performed by the terminal if they do not interfere with the defined Completion functions. Completion shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Part II, Section 6.11, and Book 4, Part I, Section 8.2.

Draft 12/18/00
31 Oct 2001
Visa Public

13–1

Completion

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

This chapter is organized as follows: 13.1 Card Data 13.2 Terminal Data 13.3 GENERATE AC Command 13.4 Transaction Authorized Offline 13.5 Transaction Authorized Online 13.6 Online Processing Requested, Transaction Was Not Sent Online 13.7 Prior Related Processing

13.1 Card Data
The terminal uses the card data elements listed and described in Table 13–1 during Completion. For a detailed description of card elements and their usage, refer to the Visa Integrated Circuit Card Specification, Appendix A, Terminal and Acquirer Data Elements.
Table 13–1: Completion—Card Data

Data Element
Card Risk Management Data Object List 2 (CDOL2) Issuer Action Code—Default

Description
A list of data objects (tags and lengths) to be passed to the card with the final GENERATE AC command Contains a series of bits that correspond to the bits in the TVR. The issuer sets a bits to “1” in this IAC if the issuer would like the corresponding TVR condition to generate an offline decline when an online authorization cannot be completed. See Chapter 10, Terminal Action Analysis, for more information on the IAC—Default.

Draft 12/18/00
13–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.1 Card Data

The final GENERATE AC response data elements used in Completion are listed and described in Table 13–2.
Table 13–2: Completion—Final GENERATE AC Response Data

Data Element
Application Cryptogram Application Transaction Counter (ATC) Card Verification Results (CVR)

Description
Contains the value of the cryptogram. A counter of the number of transactions initiated since the application was put on the card. A Visa proprietary data element containing indicators that are set based upon the results of offline processing for current and previous transactions. Contains indicators including the type of cryptogram returned by the card:
q

Cryptogram Information Data (CID)

An Application Authentication Cryptogram (AAC) for a decline A Transaction Certificate (TC) for an approval An Authorization Request Cryptogram (ARQC) for online processing (first GENERATE AC only)

q

q

Issuer Application Data

Contains proprietary application data for transmission to the Issuer. This includes the CVR.

Draft 12/18/00
31 Oct 2001
Visa Public

13–3

Completion

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.2 Terminal Data
The terminal data elements listed and described in Table 13–3 are used by the terminal during Completion. For a detailed description of terminal data elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 13–3: Completion—Terminal Data

Data Elements
Authorization Response Code

Description
A terminal data element provided to the card which indicates the disposition of the transaction. Y1 = Offline approved Z1 = Offline declined Y3 = Unable to go online (offline approved) Z3 = Unable to go online (offline declined)

Terminal Verification Results (TVR) Terminal Action Code—Default

A terminal data element used to record offline processing results, such as SDA failure or floor limit exceeded, from a terminal perspective. Contains a series of Visa-defined bits that correspond to the bits in the TVR. When a bit is set to “1” in this TAC an offline decline is generated if the corresponding TVR condition is true and an online authorization cannot be completed. See Chapter 10, Terminal Action Analysis, for additional information on the TAC—Default.

13.3 GENERATE AC Command
The GENERATE APPLICATION CRYPTOGRAM (AC) command is used by the terminal to request that the card provide a cryptogram indicating the cards authorization response. The P1 parameter in the command indicates the type of cryptogram being requested as shown in the EMV 4.0, Book 3, Part I, Section 2.5.5, Table II-10. The data portion contains the data specified in the CDOL2 received from the card during Read Application Data. The response to the command contains the data shown in Table 13–2.

Draft 12/18/00
13–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.4 Transaction Authorized Offline

13.4 Transaction Authorized Offline
When the card responded with a Transaction Certificate (TC) or an Application Authentication Cryptogram (AAC) in response to the first GENERATE AC command, the terminal shall complete the transaction offline. The terminal should display a message to indicate the action taken (approved, declined, or service not allowed) as indicated in the Cryptogram Information Data (CID) returned in the response to the first GENERATE AC and as shown in Table 13–4. If the TVR indicates that Combined DDA/AC Generation failed, the transaction is declined by the terminal as follows:
q

If a TC was returned in the first GENERATE AC command, the transaction is declined with a Z1 Response Code If an ARQC was returned in the first GENERATE AC command, the terminal requests an AAC in the second GENERATE AC

q

Table 13–4:

Offline Transaction Disposition Response

First GENERATE AC response cryptogram type in CID
TC and Combined DDA/AC Generation not performed or Passed AAC ARQC or TC and Combined DDA/AC Generation Failed

Authorization Response Code
Y1

Transaction Disposition
Offline approved

Z1 Z1

Offline declined Offline declined

Draft 12/18/00
31 Oct 2001
Visa Public

13–5

Completion

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.5 Transaction Authorized Online
13.5.1 Transmit Final GENERATE AC to the Card
If the online authorization was successfully completed, the terminal issues a final GENERATE AC command to the card to request additional card analysis and a final Application Cryptogram. The terminal uses the Authorization Response Code received from the issuer in the online authorization response to determine the type of cryptogram to request from the card:
q

If the issuer has approved the transaction (Authorization Response Code = 00, 10, or 11), the terminal requests an approval (TC). If the issuer has requested a referral (Authorization Response Code = 01 or 02), it is recommended that the terminal request a decline (AAC). If the Authorization Response Code does not indicate approve or refer, the terminal requests an AAC.

q

q

For additional information on Authorization Response Codes (V.I.P. Field 39), refer to the V.I.P. System Technical Reference, Volume 2, Field and Code Descriptions.

13.5.2 Terminal Receives Final GENERATE AC Response
When the terminal receives the card’s response to the GENERATE AC command, it performs the steps described in the following sections.

13.5.2.1 Issuer-to-Card Script Processing
Before completing the transaction, the terminal shall process the Issuer Script, if present in the online message as described in Chapter 14, Issuer-toCard Script Processing. The terminal shall not display a message indicating that the transaction has been approved or declined until after the completion of Issuer Script processing to ensure that the card was not removed from the terminal during Issuer Script processing. If Issuer Script processing was performed for the transaction, the terminal should ensure that a message, such as a clearing or advice is transmitted that contains the results of Issuer Script processing. The message may be transmitted for reasons other than Issuer Script processing or may be transmitted solely for the purpose of conveying the Issuer Script Results.

Draft 12/18/00
13–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.5 Transaction Authorized Online

13.5.2.2 Terminal Requested an AAC in the Final GENERATE AC
If the terminal requested an AAC in the final GENERATE AC command, the terminal responds with a decline regardless of the cryptogram type returned by the card in the final GENERATE AC response. The terminal shall complete the transaction and display a message indicating that the transaction was declined.

13.5.2.3 Terminal Requested a TC in the Final GENERATE AC
If the card responds with a TC, the terminal shall complete the transaction and display a message indicating that the transaction was approved. If the card responds with an AAC after the final GENERATE AC, the terminal shall complete the transaction and display a message indicating that the transaction was declined. NOTE: At an ATM, if a cash disbursement or account transfer transaction was declined by the card because of an issuer authentication failure, after the card transmits the AAC to the ATM in the response to the final GENERATE AC command, the ATM shall transmit a reversal. If a balance inquiry transaction is declined for the same reason, the ATM shall not display the balance. At a POS device, if an online-approved purchase transaction is declined by the card because of an Issuer Authentication failure, a reversal is required if the acquirer’s authorization system is single message or host-data-capture.

Draft 12/18/00
31 Oct 2001
Visa Public

13–7

Completion

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.6 Online Processing Requested, Transaction Was Not Sent Online
13.6.1 Check IAC and TAC-Default Settings
If online processing is requested and the terminal does not support online processing or is unable to send the transaction online, the terminal performs Terminal Action Analysis using the Issuer Action Code (IAC)—Default and the Terminal Action Code (TAC)—Default. This processing is identical to the process described in Chapter 10, Terminal Action Analysis, except that only the default IACs and TACs are used.

13.6.2 Issue Final GENERATE AC Command
Based on the results of this processing, the terminal sets the P1 parameter in the final GENERATE AC command to indicate that an AAC (decline) or TC (approval) is being requested. The data specified in the CDOL2 is included in the data portion of the command. The Authorization Response Code in this data is determined as shown in Table 13–5.
Table 13–5: Online Transaction Disposition Response

Terminal Requests
TC AAC

Authorization Response Code
Y3 Z3

Transaction Disposition
Unable to go online (offline approved) Unable to go online (offline declined)

The terminal then issues the final GENERATE AC command that includes the Authorization Response Code.

13.6.3 Terminal Completes Transaction
Upon receipt of the card’s response to the final GENERATE AC command, the terminal performs the following processing.

13.6.3.1 Terminal Requested AAC in Final GENERATE AC
If the terminal requested an AAC in the final GENERATE AC, the terminal shall complete the transaction as a decline regardless of the Cryptogram Type returned by the card. The terminal shall display a message indicating that the transaction was declined.

Draft 12/18/00
13–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.6 Online Processing Requested, Transaction Was Not Sent Online

13.6.3.2 Terminal Requested TC in Final GENERATE AC
If the terminal requested a TC in the final GENERATE AC, it examines the Cryptogram Type specified in the Cryptogram Information Data returned in the GENERATE AC response.
q

If the card responds with a TC, the terminal shall complete the transaction and display a message indicating that the transaction was approved. If the card responds with an AAC, the terminal shall complete the transaction and display a message indicating that the transaction was declined.

q

Draft 12/18/00
31 Oct 2001
Visa Public

13–9

Completion

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 13–1: Completion Processing Flow

Card

Terminal
Terminal analyzes first GENERATE AC response

Cryptogram = AAC? N Cryptogram = TC?

Y

Set Authorization Response Code to Z1 (decline)

B

Y

Combined DDA/AC Gen failed?

Y

Set Auth. Resp. Code to Z1 (decline)

N
ARQC & DDA/AC Gen. failed?

N Y
Set P1 in GEN AC to AAC (decline) Set Auth. Resp.Code to Y1 (approve)

A

N C
Transaction completed online? Y Y Set P1 in GEN AC to TC (approval) or AAC (decline) based on Auth. Resp. Code

N

((IAC-Def. OR TAC-Def.) & TVR) = 0? Y Set Authorization Response Code to Y3 & P1 to TC

N Set Authorization Response Code to Z3 & P1 to AAC

Card receives Final Generate AC

Final GENERATE AC Command

Issue Final GENERATE AC command

C

Card responds to Final GENERATE AC with TC (approve) or AAC (decline)

Final GENERATE AC Response

Receives Final GENERATE AC response

Card responded with a TC? Y N Terminal requested an AAC?

Terminal processes Issues Script if in auth. response

Y

A
N

B

Terminal responds with an approval

Terminal responds with a decline

Draft 12/18/00
13–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

13.7 Prior Related Processing

13.7 Prior Related Processing
Card Action Analysis The card’s response to the first GENERATE AC may indicate a TC or AAC indicating an offline approval or decline. Online Processing The Authorization Response Code is received in the authorization response.

Draft 12/18/00
31 Oct 2001
Visa Public

13–11

Issuer-to-Card Script Processing

14

Issuer-to-Card Script Processing permits issuers to change personalized data on cards without reissuance. With this function the issuer transmits commands in issuer scripts contained in the authorization response message. The terminal passes these commands to the card where they are executed if security requirements are satisfied. Issuer-to-Card Script Processing shall be performed as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 3, Section 6.10, and Book 4, Section 2.3.9. This chapter is organized in the following manner: 14.1 Card Data 14.2 Terminal Data 14.3 Online Response Data 14.4 Commands 14.5 Processing 14.6 Prior Related Processing

Draft 12/18/00
31 Oct 2001
Visa Public

14–1

Issuer-to-Card Script Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

14.1 Card Data
During Issuer-to-Card Script Processing, the terminal uses no data elements from the card.

14.2 Terminal Data
The terminal data listed and described in Table 14–1 is used in Issuer-to-Card Script Processing. For a detailed description of these elements and their usage, see Appendix A, Terminal and Acquirer Data Elements.
Table 14–1: Issuer-to-Card Script Processing—Terminal Data

Data Elements
Terminal Verification Results (TVR)

Description
Contains two script related flags:
q

Issuer Script Failed before final GENERATE APPLICATION CRYPTOGRAM (AC) Command—shall be set to “1” if Issuer Script processing fails Issuer Script Failed after final GENERATE AC Command—shall be set to “1” if Issuer Script processing fails

q

Transaction Status Information (TSI) Issuer Script Results

The TSI a bit, which is set to “1” when Issuer-to-Card Script processing is performed.

Issuer Script Results are returned to the issuer through a clearing message, another message such as a reversal, the next online authorization, or an offline advice message. It is a 5–byte field defined as follows: Byte 1 Contains the results of script processing and the sequence number of the command, which failed script processing. This sequence number is zero if script processing is successful. Contain the Issuer Script Identifier received in the Issuer Script.

Bytes 2–5

Although it is preferable that the terminal transmit the full five-byte Issuer Script Results to the acquirer, it is acceptable for the terminal to transmit only the first byte indicating script results. If this is done, the following shows the mapping from the one-byte Issuer Script Results transmitted by the terminal to the five-byte Issuer Script Results transmitted by the acquirer to Visa.

Mapping Terminal Issuer Script Results to Acquirer Issuer Script Results
Terminal to Acquirer Issuer Script Results (only 1 byte is transmitted: byte 1, indicating actual script results) Acquirer to V.I.P./BASE II Map 1 byte transmitted by terminal into first byte; zero fill next 4 bytes (Script Identifier)

Draft 12/18/00
14–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

14.3 Online Response Data

14.3 Online Response Data
The response to the online authorization request may contain the data (described in Table 14–2) that is used in Issuer-to-Card Script Processing.
Table 14–2: Issuer-to-Card Script Processing—Online Response Data

Data Element
Issuer Script

Description
This version of the Visa Integrated Circuit Card Specification supports at most one Issuer Script per response. The Issuer Script may contain one or more commands. In a subsequent version of this specification, issuers may transmit more than one Issuer Script. The tag for the script should be “72”. The format of the Issuer Script is shown in Figures 5 and 6 of the EMV 4.0, Book 3, Section 6.10.

14.4 Commands
The Visa-defined Issuer Script Commands support the functions listed below and are described in detail in the Card Volume of the specification and in the EMV 4.0, Book 3, Section 2.5, and the Visa Integrated Circuit Card Specification, Appendix C, Commands for Financial Transactions. Issuer proprietary commands may also be received and should be passed through to the card. APPLICATION BLOCK The command blocks the use of the selected application. If during the processing of a transaction, the application is blocked, the terminal shall continue to process the transaction through completion. APPLICATION UNBLOCK Unblocking the application reverses the APPLICATION BLOCK status. Unblocking of an application occurs only at a special device as designated by the issuer. The processing by this device is described in the Visa Integrated Circuit Card Specification, Chapter 14, Issuer-to-Card Script Processing. CARD BLOCK The CARD BLOCK command is a post-issuance command that permanently disables all applications on the card. If the card is blocked during the processing of a transaction, the terminal shall continue to process the transaction through completion.

Draft 12/18/00
31 Oct 2001
Visa Public

14–3

Issuer-to-Card Script Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

PIN CHANGE/UNBLOCK The PIN CHANGE/UNBLOCK command provides the issuer the capability either to unblock the offline PIN or to simultaneously change and unblock the reference PIN. PIN changes should only be performed within a secure environment controlled by the issuer. PUT DATA The PUT DATA command allows specific primitive data objects in the card to be updated. UPDATE RECORD The UPDATE RECORD command is used to update a record in a file with the data provided in the command data field.

14.5 Processing
The terminal shall process Issuer Scripts as described in the following sections.

14.5.1 Issuer Scripts
The Issuer Script shall be passed to the terminal if it is transmitted to the acquirer in the response message. In this version of the Visa Integrated Circuit Card Specification, at most only one Issuer Script is transmitted in the response message. In a subsequent version, multiple Issuer Scripts may be allowed in a response message. An Issuer Script transmitted in the response message should always have tag “72”, indicating that Issuer-to-Card Script Processing is to be performed after the final GENERATE AC command. If the online response message contains an Issuer Script, the terminal shall set the Issuer Script processing was Performed bit to “1” in the Transaction Status Information (TSI).

14.5.2 Multiple Commands
The Issuer Script may contain multiple commands. The terminal shall parse out each Issuer Script command contained in the Issuer Script and transmit the commands to the card one by one. For each command, the terminal shall increment the sequence number in Issuer Script Results.

Draft 12/18/00
14–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

14.5 Processing

14.5.3 Script Errors
If the SW1 return code is not equal to “90” in the card’s response to the Issuer Script command indicating that processing of the command failed, the terminal shall:
q

Terminate processing of that Issuer Script. Set the Issuer Script Processing Failed After Final GENERATE AC bit to “1” in the Terminal Verification Results (TVR). Set Issuer Script Result Byte 1, bit 5, to 1. Proceed to the next Issuer Script, if present.

q

q

q

14.5.4 Multiple Scripts
The terminal should not receive multiple Issuer Scripts. If multiple scripts are received, the terminal shall process the scripts as described in the EMV 4.0, Book 4, Section 2.3.9.

14.5.5 Issuer Script with Tag “71”
The terminal should not receive an Issuer Script with tag “71” indicating that Issuer Script processing is to be performed prior to the final GENERATE AC command. If an Issuer Script with tag “71” is received, the terminal shall process the script as described in the EMV 4.0, Book 4, Section 2.3.9.

14.5.6 Terminal Messages
The terminal shall not display a message indicating that the transaction has been approved or declined until after the completion of Issuer Script processing to ensure that the card is not removed from the terminal during Issuer Script processing.

14.5.7 Issuer Notification
If Issuer Script processing was performed for the transaction, the terminal should ensure that a message such as a clearing, next online authorization, or advice message is transmitted that contains the results of Issuer Script processing. The message may be transmitted for reasons other than Issuer Script processing or may be transmitted solely for the purpose of conveying the Issuer Script Results.

14.5.8 Process Flow
Issuer-to-Card Script Processing might be performed as shown in Figure 14–1.

Draft 12/18/00
31 Oct 2001
Visa Public

14–5

Issuer-to-Card Script Processing

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure 14–1: Issuer-to-Card Script Processing

Card
Terminal completes Online Processing and Completion

Terminal

Issuer Script present in online response? Y Terminal parses out Issuer Script command in sequential order

N

Terminal increments script command sequence number

Y Y

Card executes script command

Script Command

Terminal sends command to card

N

Script Command Response

Terminal receives command response from card

SW1 W2 = 9000

Y

Another command present?

N Terminal sets Script Processing Failed after final GEN AC in TVR N

Another script present? N Terminal sets Issuer Script Processing Performed in TSI

Terminal completes transaction processing

Draft 12/18/00
14–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

14.6 Prior Related Processing

14.6 Prior Related Processing
Online Processing The terminal may receive an Issuer Script in the authorization response message. Completion The Completion function will transfer to Issuer-to-Card Script Processing if an Issuer Script was present in the online response.

Draft 12/18/00
31 Oct 2001
Visa Public

14–7

Terminal and Acquirer Data Elements

A

This appendix defines those data elements that may be used for financial transaction interchange and their mapping onto data objects. This includes all terminal or acquirer data objects listed in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, and the Visa proprietary data elements. Also included is a list of terminal data element tags. Card data and issuer data elements are listed in the Visa Integrated Circuit Card, Card Specification. NOTE: Although Visa does not support certain terminal-related data objects listed in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, in this version of the Visa Integrated Circuit Card Specification (VIS), other payment systems may choose to support these data objects. Therefore, the terminal shall support all terminal-related data objects listed in those specifications.

A.1 Terminal and Acquirer Data Elements Table
When the length defined for the data object is greater than the length of the actual data, the following rules apply:
q

A data element in format n is right-justified and padded with leading hexadecimal zeros A data element in format cn is left-justified and padded with trailing hexadecimal Fs A data element in format an is left-justified and padded with trailing hexadecimal zeros A data element in format ans is left-justified and padded with trailing hexadecimal zeros

q

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

A–1

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from high order to low order, regardless of how it is internally stored. The same rules applies when concatenating data.
Table A–1: Terminal and Acquirer Data Elements (1 of 20)

Name (Format; Tag; Length)
Acquirer Identifier F: n 6-11 T: 9F01 L: 6 Additional Terminal Capabilities F: b 40 T: 9F40 L: 5

Requirement
O

Description
Uniquely identifies the acquirer within each payment system. For Visa, this is the BASE Identification Number (BIN).

Values

M

Indicates the data input and output capabilities of the terminal.

q

Byte 1 (Transaction Type Capability): bit 8: bit 7: bit 6: bit 5: bit 4: bit 3: bit 2: bit 1: 1 = Cash 1 = Goods 1 = Services 1 = Cashback 1 = Inquiry 1 = Transfer 1 = Payment 1 = Administrative

q

Byte 2 (Transaction Type Capability, cont.): bits 8–1: Reserved for future use (RFU) (“00”)·

q

Byte 3 (Terminal Data Input Capability): bit 8: 1 = Numeric keys bit 7: 1 = Alphabetic and special characters keys bit 6: 1 = Command keys bit 5: 1 = Function keys bits 4–1: RFU (0000)

Draft 12/18/00
A–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (2 of 20)

Name (Format; Tag; Length)
Additional Terminal Capabilities (continued)

Requirement

Description

Values
q

Byte 4 (Terminal Data Output Capability): bit 8: 1 = Print, attendant bit 7: 1 = Print, cardholder bit 6: 1 = Display, attendant bit 5: 1 = Display, cardholder bits 4–3: RFU (00) bit 2: 1 = Code table 10 bit 1: 1 = Code table 9

q

Byte 5 (Terminal Data Output Capability, cont.): bit 8: bit 7: bit 6: bit 5: bit 4: bit 3: bit 2: bit 1: 1 = Code table 8 1 = Code table 7 1 = Code table 6 1 = Code table 5 1 = Code table 4 1 = Code table 3 1 = Code table 2 1 = Code table 1

Amount, Authorized (Binary) F: b 32 T: 81 L: 4 Amount, Authorized (Numeric) F: n 12 T: 9F02 L: 6 Amount, Other (Binary) F: b 32 T: 9F04 L: 4

not applicable

Authorized amount of the transaction (excluding adjustments). This data object is not used in this version of VIS.

M

Authorized amount of the transaction (excluding adjustments).

not applicable

Secondary amount associated with the transaction representing a cashback amount. This data object is not used in this version of VIS.

Draft 12/18/00
31 Oct 2001
Visa Public

A–3

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (3 of 20)

Name (Format; Tag; Length)
Amount, Other (Numeric) F: n 12 T: 9F03 L: 6 Amount, Reference Currency (Binary) F: b 32 T: 9F3A L: 4 Amount, Transaction F: n 12 T: – L: 6 Application Identifier (AID) F: b 40-128 T: 9F06 L: 5–16

Requirement
C If cashback supported

Description
Secondary amount associated with the transaction representing a cashback amount.

Values

not applicable

Authorized amount expressed in the reference currency. This data object is not used in this version of VIS.

M

Transaction amount including tips and other adjustments; the clearing amount of the transaction.

M

Identifies the application as described in ISO/IEC 7816-5.

The AID consists of two parts: The Registered Application Provider Identifier (RID), which identifies the application provider (scheme); and the Proprietary Application Identifier Extension (PIX), which identifies the application within the application provider.

Draft 12/18/00
A–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (4 of 20)

Name (Format; Tag; Length)
Application Selection Indicator F: – T: – L: –

Requirement
M

Description
Indicates whether the associated AID in the terminal must match the AID in the card exactly including the length of the AID, or only up to the length of the AID in the terminal. There is only one Application Selection Indicator per AID in the terminal.

Values
Format and content are at the discretion of the terminal vendor. For Visa applications, must be set to allow partial selection.

Application Version Number F: b 16 T: 9F09 L: 2

M

Version number assigned by the payment system for the application.

The Application Version Number is the version, release, and modification number in binary of VIS supported by the terminal. For terminals supporting VIS 1.3.1, the value is 131, coded in binary. For terminals supporting VIS 1.3.2, the value is 132, coded in binary. For terminals supporting VIS 1.4.0, the value is 140, coded in binary. Codes generated by the issuer are as indicated in International Organisation for Standardisation (ISO) 8583:1987. The following codes are generated by the terminal for the following exception conditions: Y1 = Offline approved Z1 = Offline declined Y2 = Approved (after card-initiated referral) (not supported in this version of VIS) Z2 = Declined (after card-initiated referral) (not supported in this version of VIS) Y3 = Unable to go online (offline approved) Z3 = Unable to go online (offline declined)

Authorization Response Code F: an 2 T: 8A L: 2

M

Indicates the disposition of the transaction received from Issuer for online authorizations

Draft 12/18/00
31 Oct 2001
Visa Public

A–5

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (5 of 20)

Name (Format; Tag; Length)
Cardholder Verification Method (CVM) Results F: b 24 T: 9F34 L: 3

Requirement
M

Description
Indicates the results of the last CVM performed.

Values
q

Byte 1 (CVM Performed): Last CVM of the CVM List actually performed by the terminal. Coded as a 1-byte CVM Code (as defined in the CVM List) (“3F” if no CVM is performed).

q

Byte 2 (CVM Condition): Coded as a 1-byte CVM Condition Code (as defined in the CVM List)·

q

Byte 3 (CVM Result): Result of the (last) CVM performed as know by the terminal: 00 = Unknown (for example, for signature) 01 = Failed (for example, for offline PIN) 02 = Successful (for example, for offline PIN)

Certificate Authority Public Key F: b T: – L: – Certificate Authority Public Key Check Sum F: b T: – L: 20

C If SDA, DDA, or Offline Enciphered PIN supported

Payment system public key used for offline static or dynamic data authentication.

Value generated by Visa and loaded to terminal by acquirer. Up to six Visa public keys must be supported.

C If SDA, DDA, or Offline Enciphered PIN supported

A check value calculated on the concatenation of all parts of the Certificate Authority Public Key (RID, Certificate Authority Public Key Index, Certificate Authority Public Key Modulus, Certificate Authority Public Key Exponent) using SHA-1.

Draft 12/18/00
A–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (6 of 20)

Name (Format; Tag; Length)
Certificate Authority Public Key Exponent F: b T: – L: 1 or 3 Certificate Authority Public Key Index (PKI) F: b 8 T: 9F22 L: 1 Certificate Authority Public Key Modulus F: b T: – L: NCA (up to 248) Command Template F: b T: 83 L: var. Default Dynamic Data Authentication Data Object List (DDOL) F: b T: – L: var.

Requirement
C If SDA, DDA, or Offline Enciphered PIN supported

Description
Value of the exponent part of the Certificate Authority Public Key.

Values

C If SDA, DDA, or Offline Enciphered PIN supported

Identifies the Certificate Authority’s public key in conjunction with the RID for use in offline static data authentication.

Values assigned by Visa.

C If SDA, DDA, or Offline Enciphered PIN supported

Value of the modulus part of the Certificate Authority Public Key.

M

Identifies the data field of a command message.

C If DDA is supported

DDOL to be used for constructing the INTERNAL AUTHENTICATE command if the DDOL in the card is not present.

Must contain tag for Unpredictable Number (“9F37”) only.

Draft 12/18/00
31 Oct 2001
Visa Public

A–7

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (7 of 20)

Name (Format; Tag; Length)
Default Transaction Certificate Data Object List (TDOL) F: b T: – L: var. Enciphered Personal Identification Number (PIN) Data F: b 64 T: – L: 8 Interface Device (IFD) Serial Number F: an 8 T: 9F1E L: 8

Requirement
O

Description
TDOL to be used to generate the TC Hash Value if the TDOL in the card is not present. Not currently used in any VSDC cryptograms defined by Visa.

Values

C If online PIN supported or if PIN pad and card reader separate

Transaction PIN enciphered at the PIN pad for online verification or for offline verification if the PIN pad and the interface device (IFD) are not a single integrated device.

M

Unique and permanent serial number assigned to the IFD by the manufacturer.

Value assigned by IFD manufacturer.

Draft 12/18/00
A–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (8 of 20)

Name (Format; Tag; Length)
Issuer Script Results F: b T: 9F5B L: var.

Requirement
M

Description
Indicates the results of Issuer Script processing. Note: When the terminal transmits this data element to the acquirer, in this version of VIS, it is acceptable that only byte 1 is transmitted, although it is preferable for all 5 bytes to be transmitted.

Values
q

Byte 1(Issuer Script Result): bits 8–5: Result of the Issuer Script processing performed by the terminal: 0 = Issuer Script not performed 1 = Issuer Script processing failed 2 = Issuer Script processing successful bits 4–1: Sequence number of the Issuer Script Command: 0 = Not specified 1-E = Sequence number 1–14 F = Sequence number 15 or above

q

Bytes 2–5 (Issuer Script Identifier): Issuer Script Identifier received by the terminal, if available; zero filled if not available. Mandatory if more than one Issuer Script was received by the terminal.

Bytes 1–5 are repeated for each Issuer Script processed by the terminal, although in this version of VIS, only one Issuer Script may be transmitted in the response message. Maximum Target Percentage to be Used for Biased Random Selection F: – T: – L: – Merchant Category Code F: n 4 T: 9F15 L: 2 M Classifies the type of business being done by the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code. C If offline capable terminal Value used in terminal risk management for random transaction selection.

Draft 12/18/00
31 Oct 2001
Visa Public

A–9

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (9 of 20)

Name (Format; Tag; Length)
Merchant Identifier F: ans 15 T: 9F16 L: 15

Requirement
M (at terminal or acquirer)

Description
When concatenated with the Acquirer Identifier, uniquely identifies a given merchant within a given country. May be located in the terminal or inserted into messages by the acquirer. Indicates the name and location of the merchant. May be located in the terminal or inserted into messages by the acquirer.

Values

Merchant Name and Location F: ans T: – L: var. Message Type F: n 2 T: – L: 1

M (at terminal or acquirer)

C If advices supported

Indicates whether the batch data capture record is a financial record or advice.the terminal or inserted into messages by the acquirer. Secret key of a symmetric algorithm used by the PIN pad to encipher the PIN and by the card reader to decipher the PIN if the PIN pad and card reader are not integrated. Note: This is not the key used for Offline Enciphered PIN.

Personal Identification Number (PIN) Pad Secret Key F: – T: – L: –

C If PIN pad and card reader not integrated

Draft 12/18/00
A–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (10 of 20)

Name (Format; Tag; Length)
Point of Service (POS) Entry Mode Code F: n 2 T: 9F39 L: 1

Requirement
M

Description
Indicates the method by which the PAN was entered, according to the first two digits of ISO 8583:1987.

Values
Codes are as indicated in ISO 8583:1987 with the following additions. If the magnetic stripe is read instead of the ICC, the terminal may indicate this by generating the following codes for transmission to the acquirer. 90 = Magnetic stripe read; service code does not begin with “2”or “6” 91 = Magnetic stripe read; service code begins with “2”or “6”; last transaction was a successful IC read or was not an IC transaction 92 = Magnetic stripe read; service code begins with “2”or “6”; last transaction was an unsuccessful IC read Note: The new codes 91 and 92 are not transmitted in the POS Entry Mode Code from the acquirer to Visa.

Point of Service (POS) Terminal Capability

M (terminal or acquirer) M

See Terminal Entry Capability.

Proprietary Application Identifier Extension (PIX) F: b T: part of AID L: 0–11 Registered Application Provider Identifier (RID) F: b T: part of AID L: 5

As part of the Application Identifier (AID), identifies the application within the application provider (scheme).

The currently assigned Visa PIXs used for VSDC are: 1010—Visa 2010—Electron 3010—Interlink 999910—Proprietary ATM

M

As part of the Application Identifier (AID), a uniquely-assigned number that identifies the application provider (scheme).

Visa’s RID is A000000003.

Draft 12/18/00
31 Oct 2001
Visa Public

A–11

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (11 of 20)

Name (Format; Tag; Length)
Status of Last Chip Attempt F: n 1 T: – L: –

Requirement
C Mag stripe initiated from a IC reading terminal

Description
V.I.P./BASE II data element indicating for a magnetic stripe initiated transaction whether the previous transaction at the terminal was a successful IC read.

Values
Values are: 0 = Service code does not begin with “2”or “6” 1 = Service code begins with “2”or “6”; last transaction was a successful IC read or was not an IC transaction 2 = Service code begins with “2”or “6”; last transaction was an unsuccessful IC read

Target Percentage to be Used for Random Selection F: – T: – L: – Terminal Action Code—Default F: b 40 T: – L: 5

C If online/offline terminal

Value used in terminal risk management for random transaction selection.

Visa may establish a range of values.

C If offline capable terminal

Specifies payment scheme conditions that cause a transaction to be declined if it might have been approved online, but the terminal is unable to process the transaction online. Specifies payment scheme conditions that cause the decline of a transaction without attempting to go online.

Bit assignments are identical to those for Terminal Verification Results (TVR). The permissible values for the TAC—Default in this version of VIS is are shown in Chapter 10, Table 10–3.

Terminal Action Code—Denial F: b 40 T: – L: 5 Terminal Action Code–Online F: b 40 T: – L: 5

C If offline capable terminal

Bit assignments are identical to those for Terminal Verification Results (TVR). The permissible values for the TAC—Denial in this version of VIS is are shown in Chapter 10, Table 10–3.

C If online/offline terminal

Specifies payment scheme conditions that cause a transaction to be transmitted online.

Bit assignments are identical to those for Terminal Verification Results (TVR). The permissible values for the TAC—Online in this version of VIS is are shown in Chapter 10, Table 10–3.

Draft 12/18/00
A–12
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (12 of 20)

Name (Format; Tag; Length)
Terminal Capabilities F: b 24 T: 9F33 L: 3

Requirement
M

Description
Indicates the card data input, CVM, and security capabilities of the terminal.

Values
q

Byte 1 (Card Data Input Capability): bit 8: bit 7: bit 6: bits 5–1: 1 = Manual key entry 1 = Magnetic stripe 1 = IC with contacts RFU (00000)

q

Byte 2 (CVM Capability): bit 8: 1 = Plaintext PIN for offline CC verification bit 7: 1 = Enciphered PIN for online verification bit 6: 1 = Signature (paper) bit 5: 1 = Enciphered PIN for offline verification bits 4–1: RFU (00000)

q

Byte 3 (Security Capability): bit 8: 1 = Offline static data authentication bit 7: 1 = Offline dynamic data authentication bit 6: 1 = Card capture bit 5: 1 = Combined dynamic data authentication/application cryptogram generation bits 4–1: RFU (00000)

Terminal Country Code F: n 3 T: 9F1A L: 2 Terminal Entry Capability F: n 1 T: – L: –

M

Indicates the country of the terminal represented according to ISO 3166.

M (terminal or acquirer)

V.I.P./BASE II data element indicating whether the terminal supports reading of the IC, magnetic stripe, etc.

The ICC-related value is: 5 = ICC reading supported by terminal

Draft 12/18/00
31 Oct 2001
Visa Public

A–13

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (13 of 20)

Name (Format; Tag; Length)
Terminal Floor Limit F: b 32 T: 9F1B L: 4 Terminal Identification F: an 8 T: 9F1C L: 8 Terminal Risk Management Data F: b 8–64 T: 9F1D L: 1–8

Requirement
C If offline capable terminal

Description
Indicates the floor limit in the terminal in conjunction with the AID.

Values

M (at terminal or acquirer)

Designates the unique location of a terminal at a merchant.

O

Application-specific value used by the card for risk management purposes.

Draft 12/18/00
A–14
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (14 of 20)

Name (Format; Tag; Length)
Terminal Type F: n 2 T: 9F35 L: 1

Requirement
M

Description
Indicates the environment of the terminal, its communications capability, and its operational control.

Values
Values are: 11 = Attended, online only, operated by financial institution 12 = Attended, offline with online capability, operated by financial institution 13 = Attended, offline only, operated by financial institution 14 = Unattended, online only, operated by financial institution 15 = Unattended, offline with online capability, operated by financial institution 16 = Unattended, offline only, operated by financial institution 21 = Attended, online only, operated by merchant 22 = Attended, offline with online capability, operated by merchant 23 = Attended, offline only, operated by merchant 24 = Unattended, online only, operated by merchant 25 = Unattended, offline with online capability, operated by merchant 26 = Unattended, offline only, operated by merchant 34 = Unattended, online only, operated by cardholder 35 = Unattended, offline with online capability, operated by cardholder 36 = Unattended, offline only, operated by cardholder

Draft 12/18/00
31 Oct 2001
Visa Public

A–15

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (15 of 20)

Name (Format; Tag; Length)
Terminal Verification Results (TVR) F: b 40 T: 95 L: 5

Requirement
M

Description
Status of the different functions as seen from the terminal. Note: The issuer needs to set the “Issuer Script processing failed after final GENERATE AC” bit to “0” prior to validating the TC.

Values
q

Byte 1 bit 8: bit 7: bit 6: bit 5: bit 4: bit 3: bits 21: 1 = Offline data authentication was not performed 1 = Offline static data authentication failed 1 = ICC data missing 1 = Card appears on terminal exception file 1 = Offline dynamic data authentication failed 1 = Combined DDA/AC Generation failed RFU (000)

q

Byte 2 bit 8: 1 = ICC and terminal have different application versions bit 7: 1 = Expired application bit 6: 1 = Application not yet effective bit 5: 1 = Requested service not allowed for card product bit 4: 1 = New card bits 3–1: RFU (000)

q

Byte 3 bit 8: 1 = Cardholder verification was not successful bit 7: 1 = Unrecognized CVM bit 6: 1 = PIN Try Limit exceeded bit 5: 1 = PIN entry required and PIN pad not present or not working bit 4: 1 = PIN entry required, PIN pad present, but PIN was not entered bit 3: 1 = Online PIN entered bits 2–1: RFU (00)

Draft 12/18/00
A–16
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (16 of 20)

Name (Format; Tag; Length)
Terminal Verification Results (TVR) (continued)

Requirement

Description

Values
q

Byte 4 bit 8: 1 = Transaction exceeds floor limit bit 7: 1 = Lower consecutive offline limit (“9F14”) exceeded bit 6: 1 = Upper consecutive offline limit (“9F23”) exceeded bit 5: 1 = Transaction selected randomly for online processing bit 4: 1 = Merchant forced transaction online bits 3–1: RFU (000)

q

Byte 5 bit 8: bit 7: bit 6: bit 5: 1 = Default TDOL used 1 = Issuer authentication was unsuccessful 1 = Issuer Script processing failed before final GENERATE AC command 1 = Issuer Script processing failed after final GENERATE AC command

Note: bits 4–1: RFU (0000) Threshold Value for Biased Random Selection F: – T: – L: – Transaction Amount F: n12 T: – L: – 6 R Clearing amount of the transaction, including tips and other adjustments. C If online and offline terminal Value used in terminal risk management for random transaction selection. Visa may establish a range of values.

Draft 12/18/00
31 Oct 2001
Visa Public

A–17

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (17 of 20)

Name (Format; Tag; Length)
Transaction Certificate (TC) Hash Value F: b 160 T: 98 L: 20 Transaction Currency Code F: n 3 T: 5F2A L: 2

Requirement
O

Description
Result of a hash function specified in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, Book 3, Section 5.2.2.

Values

M

Indicates the currency code of the transaction according to ISO 4217. The implied exponent is indicated by the minor unit of currency associated with the Transaction Currency Code in ISO 4217. Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217.

Transaction Currency Exponent F: n 1 T: 5F36 L: 1 Transaction Date F: n 6 YYMMDD T: 9A L: 3 Transaction Personal Identification Number (PIN) Data F: b T: 99 L: var.

M

M

Local date that the transaction was authorized.

C If PIN supported

Data entered by the cardholder for the purpose of PIN verification.

Draft 12/18/00
A–18
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (18 of 20)

Name (Format; Tag; Length)
Transaction Reference Currency Code F: n 3 T: 9F3C L: 2

Requirement
not applicable

Description
Code defining the common currency used by the terminal in case the Transaction Currency Code is different from the Application Currency Code. This data object is not used in this version of VIS.

Values

Transaction Reference Currency Conversion F: n 8 T: – L: 4 Transaction Reference Currency Exponent F: n 1 T: 9F3D L: 1

not applicable

Factor used in the conversion from the Transaction Currency Code to the Transaction Reference Currency Code. This data object is not used in this version of VIS.

not applicable

Indicates the implied position of the decimal point from the right of the Transaction Amount, with the reference currency code represented according to ISO 4217. This data object is not used in this version of VIS.

Transaction Sequence Counter F: n 4-8 T: 9F41 L: 2–4

M

Counter maintained by the terminal that is incremented by one for each transaction.

Draft 12/18/00
31 Oct 2001
Visa Public

A–19

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Table A–1:

Terminal and Acquirer Data Elements (19 of 20)

Name (Format; Tag; Length)
Transaction Status Information (TSI) F: b 16 T: 9B L: 2

Requirement
M

Description
Indicates the functions performed in a terminal.

Values
q

Byte 1: bit 8: 1 = Offline data authentication was performed bit 7: 1 = Cardholder verification was performed bit 6: 1 = Card risk management was performed bit 5: 1 = Issuer authentication was performed bit 4: 1 = Terminal risk management was performed bit 3: 1 = Issuer Script processing was performed bits 2–1: RFU (00)

q

Byte 2:

1

q

RFU (“00”)

Transaction Time F: n 6 HHMMSS T: 9F21 L: 3 Transaction Type F: n 2 T: 9C L: 1

M

Local time that the transaction was authorized.

M

Indicates the type of financial transaction, represented by the first two digits of ISO 8583-1987 Processing Code. Value to provide variability and uniqueness to the generation of the application cryptogram.

Unpredictable Number F: b 32 T: 9F37 L: 4

M

Draft 12/18/00
A–20
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–1:

A.1 Terminal and Acquirer Data Elements Table

Terminal and Acquirer Data Elements (20 of 20)

Name (Format; Tag; Length)
VLP Terminal Support Indicator F: n 1 T: 9F7A L: 1 VLP Terminal Transaction Limit F: n 12 T: 9F7B L: 6

Requirement
C If VLP supported

Description
A data element, which if present in the terminal, indicates that the terminal supports VLP processing.

Values
0 = VLP Not Supported 1 = VLP Supported 2 = Contactless – VLP Only

O

If this data element is present it is used by the terminal to determine whether a transaction can be processed as VLP. If it is not present, the Terminal Floor Limit is used. The transaction amount must be below either the VLP Terminal Transaction Limit or the Terminal Floor Limit.

Draft 12/18/00
31 Oct 2001
Visa Public

A–21

Terminal and Acquirer Data Elements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

A.2 Terminal Data Element Tags
The tags allocated to the terminal data elements are shown in Table A–2.
Table A–2: Terminal Data Element Tags (1 of 2)

Tag
5F2A 5F36 81 83 8A 95 98 99 9A 9B 9C 9F01 9F02 9F03 9F04 9F06 9F09 9F15 9F16

Terminal Data Element Name
Transaction Currency Code Transaction Currency Exponent Amount, Authorized (binary) Command Template Authorization Response Code Terminal Verification Results Transaction Certificate (TC) Hash Value Transaction PIN Transaction Date Transaction Status Information (TSI) Transaction Type Acquirer Identifier Amount, Authorized (Numeric) Amount, Other (Numeric) Amount, Other (Binary) Application Identifier (AID) Application Version Number Merchant Category Code Merchant Identifier

Draft 12/18/00
A–22
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table A–2: Terminal Data Element Tags (2 of 2)

A.2 Terminal Data Element Tags

Tag
9F1A 9F1B 9F1C 9F1D 9F1E 9F21 9F22 9F33 9F34 9F35 9F37 9F39 9F3A 9F3C 9F3D 9F40 9F41 9F7AVLP 9F7B

Terminal Data Element Name
Terminal Country Code Terminal Floor Limit Terminal Identification Terminal Risk Management Data Interface Device (IFD) Serial Number Transaction Time Certificate Authority Public Key Index (PKI) Terminal Capabilities Cardholder Verification Method (CVM) Results Terminal Type Unpredictable Number Point of Service (POS) Entry Mode Code Amount, Reference Currency (Binary) Transaction Reference Currency Code Transaction Reference Currency Exponent Additional Terminal Capabilities Transaction Sequence Counter Terminal Support Indicator VLP Terminal Transaction Limit

Draft 12/18/00
31 Oct 2001
Visa Public

A–23

Commands for Financial Transactions

B

This appendix lists the commands described in the functional chapters of this document and in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 2, Section 2.5. These commands support transaction processing. Issuer Script Commands are not included.
q

EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE READ RECORD SELECT VERIFY

q

q

q

q

q

q

q

q

These commands may be used for other purposes, such as for personalization of cards. With the exception of the GET DATA command, this section does not address requirements for the support of these commands for such purposes. Issuer Script commands are generated by the issuer and included in the authorization response message as part of issuer script. Because the terminal’s only function is to parse the script and pass the commands to the card, they are not described in this appendix. The Visa Integrated Circuit Card, Appendix C, Commands for Financial Transactions, contains information about these commands.

Draft 12/18/00
31 Oct 2001
Visa Public

B–1

Commands for Financial Transactions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

All commands are issued by the terminal to the card. After processing the command, the card returns a command response to the terminal. The command formats are described in the EMV 4.0, Book 3, Section 2. Each command includes class and instruction bytes that designate the type of command. Parameter bytes (P1 and P2) provide additional processing information. The command may include a data field. The command response includes two status bytes (SW1 and SW2) that describe the command results. SW1 SW2 equals “9000” when the command process was completed successfully. Other values for SW1 SW2 are listed with the individual commands. The command response may optionally include a data field. The data fields returned from VSDC cards are coded according to Format 1 as described in the EMV 4.0, Book 3, Section 2.5.

B.1 Basic Processing Rules for Issuer Script Commands
The recommended Issuer Script commands are used to perform the functions described in Chapter 14, Issuer-to-Card Script Processing. These commands are sent by the issuer in the authorization response message and passed to the card by the terminal. Issuer Scripts for some functions such as Application Unblock and PIN Change/Unblock may be sent in non-financial transactions from special issuer-controlled devices. NOTE: In the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, Le (the expected length of the response data field) is not shown as being present in an Issuer Script Command because only the status bytes are required in the response message. However, the EMV 4.0 does not prohibit data from being transmitted in the script command response message.

B.2 EXTERNAL AUTHENTICATE Command—Response APDUs
The EXTERNAL AUTHENTICATE command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.4. This command is used in performing online Issuer Authentication. The terminal transmits to the card a data object called the Issuer Authentication Data in the EXTERNAL AUTHENTICATE command. The Issuer Authentication Data was received from the issuer in the authorization response. The terminal shall issue at most one EXTERNAL AUTHENTICATE command during a transaction.

Draft 12/18/00
B–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

B.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command Response APDUs

B.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command Response APDUs
The GENERATE APPLICATION CRYPTOGRAM (AC) command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.5. This command is used in generating the Authorization Request Cryptogram (ARQC), Transaction Certificate (TC), Application Authentication Cryptogram (AAC), and Application Authorization Referral (AAR). In this version of the Visa Integrated Circuit Card Specification, the card never initiates a referral, so an AAR is never generated. P1 of the GENERATE AC command may be used by the terminal to indicate that Combined DDA/AC Generation is to be performed and the type of cryptogram being requested. If SW1 SW2 returned from the GENERATE APPLICATION CRYPTOGRAM (AC) is not “9000”, the terminal shall terminate the transaction. The data field returned in the response to the GENERATE AC command from cards that do not support Combined DDA/AC Generation is coded according to Format 1 as described in the EMV 4.0, Book 3, Section 2.5.5.4. This allows a card to transmit to the terminal a variable-length data object called the Issuer Application Data, which contains proprietary card data for online transmission. The data field returned in the response to the GENERATE AC command from cards that do support Combined DDA/AC Generation is coded according to Format 2, using BER-TLV encoding, as described in the EMV 4.0, Book 3, Section 2.5.5.4. If the response is returned in an envelope, the data returned by the card shall be formatted as shown in the EMV 4.0, Book 2, Table 16. In this version of the Visa Integrated Circuit Card Specification, the Issuer Application Data is a mandatory data object used to transmit Visa discretionary data from the card to the terminal for input to the online request message or clearing record. Issuer Application Data is described in Chapter 12, Online Processing, and the Visa Integrated Circuit Card Specification, Appendix A, Terminal and Acquirer Data Elements.

B.4 GET CHALLENGE Command—Response APDUs
The GET CHALLENGE command is optional in the card. The terminal shall support it if the terminal supports Offline Enciphered PIN. The GET CHALLENGE command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.6.

Draft 12/18/00
31 Oct 2001
Visa Public

B–3

Commands for Financial Transactions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

B.5 GET DATA Command—Response APDUs
The GET DATA command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.7. Data retrievable by financial terminals using the GET DATA command is shown in Table B–1. If the issuer stores this data on the card as Visa proprietary data elements, it is not accessible using GET DATA.
Table B–1: Data Retrieval Using GET DATA

Data Element
Application Transaction Counter (ATC) Last Online ATC Register PIN Try Counter (may be stored as a proprietary data element to prevent retrieval by GET DATA)

If the data element requested in the GET DATA command is not present in the card or is a proprietary data element, the card returns SW1 SW2 not equal to “9000”. Retrieval of the card life cycle data and the tagged Visa proprietary data is performed by special devices. Terminals are not required to support the GET DATA command to retrieve the card life cycle data. Terminals shall not use the GET DATA command to retrieve the tagged Visa proprietary data.

Draft 12/18/00
B–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

B.6 GET PROCESSING OPTIONS Command—Response APDUs

B.6 GET PROCESSING OPTIONS Command—Response APDUs
The GET PROCESSING OPTIONS command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.8. The data portion of the command is the data specified in the PDOL provided by the card during Application Selection in the SELECT response. Data retrievable by the GET PROCESSING OPTIONS command is shown in Table B–2.
Table B–2: Data Retrieval With GET PROCESSING OPTIONS

Data Element
Application Interchange Profile Application File Locator

The data field returned in the response to the GET PROCESSING OPTIONS command is coded according to Format 1 as described in the EMV 4.0, Book 3, Section 2.5.8.4.

B.7 INTERNAL AUTHENTICATE Command—Response APDUs
The INTERNAL AUTHENTICATE command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.9. The data field returned in the response to the INTERNAL AUTHENTICATE commands coded according to Format 1 as described in the EMV 4.0, Book 3, Section 2.5.9.4.

B.8 READ RECORD Command—Response APDUs
The READ RECORD command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.11.

Draft 12/18/00
31 Oct 2001
Visa Public

B–5

Commands for Financial Transactions

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

B.9 SELECT Command—Response APDUs
The SELECT command shall be performed as described in the EMV 4.0, Book 1, Section 7.3. As described in Part II, the following data objects are returned in the response to the SELECT command when the Payment System Environment (PSE) Directory is selected:
q

File Control Information (FCI) Template Dedicated File (DF) Name (1PAY.SYS.DDF01) FCI Proprietary Template – – – – Short File Identifier (SFI) of directory elementary file Language Preference (optional) Issuer Code Table Index (optional) FCI Issuer Discretionary Data (optional)

q

q

The Issuer Code Table Index is present if the Application Preferred Name is present in an Application Definition File (ADF) directory entry (see Chapter 3, Application Selection) The following data objects are returned when a Directory Definition File (DDF) is selected:
q

FCI Template DF Name FCI Proprietary Template – – SFI of directory elementary file FCI Issuer Discretionary Data (optional)

q

q

Draft 12/18/00
B–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

B.10 VERIFY Command—Response APDUs

The following data objects are returned in the response to the SELECT command when an ADF is selected, unless otherwise noted:
q

FCI Template DF Name FCI Proprietary Template – – – – – – – Application Label Application Priority Indicator (if present in card) Processing Options Data Object List (PDOL) (optional) Language Preference (optional) Issuer Code Table Index (optional) Application Preferred Name (optional) FCI Issuer Discretionary Data (optional)

q

q

Additional data objects may be returned. The terminal shall ignore these data objects.

B.10 VERIFY Command—Response APDUs
The VERIFY command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.12. The terminal shall support the VERIFY command if the terminal supports offline PIN verification.

Draft 12/18/00
31 Oct 2001
Visa Public

B–7

General Terminal Requirements

C

This appendix lists the requirements for Visa Smart Debit and Visa Smart Credit (VSDC) terminals, which are in addition to the requirements listed in the functional chapters. The general requirements shall be implemented as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 4, Part I.

C.1 Terminal Types and Capabilities
The terminal types and capabilities data objects shall be implemented as described in the EMV 4.0, Book 4, Part I. This document refers to the online/offline capabilities of terminals using the following terminology:
q

Offline-capable—A terminal with non-zero floor limits which is able to approve transactions offline Offline-only—A terminal with non-zero floor limits which is not capable of going online to the issuer for an authorization. All transactions at these terminals are approved or declined offline Online-capable—A terminal which is capable of going online to the issuer for an authorization Online-only—A terminal with zero floor limits which is not capable of approving transactions offline. An online only terminal may decline a transaction offline.

q

q

q

In this version of the specification, an ATM is considered to be an online-only terminal. Therefore, any requirement in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, for an online-only terminal applies to ATMs. The functional requirements shall be performed as described in the EMV 4.0, Book 4, Part I.

Draft 12/18/00
31 Oct 2001
Visa Public

C–1

General Terminal Requirements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

C.1.1 Advice Creation
When the card sends an indicator to the terminal in the response to a GENERATE APPLICATION CRYPTOGRAM (AC) command requesting the creation of an advice, the terminal needs to determine whether an advice is the appropriate message to transmit the necessary data to the acquirer. If the terminal is required to transmit a data capture record or a reversal message for that transaction, it is not necessary for the terminal to also transmit an advice. If the terminal is required to transmit an advice, the terminal shall determine whether to transmit an offline or online advice based upon its capabilities. ATMs are not required to support transmission of an advice when requested by the card. Certain markets may require that POS terminals support the transmission of advices, while other markets may choose not to support advices.

C.1.2 Amount Entry and Management
During the transaction, the amount of the transaction (not including adjustments) and the amount of a cashback (if present) shall be made available to the card and terminal for card and terminal risk management and for authorization and clearing. The following features are dependent upon the environment and are independent of whether a chip or a magnetic stripe is used to initiate a transaction.
q

When an amount is entered through the use of a key pad at an attended terminal, the attendant should be able to edit the amount during entry. The attendant should be able to either correct the amount entered prior to authorization and proceed with the transaction or abort the transaction if the amount was entered incorrectly. The attendant or cardholder should be able to validate the original or corrected amount.

q

q

NOTE: When transmitted to the card or the acquirer, the amount fields should be formatted so that the implied currency exponent is the default value as designated in International Organisation for Standardisation (ISO) 4217.

Draft 12/18/00
C–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

C.1 Terminal Types and Capabilities

C.1.3 Card Reading
When a card is read at a terminal, the card-related data for the transaction should be obtained from the chip. This data is obtained from the magnetic stripe only if the chip is not readable. If the magnetic stripe is not readable, the cardholder data may be manually entered. (These default procedures for reading the card may be prohibited within specific countries.) If the terminal allows the magnetic stripe to be read if the chip is not readable, the terminal shall support a means to bypass the “Use Chip Reader” prompt to allow magnetic stripe reading. The EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, requires that the request message indicate if the magnetic stripe was read because the chip was unreadable. For this version of the Visa Integrated Circuit Card Specification, this shall be performed as follows:
q

The terminal shall maintain an internal flag that is set whenever a chip read failure occurs. This flag is reset at the completion of a transaction if any of the following conditions occur: – – Successful chip read Successful magnetic stripe read

q

If the flag is set and a magnetic stripe card is read successfully, and the service code indicates that a chip is present, the terminal sets the “Magnetic stripe read, ICC service code begins with ‘2’ or ‘6’, last transaction was an unsuccessful chip read” code. If the flag is not set, a magnetic stripe card is read successfully, and the service code indicates that a chip is present, the terminal sets the “Magnetic stripe read, service code begins with ‘2’ or ‘6’, last transaction was a successful chip read or was not a chip transaction” code. If the magnetic stripe is read and the service code indicates magnetic stripe only, regardless of the internal flag setting, the terminal sets the “Magnetic stripe read, service code does not begin with ‘2’ or ‘6’” code.

q

q

The terminal shall convey this information to the acquirer for conversion to the VisaNet Chip Condition Code field. POS Entry Mode may be used to convey this information from the terminal to the acquirer as follows:
q

02 or 90—Magnetic stripe read, service code does not begin with “2” or “6” code. 91—Magnetic stripe read, service code begins with “2” or “6”; last transaction was a successful chip read or was not a chip transaction. 92—Magnetic stripe read; service code begins with “2” or “6”; last transaction was an unsuccessful chip read.

q

q

Draft 12/18/00
31 Oct 2001
Visa Public

C–3

General Terminal Requirements

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

The POS Entry Mode Codes of “91” and “92” are not valid in messages from the acquirer to VisaNet and, if used from the terminal to the acquirer, shall be converted, by the acquirer, to “02” or “90” as appropriate.

C.2 Physical Characteristics
The physical requirements shall be performed as described in the EMV 4.0, Book 4, Part I. The terminal shall support a magnetic stripe reader (either track 1 or 2 or both) and manual entry capability. If manual entry of the PAN is supported, the terminal shall support a PAN of up to 19 digits in length. (Support of manual entry for PANs may be prohibited with specific countries or may not be allowed for specific types of terminals, such as ATMs.) The terminal shall support ICCs conforming to the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0, and shall support magnetic stripe cards conforming to ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, and ISO/IEC 7813.

C.3 Security Requirements
The security requirements shall be performed as described in the EMV 4.0, Book 4, Part I.

C.4 Data Management
To ensure the accuracy of the data elements Transaction Date (local date) and Transaction Time (local time), the terminal shall ensure that it is able to accurately calculate, store, and display date-dependent fields representing the year 2000 and subsequent years without compromising the integrity of dates or their use, including calculations for leap year. This requirement applies to terminals supporting clocks as well as those that update the date and time based upon online messages.

Draft 12/18/00
C–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

C.5 Cardholder and Attendant Interface

C.5 Cardholder and Attendant Interface
The cardholder and attendant interface requirements shall be performed as described in the EMV 4.0, Book 4, and in chapters 3 to 14 of this document.

C.5.1 Receipt
National requirements for data printed on the receipt will be developed for each country, although each country shall comply with the Visa International Operating Regulations. The receipt shall comply with the requirements in the EMV 4.0, Book 4.

C.6 Acquirer Interface
The acquirer interface requirements shall be performed as described in the EMV 4.0, Book 4, with the restrictions for this version of the Visa Integrated Circuit Card Specification described in Chapters 3 to 14 of this document and as described in the Visa Smart Debit/Visa Smart Credit System Technical Manual.

Draft 12/18/00
31 Oct 2001
Visa Public

C–5

Terminal Requirements for Visa Low-Value Payment Feature

D

The Visa Low-value Payment (VLP) feature of VSDC provides Members with an optional source of pre-authorized spending power that is reserved for rapid processing of offline low-value payments. Risk management features may differ from those supported for non-VLP VSDC and are selected by the issuer. VLP supports a total amount limit (VLP Funds Limit) and a per transaction amount limit (VLP Single Transaction Limit). Since VLP consists of many low-value transactions, adding these transactions to standard VSDC velocity checking counters could cause VSDC transactions to be processed online more frequently than intended by issuers. Therefore, standard VSDC velocity checking counters are not incremented by VLP transactions. VLP transactions are either approved or declined offline by the card and terminal. They are never sent online for authorization. Any request requiring online authorization is processed subject to VSDC requirements and Visa/Visa Electron program rules. The amount of spending power (VLP Available Funds) on the card is reset to the spending limit (VLP Funds Limit) at any online capable VSDC terminal if an online authorization or an online status check message (single unit of currency) is approved by the issuer and the card. A reset without a financial transaction can also take place at a dedicated online unattended device, identified by Merchant Category Code “5999”, which performs an online status check. If the response to the status check is an approval by the issuer and the card, the amount of VLP spending power is reset to the VLP spending limit. The general requirements shall be implemented as described in the EMV 2000 Integrated Circuit Card Specification for Payment Systems, Version 4.0 (EMV 4.0), Book 4, Part I.

Draft 12/18/00
31 Oct 2001
Visa Public

D–1

Terminal Requirements for Visa Low-Value Payment Feature

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

D.1 Card Data
Card data elements are described in Table D–1.
Table D–1: Initiate Application Processing—Card Data (1 of 2)

Data Element
Application Currency Code “9F51”

Description
Visa proprietary data element indicating the currency in which the account is managed according to International Organisation for Standardisation (ISO) 4217. Indicates the location (SFI, range of records) of the AEFs related to a given application. The AIP indicates the capabilities of the card to support specific functions in the application. These may differ for VLP. Identifies a prioritized list of methods of verification of the cardholder supported by the card application for VLP transactions. The IACs specify the Issuer’s conditions for VLP transactions for offline decline or online processing or offline decline if online processing requested and the terminal is unable to go online. Contains proprietary application data for transmission to the issuer in an online transaction. The first 16 bytes contain Visa Discretionary Data. The remaining 16 bytes contain Issuer Discretionary Data. List of terminal-related data objects (tags and lengths) requested by the card to be transmitted in the GET PROCESSING OPTIONS command. A counter that is decremented by the transaction amount when a VLP transaction is approved (VLP transactions are either approved or declined offline). Issuer Limit for VLP available funds that may be used by the card to reset VLP Available Funds after an online approved transaction.

Application File Locator (AFL) for VLP Application Interchange Profile (AIP) for VLP

CVM List for VLP

Issuer Action Codes (IACs) for VLP

Issuer Application Data

PDOL

VLP Available Funds

VLP Funds Limit

Draft 12/18/00
D–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table D–1:

D.2 Terminal Data

Initiate Application Processing—Card Data (2 of 2)

Data Element
VLP Issuer Authorization Code

Description
Code on the card that indicates that the transaction is approved for VLP. It is placed in the Authorization Code in the clearing message if the transaction is approved (VLP transactions are either approved or declined offline). Maximum amount allowed for a single VLP transaction.

VLP Single Transaction Limit

D.2 Terminal Data
Terminal data elements are described in Table D–2.
Table D–2: Initiate Application Processing—Terminal Data

Data Element
Amount, Authorized

Description
Authorized amount of the transaction (excluding adjustments) Payment scheme conditions that cause VLP transactions to be approved or declined offline. Indicates the currency code of the transaction according to ISO 4217. A data element, which if present in the terminal, indicates that the terminal supports VLP processing. The terminal uses this data element, if present, to determine whether a transaction can be processed as VLP. If it is not present, the Terminal Floor Limit is used. The transaction amount must be below either the VLP Terminal Transaction Limit or the Terminal Floor Limit.

Terminal Action Codes (TACs) for VLP Transaction Currency Code

VLP Terminal Support Indicator VLP Terminal Transaction Limit

Draft 12/18/00
31 Oct 2001
Visa Public

D–3

Terminal Requirements for Visa Low-Value Payment Feature

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

D.3 Terminal Requirements
The terminal must meet the following requirements:
q

The terminal is EMV compliant The terminal contains Visa AID or Visa Electron AID, or both The terminal contains enhancements to the VSDC application to support VLP New terminal data elements include the VLP Terminal Support Indicator The terminal may optionally support display of VLP Available Funds or printing of VLP Available Funds on the receipt

q

q

q

q

D.4 VLP Purchase Transaction Process
D.4.1 VLP Transaction With VLP-Capable Card at a VLP-Capable Terminal
The terminal selects the VSDC application using the Visa or the Visa Electron AID and the card response contains a PDOL, in the FCI, requesting the “VLP Terminal Support Indicator”, “Amount, Authorized”, and “Transaction Currency Code.” The terminal provides the VLP Terminal Support Indicator in the GET PROCESSING OPTIONS command if:
q

VLP Terminal Support Indicator is present in the terminal. The transaction is under the terminal VLP Terminal Transaction Limit or under the Terminal Floor Limit if no separate VLP Terminal Transaction Limit is present. The Transaction Type is purchase (does not indicate cash or cashback). A random selection process prior to Get Processing Options is not supported or is supported and transaction is not eligible for VLP because it was randomly selected.

q

q

q

If all card conditions for a VLP transaction are met, the terminal receives an AFL that includes a file and record containing the VLP Issuer Authorization Code and VLP Available Funds (after transaction amount is deducted). VLP transactions are offline only; no Issuer Script processing takes place.

Draft 12/18/00
D–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

D.4 VLP Purchase Transaction Process

If any card or terminal conditions are not met, the transaction is processed as a standard VSDC transaction. NOTE: If terminal requirements for VLP are not met, the terminal does not provide the VLP Terminal Support Indicator to the card in GPO. If card requirements are not met, the card provides VSDC AIP and AFL (does not include VLP Issuer Authorization Code) rather than VLP. AIP and AFL and standard VSDC processing takes place.

Draft 12/18/00
31 Oct 2001
Visa Public

D–5

Terminal Requirements for Visa Low-Value Payment Feature

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

A second set of TACs unique for VLP means that processing results differ from those for standard VSDC. The required TACs for VLP are listed in Table D–3.
Table D–3: Terminal TACs for VLP (1 of 2)

Card or Terminal Conditions
Offline Data Authentication not performed SDA Failure Chip Data Missing PAN on terminal exception file Standard DDA failure Combined DDA/AC Generation Failure Chip and terminal are different versions Expired Application Application not yet active Service not allowed for card product New Card Cardholder verification failed CVM not recognized PIN try limit exceeded Offline PIN required and pin pad not working Offline PIN required and no pin entered Online PIN entered Transaction exceeds floor limit

Default
0 1 1 1 1 1 0 1 1 1 0 1 0 1 1 1 0 0

Online
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Denial
0 1 1 1 1 1 0 1 1 1 0 1 0 1 1 1 0 0

Draft 12/18/00
D–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 Table D–3: Terminal TACs for VLP (2 of 2)

D.4 VLP Purchase Transaction Process

Card or Terminal Conditions
Lower offline limit exceeded Upper offline limit exceeded Transaction selected randomly for online Merchant forced transaction online Default TDOL used Issuer Authentication failed Script Processing failed prior to final AC Script Processing failed after final AC

Default
0 0 0 1 0 0 0 0

Online
0 0 0 0 0 0 0 0

Denial
0 0 0 1 0 0 0 0

According to regional or market rules, terminal exception files or use of a terminal transaction log (for checking for excessive transactions on a single card) may be implemented to reduce risk. The terminal provides the VLP Issuer Authorization Code in the clearing message in the Authorization Code in TCR 0. The receipt may include VLP Available Funds, provided by the card to the terminal.

Draft 12/18/00
31 Oct 2001
Visa Public

D–7

Terminal Requirements for Visa Low-Value Payment Feature

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Figure D–1: VLP Transaction Flow
Terminal
SELECT command

Card
SELECT response (includes PDOL requesting VLP Terminal Support Indicator, Amount Authorized, and Transaction Currency Code)

Terminal selects the VIS AID

Card responds to SELECT command

All are true? Txn Type is Purchase Under txn limit for VLP VLP is supported

Y

Terminal provides VLP Terminal Support Indicator greater than 0 in GET PROCESSING OPTIONS command

N

Terminal provides VLP Terminal Support Indicator equal to 0 in GET PROCESSING OPTIONS command

Terminal initiates processing by by issuing the GET PROCESSING OPTIONS command

GET PROCESSING OPTIONS command (includes VLP Terminal Support Indicatior, Amount Authorized, and Transaction Currency Code)

Card receives GET PROCESSING OPTIONS command

VLP Terminal Support Indicator > 0? Y

N

GET PROCESSING OPTIONS response

Txn Currency Code = Application Currency Code?
Y

N

AIP and AFL received? Y

N

Terminal terminates initiate processing
N

Txn amount < or = to VLP Available Funds? Y Txn amount < or = to VLP Single Transaction Limit?

N

Terminal reads records from card

Terminal is VSDC capable?

N

VLP Issuer Authorization Code present? Y

N

Y
Last Online ATC Register > 0 and PIN Try Counter > 0? Y

N

Terminal uses VLP TACs and normal processing continues

Issuer Authentication Failure Indicator = 0? Y Card deducts the amount of txn from the VLP Available Funds

N

Card responds to GET PROCESSING Options with VLP AIP and VLP AFL (pointing to a file and record containing the VLP Issuer Authorization Code and the VLP Available Funds Card responds with VSDC AIP and AFL

Draft 12/18/00
D–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

D.5 VLP Reset Transaction Processing

D.4.2 VSDC Transaction With a Non-VLP-Capable Card at a VLP-Capable Terminal
The terminal selects the VSDC application using the Visa AID or Visa Electron AID. In the card’s response, the PDOL if present in the FCI does not request the VLP Terminal Support Indicator. The terminal does not receive the request for the VLP Terminal Support Indicator from the card and does not provide the VLP Terminal Support Indicator to the card. The transaction is processed as standard VSDC. For online transactions, the terminal processes any Issuer Script received on the authorization response message.

D.5 VLP Reset Transaction Processing
The VLP card requests the VLP Terminal Support Indicator, Amount, Authorized, and the Transaction Currency Code from the terminal in the PDOL.

D.5.1 VSDC Online-Capable Terminal
The transaction is a VSDC transaction that is sent online for processing. The terminal may permit display of VLP Available Funds, which is received from the card in the Issuer Discretionary Data portion of the Issuer Application Data. The terminal processes any Issuer Script received on the authorization response message.

D.5.2 Dedicated Online Unattended Terminal—VLP Reset-Capable
This online only terminal selects the VSDC application and extracts the PDOL from the File Control Information received in the card response to the SELECT command. This terminal does not contain the VLP Terminal Support Indicator and cannot provide it in the response even if requested by the card. The terminal processes the transaction as a standard VSDC transaction. The message is an online status check, which is a special type of authorization that will not impact the cardholder’s open to buy. The transaction amount is a single unit of currency and the merchant type is “5999”. The VLP Available Funds is received by the terminal in the Issuer Discretionary Data portion of the Issuer Application data and sent in the online authorization request to the Issuer.

Draft 12/18/00
31 Oct 2001
Visa Public

D–9

Terminal Requirements for Visa Low-Value Payment Feature

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

If the issuer approves the transaction, the terminal requests an approval from the card and if the card approves, the VLP Available Funds is reset to the VLP Funds Limit. The terminal processes any Issuer Script received in the authorization response message.

Draft 12/18/00
D–10
Visa Public

31 Oct 2001

Acronyms

E

Acronym
a AAC AAR AC ADA ADF AEF AFL AID AIP AMD an ans

Meaning
alpha Application Authentication Cryptogram Application Authentication Referral Application Cryptogram Application Default Action Application Definition File Application Elementary File Application File Locator Application Identifier Application Interchange Profile Application Management Data alphanumeric alphanumeric special

Draft 12/18/00
31 Oct 2001
Visa Public

E–1

Acronyms

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Acronym
APDU ARPC ARQC ATC ATM AUC Auth. b BIN C CA CAM CDOL Cert. CID CLA cn Cons. CPLC Cum. CVM

Meaning
Application Protocol Data Unit Authorization Response Cryptogram Authorization Request Cryptogram Application Transaction Counter Automated Teller Machine Application Usage Control authentication binary BASE Identification Number conditional Certificate Authority Card Authentication Method Card Risk Management Data Object List certificate Cryptogram Information Data Class Byte of the Command Message compressed numeric consecutive Card Production Life Cycle Data cumulative Cardholder Verification Method

Draft 12/18/00
E–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Acronyms

Acronym
CVR CVV DDA DDF DDOL DEA DES DF EEPROM EMV ENC MDK ENC UDK FCI FCP FMD GPO hex. HHMMSS HSM IA IAC

Meaning
Card Verification Results Card Verification Value Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Algorithm Data Encryption Standard dedicated file Electronically Erasable Programmable Read-Only Memory Europay, MasterCard, Visa Master Data Encipherment DEA Key Unique Data Encipherment DEA Key File Control Information File Control Parameters File Management Data GET PROCESSING OPTIONS hexadecimal hours, minutes, seconds host security module Issuer Authentication Issuer Action Code

Draft 12/18/00
31 Oct 2001
Visa Public

E–3

Acronyms

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Acronym
IC ICC IEC IFD INS Int’l ISO Lc Le LD LRC M MAC MAC MDK MAC UDK MCC MDK n N/A NCA NI

Meaning
integrated circuit integrated circuit card International Electrotechnical Commission interface device Instruction Byte of the Command Message international International Organisation for Standardisation Length of the Command Data Field Expected Length of the Response Data Field Length of the plaintext data in the Command Data Field Longitudinal Redundancy Check mandatory Message Authentication Code Master Message Authentication Code DEA Key Unique Message Authentication Code DEA Key Merchant Category Code Master DEA Key numeric not applicable Length of the Certification Authority Public Key Modulus Length of the Issuer Public Key Modulus

Draft 12/18/00
E–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Acronyms

Acronym
NIC No. O P1 P2 PAN PDOL PIN PIX PK PKI POS PSE PVV R RFU RID ROM RSA SAD SAM

Meaning
Length of the ICC Public Key Modulus number optional Parameter 1 Parameter 2 Primary Account Number Processing Options Data Object List Personal Identification Number Proprietary Application Identifier Extension public key Certificate Authority Public Key Index point of service payment system environment PIN Verification Value required Reserved for Future Use Registered Application Provider Identifier Read-Only Memory Rivest, Shamir, Adleman Signed Static Application Data Secure Access Module

Draft 12/18/00
31 Oct 2001
Visa Public

E–5

Acronyms

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Acronym
SDA SFI SW1, SW2 TC TDOL TLV Txn. TSI TVR UDK var. V.I.P. VLP YDDD

Meaning
Static Data Authentication Short File Identifier Status Words Transaction Certificate Transaction Certificate Data Object List tag-length-value transaction Transaction Status Information Terminal Verification Results Unique DEA Key variable VisaNet Integrated Payment Visa Low-value Payment year, day where Y = right-most digit of the year (0–9) and DDD = Julian day of the year (001–366) year, month where YY = year (00–99) and MM = month (01–12) year, month, day where DD = day (01–31)

YYMM YYMMDD

Draft 12/18/00
E–6
Visa Public

31 Oct 2001

Glossary

This is a glossary of terms used in this specification; it is not intended as a data dictionary. For descriptions of terminal and acquirer data elements, refer to Appendix A of the Card and Terminal volumes of this specification.
acquirer

A Visa member that signs a merchant or disburses currency to a cardholder in a cash disbursement, and directly or indirectly enters the resulting transaction into interchange.
ANSI

American National Standards Institute. A U.S. standards accreditation organization.
application

A computer program and associated data that reside on an integrated circuit chip and satisfy a business function. Examples of applications include payment, stored value, and loyalty.
Application Authentication Cryptogram (AAC)

A cryptogram generated by the card for offline and online declined transactions.
application block

Instructions sent to the card by the issuer, to shut down the selected application on a card to prevent further use of that application. This process does not preclude the use of other applications on the card.
ATM

An unattended terminal that has electronic capability, accepts PINs, and disburses currency or checks.

Draft 12/18/00
31 Oct 2001
Visa Public

Glossary–1

Glossary

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

ATM cash disbursement

A cash disbursement obtained at an ATM displaying the Visa, PLUS, or Visa Electron acceptance mark, for which the cardholder’s PIN is accepted.
authentication

A cryptographic process that validates the identity and integrity of data.
authorization

A process where an issuer or a representative of the issuer approves a transaction.
authorization controls

Information in the chip application enabling the card to act on the issuer’s behalf at the point of transaction. The controls help issuers manage their below-floor-limit exposure to fraud and credit losses. Also known as offline authorization controls.
authorization request

A merchant’s or acquirer’s request for an authorization.
Authorization Request Cryptogram (ARQC)

The cryptogram generated by the card for transactions requiring online authorization and sent to the issuer in the authorization request. The issuer validates the ARQC during the Online Card Authentication (CAM) process to ensure that the card is authentic and was not created using skimmed data.
authorization response

The issuer’s reply to an authorization request. Types of authorization responses are:
q

approval decline pickup referral

q

q

q

Authorization Response Cryptogram (ARPC)

A cryptogram generated by the issuer and sent to the card in the authorization response. This cryptogram is the result of the Authorization Request Cryptogram (ARQC) and the Issuer’s authorization response encrypted with the Unique Derivation Key (UDK). It is validated by the card during Issuer Authentication to ensure that the response came from a valid issuer.
Bank Identification Number (BIN)

A 6-digit number assigned by Visa and used to identify a member or processor for authorization, clearing, or settlement processing.

Draft 12/18/00
Glossary–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 BASE I Authorization System

BASE I Authorization System

The V.I.P. System component that performs message routing, cardholder and card verification, and related functions such as reporting and file maintenance.
BASE II

The VisaNet system that provides deferred clearing and settlement services to members.
byte

8 bits of data.
card acceptance device

A device capable of reading and/or processing a magnetic stripe or chip on a card for the purpose of performing a service such as obtaining an authorization or processing a payment.
card authentication

A means of validating whether a card used in a transaction is the genuine card issued by the issuer.
Card Authentication Method (CAM)

See Online Card Authentication.
card block

Instructions, sent to the card by the Issuer, which shut down all proprietary and non-proprietary applications that reside on a card to prevent further use of the card.
Card Verification Value (CVV)

A unique check value encoded on a card’s magnetic stripe and chip to validate card information during an online authorization.
cardholder

An individual to whom a card is issued or who is authorized to use that card.
cardholder verification

The process of determining that the presenter of the card is the valid cardholder.
Cardholder Verification Method (CVM)

A method used to confirm the identity of a cardholder.
cash disbursement

Currency, including travelers cheques, paid to a cardholder using a card.

Draft 12/18/00
31 Oct 2001
Visa Public

Glossary–3

Glossary

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

cashback

Cash obtained in conjunction with, and processed as, a purchase transaction.
CCPS

Chip Card Payment Service, the former name for Visa Smart Debit and Visa Smart Credit (VSDC).
Certificate Authority (CA)

A trusted central administration that issues and revokes certificates.
chargeback

A transaction that an issuer returns to an acquirer.
chip

An electronic component designed to perform processing or memory functions.
chip-capable

A card acceptance device that is designed and constructed to facilitate the addition of a chip reader/writer.
chip card

A card embedded with a chip that communicates information to a point-of-transaction terminal.
clearing

The collection and delivery to the issuer of a completed transaction record from an acquirer.
cleartext

See plaintext.
cryptogram

A numeric value that is the result of data elements entered into an algorithm and then encrypted. Commonly used to validate data integrity.
cryptographic key

The numeric value entered into a cryptographic algorithm that allows the algorithm to encrypt or decrypt a message.
cryptography

The art or science of keeping messages secret or secure, or both.

Draft 12/18/00
Glossary–4
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 CVM List

CVM List

An issuer-defined list contained within a chip application establishing the hierarchy of methods for verifying the authenticity of a cardholder.
data authentication

Validation that data stored in the integrated circuit card has not been altered since card issuance. See also Offline Data Authentication.
Data Encryption Algorithm (DEA)

An encipherment operation and an inverse decipherment operation in a cryptographic system.
Data Encryption Standard (DES)

The public domain symmetric key cryptography algorithm of the National Institute for Standards and Technology.
decryption

The process of transforming ciphertext into cleartext.
DES key

A secret parameter of the Data Encryption Standard algorithm.
digital signature

A cryptogram generated by encrypting a message digest (or hash) with a private key that allows the message content and the sender of the message to be verified.
double-length DES Key

Two secret 64-bit input parameters each of the Data Encryption Standard algorithm, consisting of 56 bits that must be independent and random, and 8 error-detecting bits set to make the parity of each 8-bit byte of the key odd.
Dynamic Data Authentication (DDA)

A type of Offline Data Authentication where the card generates a cryptographic value using transaction-specific data elements for validation by the terminal to protect against skimming.
Easy Entry

A replication of the magnetic stripe information on the chip to facilitate payment as part of multi-application programs. Easy Entry is not EMV-compliant and is being phased out.

Draft 12/18/00
31 Oct 2001
Visa Public

Glossary–5

Glossary

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

EMV specifications

Technical specifications developed jointly by Europay International, MasterCard International, and Visa International to create standards and ensure global interoperability for use of chip technology in the payment industry.
encryption

The process of transforming cleartext into ciphertext.
expired card

A card on which the embossed, encoded, or printed expiration date has passed.
floor limit

A currency amount that Visa has established for single transactions at specific types of merchants, above which online authorization is required.
Hardware Security Module (HSM)

A secure module used to store cryptographic keys and perform cryptographic functions.
hash

The result of a non-cryptographic operation, which produces a unique value from a data stream.
host data capture system

An acquirer authorization system that retains authorized transactions for settlement without notification from the terminal that the transaction was completed.
Integrated Circuit Card (ICC)

See chip card.
Integrated Circuit Chip

See chip.
interchange

The exchange of clearing records between members.
International Organisation for Standardisation (ISO)

The specialized international agency that establishes and publishes international technical standards.
interoperability

The ability of all card acceptance devices and terminals to accept and read all chip cards that are properly programmed.

Draft 12/18/00
Glossary–6
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 issuer

issuer

A Visa member that issues Visa or Electron cards, or proprietary cards bearing the PLUS or Visa Electron Symbol.
Issuer Action Codes (IACs)

Card-based rules which the terminal uses to determine whether a transaction should be declined offline, sent online for an authorization, or declined if online is not available.
Issuer Authentication

Validation of the issuer by the card to ensure the integrity of the authorization response. See Authorization Response Cryptogram (ARPC).
key generation

The creation of a new key for subsequent use.
key management

The handling of cryptographic keys and other related security parameters during the entire life cycle of the keys, including their generation, storage, distribution, entry and use, deletion or destruction, and archiving.
magnetic stripe

The stripe on the back of the card that contains the magnetically coded account information necessary to complete a non-chip electronic transaction.
Magnetic Stripe Image

The minimum chip payment service data replicating information in the magnetic stripe required to process a transaction that is compliant with EMV.
Master Derivation Keys (MDK)

Master DES keys stored in the issuer host system. These keys are used to generate Unique Derivation Keys (UDKs) for personalization, to validate ARQCs, and to generate ARPCs.
merchant category code (MCC)

A code designating the principal trade, profession, or line of business in which a merchant is engaged.
message authentication code (MAC)

A digital code generated using a cryptographic algorithm which establishes that the contents of a message have not been changed and that the message was generated by an authorized entity.

Draft 12/18/00
31 Oct 2001
Visa Public

Glossary–7

Glossary

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

multi-application

The presence of multiple applications on a chip card (for example, payment, loyalty, and identification).
nibble

The four most significant or least significant bits of a byte of data.
offline approval

A transaction that is positively completed at the point of transaction between the card and terminal without an authorization request to the issuer.
offline authorization

A method of processing a transaction without sending the transaction online to the issuer for authorization.
offline-capable

A card acceptance device that is able to perform offline approvals.
Offline Data Authentication

A process whereby the card is validated at the point of transaction using RSA public key technology to protect against counterfeit or skimming. VIS includes two forms: Static Data Authentication (SDA) and Dynamic Data Authentication (DDA).
offline decline

A transaction that is negatively completed at the point of transaction between the card and terminal without an authorization request to the issuer.
offline-only terminal

A card acceptance device that is not capable of sending transactions online for issuer authorization.
offline PIN

A PIN value stored on the card that is validated at the point of transaction between the card and the terminal.
offline PIN verification

The process whereby a cardholder-entered PIN is passed to the card for comparison to a PIN value stored secretly on the card.
online authorization

A method of requesting an authorization through a communications network other than voice to an issuer or issuer representative.

Draft 12/18/00
Glossary–8
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 online-capable terminal

online-capable terminal

A card acceptance device that is able to send transactions online to the issuer for authorization.
Online Card Authentication (CAM)

Validation of the card by the issuer to protect against data manipulation and skimming. See Authorization Request Cryptogram (ARQC).
online PIN

A method of PIN verification where the PIN entered by the cardholder into the terminal PIN pad is DES-encrypted and included in the online authorization request message sent to the issuer.
personalization

The process of populating a card with the application data that makes it ready for use.
plaintext

Data in its original unencrypted form.
point of transaction (POT)

The physical location where a merchant or acquirer (in a face-to-face environment) or an unattended terminal (in an unattended environment) completes a transaction.
point-of-transaction terminal

A device used at the point of transaction that has a corresponding point-of-transaction capability. See also Card Acceptance Device.
post-issuance update

A command sent by the issuer through the terminal via an authorization response to update the electronically stored contents of a chip card.
private key

As part of an asymmetric cryptographic system, the key that is kept secret and known only to the owner.
public key

As part of an asymmetric cryptographic system, the key known to all parties.
public key cryptographic algorithm

A cryptographic algorithm that allows the secure exchange of information, but does not require a shared secret key, through the use of two related keys—a public key which may be distributed in the clear and a private key which is kept secret.

Draft 12/18/00
31 Oct 2001
Visa Public

Glossary–9

Glossary

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

public key pair

The two mathematically related keys, a public key and a private key which, when used with the appropriate public key cryptographic algorithm, can allow the secure exchange of information, without the secure exchange of a secret.
purchase transaction

A retail purchase of goods or services; a point-of-sale transaction.
quasi-cash transaction

A transaction representing a merchant’s sale of items, such as gaming chips or money orders, that are directly convertible to cash.
random selection

An EMV online-capable terminal function that allows for the selection of transactions for online processing. Part of Terminal Risk Management.
receipt

A paper record of a transaction generated for the cardholder at the point of transaction.
referral response

An authorization response where the merchant or acquirer is instructed to contact the issuer for further instructions before completing the transaction.
reversal

A BASE II or online financial transaction used to negate or cancel a transaction that has been sent through interchange.
ROM (Read-Only Memory)

Permanent memory that cannot be changed once it is created. It is used to store chip operating systems and permanent data.
RSA (Rivest, Shamir, Adleman)

A public key cryptosystem developed by Rivest, Shamir, and Adleman, used for data encryption and authentication.
secret key

A key that is used in a symmetric cryptographic algorithm (that is, DES), and cannot be disclosed publicly without compromising the security of the system. This is not the same as the private key in a public/private key pair.
secure messaging

A process that enables messages to be sent from one entity to another, and protects against unauthorized modification or viewing.

Draft 12/18/00
Glossary–10
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0 session key

session key

A temporary cryptographic key computed in volatile memory and not valid after a session is ended.
settlement

The reporting of settlement amounts owed by one member to another or to Visa, as a result of clearing.
Single Message System

A component of the V.I.P. System that processes Online Financial and Deferred Clearing transactions.
smart card

A commonly used term for a chip card.
Static Data Authentication (SDA)

A type of Offline Data Authentication where the terminal validates a cryptographic value placed on the card during personalization. This validation protects against some types of counterfeit, but does not protect against skimming.
Terminal Action Codes (TACs)

Visa-defined rules in the terminal which the terminal uses to determine whether a transaction should be declined offline, sent online for an authorization, or declined if online is not available.
transaction

An exchange of information between a cardholder and a merchant or an acquirer that results in the completion of a financial transaction.
Triple DES

The data encryption algorithm used with a double-length DES key.
V.I.P. System

VisaNet Integrated Payment System, the online processing component of VisaNet.
Visa Certificate Authority (CA)

A Visa-approved organization certified to issue certificates to participants in a Visa payment service.
Visa Low-value Payment (VLP)

VLP is a feature of VSDC designed to provide an optional source of pre-authorized spending power that is reserved for rapid processing of offline low-value payments.

Draft 12/18/00
31 Oct 2001
Visa Public

Glossary–11

Glossary

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

Visa Smart Debit and Visa Smart Credit (VSDC)

The Visa service offerings for chip-based debit and credit programs. These services, based on EMV and VIS specifications, are supported by VisaNet processing, as well as by Visa rules and regulations.
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.

Draft 12/18/00
Glossary–12
Visa Public

31 Oct 2001

Index
A
AAC, 10–8 to 10–9, 11–2, 11–4, 12–7, 13–1, 13–5 to 13–11, B–3 AAR, B–3 account transfer, 13–7 advice message, 13–6, 14–2, 14–5, C–2 AFL. See Application File Locator AID, 3–2, 9–3, D–4, D–9 AID matching example, 3–9 Amount entry, C–2 Amount X, 8–4 Amount Y, 8–4 Amount, Authorized, 8–7, 9–4 to 9–5, 12–4, D–3 to D–4, D–9 Amount, Other, 12–4 APPLICATION BLOCK command, 14–3 Application Cryptogram, 11–2, 12–2, 12–4, 13–3 Application Currency Code, 8–3, D–2 Application Definition File, 3–2, 3–7, B–6 to B–7 Application Effective Date, 7–2 Application Elementary Files, 3–2, 5–2 Application Expiration Date, 7–2 Application File Locator, 4–1 to 4–6, 5–2, 6–10, B–5, D–2, D–4 Application Interchange Profile, 4–1 to 4–6, 6–5, 8–3, 8–9, 9–1, 12–3 to 12–4, 12–8, B–5, D–2 Application Label, 3–2, B–7 Application PAN Sequence Number, 12–4 Application Preferred Name, 3–3, B–6 to B–7 Application Priority Indicator, 3–3, B–7 Application Selection, 1–7, 2–1, 2–7, 3–1 to 3–15, 4–6 card data, 3–2 identifying and selecting the application, 3–10 processing flow, 3–12 to 3–14 terminal data, 3–4 Application Selection Indicator, 1–7, 3–4 APPLICATION UNBLOCK command, 14–3, B–2 Application Usage Control, 7–2, 7–4 to 7–6 Application Version Number (“9F08”), 7–2 Application Version Number (“9F09”), 7–3 ARPC, 12–5 ARQC, 10–8, 11–2, 11–4, 12–2, 12–6 to 12–7, 13–1, 13–5, B–3 ATC, 9–3, 9–5, 9–7, 11–2, 12–2, 12–4, 13–3, B–4 ATM, 1–7, 6–3, 7–4 to 7–5, 13–7, C–1 to C–2, C–4 Authorization Response Code, 10–3, 10–8, 12–5, 13–4, 13–6

B
balance inquiry, 13–7 biometrics, 8–1 bypass PIN entry, 8–13, 8–21

C
candidate list, building the, 3–6 Card Action Analysis, 2–4, 2–8, 11–1 to 11–5, 12–10, 13–11 card data, 11–2 processing, 11–4 terminal data, 11–3 CARD BLOCK command, 14–3 card data for Application Selection, 3–2 for Card Action Analysis, 11–2 for Cardholder Verification, 8–3 for Completion, 13–2 for Dynamic Data Authentication, 6–12 for Initiate Application Processing, 4–2 for Issuer-to-Card Script Processing, 14–2 for Online Processing, 12–2 for Processing Restrictions, 7–2 for Static Data Authentication, 6–7 for Terminal Action Analysis, 10–2 for Terminal Risk Management, 9–3 card life cycle data, B–4 card override of terminal decision, 11–4 card reader, 8–7, 8–15 Card Risk Management checks, 11–4 card velocity checking. See velocity checking, card cardholder confirmation, 3–10

Draft 12/18/00
31 Oct 2001
Visa Public

Index–1

D

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0
counters, 13–1 credit, 12–1 cryptogram, 10–1 Cryptogram Information Data, 11–2, 12–2, 12–10, 13–3, 13–5, 13–9 cryptogram type, 10–5, 13–9 cryptogram version 10, 12–4 cryptogram version 14, 1–8, 12–4 Cumulative Total Transaction Amount Upper Limit, 1–9 CVM Code, 8–4, 8–10 to 8–22 CVM Conditions, 8–4, 8–10 CVM Entry, 8–10 CVM List, 1–7 to 1–8, 2–3, 8–1, 8–4, 8–9 to 8–10, D–2 CVM List processing, 8–3, 8–9 card data, 8–3 processing flow, 8–12 CVM results, 8–7 CVM Type, 8–4 CVR, 8–6, 11–2, 13–3

cardholder selection, 3–10 to 3–11 Cardholder Verification, 2–3, 2–7, 4–2, 4–6, 8–1 to 8–22, 10–11 card data, 8–3 CVM List Processing, 8–9 CVM Processing, 8–13 processing, 8–9 terminal requirements, 8–3 Cardholder Verification Method List. See CVM List Cardholder Verification Method. See CVM cash, 7–5, 8–4 cash disbursement, 13–7 cashback, 7–5, C–2 CDOL1, 10–3, 10–5, 11–2 to 11–3 CDOL2, 13–2, 13–4, 13–8 Certificate Authority Public Key Index, 6–7 to 6–11, 6–15, 6–18, 8–5, 8–8 Certificate Serial Number, 6–9, 6–15, 6–18 Chip Condition Code, C–3 chip read, C–3 CID. See Cryptogram Information Data clearing message, 13–1, 13–6, 14–2, 14–5, B–3 Combined DDA/AC Generation, 1–7 to 1–8, 2–2, 2–7, 6–1, 6–18 to 6–19, 6–23 to 6–24, 10–9 online processing, 12–6 Combined DDA/AC Generation failure, 12–7, 12–10 to 13–1, 13–5 command response, B–2 command support requirements, 2–9 commands, 14–3 APPLICATION BLOCK, 14–3 APPLICATION UNBLOCK, 14–3 CARD BLOCK, 14–3 EXTERNAL AUTHENTICATE, 12–6, B–2 GENERATE AC, 10–5, 11–2 to 11–5, 12–6, 13–4 to 13–11, B–3 GET CHALLENGE, 8–8, 8–19, B–3 GET DATA, 8–8, 9–5, B–4 GET PROCESSING OPTIONS, 4–3, B–5 INTERNAL AUTHENTICATE, 6–14, B–5 PIN CHANGE/UNBLOCK, 14–4 PUT DATA, 14–4 READ RECORD, 3–5, B–5 SELECT, 3–5, B–5 to B–6 UPDATE RECORD, 14–4 VERIFY, 8–9, B–7 Completion, 2–5, 2–8, 6–23, 12–7 to 13–11, 14–7 card data, 13–2 processing flow, 13–10

D
Data Authentication Code (DAC), 1–7 DDA, 2–2, 4–2, 5–1 to 5–2, 6–1, 6–12 to 6–22, 8–5, 8–19 card data, 6–12 terminal data, 6–13 DDOL, 6–12 to 6–22 Dedicated File Name, B–6 default CVM, 2–3 Default DDOL, 6–13 to 6–22 DES, 11–5 DES keys, 8–7 Directory Definition File, 3–3, 3–7, B–6 Directory File, 3–3 Directory Selection Method, 1–7, 3–6 to 3–8, 3–10 to 3–11 domestic, 7–5 dynamic signature, 6–14, 6–17, 12–6

E
effective date checking, 7–6 EMV, 1–3, 1–6 to 1–7, D–4 EMV documentation, 1–11 Enciphered PIN data, 8–7 Enter PIN, 8–14, 8–17 expiration date checking, 7–6 expired application, 7–6, 10–4 EXTERNAL AUTHENTICATE command, 2–9, 12–6, 12–8, B–1 to B–2

Draft 12/18/00
Index–2
Visa Public

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0

F

F
Fail CVM, 8–22 FCI Issuer Discretionary Data, B–6 FCI Proprietary Template, B–6 FCI Template, B–6 to B–7 File Control Information, 3–3, 3–7, 4–2, 4–4, D–4, D–9 final approval by card, D–10 floor limits, 9–5 fraud risk, 6–7, 12–1, D–1 functional overview, 2–1 functions Application Selection, 3–1 to 3–15 Card Action Analysis, 11–1 Cardholder Verification, 8–1 Completion, 13–1 to 13–11 Initiate Application Processing, 4–1 Issuer-to-Card Script Processing, 14–1 to 14–7 Offline Data Authentication, 6–1 Online Processing, 12–1 Processing Restrictions, 7–1 Read Application Data, 5–1 Terminal Action Analysis, 10–1 Terminal Risk Management, 9–1 functions, mandatory and optional, 2–7

G
GENERATE AC command, 2–9, 12–6 to 12–7, 13–4 to 13–11, 14–2, 14–4, B–1, B–3, C–2 Completion, 13–1 Terminal Action Analysis, 10–5 to 10–10, 11–3 to 11–5 GET CHALLENGE command, 2–9, 8–8, 8–19, B–1, B–3 GET DATA command, 2–9, 8–8, 8–13 to 8–15, 9–5, 9–7 to 9–8, B–1, B–4 GET PROCESSING OPTIONS command, 2–9, 3–15, 4–1, 4–3 to 4–6, B–1, B–5, D–4

H
hash, 6–10, 6–13, 6–15, 6–18, 12–7 host-data-capture system, 13–7

I
IACs, 10–1 to 10–11, 13–2, 13–8, D–2 ICC Dynamic Data, 6–13 ICC Dynamic Number, 1–7 ICC PIN Encipherment key data, 8–19 ICC PIN Encipherment Private Key, 8–5 ICC PK Certificate, 6–12, 6–16, 6–19

ICC Private Key, 6–16 ICC Public Key, 1–8, 2–2, 6–17, 8–19, 12–6 ICC Public Key Exponent, 6–12 ICC Public Key Modulus, 6–17 ICC Public Key Remainder, 6–12 incorrect PIN, 8–17 indicators, 13–1 Initiate Application Processing, 2–2, 2–7, 3–5, 3–15, 4–1, 5–2, 5–5, 6–23, 8–23 card data, 4–2 processing, 4–4 processing flow, 4–5 terminal data, 4–3 Interface Device (IFD) Serial Number, 12–4 INTERNAL AUTHENTICATE command, 2–9, 6–13 to 6–16, B–1, B–5 international, 7–5 ISO documentation, 1–10 Issuer Application Data, 11–2, 12–2, 12–4, B–3, D–2, D–9 to D–10 issuer approval, D–10 Issuer Authentication, 2–5, 4–2, 12–1, 12–6 to 13–1 Issuer Authentication Data, 12–5 to 12–6, 12–8, B–2 Issuer Code Table Index, 3–3, B–6 to B–7 Issuer Country Code “5F28”, 7–2, 7–4 Issuer Discretionary Data, D–9 to D–10 issuer host, 12–1, 12–5 Issuer Identification Number, 6–9 Issuer PK Certificate, 6–7, 6–9, 6–15, 6–18, 8–5 Issuer Private Key, 8–5 Issuer Public Key, 1–8, 2–2, 6–9, 6–15, 6–18 Issuer Public Key Certificate. See Issuer PK Certificate Issuer Public Key Exponent, 6–7, 6–15, 6–18, 8–6 Issuer Public Key Modulus, 6–9, 6–15, 6–18 Issuer Public Key Remainder, 6–7, 6–9, 6–15, 6–18, 8–5 issuer script, 12–5, 14–3 to 14–4, D–9 to D–10 issuer script commands, B–1 to B–2 Issuer Script Identifier, 14–2 Issuer Script Results, 13–6, 14–2, 14–5 issuer scripts. See Issuer-to-Card Script processing Issuer-to-Card Script Processing, 2–5, 12–1, 13–6, 14–1 to 14–7 card data, 14–2 commands, 14–3 online response data, 14–3 processing, 14–4 processing flow, 14–6 terminal data, 14–2

Draft 12/18/00
31 Oct 2001
Visa Public

Index–3

K

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0
Online Authorization Indicator, 1–8 to 1–9 online authorization message, 12–4 to 12–5, 14–2, 14–5, B–3 Online Card Authentication, 2–5, 12–1 online PIN, 8–1, 8–21, 10–4 Online Processing, 2–4, 2–8, 4–6, 6–23, 12–1, 13–11, 14–7 card data, 12–2 commands, 12–6 new response data elements, 12–5 Processing, 12–6 processing flow, 12–9 terminal data, 12–2 to 12–3 Online Processing Requested, Online Authorization Not Completed, 13–8 online request, 10–1, 11–4, 12–6, C–3 online response, 12–5 to 12–6 online-capable terminal, 9–5, C–1, D–9 online-only terminal, 6–3, C–1, D–9 optional, 1–3

K
key entered, 12–1

L
Language Preference, B–6 to B–7 Last Online ATC Register, 9–3, 9–5, 9–7 to 9–8, B–4 Last PIN Try, 8–3, 8–14, 8–17 List of AIDs Method, 1–7, 3–6 to 3–7, 3–9 Lower Consecutive Offline Limit “9F14”, 9–3, 9–7 to 9–8, 10–4

M
magnetic stripe read, 12–1, C–3 magnetic stripe reader, C–4 mandatory, 1–3 manual entry, C–4 Maximum Target Percentage to be used for Biased Random Selection, 9–4, 9–6 merchant floor limit. See floor limits Merchant Forced Transaction Online, 9–5, 10–4 Merchant type, D–1, D–9 multiple commands, 14–4

P
PAN, 6–9, 6–16, 6–19, 9–3, 9–5, C–4 Payment Systems Directory, 3–7 Payment Systems Environment, 3–3, 3–5, 3–7 PDOL, 3–3, 3–5, 4–1 to 4–6, B–5, B–7, D–2, D–4, D–9 PIN block, 8–19 PIN CHANGE/UNBLOCK command, 14–4, B–2 PIN encipherment, 8–15 PIN OK, 8–17 PIN pad, 8–3, 8–7, 8–13 to 8–20 PIN Pad Secret Key, 8–7, 8–13, 8–15 PIN Try Counter, 8–5, 8–8, 8–13, 8–16, B–4 PIN Try Counter checking, 8–15 PIN Try Limit, 8–6 to 8–9, 8–16 to 8–18, 8–21 PIX, 3–2 POS device, 13–7 POS Entry Mode, C–3 post-issuance updates. See Issuer-to-Card Script Processing processing overview, 2–1 Processing Restrictions, 2–3, 2–7, 7–1, 10–11 Application Effective Date, 7–6 Application Expiration Date, 7–6 Application Usage Control, 7–4 Application Version Number, 7–3 card data, 7–2 processing flow, 7–7 terminal data, 7–3

N
new card, 9–8, 11–4 No CVM Required, 8–23

O
offline approval, 10–1, 11–4, 13–4 to 13–5, 13–8, D–1 Offline Data Authentication, 2–2, 2–7, 4–2, 4–6, 5–5, 6–1, 10–4, 10–11 terminal requirements, 6–3 offline decline, 10–1, 11–4, 13–1, 13–4 to 13–5, 13–8, D–1 Offline Enciphered PIN, 1–7, 8–1, 8–7, 8–16, 8–19 card data, 8–5 Offline Enciphered PIN processing flow, 8–20 offline low-value payments, D–1 Offline PIN, B–7 Offline PIN Processing card data, 8–5 Offline PIN processing card data, 8–6 Offline PIN Processing flow, 8–18 Offline Plaintext PIN, 8–1, 8–9, 8–13, 8–15 offline-capable terminal, 9–7, C–1 offline-only terminal, 13–1, C–1 offline-only transaction, D–4 online approval, 13–1 online authorization, 13–1, 13–4, 13–6, D–1, D–9

Draft 12/18/00
Visa Public

Index–4

31 Oct 2001

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0
PSE File Name, 3–4 PUT DATA command, 14–4 Subsequent Related Processing Card Action Analysis, 8–24, 10–11 Completion, 8–24, 11–5, 12–10 Issuer-to-Card Script Processing, 8–24, 12–10 Online Processing, 11–5 Terminal Action Analysis, 8–24, 9–11

Q

Q
quasi-cash, 8–4

R
Random Transaction Selection, 9–6, 10–4 Read Application Data, 2–2, 4–6 to 5–1, 6–23, 7–8, 8–23, 9–11, 10–11, 11–5 card data, 5–2 card files, 5–2 processing, 5–3 processing flow, 5–4 READ RECORD command, 2–9, 3–5, 3–7, 5–2 to 5–3, B–1, B–5 receipt, 8–21, 13–1, C–5 recommended, 1–3 Reference PIN, 8–5 to 8–6, 8–9, 8–16, 14–4 referrals, 13–6, B–3 required, 1–3 reversals, 13–7, 14–2, C–2 RID, 3–2, 6–7 to 6–9, 6–15, 6–18, 8–6, 8–8 RSA, 6–3 RSA key management, 6–4

T
TACs, 10–1 to 10–11, 13–4, 13–8, D–3, D–6 tamper-evident device, 8–7 Target Percentage to be used for Random Selection, 9–4, 9–6 TC, 10–9, 11–2, 11–4, 12–6 to 12–7, 13–1, 13–5 to 13–11, B–3 TC Hash Value, 10–5 Terminal Action Analysis, 2–4, 2–8, 6–23, 7–8, 10–1 to 10–11, 11–5, 13–8 card data, 10–2 processing, 10–6 processing flow, 10–10 terminal data, 10–3 Terminal Capabilities, 6–4 to 6–5, 8–7, 8–10, 12–4 Terminal Country Code, 4–3, 7–3, 12–4 terminal data for Application Selection, 3–4 for Card Action Analysis, 11–3 for Cardholder Verification, 8–7 for Completion, 13–4 for Initiate Application Processing, 4–3 for Issuer-to-Card Script Processing, 14–2 for Online Processing, 12–3 for Processing Restrictions, 7–3 for Terminal Action Analysis, 10–3 for Terminal Risk Management, 9–4 Terminal Exception File, 9–5, 10–4, D–7 terminal floor limit, 9–4 to 9–6, 10–4, D–3 to D–4 terminal messages, 3–10, 8–3, 8–14 to 8–18, 13–6 to 13–7, 13–9, 14–5, C–3 terminal random number, 9–6 Terminal Risk Management, 2–3, 2–8, 9–1, 10–6, 10–11 card data, 9–3 processing flow, 9–8 terminal data, 9–4 terminal velocity checking, 9–7 terminated transactions, 1–3 Threshold Value for Biased Random Selection, 9–4, 9–6 transaction authorized offline, Completion, 13–5 transaction authorized online, Completion, 13–6

S
script errors, 14–5 scripts, multiple, 14–5 SDA, 2–2, 2–7, 4–2, 5–1 to 5–2, 6–1, 6–7 SDA or DDA, determining which to perform Offline Data Authentication, 6–4 to 6–6 SDA Tag List, 1–7 to 1–8 SELECT command, 2–9, 3–5, 3–7 to 3–15, B–1, B–6, D–9 Service Code, C–3 services, 7–5 Session Key Generation, 1–8 Short File Identifier, 3–3, 3–5, 5–2, B–6 signature and offline PIN, 8–1, 8–21 to 8–22 signature, cardholder, 13–1 Signed Dynamic Application Data, 6–13 to 6–22, 12–6 Signed Static Application Data, 6–7, 6–10, 6–12 skimming, 6–1 Standard DDA, 2–2, 2–7, 6–15, 6–18 Standard Online Processing, 12–6 to 12–7 Standard VSDC, D–5, D–9 Static Data Authentication Tag List, 6–8, 6–10, 6–16, 6–19 static data to be authenticated, 6–8

Draft 12/18/00
31 Oct 2001
Visa Public

Index–5

U

Visa Integrated Circuit Card Terminal Specification, Version 1.4.0
VLP Terminal Support Indicator, D–3 to D–4, D–9 VLP Terminal Transaction Limit, D–3 to D–4

Transaction Currency Code, 8–7, 8–10, 12–4, D–3 to D–4, D–9 Transaction Date, 7–3, 7–6, 12–4, C–4 transaction flow, sample, 2–6 Transaction Log, 9–4 to 9–5, D–7 Transaction PIN, 8–5, 8–7, 8–9, 8–13, 8–15 to 8–16, 8–19 Transaction Status Information (TSI), 4–3 to 4–4, 6–4, 6–10, 6–17, 8–7, 8–11, 9–4, 9–8, 12–3, 12–7 to 12–8, 14–2, 14–4 Transaction Time, C–4 Transaction Type, 7–3, 12–4, D–4 TVR, 4–3 to 4–4, 6–4 to 6–5, 6–8, 6–10, 6–13, 6–17, 7–3, 8–7, 8–9, 8–16 to 8–17, 8–21, 9–4 to 9–8, 10–2 to 10–11, 12–3 to 12–4, 12–7 to 12–8, 13–4, 14–2, 14–5

Y
Y1 Authorization Response Code, 10–9, 13–4 to 13–5 Y3 Authorization Response Code, 13–4, 13–8

Z
Z1 Authorization Response Code, 10–8, 12–10, 13–4 to 13–5 Z3 Authorization Response Code, 10–9, 13–4, 13–8

U
unable to go online, 13–4, 13–8 Unpredictable Number, 6–13, 6–16, 8–8, 12–4 unrecognized CVM, 8–7, 8–10 to 8–12 UPDATE RECORD command, 14–4 Upper Consecutive Offline Limit “9F23”, 9–3, 9–7 to 9–8, 10–4 Use Chip Reader, C–3

V
velocity checking, card, 11–1, 11–4 velocity checking, terminal, 9–7 VERIFY command, 2–9, 8–5, 8–9, 8–16 to 8–20, B–1, B–7 Visa Certificate Authority, 6–3 Visa documentation, 1–11 Visa Integrated Circuit Card Specification, 1–1 impact summary, 1–7 revisions, 1–6 update, 1–2 Visa Low-value Payment, 1–7, 1–9, D–1 Visa Private Key, 8–5 Visa Public Key, 6–9, 6–15, 6–18, 8–8 to 8–9 Visa Public Key Modulus, 6–9, 6–15, 6–18 VLP duplicate data elements, D–1 to D–2, D–4, D–6 reset transaction, D–1, D–9 VLP Available Funds, D–1 to D–2, D–4, D–7, D–9 to D–10 VLP capable, card, D–4, D–9 VLP capable, terminal, D–4, D–9 VLP Funds Limit, D–1 to D–2, D–10 VLP Issuer Authorization Code, D–3 to D–4, D–7 VLP processing, D–4 VLP Single Transaction Limit, D–1, D–3

Draft 12/18/00
Visa Public

Index–6

31 Oct 2001

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.