visa integrated circuit card terminal specification

Welcome to Visa Integrated Circuit Card Terminal SpecificationThe 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

Terminal SpecificationVersion 1.4.0

Visa Integrated Circuit Card

Effective: 31 October 2001

Visa International 1998, 1999, 2001 5103-03

Visa Public

Printed on recycled paper.

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.

Draft 12/18/00i31 Oct 2001 Visa Public

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

1.3.2 Card/Integrated Circuit . . . . . . . . . . . . . . . . . . . . 1–3

1.3.3 Terminated Transactions . . . . . . . . . . . . . . . . . . . . 1–3

1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . 1–4

1.4.1 Volume Overview . . . . . . . . . . . . . . . . . . . . . . 1–4

1.4.2 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . 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

Contents

Draft 12/18/00

Contents Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

ii 31 Oct 2001Visa Public

1.7 Reference Materials . . . . . . . . . . . . . . . . . . . . . . . 1–10

1.7.1 International Organisation for Standardisation (ISO) Documents . . . . 1–10

1.7.2 EMV Documents . . . . . . . . . . . . . . . . . . . . . . 1–11

1.7.3 Visa Documents . . . . . . . . . . . . . . . . . . . . . . 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–7

3.4.2 List of AIDs Method . . . . . . . . . . . . . . . . . . . . . . 3–9

Draft 12/18/00

Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

Contents

iii31 Oct 2001 Visa Public

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


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



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


iv 31 Oct 2001Visa Public

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

6.2.1 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . 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–8

6.3.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 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–13

6.4.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . 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–18

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


Contents

v31 Oct 2001 Visa Public

7.5 Application Effective Date . . . . . . . . . . . . . . . . . . . . . . 7–6

7.6 Application Expiration Date . . . . . . . . . . . . . . . . . . . . . 7–6



Chapter 8 • Cardholder Verification

8.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . . 8–3

8.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–3

8.3 Terminal Data . . . . . . . . . . . . . . . . . . . . . . . . . . 8–7

8.4 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8

8.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 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



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 Merchant Forced Transaction Online . . . . . . . . . . . . . . . . . 9–5

Draft 12/18/00


vi 31 Oct 2001Visa Public

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



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



Draft 12/18/00


Contents

vii31 Oct 2001 Visa Public

Chapter 12 • Online Processing

12.1 Terminal Requirements . . . . . . . . . . . . . . . . . . . . . . 12–2

12.2 Card Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12–2

12.2.1 GENERATE AC Response Data . . . . . . . . . . . . . . . . 12–2

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

12.5.1.2 Standard Online Processing . . . . . . . . . . . . . . . 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.7 Subsequent Related Processing . . . . . . . . . . . . . . . . . 12–10

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


viii 31 Oct 2001Visa Public

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


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

14.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 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

14.5.8 Process Flow . . . . . . . . . . . . . . . . . . . . . . . 14–5


Draft 12/18/00


Contents

ix31 Oct 2001 Visa Public

Appendix A • Terminal and Acquirer Data Elements

A.1 Terminal and Acquirer Data Elements Table . . . . . . . . . . . . . . A–1

A.2 Terminal Data Element Tags . . . . . . . . . . . . . . . . . . . . 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


x 31 Oct 2001Visa Public

Appendix D • Terminal Requirements for Visa Low-Value PaymentFeature

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

D.5.1 VSDC Online-Capable Terminal . . . . . . . . . . . . . . . . .D–9

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

Appendix E • Acronyms

Glossary

Index

Draft 12/18/00xi31 Oct 2001 Visa Public

2–1: Sample Transaction Flow . . . . . . . . . . . . . . . . . . . 2–6

3–1: Directory Selection Method Example . . . . . . . . . . . . . . . . 3–8

3–2: Application Selection Processing Flow (1 of 3) . . . . . . . . . . . . 3–12



4–1: Initiate Application Processing Flow . . . . . . . . . . . . . . . . 4–5

5–1: Read Application Data Processing Flow . . . . . . . . . . . . . . . 5–4

6–1: SDA or DDA Determination . . . . . . . . . . . . . . . . . . . 6–6

6–2: SDA Flow . . . . . . . . . . . . . . . . . . . . . . . 6–11

6–3: DDA Flow (1 of 3) . . . . . . . . . . . . . . . . . . . . . 6–20

6–4: DDA Flow (2 of 2) . . . . . . . . . . . . . . . . . . . . . 6–21

6–5: DDA Flow (3 of 3) . . . . . . . . . . . . . . . . . . . . . 6–22

7–1: Processing Restrictions Flow . . . . . . . . . . . . . . . . . . 7–7

8–1: CVM List Processing . . . . . . . . . . . . . . . . . . . . 8–12

8–2: PIN Try Counter Checking . . . . . . . . . . . . . . . . . . 8–15

8–3: Offline PIN Processing . . . . . . . . . . . . . . . . . . . 8–18

8–4: Offline Enciphered PIN Processing . . . . . . . . . . . . . . . 8–20

8–5: Online PIN Processing . . . . . . . . . . . . . . . . . . . 8–21

8–6: Signature Processing . . . . . . . . . . . . . . . . . . . 8–22

8–7: Fail CVM Processing . . . . . . . . . . . . . . . . . . . . 8–22

8–8: No CVM Required Processing . . . . . . . . . . . . . . . . . 8–23

9–1: Terminal Risk Management Processing Flow (1 of 2) . . . . . . . . . . . 9–9

9–2: Terminal Risk Management Processing Flow (2 of 2) . . . . . . . . . . 9–10

10–1: Terminal Action Analysis . . . . . . . . . . . . . . . . . . . 10–10

12–1: Online Processing . . . . . . . . . . . . . . . . . . . . . 12–9

Figures

Draft 12/18/00

Figures Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

xii 31 Oct 2001Visa Public

13–1: Completion Processing Flow . . . . . . . . . . . . . . . . . . 13–10

14–1: Issuer-to-Card Script Processing . . . . . . . . . . . . . . . . 14–6

D–1: VLP Transaction Flow . . . . . . . . . . . . . . . . . . . . D–8

Draft 12/18/00xiii31 Oct 2001 Visa Public

2–1: Terminal Functional Requirements . . . . . . . . . . . . . . . . 2–7

2–2: Command Support Requirements . . . . . . . . . . . . . . . . . 2–9

3–1: Application Selection—Card Data . . . . . . . . . . . . . . . . . 3–2

3–2: Application Selection—Terminal Data . . . . . . . . . . . . . . . 3–4

3–3: Application Selection Indicator Matching Criteria . . . . . . . . . . . . 3–6

3–4: Sample AIDs Matching . . . . . . . . . . . . . . . . . . . . 3–9

4–1: Initiate Application Processing—Card Data . . . . . . . . . . . . . . 4–2

4–2: Initiate Application Processing—Terminal Data . . . . . . . . . . . . . 4–3

5–1: Read Application Data—Card Data . . . . . . . . . . . . . . . . 5–2

5–2: Read Application Data—Card Files . . . . . . . . . . . . . . . . 5–2

6–1: Terminal Data Used in SDA or DDA Determination . . . . . . . . . . . 6–4

6–2: Card Data Used in SDA or DDA Determination . . . . . . . . . . . . 6–5

6–3: Offline Data Authentication—SDA Card Data . . . . . . . . . . . . . 6–7

6–4: Offline Data Authentication—SDA Terminal Data . . . . . . . . . . . . 6–8

6–5: Offline Data Authentication—DDA Card Data . . . . . . . . . . . . 6–12

6–6: Offline Data Authentication—DDA Card Data in INTERNAL AUTHENTICATE Response . . . . . . . . . . . . . . . . . 6–13

6–7: Offline Data Authentication—DDA Terminal Data . . . . . . . . . . . 6–13

7–1: Processing Restrictions—Card Data . . . . . . . . . . . . . . . . 7–2

7–2: Processing Restrictions—Terminal Data . . . . . . . . . . . . . . . 7–3

7–3: Application Usage Control (AUC) . . . . . . . . . . . . . . . . . 7–5

8–1: CVM List Processing—Card Data . . . . . . . . . . . . . . . . . 8–3

8–2: Offline PIN—Card Data . . . . . . . . . . . . . . . . . . . . 8–5

8–3: Offline Enciphered PIN—Card Data . . . . . . . . . . . . . . . . 8–5

8–4: Offline PIN Processing—Card Data . . . . . . . . . . . . . . . . 8–6

Tables

Draft 12/18/00

Tables Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

xiv 31 Oct 2001Visa Public

8–5: CVM Processing—Terminal Data . . . . . . . . . . . . . . . . 8–7

8–6: Offline Enciphered PIN—Terminal Data . . . . . . . . . . . . . . 8–8

9–1: Terminal Risk Management—Card Data . . . . . . . . . . . . . . 9–3

9–2: Terminal Risk Management—Terminal Data . . . . . . . . . . . . . 9–4

9–3: Example Terminal Parameters . . . . . . . . . . . . . . . . . 9–6

10–1: Offline Processing Results—Card Data . . . . . . . . . . . . . . 10–2

10–2: Request Application Cryptogram—Card Data . . . . . . . . . . . . 10–3

10–3: Offline Processing Results—Terminal Data . . . . . . . . . . . . . 10–3

10–4: Request Application Cryptogram—Terminal Data . . . . . . . . . . . 10–5

11–1: Card Action Analysis—Card Data . . . . . . . . . . . . . . . . 11–2

11–2: GENERATE AC Command Response Data . . . . . . . . . . . . . 11–2

11–3: Card Action Analysis—Terminal Data . . . . . . . . . . . . . . . 11–3

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

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

12–2: Online Processing—Other Card Data . . . . . . . . . . . . . . . 12–3

12–3: Online Processing—Terminal Data . . . . . . . . . . . . . . . . 12–3

12–4: Visa Smart Debit Credit (VSDC) Data Objects Required in Online Message . . . 12–4

12–5: New Authorization/Financial Transaction Response Data Elements . . . . . 12–5

13–1: Completion—Card Data . . . . . . . . . . . . . . . . . . . 13–2

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

13–3: Completion—Terminal Data . . . . . . . . . . . . . . . . . . 13–4

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

13–5: Online Transaction Disposition Response . . . . . . . . . . . . . 13–8

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

14–2: Issuer-to-Card Script Processing—Online Response Data . . . . . . . . 14–3

A–1: Terminal and Acquirer Data Elements . . . . . . . . . . . . . . . A–2

A–2: Terminal Data Element Tags . . . . . . . . . . . . . . . . . . A–22

B–1: Data Retrieval Using GET DATA . . . . . . . . . . . . . . . . B–4

B–2: Data Retrieval With GET PROCESSING OPTIONS . . . . . . . . . . B–5

D–1: Initiate Application Processing—Card Data . . . . . . . . . . . . . D–2

D–2: Initiate Application Processing—Card Data . . . . . . . . . . . . . D–3

D–3: Terminal TACs for VLP . . . . . . . . . . . . . . . . . . . D–6

Draft 12/18/001–131 Oct 2001 Visa Public

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:

● 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

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

About This Specification Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

1–2 31 Oct 2001Visa Public

1.1 AudienceThis 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 UpdateThis 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.3 Terminology

1–331 Oct 2001 Visa Public

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



1.4 Document StructureThis 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:

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

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



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:

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

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

1.5 Revisions to This SpecificationRevisions 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 Impact Summary


1.6 Impact SummaryThe 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● 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.

1.6.1.2 Optional● 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.

Draft 12/18/00



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

1.6.2.2 Optional● 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.

Draft 12/18/00


1.6 Impact Summary


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

Draft 12/18/00



1.7 Reference MaterialsThe 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

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

Draft 12/18/00


1.7 Reference Materials


1.7.2 EMV Documents

Available on the EMVCo Website: http://www.emvco.com/specifications.cfm

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

1.7.3 Visa Documents

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

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

● VIS Corrections and Updates

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

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

● 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



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

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

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

Draft 12/18/00


1.7 Reference Materials


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

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

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

● 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

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

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

Available by request to the VSDC Hotline:

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


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

Processing Overview Visa Integrated Circuit CardTerminal 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.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



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



Figure 2–1: Sample Transaction Flow

1 - I f DDA2 - If Offline Enciphered

PIN3 - Optional for Offline PIN4 - If Offline PIN

Mandatoryprocess

Mandatoryp rocess w /

opt ionals teps

K E Y

Optionalp rocess

C a r d Terminal

Init iate ApplicationProcess ing

Onl ineTransact ion?

Appl icat ion Select ion

Read Appl icat ionData

Lis t o f Suppor tedAppl icat ions

Offl ine DataAuthenticationS D A o r D D A

Process ingRest r ic t ions

CardholderVer i f icat ion

Termina l R iskM a n a g e m e n t

Terminal Act ionAnalysis

Issuer Authentication

Onl ine Processing

Complet ion

Issuer-to-Card ScriptProcess ing

S E L E C TCommand/Response

Suppor ted Funct ions& Pointers to

Appl icat ion Data

Provide Appl icat ionRecords

Generate DynamicCryptogram

Last OnlineAppl icat ion

Transact ion Counter(ATC) Register

GET PROCESSING OPT IONSCommand /Response

R E A D R E C O R DCommands /Responses

INTERNAL AUTHENTICATE1

Command /Response

PIN Try Counter

N

Y

VERIFY Command/Response4

GET DATACommand/Response

Perform Card Act ionAnalysis & generate

Appl icat ionCryptogram

GENERATE APPLICATIONCRYPTOGRAM Response

Val idate ARPCCryptogram

E X T E R N A L A U T H E N T I C A T ECommand /Response

Apply Script

Perform f inal checks& genera te f ina l

cryptogram

Issuer-to-Card ScriptCommands /Responses

GENERATE APPL ICAT IONC R Y P T O G R A M

Command /Response

G E N E R A T E A P P L I C A T I O NC R Y P T O G R A M C o m m a n d

GET DATA Command /Response 3

GET CHALLENGE Command /Response 2Generate Unpred.

Number

Val idate PIN

READ RECORDCommand/Response

Draft 12/18/00


2.2 Terminal Mandatory and Optional Functionality


2.2 Terminal Mandatory and Optional FunctionalityVSDC 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 Terminal Support

Application Selection

● Directory Method

● Explicit Selection Method

● Implicit Selection Method

Mandatory

Optional (EMV)

Mandatory (EMV)

Not used for financial interchange (EMV)

Initiate Application Processing Mandatory (EMV)

Offline Data Authentication

● SDA

● Standard DDA

● Combined DDA/AC Generation

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)

Optional (EMV)

Processing Restrictions

● Application Version Number

● Application Usage Control

● Effective Date Checking

● Expiration Date Checking

Mandatory (EMV)

Mandatory (EMV)

Mandatory (EMV)

Mandatory (EMV)

Mandatory (EMV)

Cardholder Verification

● No CVM Required

● Fail CVM Processing

● Other CVMs (Offline PIN, Online PIN, signature, etc.)

Mandatory (EMV) with Operating Regulation exceptions (VIS)

Mandatory (EMV)

Mandatory (EMV)

Optional (EMV)

Conditional with Operating Regulation exceptions (VIS)

Draft 12/18/00



Terminal Risk Management

● Terminal Exception File

● Merchant Force Online

● Floor Limits

● Transaction Log

● Random Selection

● Velocity Checking

● New Card

Conditional—If merchant controlled terminal (EMV)

Some functions do not apply for online-only or offline-only terminals (EMV)

Optional (EMV)

Optional (EMV)

Mandatory (EMV)

Optional (EMV)

Conditional—If both online & offline capable (EMV)

Conditional—If offline capable (EMV)

Mandatory—(EMV)

Terminal Action Analysis Mandatory (EMV)

Card Action Analysis n/a (card function)

Online Processing

● Online Capability

● Advice Messages

● Issuer Authentication

Optional (EMV and VIS)

Optional (EMV and VIS)

Conditional—If online capable

Completion Mandatory

Miscellaneous Functions

● Cardholder amount validation

● Voice Referrals

● Card initiated referrals

● Merchant forced acceptance

● Chip card informationaladvices

● Prompt for chip read

Recommended (EMV)

Recommended

Not supported (VIS)

Optional (EMV)

Optional (EMV)

Conditional—At discretion of country or region (VIS)

Mandatory (EMV)

Table 2–1: Terminal Functional Requirements (2 of 2)

Function Terminal Support

Draft 12/18/00


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

Command Terminal Support

EXTERNAL AUTHENTICATE Conditional—If online-capable (EMV)

GENERATE APPLICATION CRYPTOGRAM (AC)

Mandatory (EMV)

GET CHALLENGE Conditional—If Offline Enciphered PIN supported (EMV)

GET DATA Conditional—If ATM or merchant controlled device (EMV)

GET PROCESSING OPTIONS Mandatory (EMV)

INTERNAL AUTHENTICATE Conditional—If DDA supported (EMV)

READ RECORD Mandatory (EMV)

Issuer Script Commands

● APPLICATION BLOCK (EMV)

● APPLICATION UNBLOCK (EMV)

● CARD BLOCK (EMV)

● PUT DATA (VIS)

● UPDATE RECORD (VIS)

● PIN CHANGE/UNBLOCK (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)

SELECT Mandatory (EMV)

VERIFY Conditional—If Offline PIN supported (EMV)


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. The terminal builds a candidate list of mutually supported applications.

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

Application Selection Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


3.1 Card DataThe 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 Description

Application Definition File (ADF) 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.

Application Elementary Files (AEF)

AEF contains data elements used by the application in processing.

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.

● 1010—Visa Debit and Visa Credit

● 2010—Visa Electron

● 3010—Interlink

● 8010—Plus

● 999910—Proprietary ATM applications

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.1 Card Data


Application Preferred Name 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.

Application Priority Indicator Indicates the priority of a given application or group of applications in a directory.

Directory Definition File (DDF) 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.

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.

File Control Information (FCI) The FCI is provided in response to the SELECT command. This information varies depending on the type of file selected.

Issuer Code Table Index 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.

Payment Systems Environment (PSE)

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.

Processing Options Data Objects List (PDOL)

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.

Short File Identifier (SFI) The SFI is a pointer to elementary files (EF).

● 1–10 Reserved for EMV

● 11–20 Payment system specific

● 21–30 Issuer specific

Table 3–1: Application Selection—Card Data (2 of 2)


Draft 12/18/00



3.2 Terminal DataThe 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


Application Identifier (AID) 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.

● 1010—Visa Debit and Visa Credit

● 2010—Visa Electron

● 3010—Interlink

● 8010—Plus

● 999910—Proprietary ATM applications

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.

PSE File Name The name of the PSE (1PAY.SYS.DDF01) is used in Application Selection if the terminal supports directory selection.

Draft 12/18/00


3.3 Commands


3.3 CommandsSELECT

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:

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

● 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



3.4 Building the Candidate ListTwo 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.

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

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:

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

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

Option 1Match

Option 2

A0000000031010 A000000003101001 N Y

A0000000031010 A000000003101002 N 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.4.1 Directory Selection Method

Directory Selection Method processing includes the following steps:

1. The terminal selects the PSE, which is a special DDF, using the SELECT command. The name of the PSE file is 1PAY.SYS.DDF01.

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

3. If the card responds with SW1 SW2 “6181”, the session is terminated.

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

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

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

Draft 12/18/00



In the example in Figure 3–1, the terminal:

1. Reads Record 1 from the Payment Systems Directory.

2. Checks to see if either of the AIDs for the ADF Entry 1 or 2 match terminal AIDs.

3. Reads Record 2 from the Payment Systems Directory.

4. Selects the DDF directory indicated in Entry 1 of Record 2.

5. Reads Record 1 from the DDF Directory.

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

7. Returns to processing entries and records from the previous directory, when card responds that there are no more records in the directory.

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

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

Entry 2ADF

Entry 1ADF

PaymentSystemsDirectory

Record 2Record 1

PSE

Entry 2ADF

Entry 1DDF

DDFDirectory

Record 1

Entry 2ADF

Entry 1ADF

DDF

Draft 12/18/00




3.4.2 List of AIDs Method

List of AIDs Method processing includes the following steps:

1. The terminal retrieves the AID of an application from a list of applications supported by the terminal.

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

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

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

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

Figure 3–4 shows sample matching AIDs.

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.

Table 3–4: Sample AIDs Matching

Terminal AIDTerminal Application Card AID

Card Application

A0000000031010 Visa A000000003101001 Visa Credit

A0000000031010 Visa A000000003101002 Visa Credit

Draft 12/18/00



3.5 Identifying and Selecting the ApplicationIf 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.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



3.6 Flow

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

Appl icat ion Select ion- Directory Select ion

Method

T e r m i n a lsuppor ts PSE

List o f AIDsMe thod

Card respondsw i t h FC I and“9000” i f (card

not blocked andPSE found andnot b locked) or

(ca rd no tb locked andDDF found)

N

Terminal c lears thecandidate l ist and

issues SELECT wi thDFNAME =

1PAY.SYS.DDF01

Y

S E L E C Tc o m m a n d

Cardb locked?

Get SFI for Directory fromFCI and set record # to 1

Termina l issuesR E A D R E C O R D

Card respondswith Directory

Entry and“9000” i f found

R E A DR E C O R Dc o m m a n d

Record Found?READ

RECORDresponse

Directory stackempty?

C h o o s eAppl icat ion

and SELECT

Get p rev iousdirectory from l ist andcont inue processing

N

Another entry in record?

Incrementrecord numberN

Get entry

Y

A D F ?

Termina lsupports?

Y

Y

Add to candidate l ist

Y

C

C

A

N

A

Place current directoryand resumpt ion

information on directorys tack

Termina l issuesSELECT wi th

DFNAME o f DDF

B

B

S W 1 & 2 =9000?

N

C

N

N

Card Terminal

Cand ida teList Empty?Y

N

Y

D D F =PSE?

SELECTresponse

Y

N

N

Y

Terminatetransact ion

Y

Draft 12/18/00


3.6 Flow



List of AIDsSelec t ionMethod

Issue SELECTcommand w i t h DF

Name = AID.

Card respondswi th FCI or er ror

message

Card B locked?(SW1SW2 =

6A81)

Appl icat ionb locked?

(SW1SW2 =6 2 8 3 ) ?

Add Appl icat ion toCandidate L is t

Set P2 in SELECT to “02 ”indicat ing select next appl icat ion

wi th same DFNAME

Get nex t A ID f romterminal l is t of AIDs

N a m e i n F C Iexac t ma tch?

Another AID interminal l ist?

ChooseAppl icat ion

a n d S E L E C T

Filefound for AID?( S W 1 S W 2 N E

6A82)

N a m e i n F C Ipart ial match?

Terminalterminates card

session

SELECTcommand

S E L E C Tresponse Y

N

N

Y

Y

N

Y

N

N

Y

B B

B

Get f i rst AID fromterminal l ist of AIDs

Y

N

TerminalCard

Y

Part ia l Select ionsupported for AID? N

Draft 12/18/00




Terminalterminates the

t ransact ion

Any mutual lysuppor ted

appl icat ions?N

Termina lsupportsselection?

Appl icat ionsavai lable wi thout

conf i rmat ion?

Terminal ident i f ieshighest priori tyapp l ica t ion not

requir ingconfirmation

Term ina lconf i rmat ion

support?

Terminaldisplays highest

priorityapplication on

list forconfirmation

Terminaldisplays

appl icat ions bypriority and

asks cardholderto select

T

Termina l i ssuesSELECT commandwith the identif ied

appl icat ion

Card responds wi th FCIfor requested AID and

“9000” (select ionsuccessful) or “6283 ”(appl icat ion blocked)

SuccessfulSELECT( “9000 ”)?

S E L E C Tresponse

BTerminal proceeds to

Init iate ApplicationProcess ing

B

Termina l removesappl icat ion from l ist

Y

SELECTcommand

Appl icat ionselected?

Cardholderconf i rms?

Y

N

Y

NT

N

Y

N

Y

Y

N

N

ChooseAppl icat ion& S E L E C T

Card Terminal

Draft 12/18/00




3.7 Subsequent Related ProcessingInitiate 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.


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.


4.1 Card Data

4.2 Terminal Data

4.3 GET PROCESSING OPTIONS Command

4.4 Processing

4.5 Prior Related Processing


Draft 12/18/00

Initiate Application Processing Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


4.1 Card DataThe 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


File Control Information (FCI) Information such as file name and language preference provided by card in response to the SELECT command issued by the terminal.

Processing Options Data Object List (PDOL)

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

Application Interchange Profile (AIP)

A data element, which indicates the capability of the card to support specific functions in the application (SDA, DDA, Cardholder Verification, and Issuer Authentication).

Application File Locator (AFL) 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:

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

Draft 12/18/00


4.2 Terminal Data


4.2 Terminal DataThe 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.

4.3 GET PROCESSING OPTIONS CommandThe 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).

Table 4–2: Initiate Application Processing—Terminal Data


Terminal Country Code 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.

Terminal Verification Results (TVR)

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.

Transaction Status Information (TSI)

Indicates the functions performed by the terminal. This data element is not provided in the online authorization and clearing messages.

Draft 12/18/00



4.4 ProcessingThe terminal initiates application processing by sending the GET PROCESSING OPTIONS command to the card. The terminal:

1. Extracts the PDOL (if present) from the FCI provided by the card in response to the SELECT command.

2. Sets the Transaction Status Information (TSI) to zero.

3. Sets the Terminal Verification Results (TVR) to zero.

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

5. Receives the card response to the GET PROCESSING OPTIONS command.

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

7. If the card responds with the AFL and the AIP, the terminal proceeds to Read Application Data.

Draft 12/18/00


4.4 Processing


Figure 4–1 shows the Initiate Application Processing flow.

Figure 4–1: Initiate Application Processing Flow

Terminal completesApplicat ion Select ion

(Chapter 3)

Termina l issues GETP R O C E S S I N G O P T I O N S

(includes data requested bycard in PDOL)

Terminal sets TSI and TVRto ze ro

N

Termina l uses PDOL ( i fprov ided by card dur ingAppl icat ion Select ion) todetermine terminal data

elements to inc lude in GETP R O C E S S I N G O P T I O N S

command.

Card response= condi t ions of use not

sat is f ied (SW1SW26 9 8 5 ) ?

Y

Terminal proceeds to ReadAppl icat ion

Data (Chapte r 5 )

Termina l e l iminatesapplication from l ist of

el igible appl icat ions andreturns to Appl icat ionSelect ion (Chapter 3)

GETPROCESSING

OPTIONScommand

GETPROCESSING

OPTIONS response

Card Terminal

Card rece i vescommand, does in terna lprocess ing & respondswith “9000” , AIP, & AFL

or error code

Draft 12/18/00



4.5 Prior Related ProcessingApplication 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 ProcessingRead 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.


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.


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.


5.1 Card Data

5.2 Terminal Data

5.3 READ RECORD Command

5.4 Processing



Draft 12/18/00

Read Application Data Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


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

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

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

Table 5–1: Read Application Data—Card Data


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

● 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

Table 5–2: Read Application Data—Card Files


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.

Draft 12/18/00


5.3 READ RECORD Command


5.3 READ RECORD CommandThe 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:

● P2 includes the Short File Identifier (SFI) of the file to be read

● P1 is the record number within the file

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

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

Draft 12/18/00

Read Application Data Visa Integrated Circuit CardTerminal 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

SDA Count = count inAFL ent ry

Terminal completesInit iate Appl.Processing

Card passes recordto terminal

Termina l sendsR E A D R E C O R Dcommand to ca rd

READR E C O R Dcommand

P1= last record number

in AFL entry?

A n y m o r e A F Lentr ies?

Terminal proceeds toOff l ine Data

Authenticat ion(Chapter 6)

Terminal selects nextAFL ent ry

Y

Card

S W 1 S W 2 =9000 (successfu l

read)?

Requested record inR E A D R E C O R D

response

SDA Count = 0?

Y

Terminal stores datafor la ter use

A n ydata e lement tags

alreadyrece ived?

All mandatorydata received?

N

Y

Term ina lte rmina testransaction

Termina lincrements P1

(record number)

Terminal selects f irstentry f rom AFL

NPuts data in a l ist of

SDA data

Terminal

Y

N

P1 = f irst recordnumber in AFL

P 2 = S F I

D e c r e m e n t S D ACount by 1

Y

N

N

Y

N

Draft 12/18/00




5.5 Prior Related ProcessingInitiate 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 ProcessingOther functions use the data saved during Read Application Data for processing.


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.


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:

● Static Data Authentication (SDA)

● Dynamic Data Authentication (DDA)

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

Offline Data Authentication Visa Integrated Circuit CardTerminal Specification, Version 1.4.0



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)



Draft 12/18/00




6.1 Terminal RequirementsTerminals 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:

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

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:

● 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

Draft 12/18/00



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


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

● SDA supported

● Standard DDA supported

● Combined DDA/AC Generation Supported


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

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:

● 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

Table 6–2: Card Data Used in SDA or DDA Determination



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

● SDA supported

● DDA supported

● Combined DDA/AC Generation supported

Draft 12/18/00



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/ACGenerat ion supported b i t

set to “1” in AIP?

Terminalsuppor ts Combined DDA/

AC Genera t ion?

Terminal proceeds toProcess ing Rest r ic t ions

(Chap te r 7 )

Off l ine DDA issupported set to “1” in

AIP?

Terminal supportsStandard DDA?

Terminal sets Off l ine DataAuth. was Not Per formed

bi t to “1” in TVR.

YY

N

N

Y

Termina l p roceeds to DDAprocess ing

(Sect ion 6 .4 )

Termina l proceeds to SDAprocess ing

(Sect ion 6.3)

N

Off l ine SDA suppor tedset to “1” in AIP?

N

Terminalsupports

SDA?

Y

N

Y

Method used isS tandard DDA

Method used isC o m b i n e d D D AAC Generat ion

Y

N

Draft 12/18/00




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 Description

Certificate Authority Public Key Index (PKI)

Used with the RID to designate which Visa CA Public Key to use for offline data authentication.

Issuer Public Key (PK) Certificate

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:

● 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

Issuer Public Key Exponent Used in the RSA decryption algorithm.

Issuer Public Key Remainder If necessary, it contains the portion of the Issuer Public Key that does not fit within the Issuer Public Key Certificate.

Registered Application Identifier (RID)

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.

Signed Static Application Data (SAD)

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.

Draft 12/18/00



6.3.2 Terminal Data

The terminal data elements described in Table 6–4 are required if the terminal supports SDA.

6.3.3 Commands

No commands are used in SDA.

Static Data Authentication Tag List

Optional field containing the tag of the AIP (tag “82”). If other tags are present, SDA processing fails.

Static Data to be Authenticated 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.

Table 6–4: Offline Data Authentication—SDA Terminal Data

Data 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 Visa CA Public Keys 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.

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.

Table 6–3: Offline Data Authentication—SDA Card Data (2 of 2)

Data Description

Draft 12/18/00




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:

■ 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

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



3. Verification of the Signed Static Application Data (SAD)


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



■ A valid data format

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. Compares the calculated hash with the hash recovered from SAD. If they are not the same, SDA fails.

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




Figure 6–2 illustrates how SDA could be performed.

Figure 6–2: SDA Flow

Card data to suppor tSDA present?

Terminal data tosuppor t SDA present?

Recove redcertif icate passes validity

checking?

Y

Terminal sets ICC DataMissing bi t to “1” in TVR

Terminal uses V isa CA PK torecover Issuer PK from IssuerPK Cert i f icate and Issuer PK

Remainder

Terminal uses Issuer PK torecover SAD, which inc ludes a

hash of stat ic data

Recovered da ta passesvalidity checking?

Terminal concatenates datarecovered f rom SAD and stat ic

data to be authent icated &calculates a hash from

concatenation result

Calculated hashequals hash recovered

f rom SAD?

Terminal sets Off l ine Data Auth.was Performed bi t to “1” in TSI

Terminal proceeds toProcess ing Rest r ic t ions

(See Chap te r 7 )

Terminal sets Off l ine Stat icData Auth. Fai led bit to “1” in

TVR

N

Y

Y

N

N

Y

Y

N

N

Draft 12/18/00



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 Description

ICC Public Key (PK) Certificate Contains the ICC Public Key and a hash of the static data. This data is signed with the Issuer Private Key.

ICC Public Key Exponent Contains the exponent to be used by the RSA algorithm that recovers the ICC PK Certificate.

ICC Public Key Remainder If necessary, contains that part of the ICC Public Key that did not fit in the ICC PK Certificate.

Dynamic Data Authentication Data Object List (DDOL)

Contains the tags and lengths of the terminal data to be included in the INTERNAL AUTHENTICATE command requesting a dynamic signature.

Draft 12/18/00




During DDA, the terminal receives the data (described in Table 6–6) from the card in the INTERNAL AUTHENTICATE response.

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–6: Offline Data Authentication—DDA Card Data in INTERNAL AUTHENTICATE Response


Signed Dynamic Application Data

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

● 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

Table 6–7: Offline Data Authentication—DDA Terminal Data


Default Dynamic Data Authentication Data Object List (Default DDOL)

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.

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

Draft 12/18/00



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:

● 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

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




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.




b. Recovers the data from Issuer Public Key Certificate using the Visa CA Public Key. The recovered data includes the Issuer Public Key.








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



3. Retrieval of the ICC Public Key


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.







■ A recovered PAN which matches the Application PAN from the card

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




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.





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



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.


The terminal:


b. Recovers the data from Issuer Public Key Certificate using the Visa CA Public Key. The recovered data includes the Issuer Public Key.








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




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.







■ A recovered PAN which matches the Application PAN from the card

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



Figure 6–3: DDA Flow (1 of 3)

Data requi redto authent icate ICC PK

available?

Retr ieve Terminal CA PK using R ID/CA PK Index

CA PK found fo rR ID /CA PK

Index?

IssuerPK Certi f icate

& CA PK sameleng th?

Recover data in Issuer PKCert i f icate using CA PK

Recovered datahas val id header, t rai ler ,format and PK Algori thm

Indicator?

Concatenate recovered cert i f icatedata, Issuer PK Remainder , and

Issuer PK Exponent

Calcu la te hash f rom concatenateddata

Set ICC Data Miss ingbit to “1” in TVR

Terminal proceeds to DDAfa i lu re

N

Y

Y

Y

Y

N

N

N

Ret r ieva l o fCert i f icate Authori ty

Publ ic Key

Retrieval of IssuerPubl ic Key

Recovered hash =calculated hash?

Issuer ID Number =first digits of

P A N ?

Issuer PK Cert i f icateexp i red?

Concatenate cert i f icate'sIssuer PK and Issuer PK

Remainder to get Issuer PKModu lus

N

Y

Y

N

N

A

B

A

Y

C

TerminalCard

Draft 12/18/00





ICC PK Cert i f icateand Issuer PK Modulus

same length?

Retr ieval of ICCPubl ic Key

Recover data in ICC PK Cert i f icateusing Issuer PK

Recovereddata has val id header, t rai ler,

format, and PK algor i thmindicator?

Y

B

Calculated hash =recovered hash?

Concatenate cert i f icate dataelements, ICC PK Remainder,

ICC PK Exponent, and stat ic datato be authenticated

Apply hashing algorithm to resultof concatenation

Recovered PAN =Appl icat ion PAN?

Cert i f icate expired?

Y

Y

Concatenatecerti f icate ’s ICC PK andICC PK Remainder toform ICC PK Modulus

Y

Y

N

N

C

D

N

N

TerminalCard

DDA Fai led

Standard DDA?

Y

Proceed to ProcessingRestr ict ions

N

Draft 12/18/00




D

DDOL rece ived f rom Card?

U s e C a r d D D O L

Terminal issues INTERNALA U T H E N T I C A T E c o m m a n dwi th DDOL data e lements

Use Terminal ’sDefau l t DDOL

DDOL inc ludes Unpred ic tab le Number?

Card genera tesdynamic s ignatureusing ICC PrivateKey and re turns

response to termina l

SW1 SW2 =9000

( INTERNALA U T H E N T I C A T E

successful)?

Set Off l ine DynamicData Authent icat ionFai led to “1 ” in TVR.

N

Y

Y

DynamicSignatureGenerat ion

Signed DynamicAppl icat ion Data &ICC PK Modu lus

same leng th?

DynamicSignatureVerif ication

Concatenate recovereddata f rom Signed

Dynamic Appl icat ionData w i th DDOL da ta

Calculate hashf rom

concatenated data

Recovered hash = calculated hash?

Set Off l ine DataAuthent icat ion

was Performed inTSI .

Y

G

G

Y

Recovered datahas val id header ,trailer, & format?

INTERNALAUTHENTICATE

response withdynamic s ignature

Y

Recover data inSigned Dynamic

Appl icat ion Data usingICC PK

N

C

Y

N

N

N

Proceed toProcessingRestr ict ions(Chapter 7 )

DDASuccess

DDAFailure

Terminal(Standard DDA Only)

Card(Standard

DDA Only)

INTERNALAUTHENTICATE

Command

Draft 12/18/00





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

● 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



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


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



Draft 12/18/00

Processing Restrictions Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


7.1 Card DataThe 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


Application Effective Date The Application Effective Date is the date when the application becomes activated for use.

Application Expiration Date The Application Expiration Date is the date after which the application is no longer available for use.

Application Usage Control (AUC)

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.

Application Version Number 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.

Issuer Country Code 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.

Draft 12/18/00


7.2 Terminal Data


7.2 Terminal DataThe 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.

7.3 Application Version NumberThe 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.

Table 7–2: Processing Restrictions—Terminal Data


Application Version Number This data element, (tag “9F09”), indicates the version of the application in the terminal. Terminals complying with this specification should use 140.

Terminal Country Code 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.

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.

Transaction Type 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.

Draft 12/18/00



7.4 Application Usage ControlApplication 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. To process the transaction at an ATM, the indicator for “Valid at ATMs” shall be “1” in the AUC.

3. 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 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 b8 b7 b6 b5 b4 b3 b2b b1 Usage

1 1 - - - - - - - Valid for domestic cash transactions

1 - 1 - - - - - - Valid for international cash transactions

1 - - 1 - - - - - Valid for domestic goods

1 - - - 1 - - - - Valid for international goods

1 - - - - 1 - - - Valid for domestic services

1 - - - - - 1 - - Valid for international services

1 - - - - - - 1 - Valid at ATMs

1 - - - - - - - 1 Valid at terminals other than ATMs

2 1 - - - - - - - Domestic cashback allowed

2 - 1 - - - - - - International cashback allowed

Draft 12/18/00



7.5 Application Effective DateIssuer-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 DateApplication 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 Application Expiration Date


Figure 7–1: Processing Restrictions Flow

Appl icat ionVers ion Number forcard and te rmina l

present?

Appl icat ionVers ion Numbers

identical?

Set ICC and Termina lHave Di f ferent

Appl icat ion Versions bi tto “1” in TVR

N N

A U C a n dIssuer CountryCode present?

IssuerCount ry Code =

Terminal CountryCode?

Set Requested Serv iceNot A l lowed for CardProduct to “1” in TVR

AUC ind ica tesTransact ion Type

allowed for Internat ’ ltransactions?

AUC indicatesTransact ion Type

al lowed for domest ictransactions?

ATM Device?

AUC indicatesATM Transact ion

Al lowed?

AUC indicatestransact ion al lowed at

other than ATMDevices?

Set Requested Servicenot Al lowed for Card

Product bi t to “1” in TVR

Y

N

N

N

B

Y

B

N

Y

N

N

Y

Y

N

Appl icat ionEffective Date <

Current Date

Set Appl icat ion notyet Effective bit to “1”

in the TVR

Appl icat ionExpirat ion Date >

Current Date?

Set Appl icat ion hasExpired bi t to “1” in

the TVR

Terminal proceedsto Cardholder

Verif ication(Chap te r 8 )

Y

Y

Y

Y

Y

N

N

Card Terminal

Y

Draft 12/18/00



7.7 Prior Related ProcessingRead 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.


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.


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:

● Offline Plaintext PIN

● Offline Enciphered PIN

● Online PIN

● Signature

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

Cardholder Verification Visa Integrated Circuit CardTerminal Specification, Version 1.4.0




8.2 Card Data

8.3 Terminal Data

8.4 Commands

8.5 Processing



Draft 12/18/00




8.1 Terminal RequirementsTerminals shall comply with the following Cardholder Verification requirements:

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

● 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 DataThe 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)


Application Currency Code 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



Cardholder Verification Method (CVM) List

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

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

CVM Code Designates the action to take if the CVM fails. Choicesare process the next CVM entry or fail CVM processing.

CVM Type The type of CVM to perform:

● 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 consideredsuccessful with no additional CVM processing)

● Fail CVM processing (CVM processing is considered afailure with no additional CVM processing)

CVM Conditions Conditions when this CVM entry should be used:

● 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

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.

Table 8–1: CVM List Processing—Card Data (2 of 2)


Draft 12/18/00


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.

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–2: Offline PIN—Card Data


PIN Try Counter 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.

Table 8–3: Offline Enciphered PIN—Card Data (1 of 2)



With the Registered Application Provider Identifier (RID), designates the Visa CA Public Key to use to decipher the Issuer PK Certificate.

ICC PIN Encipherment or ICC Public Key (PK) Certificate

Encrypted with the Issuer Private Key and contains the public key to be used in PIN encipherment.

ICC PIN Encipherment or ICC Public Key Remainder

Contains the portion, if necessary, of the public key, which does not fit into the public key certificate.

ICC PIN Encipherment or ICC Private Key

Stored in a secure location on the card. Used to decipher the enciphered PIN after it is received at the card.

ICC PIN Encipherment or ICC Public Key Exponent

Used in the algorithm to decipher the enciphered PIN.

Issuer Public Key (PK) Certificate

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.

Issuer Public Key Remainder Contains the portion, if necessary, of the public key, which does not fit into the public key certificate.

Draft 12/18/00



The card data described in Table 8–4 is used internally by the card during Offline PIN processing.

Issuer Public Key Exponent 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.

Table 8–4: Offline PIN Processing—Card Data


Card Verification Results (CVR) Contains indicators set by the card to reflect Cardholder Verification processing.

PIN Try Limit Issuer-specified maximum number of consecutive incorrect PIN tries allowed.

Reference PIN The cardholder PIN that is stored in a secure location on the card.

Table 8–3: Offline Enciphered PIN—Card Data (2 of 2)


Draft 12/18/00


8.3 Terminal Data


8.3 Terminal DataThe 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


Amount, Authorized The amount of the transaction in the transaction currency. Also referred to as the transaction amount.

Cardholder Verification Method (CVM) Results

Indicates the results of the last CVM performed.

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.

PIN Pad Secret Key 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.

Terminal Capabilities Indicates the cardholder verification methods supported by the terminal.


Indicators are set in the TVR for the following conditions:

● 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

Transaction Currency Code The currency in which the transaction is initiated.

Transaction PIN Contains value keyed by the cardholder for PIN verification.


Contains an indicator, which is set when Cardholder Verification is performed.

Draft 12/18/00



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.

8.4 CommandsThe 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.

Table 8–6: Offline Enciphered PIN—Terminal Data



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.

Visa CA Public Keys The terminal uses the selected key to decrypt the Issuer PK Certificate from the card.

Draft 12/18/00


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:

● “80” if the CVM is Offline Plaintext PIN.

● “88” if the CVM is Offline Enciphered PIN.

The valid SW1 SW2 values in the VERIFY response are:

● “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.

8.5 ProcessingCardholder verification involves the following two functions:

● CVM List processing—The terminal determines the CVM to use.

● CVM processing—The terminal performs the CVM selected in CVM List processing.

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



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



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

Figure 8–1: CVM List Processing

Card ’sAIP shows card

suppor tsC V M ?

Terminal selects f i rstCVM in CVM L is t

CVM L is tpresent?

Terminalunderstands CVM

Condit ion?

Terminalrecognizes

C V M ?

Terminalsupports

C V M ?

CVMSuccessful?

Y

Y

Terminal setsICC Data

Missing in theTVR

N

A n y m o r e C V Mentries?

Termina l sets“Unrecog. CVM ”

in TVR

CVM Code=Apply

Succeeding CVMEntry?

Terminal selects nextCVM in CMV L is t .

Y

N

A

C V M = P I N ?

A

Terminal sets “PINentry required but PIN

pad not present ornot working” in TVR

N

Terminal completesCardholderVerif icationProcessing

Terminal sets“cardho lder

verif ication notsuccessful” in

T V R .

CVM Condi t ionsatisfied?

CVMCondi t ion data

avai lable?

Y

Y

Y

Termina lperforms

processing forspeci f ied CVM

Y

N

Y

N

N

CVM Code =Fai l CVM

N

Y

Y

N

Terminal setsCardholder

Veri f icat ion wasPerformed in TSI.

YN

Terminalperforms Visa

magnet ic s t r ipeCVM process ing

N

Terminalproceeds to

Termina l R iskM a n a g e m e n t

C V M w a s N oCVM Req ’d?

N

Visa specif ied

defaul t CVM forterminal?

Y

Terminalper forms mag

s t r ipe CVM

Y

N

N

Draft 12/18/00


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:

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

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.

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

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



b. No PIN Tries Remaining

If the PIN Try Counter is zero indicating no remaining PIN tries, the terminal shall:

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

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.5 Processing


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

Figure 8–2: PIN Try Counter 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.

I s sue GET DATAfor PIN Try Counter

SW1 SW2 =9000?

Per fo rm CVM Codeact ion.

PIN Try Counter= 0?

Set PIN Try LimitExceeded in TVR.

Do not display anyPIN messages

CARD

GET DATAc o m m a n d

TERMINAL

G E T D A T A r e s p o n s e

Display “Last PIN Try”

PIN Try Counter= 1 ?

Y

N

Y

Display “Enter PIN ”

N

Y

N

Proceed to PINChecking

Rece ive GET DATAand respond wi thPIN t ry counter i f

card a l lows

Draft 12/18/00



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)

■ 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”.

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:

■ Set PIN Try Limit Exceeded to “1” in the TVR.

■ Perform the action specified in CVM Code of the CVM List entry.

Draft 12/18/00


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.

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

■ 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



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

Figure 8–3: Offline PIN Processing

Encr iphered PIN?

Offline PINProcessing

Termina l I ssuesVERIFY commandwith Entered PIN.

N

SW1 SW2 =9000?

Terminal proceeds toTerminal RiskManagemen t

SW1 SW2 =6983 or 6984?

N

Terminal sets “PINTry Limi t Exceeded ”

in TVR.

VERIFY command

VERIFY commandresponse

SW1 SW2 =63Cx?

P IN T r i esRemain ing

= 1 ?

P IN T r i esRemain ing

= 0?

Disp lay“ Incorrect PIN ”

Disp lay“Last PIN Try ”

Display “Enter PIN ”

Y

Display “PIN OK ”Y

Set PIN Try L imi tExceeded to “1” in

T V RY

N

Y

N

Terminatetransact ion

Cardholder entersPIN

Y

EncipheredPIN

processing

Termina l per fo rmsaction specif ied in

CVM Code o f CVMList entry.

N

A

A

N

PINs Matched

PIN Try Limit Exceeded Previously

Invalid Response from VERIFY Command

PIN Try Limit Exceeded on This Transaction

More PIN Tries Remaining

Termina l per formsaction specif ied in

C V M C o d e o f C M VList entry.

Y

TerminalCard

Card rece ivesVer i fy comandand responds

Draft 12/18/00


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



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

Figure 8–4: Offline Enciphered PIN Processing

ICCEnc iphered

PIN PK Cert i f icateavai lable?

Enc ipheredPIN

Processing

Issue GETC H A L L E N G E

command

Use ICC PKCert i f icate.

Use ICC Enc iphe redPIN PK Certi f icate.

ICC PKCertif icateavai lable?

Fai l CVM ProcessingN N

YY

Recover Publ ic Key(See DDA sect ion o f

Chapter 6)

Concatenate data( ICC Unpred.

Number, PIN, etc)

Genera te ICCUnpredictable

Number

G E TC H A L L E N G E

c o m m a n d

G E T C H A L L E N G Eresponse w/ ICC

Unpredictable Number

Encipherconcatenated data

with public key.

Set P2 to “88” inV E R I F Y c o m m a n d .

Issue VERIFYc o m m a n d a n d

cont inue process ingas with Off l inePla in text PIN.

VERIFYc o m m a n d

Termina lCard

Draft 12/18/00


8.5 Processing


8.5.2.3 Online PIN

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

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

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

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

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

Figure 8–5: Online PIN Processing

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.

Online PINSet Online PINEntered to 1

in TVR.

Encipher PINaccording to current

standards.

Terminal proceeds toTerminal RiskManagement(Chapter 9)

Enciphered PIN isincluded in online

authorization(Chapter 10)

Draft 12/18/00



The processing for Signature is shown in Figure 8–6.

Figure 8–6: Signature Processing

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

Terminal performsaction specified in

CVM Code of CVMList entry.

Terminal proceeds toTerminal RiskManagement.

Terminalsupports

signature?

SIGNATURE N

Y

Fail CVM Terminal performsaction specified inCVM Code of CVM

List entry.

Draft 12/18/00




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


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.

NO CVM REQUIRED

Terminal proceeds toTerminal RiskManagement(Chapter 9)

Perform Default CVMTerminal has

Visa Specified DefaultCVM?

N

Y

Draft 12/18/00




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.


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

Terminal Risk Management Visa Integrated Circuit CardTerminal Specification, Version 1.4.0



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



Draft 12/18/00


9.1 Card Data


9.1 Card DataThe 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


Application Identifier (AID) Identifies the Terminal Floor Limit to be used during Terminal Risk Management

Application Primary Account Number (PAN)

Cardholder account number used in terminal exception file checking.

Application Transaction Counter (ATC)

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.

Last Online Application Transaction (ATC) Register

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.

Lower Consecutive Offline Limit 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.

Upper Consecutive Offline Limit 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.

Draft 12/18/00



9.2 Terminal DataThe 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


Amount, Authorized This numeric data element (tag “9F02”) stores the amount (excluding adjustments) for the current transaction. It is used in floor limit checking.

Maximum Target Percentage to be used for Biased Random Selection

Value used in terminal risk management for random selection of transactions for online processing.

Target Percentage to be used for Random Selection


Terminal Floor Limit 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.

Threshold Value for Biased Random Selection


Transaction Log 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.

Draft 12/18/00


9.3 GET DATA Command


9.3 GET DATA CommandThe 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 FileIf 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 OnlineAt 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 LimitsFloor 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



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

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.

Table 9–3: Example Terminal Parameters

Terminal floor limit 100

Terminal random number 25

Threshold for Biased Random Selection 40

Target percentage for Random Selection 20%

Maximum target percentage for Biased Random Selection 50%

Draft 12/18/00


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

● 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



● 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 CheckNew 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 ManagementUpon 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.10 End Terminal Risk Management


Figure 9–1: Terminal Risk Management Processing Flow (1 of 2)

B

Terminal except ionf i le present?

Y

Card appears onexcept ion f i le?

Terminal sets CardAppears on Termina l

Exception File bit to “1” inTVR

Y

Merchan telected to force

transact iononl ine?

Y

Termina l se ts MerchantForced Transact ions

Online bi t to “1” in TVR

N

N

N

Log Ent ry Presen twhich matches current

transact ion

A

A

Transact ion amount >terminal f loor l imit

Amoun t ,au thor i zed + amount

in log > terminalfloor limit

N

Y

Terminal setsTransact ion ExceedsFloor Limit bit to “1” in

TVR

Y

Y

NN

Terminal randomlyselects transaction for

onl ine processing

Terminal sets Transact ionSeleted Randomly for

Online Processsing bit to“1” in TVR

Y

N

Transact ion logpresent

in terminal?

Y

N

Terminal

Draft 12/18/00



Figure 9–2: Terminal Risk Management Processing Flow (2 of 2)

L o w e r a n dUpper Consecut iveOffl ine Limits read

by terminal?

Terminal issues GETDATA

to obta in ATC and LastOnl ine ATC Register

Y

Both ATC and LastOn l ine ATC Reg is te r

re tu rned?

Terminal sets ICC DataMissing bi t to “1 ” in TVR

(ATC-Las tOnl ine ATC Register) >

Lower Consecut iveOffl ine Limit?

YTerminal sets both LowerConsecutive Off l ine Limit

Exceeded and UpperConsecutive Off l ine Limit

Exceeded bits to “1 ” in TVR

Terminal sets LowerConsecut ive Off l ine Limit

Exceede bi t to “1 ” in TVR

(ATC-Last Onl ine ATC

Regis ter ) > UpperConsecutive Off l ine

Limit

Termina l se ts UpperConsecut ive Off l ine Limit

Exceeded b i t to “1 ” in TVR

Y

Y

N

NN

B

Last Onl ineATC Register = 0

Y

N

Terminal sets “new card”bit in CVR

Terminalproceeds to

Terminal Act ionAnalysis

(Chapter 10)

Terminal

N

Draft 12/18/00





The following data is read from the card:

● 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


Based on card and terminal settings, the terminal determines what action to take if:

● 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


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

2. Request Cryptogram Processing—The terminal requests a cryptogram from the card.

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.


10.1 Card Data

10.2 Terminal Data

10.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command

10.4 Processing



Draft 12/18/00

Terminal Action Analysis Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


10.1 Card DataThe 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


Issuer Action Codes (IACs) 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:

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

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

● 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 Terminal Data


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

10.2 Terminal DataThe 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–2: Request Application Cryptogram—Card Data


Card Data Management Object List 1 (CDOL1)

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.

Table 10–3: Offline Processing Results—Terminal Data (1 of 2)


Authorization Response Code Indicates the terminal’s requested disposition for the transaction.

Terminal Action Codes (TAC) 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:

● 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



Terminal Action Codes (TAC)

(continued)

● 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

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


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.

Table 10–3: Offline Processing Results—Terminal Data (2 of 2)


Draft 12/18/00


10.3 GENERATE APPLICATION CRYPTOGRAM (AC)Command


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

10.3 GENERATE APPLICATION CRYPTOGRAM (AC) CommandIn 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.

Table 10–4: Request Application Cryptogram—Terminal Data


Data Objects specified in CDOL1 by the issuer

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

Draft 12/18/00



10.4 ProcessingTerminal Action Analysis consists of two steps:

● Review of Offline Processing Results

● Generate Cryptogram Processing

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



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:

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

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


Draft 12/18/00


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.


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


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



10.4.3 Process Flow

Figure 10–1 shows how Terminal Action Analysis might be performed.

Figure 10–1: Terminal Action Analysis

Terminal sets AuthResp Code to Z3(off l ine decl ined)

Are anycorresponding bi ts

set in both TVR and theIAC-Denia l orTAC-Denia l?

Are anycorresponding bits setin TVR & IAC-Onl ine or

TAC-Onl ine?Terminal sets Auth Resp

Code to Z (off l ine approved)

P1 (Cryptogram type)i n G E N A C = A R Q C

(Send Onl ine)

Terminal issues 1stGenera te AC

Online capableterminal?

Are anycorresponding bi ts set in

both TVR & IAC-Defau l t orTAC-Defaul t?

IAC-Denialpresent?

TAC-Denia lpresent?

Termina l uses IAC-Denial defaul t valueof al l bits set to “0”

Term ina l uses TAC-Denia l defaul t va lue

of al l bits set to “0”

IAC-Onl inepresent?

TAC-Onl inepresent?

IAC-Defaultpresent?

TAC-Defaul t present?

Terminal uses IAC-Default default

value of al l bits setto “1”

Term ina l uses TAC-Default default


Terminal uses IAC-Onl ine default


Termina l usesTAC-Onl ine

default value of al lbits set to “0”

N

Y

N

N

Y

NY

N

Y Y

N

NN

Y

Y

N

P1 (Cryptogram type) inG E N A C = T C ( A p p r o v e )

P1 (Cryptogram type)i n GEN AC = AAC

(Decl ine)

Y

Y

N

Card

G E N E R A T E A Cc o m m a n d

Proceed to CardAction Analysis

(See Chapter 11)

D D A /AC Genera t ion to

b e d o n e ?

N

Terminal sets P1 inGENERATE AC ind ica t ingDDA/AC Generat ion req 'd

Y

Draft 12/18/00





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


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:

● Activity on previous transactions

● If card is a new card

● Velocity counters

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.


11.1 Card Data

11.2 Terminal Data

11.3 GENERATE APPLICATION CRYPTOGRAM (AC) Command

11.4 Processing



Draft 12/18/00

Card Action Analysis Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


11.1 Card DataThe 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.

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

Table 11–1: Card Action Analysis—Card Data


Card Risk Management Data Object List 1 (CDOL1)

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.

Table 11–2: GENERATE AC Command Response Data


Application Cryptogram The value of the cryptogram.


A counter of the number of transactions initiated since the application was put on the card.

Cryptogram Information Data Contains indicators for:

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

● Other status information including Service Not Allowed.

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

Card Verification Results A Visa proprietary data element containing indicators, which are set, based upon the results of offline processing for current and previous transactions.

Draft 12/18/00


11.2 Terminal Data


11.2 Terminal DataThe terminal data element used in Card Action Analysis is listed and described in Table 11–3.

11.3 GENERATE APPLICATION CRYPTOGRAM (AC) CommandThe 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.

Table 11–3: Card Action Analysis—Terminal Data


Data Requested in CDOL1 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.

Draft 12/18/00

Card Action Analysis Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


11.4 ProcessingThe 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:

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

These decision rules are shown in Table 11–4.

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.

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

Card Responds

AAC ARQC TC

Terminal

Requests

AAC Decline — —

ARQC Decline Go Decline —

TC Decline Go Decline Approve

Draft 12/18/00




11.4.2 Standard Response to GENERATE AC

The card returns a cryptogram and indicates the response decision by the cryptogram type.


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

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


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.2 Card Data

12.3 Terminal Data

12.4 Commands

12.5 Processing



Draft 12/18/00

Online Processing Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


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

12.2 Card DataThe 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 inTable 12–1.

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.

Table 12–1: Online Processing—GENERATE AC Response Card Data


Application Cryptogram The cryptogram value from the card.



Cryptogram Information Data 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 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.

Draft 12/18/00


12.3 Terminal Data


12.2.2 Other Card Data

The terminal also uses the card data element listed and described inTable 12–2 during Online Processing.

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

Table 12–2: Online Processing—Other Card Data



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.

Table 12–3: Online Processing—Terminal Data



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



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 Source

Amount, Authorized Transaction amount from terminal

Amount, Other Portion of transaction amount that is cashback from terminal (if present)

Application Cryptogram Authorization Request Cryptogram (ARQC) received from card in GENERATE APPLICATION CRYPTOGRAM (AC) response

Application Interchange Profile (AIP) Received from card during Initiate Application Processing

Application PAN Sequence Number Received from card during Read Application Data

Application Transaction Counter (ATC) Received from card in GENERATE AC response

Interface Device (IFD) Serial Number From terminal or acquirer (optional)

Issuer Application Data Received from card in GENERATE AC response

Terminal Capabilities From terminal or acquirer

Terminal Country Code From terminal

Terminal Verification Results (TVR) Transaction data from terminal

Transaction Currency Code From terminal

Transaction Date From terminal

Transaction Type Transaction data from terminal

Unpredictable Number Transaction data from terminal

Draft 12/18/00


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.

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.

Table 12–5: New Authorization/Financial Transaction Response Data Elements


Issuer Authentication Data Contains the following subfields:

● Authorization Response Cryptogram (ARPC)—cryptogram generated by issuer host

● Authorization Response Code—response code used in generation of ARPC

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

Draft 12/18/00



12.4 CommandsOnline 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 ProcessingOnline 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. Uses the ICC Public Key to unlock the dynamic signature (Signed Dynamic Application Data) and recover the hash of data elements.

2. 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.5 Processing


3. Calculates a hash from the dynamic data elements that are in the clear.

4. 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. Set the Card Risk Management Was Performed bit in the TSI to “1”.

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



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:

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

● 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. The terminal shall set the Issuer Authentication was Performed bit to “1” in the Transaction Status Information (TSI).

2. The terminal shall transmit an EXTERNAL AUTHENTICATE command to the card.

3. The card performs Issuer Authentication and transmits the EXTERNAL AUTHENTICATE command response to the terminal indicating whether Issuer Authentication was successful or failed.

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

5. The terminal shall then proceed to the Completion function described in Chapter 13, Completion.

Draft 12/18/00


12.5 Processing


12.5.4 Flow

The Online Processing flow is shown in Figure 12–1.

Figure 12–1: Online Processing

Terminal proceeds toComplet ion

(See Chap te r 13 )

A R Q C & terminal can

process onl ine?

Issuer Authenticat ionData in response?

Terminal t ransmits onl ine auth.request to issuer through acquirer

Card Act ion Analys isCard returns

response f rom f i rs tG E N E R A T E A C

Issuer returnsauthorization

response

A I P s h o w scard suppor ts Issuer

Authent icat ion?

Terminal proceeds toComplet ion.

(See Chap te r 13 )

Terminal receives author izat ionresponse

Author izat ion Responsewith opt ional ARPCand/or issuer script

N

N

Y

Terminal issuesEXTERNAL

AUTHENTICATEcommand

Y

Card per fo rmsIssuer

Authentication(val idates ARPC)

EXTERNALAUTHENTICATE

c o m m a n d

Terminal receivesEXTERNAL

AUTHENTICATEresponse

Terminal sets IssuerAuth. Per formed to “1”

in TSI

EXTERNALAUTHENTICATE

response

Responseshows I ssuer

Authenticationpassed?

Set IssuerAuthent icat ion wasUnsuccessful to “1”

in TVR

N

Y

Card Termina l I ssue r

Author izat ion Requestw i t h A R Q C

Set Card RiskM a n a g e m e n t

Performed to “1” inTSI

GENERATEAC response

A

A

Terminal validatesdynamic signature &hash of static data

CombinedD D A / A C

reques ted and TCo r A R Q C ?

Valid?

If AAC returned ordynamic signature

is not valid, theterminal indicates

DDA/AC Generationfailed in TVR

N

Y

NY

Y

N

Draft 12/18/00



12.6 Prior Related ProcessingCard 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 ProcessingCompletion

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:

● Approve (TC), the transaction shall be declined with a Z1.

● Go Online (ARQC), the terminal shall issue a second GENERATE AC requesting an AAC.

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.


Completion 13

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

● 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

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

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

Completion Visa Integrated Circuit CardTerminal 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.1 Card DataThe 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


Card Risk Management Data Object List 2 (CDOL2)

A list of data objects (tags and lengths) to be passed to the card with the final GENERATE AC command

Issuer Action Code—Default 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 theIAC—Default.

Draft 12/18/00


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


Application Cryptogram Contains the value of the cryptogram.



Card Verification Results (CVR) A Visa proprietary data element containing indicators that are set based upon the results of offline processing for current and previous transactions.

Cryptogram Information Data (CID)

Contains indicators including 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)

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

Draft 12/18/00



13.2 Terminal DataThe 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.

13.3 GENERATE AC CommandThe 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.

Table 13–3: Completion—Terminal Data


Authorization Response Code 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)


A terminal data element used to record offline processing results, such as SDA failure or floor limit exceeded, from a terminal perspective.

Terminal Action Code—Default 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.

Draft 12/18/00


13.4 Transaction Authorized Offline


13.4 Transaction Authorized OfflineWhen 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:

● 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

Table 13–4: Offline Transaction Disposition Response

First GENERATE AC response cryptogram typein CID

Authorization Response Code Transaction Disposition

TC and Combined DDA/AC Generation not performed or Passed

Y1 Offline approved

AAC Z1 Offline declined

ARQC or TC and Combined DDA/AC Generation Failed

Z1 Offline declined

Draft 12/18/00




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:

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

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-to-Card 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.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



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.

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.

Table 13–5: Online Transaction Disposition Response

Terminal RequestsAuthorization

Response Code Transaction Disposition

TC Y3 Unable to go online (offline approved)

AAC Z3 Unable to go online (offline declined)

Draft 12/18/00


13.6 Online Processing Requested, Transaction WasNot 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.

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

Draft 12/18/00



Figure 13–1: Completion Processing Flow

Termina l ana lyzesf i rs t GENERATE AC

response

Card receives F ina lGene ra te AC

Transact ioncompleted onl ine?

Set Auth.Resp.Code toY1 (approve)

Set Author izat ionResponse Codeto Y3 & P1 to TC

N

Y

S e t P 1 i n G E N A C t oTC (approval ) or AAC

(decl ine) based onAuth . Resp . Code

Issue FinalG E N E R A T E A C

command

Card responds toF ina l GENERATE ACwi th TC (approve) or

AAC (decl ine)

F i n a lG E N E R A T E A C

C o m m a n d

Receives FinalG E N E R A T E A C

response

FinalG E N E R A T E A C

Response

Termina l processesIssues Script i f in

auth. response

Cryptogram = TC?

A

A

CardTermina l

Set Author izat ionResponse Code to Z1

(decl ine)Cryptogram =

AAC?BY

(( IAC-Def.OR TAC-Def. ) &

T V R ) = 0 ?

N

Set Author izat ionResponse Code

to Z3 & P1 to AACY

N

Card respondedw i t h a T C ?

Termina l respondswi th an approva l

Terminal responds wi th a dec l ine

N

B

Termina lrequested an

AAC?

N

Y

Y

Combined

fa i led?Y

Set Au th .Resp. Code

to Z1(decl ine)

Y

A R Q C &

fa i led?

N

N

Set P1 inGEN AC to

AAC (decline)

N

Y

C

C

DDA/AC Gen

DDA/AC Gen.

Y

Draft 12/18/00




13.7 Prior Related ProcessingCard 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.


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


Draft 12/18/00

Issuer-to-Card Script Processing Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


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

14.2 Terminal DataThe 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



Contains two script related flags:

● 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


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

Issuer Script Results 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.

Bytes 2–5 Contain the Issuer Script Identifier received in the Issuer Script.

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 Acquirer to V.I.P./BASE II

Issuer Script Results (only 1 byte is transmitted: byte 1, indicating actual script results)

Map 1 byte transmitted by terminal into first byte; zero fill next 4 bytes (Script Identifier)

Draft 12/18/00


14.3 Online Response Data


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

14.4 CommandsThe 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.

Table 14–2: Issuer-to-Card Script Processing—Online Response Data


Issuer Script 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.

Draft 12/18/00



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 ProcessingThe 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.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:

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

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



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

Termina l comple tesOnl ine Processing

and Comple t ion

Terminal sendscommand to cardScr ip t Command

Anothercommandpresent?

Termina l comple testransact ionprocess ing

Issuer Scriptpresent in onl ine

response?

Terminal sets IssuerScript ProcessingPerformed in TSI

Terminal parses outIssuer Scr ip tcommand in

sequent ial order

Terminal sets Scr iptProcessing Fai led

after f inal GEN AC inT V R

Y

N

Termina l rece ivescommand response

f rom card

SW1 W2 = 9000

Scr ip t CommandResponse

Card

Y

N

Card executes scr ip tc o m m a n d

Terminal incrementsscr ipt command

sequence number

Y

Another scr ip tpresent?

N

N

N

Y

Terminal

Draft 12/18/00




14.6 Prior Related ProcessingOnline 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/00A–131 Oct 2001 Visa Public

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 TableWhen the length defined for the data object is greater than the length of the actual data, the following rules apply:

● 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

Draft 12/18/00

Terminal and Acquirer Data Elements Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

A–2 31 Oct 2001Visa Public

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) Requirement Description Values

Acquirer Identifier

F: n 6-11T: 9F01L: 6

O Uniquely identifies the acquirer within each payment system.

For Visa, this is the BASE Identification Number (BIN).

Additional Terminal Capabilities

F: b 40T: 9F40L: 5

M Indicates the data input and output capabilities of the terminal.

● Byte 1 (Transaction Type Capability):

bit 8: 1 = Cashbit 7: 1 = Goodsbit 6: 1 = Servicesbit 5: 1 = Cashbackbit 4: 1 = Inquirybit 3: 1 = Transferbit 2: 1 = Paymentbit 1: 1 = Administrative

● Byte 2 (Transaction Type Capability, cont.):

bits 8–1: Reserved for future use (RFU) (“00”)·

● Byte 3 (Terminal Data Input Capability):

bit 8: 1 = Numeric keysbit 7: 1 = Alphabetic and special

characters keysbit 6: 1 = Command keysbit 5: 1 = Function keysbits 4–1: RFU (0000)

Draft 12/18/00


A.1 Terminal and Acquirer Data Elements Table

A–331 Oct 2001 Visa Public

Additional Terminal Capabilities

(continued)

● Byte 4 (Terminal Data Output Capability):

bit 8: 1 = Print, attendantbit 7: 1 = Print, cardholderbit 6: 1 = Display, attendantbit 5: 1 = Display, cardholderbits 4–3: RFU (00)bit 2: 1 = Code table 10bit 1: 1 = Code table 9

● Byte 5 (Terminal Data Output Capability, cont.):

bit 8: 1 = Code table 8bit 7: 1 = Code table 7bit 6: 1 = Code table 6bit 5: 1 = Code table 5bit 4: 1 = Code table 4bit 3: 1 = Code table 3bit 2: 1 = Code table 2bit 1: 1 = Code table 1

Amount, Authorized

(Binary)

F: b 32T: 81L: 4

not applicable Authorized amount of the transaction (excluding adjustments).

This data object is not used in this version of VIS.

Amount, Authorized

(Numeric)

F: n 12T: 9F02L: 6

M Authorized amount of the transaction (excluding adjustments).

Amount, Other

(Binary)

F: b 32T: 9F04L: 4

not applicable Secondary amount associated with the transaction representing a cashback amount.




Draft 12/18/00



Amount, Other

(Numeric)

F: n 12T: 9F03L: 6

C

If cashback supported

Secondary amount associated with the transaction representing a cashback amount.

Amount, Reference Currency

(Binary)

F: b 32T: 9F3AL: 4

not applicable Authorized amount expressed in the reference currency.


Amount, Transaction

F: n 12T: –L: 6

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

Application Identifier (AID)

F: b 40-128T: 9F06L: 5–16

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




Application Selection Indicator

F: –T: –L: –

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

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 16T: 9F09L: 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.

Authorization Response Code

F: an 2T: 8AL: 2

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

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)



Draft 12/18/00



Cardholder Verification Method (CVM) Results

F: b 24T: 9F34L: 3

M Indicates the results of the last CVM performed.

● Byte 1 (CVM Performed):

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

● Byte 2 (CVM Condition):

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

● 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: bT: –L: –

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.

Certificate Authority Public Key Check Sum

F: bT: –L: 20

C



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




Certificate Authority Public Key Exponent

F: bT: –L: 1 or 3

C



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


F: b 8T: 9F22L: 1

C



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

Values assigned by Visa.

Certificate Authority Public Key Modulus

F: bT: –L: NCA (up to 248)

C



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

Command Template

F: bT: 83L: var.

M Identifies the data field of a command message.

Default Dynamic Data Authentication Data Object List (DDOL)

F: bT: –L: var.

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



Default Transaction Certificate Data Object List (TDOL)

F: bT: –L: var.

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

Enciphered Personal Identification Number (PIN) Data

F: b 64T: –L: 8

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.

Interface Device (IFD) Serial Number

F: an 8T: 9F1EL: 8

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

Value assigned by IFD manufacturer.



Draft 12/18/00




Issuer Script Results

F: bT: 9F5BL: var.

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

● Byte 1(Issuer Script Result):

bits 8–5: Result of the Issuer Script processing performed by the terminal:

0 = Issuer Script not performed1 = Issuer Script processing failed2 = Issuer Script processing successful

bits 4–1: Sequence number of the Issuer Script Command:

0 = Not specified1-E = Sequence number 1–14F = Sequence number 15 or above

● 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: –

C

If offline capable terminal

Value used in terminal risk management for random transaction selection.

Merchant Category Code

F: n 4T: 9F15L: 2

M Classifies the type of business being done by the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code.



Draft 12/18/00



Merchant Identifier

F: ans 15T: 9F16L: 15

M

(at terminal or acquirer)

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.

Merchant Name and Location

F: ansT: –L: var.

M


Indicates the name and location of the merchant. May be located in the terminal or inserted into messages by the acquirer.

Message Type

F: n 2T: –L: 1

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.

Personal Identification Number (PIN) Pad Secret Key

F: –T: –L: –

C

If PIN pad and card reader

not integrated

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.



Draft 12/18/00




Point of Service (POS) Entry Mode Code

F: n 2T: 9F39L: 1

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

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)

See Terminal Entry Capability.

Proprietary Application Identifier Extension (PIX)

F: bT: part of AIDL: 0–11

M 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


F: bT: part of AIDL: 5

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



Status of Last Chip Attempt

F: n 1T: –L: –

C

Mag stripe initiated from a

IC reading terminal

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

C

If online/offline terminal


Visa may establish a range of values.

Terminal Action Code—Default

F: b 40T: –L: 5

C


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.

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 40T: –L: 5

C


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—Denial in this version of VIS is are shown in Chapter 10, Table 10–3.

Terminal Action Code–Online

F: b 40T: –L: 5

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




Terminal Capabilities

F: b 24T: 9F33L: 3

M Indicates the card data input, CVM, and security capabilities of the terminal.

● Byte 1 (Card Data Input Capability):

bit 8: 1 = Manual key entrybit 7: 1 = Magnetic stripebit 6: 1 = IC with contactsbits 5–1: RFU (00000)

● Byte 2 (CVM Capability):

bit 8: 1 = Plaintext PIN for offlineCC verification

bit 7: 1 = Enciphered PIN for onlineverification

bit 6: 1 = Signature (paper)bit 5: 1 = Enciphered PIN for offline

verificationbits 4–1: RFU (00000)

● Byte 3 (Security Capability):

bit 8: 1 = Offline static dataauthentication

bit 7: 1 = Offline dynamic dataauthentication

bit 6: 1 = Card capturebit 5: 1 = Combined dynamic data

authentication/applicationcryptogram generation

bits 4–1: RFU (00000)

Terminal Country Code

F: n 3T: 9F1AL: 2

M Indicates the country of the terminal represented according to ISO 3166.

Terminal Entry Capability

F: n 1T: –L: –

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



Terminal Floor Limit

F: b 32T: 9F1BL: 4

C


Indicates the floor limit in the terminal in conjunction with the AID.

Terminal Identification

F: an 8T: 9F1CL: 8

M


Designates the unique location of a terminal at a merchant.

Terminal Risk Management Data

F: b 8–64T: 9F1DL: 1–8

O Application-specific value used by the card for risk management purposes.



Draft 12/18/00




Terminal Type

F: n 2T: 9F35L: 1

M Indicates the environment of the terminal, its communications capability, and its operational control.

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




F: b 40T: 95L: 5

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

● Byte 1

bit 8: 1 = Offline data authenticationwas not performed

bit 7: 1 = Offline static dataauthentication failed

bit 6: 1 = ICC data missingbit 5: 1 = Card appears on terminal

exception filebit 4: 1 = Offline dynamic data

authentication failedbit 3: 1 = Combined DDA/AC

Generation failedbits 21: RFU (000)

● Byte 2

bit 8: 1 = ICC and terminal havedifferent applicationversions

bit 7: 1 = Expired applicationbit 6: 1 = Application not yet

effectivebit 5: 1 = Requested service not

allowed for card productbit 4: 1 = New cardbits 3–1: RFU (000)

● Byte 3

bit 8: 1 = Cardholder verification wasnot successful

bit 7: 1 = Unrecognized CVMbit 6: 1 = PIN Try Limit exceededbit 5: 1 = PIN entry required and PIN

pad not present or notworking

bit 4: 1 = PIN entry required, PINpad present, but PIN wasnot entered

bit 3: 1 = Online PIN enteredbits 2–1: RFU (00)



Draft 12/18/00





(continued)

● Byte 4

bit 8: 1 = Transaction exceeds floorlimit

bit 7: 1 = Lower consecutive offlinelimit (“9F14”) exceeded

bit 6: 1 = Upper consecutive offlinelimit (“9F23”) exceeded

bit 5: 1 = Transaction selectedrandomly for onlineprocessing

bit 4: 1 = Merchant forcedtransaction online

bits 3–1: RFU (000)

● Byte 5

bit 8: 1 = Default TDOL usedbit 7: 1 = Issuer authentication was

unsuccessfulbit 6: 1 = Issuer Script processing

failed before finalGENERATE AC command

bit 5: 1 = Issuer Script processingfailed after finalGENERATE AC command

Note: bits 4–1: RFU (0000)

Threshold Value for Biased Random Selection

F: –T: –L: –

C

If online and offline terminal


Visa may establish a range of values.

Transaction Amount

F: n12T: –L: – 6

R Clearing amount of the transaction, including tips and other adjustments.



Draft 12/18/00



Transaction Certificate (TC) Hash Value

F: b 160T: 98L: 20

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

Transaction Currency Code

F: n 3T: 5F2AL: 2

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.

Transaction Currency Exponent

F: n 1T: 5F36L: 1

M Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217.

Transaction Date

F: n 6 YYMMDDT: 9AL: 3

M Local date that the transaction was authorized.

Transaction Personal Identification Number (PIN) Data

F: bT: 99L: var.

C

If PIN supported

Data entered by the cardholder for the purpose of PIN verification.



Draft 12/18/00




Transaction Reference Currency Code

F: n 3T: 9F3CL: 2

not applicable Code defining the common currency used by the terminal in case the Transaction Currency Code is different from the Application Currency Code.


Transaction Reference Currency Conversion

F: n 8T: –L: 4

not applicable Factor used in the conversion from the Transaction Currency Code to the Transaction Reference Currency Code.


Transaction Reference Currency Exponent

F: n 1T: 9F3DL: 1

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.


Transaction Sequence Counter

F: n 4-8T: 9F41L: 2–4

M Counter maintained by the terminal that is incremented by one for each transaction.



Draft 12/18/00




F: b 16T: 9BL: 2

M Indicates the functions performed in a terminal.

● Byte 1:

bit 8: 1 = Offline data authenticationwas performed

bit 7: 1 = Cardholder verificationwas performed

bit 6: 1 = Card risk managementwas performed

bit 5: 1 = Issuer authentication wasperformed

bit 4: 1 = Terminal risk managementwas performed

bit 3: 1 = Issuer Script processingwas performed

bits 2–1: RFU (00)

● Byte 2: 1

● RFU (“00”)

Transaction Time

F: n 6 HHMMSST: 9F21L: 3

M Local time that the transaction was authorized.

Transaction Type

F: n 2T: 9CL: 1

M Indicates the type of financial transaction, represented by the first two digits of ISO 8583-1987 Processing Code.

Unpredictable Number

F: b 32T: 9F37L: 4

M Value to provide variability and uniqueness to the generation of the application cryptogram.



Draft 12/18/00




VLP Terminal Support Indicator

F: n 1T: 9F7AL: 1

C

If VLP supported

A data element, which if present in the terminal, indicates that the terminal supports VLP processing.

0 = VLP Not Supported

1 = VLP Supported

2 = Contactless – VLP Only

VLP Terminal Transaction Limit

F: n 12T: 9F7BL: 6

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



A.2 Terminal Data Element TagsThe tags allocated to the terminal data elements are shown in Table A–2.

Table A–2: Terminal Data Element Tags (1 of 2)

Tag Terminal Data Element Name

5F2A Transaction Currency Code

5F36 Transaction Currency Exponent

81 Amount, Authorized (binary)

83 Command Template

8A Authorization Response Code

95 Terminal Verification Results

98 Transaction Certificate (TC) Hash Value

99 Transaction PIN

9A Transaction Date

9B Transaction Status Information (TSI)

9C Transaction Type

9F01 Acquirer Identifier

9F02 Amount, Authorized (Numeric)

9F03 Amount, Other (Numeric)

9F04 Amount, Other (Binary)

9F06 Application Identifier (AID)

9F09 Application Version Number

9F15 Merchant Category Code

9F16 Merchant Identifier

Draft 12/18/00


A.2 Terminal Data Element Tags


9F1A Terminal Country Code

9F1B Terminal Floor Limit

9F1C Terminal Identification

9F1D Terminal Risk Management Data

9F1E Interface Device (IFD) Serial Number

9F21 Transaction Time

9F22 Certificate Authority Public Key Index (PKI)

9F33 Terminal Capabilities

9F34 Cardholder Verification Method (CVM) Results

9F35 Terminal Type

9F37 Unpredictable Number

9F39 Point of Service (POS) Entry Mode Code

9F3A Amount, Reference Currency (Binary)

9F3C Transaction Reference Currency Code

9F3D Transaction Reference Currency Exponent

9F40 Additional Terminal Capabilities

9F41 Transaction Sequence Counter

9F7AVLP Terminal Support Indicator

9F7B VLP Terminal Transaction Limit

Table A–2: Terminal Data Element Tags (2 of 2)

Tag Terminal Data Element Name

Draft 12/18/00B–131 Oct 2001 Visa Public

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.

● EXTERNAL AUTHENTICATE

● GENERATE APPLICATION CRYPTOGRAM

● GET CHALLENGE

● GET DATA

● GET PROCESSING OPTIONS

● INTERNAL AUTHENTICATE

● READ RECORD

● SELECT

● VERIFY

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

Commands for Financial Transactions Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

B–2 31 Oct 2001Visa Public

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 CommandsThe 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 APDUsThe 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.3 GENERATE APPLICATION CRYPTOGRAM (AC) CommandResponse APDUs

B–331 Oct 2001 Visa Public

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



B.5 GET DATA Command—Response APDUsThe 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.

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.

Table B–1: Data Retrieval Using GET DATA

Data Element


Last Online ATC Register

PIN Try Counter (may be stored as a proprietary data element to prevent retrieval by GET DATA)

Draft 12/18/00


B.6 GET PROCESSING OPTIONS Command—Response APDUs


B.6 GET PROCESSING OPTIONS Command—Response APDUsThe 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 inTable B–2.

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 APDUsThe 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 APDUsThe READ RECORD command shall be performed as described in the EMV 4.0, Book 3, Section 2.5.11.

Table B–2: Data Retrieval With GET PROCESSING OPTIONS

Data Element

Application Interchange Profile

Application File Locator

Draft 12/18/00



B.9 SELECT Command—Response APDUsThe 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:

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

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:

● FCI Template

● DF Name


– SFI of directory elementary file


Draft 12/18/00


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:

● FCI Template

● DF Name


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


Additional data objects may be returned. The terminal shall ignore these data objects.

B.10 VERIFY Command—Response APDUsThe 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/00C–131 Oct 2001 Visa Public

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

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

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

General Terminal Requirements Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

C–2 31 Oct 2001Visa Public

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.

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

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.1 Terminal Types and Capabilities

C–331 Oct 2001 Visa Public

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:

● 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

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

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:

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

Draft 12/18/00

General Terminal Requirements Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

C–4 31 Oct 2001Visa Public

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 CharacteristicsThe 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 RequirementsThe security requirements shall be performed as described in the EMV 4.0, Book 4, Part I.

C.4 Data ManagementTo 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.5 Cardholder and Attendant Interface

C–531 Oct 2001 Visa Public

C.5 Cardholder and Attendant InterfaceThe 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 InterfaceThe 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/00D–131 Oct 2001 Visa Public

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

Terminal Requirements for Visa Low-Value Payment Feature Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

D–2 31 Oct 2001Visa Public

D.1 Card DataCard data elements are described in Table D–1.

Table D–1: Initiate Application Processing—Card Data (1 of 2)


Application Currency Code “9F51”

Visa proprietary data element indicating the currency in which the account is managed according to International Organisation for Standardisation (ISO) 4217.

Application File Locator (AFL) for VLP

Indicates the location (SFI, range of records) of the AEFs related to a given application.

Application Interchange Profile (AIP) for VLP

The AIP indicates the capabilities of the card to support specific functions in the application. These may differ for VLP.

CVM List for VLP Identifies a prioritized list of methods of verification of the cardholder supported by the card application for VLP transactions.

Issuer Action Codes (IACs) for VLP

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.

Issuer Application Data 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.

PDOL List of terminal-related data objects (tags and lengths) requested by the card to be transmitted in the GET PROCESSING OPTIONS command.

VLP Available Funds A counter that is decremented by the transaction amount when a VLP transaction is approved (VLP transactions are either approved or declined offline).

VLP Funds Limit Issuer Limit for VLP available funds that may be used by the card to reset VLP Available Funds after an online approved transaction.

Draft 12/18/00


D.2 Terminal Data

D–331 Oct 2001 Visa Public

D.2 Terminal DataTerminal data elements are described in Table D–2.

VLP Issuer Authorization Code

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

VLP Single Transaction Limit

Maximum amount allowed for a single VLP transaction.

Table D–2: Initiate Application Processing—Terminal Data


Amount, Authorized Authorized amount of the transaction (excluding adjustments)

Terminal Action Codes (TACs) for VLP

Payment scheme conditions that cause VLP transactions to be approved or declined offline.

Transaction Currency Code Indicates the currency code of the transaction according to ISO 4217.

VLP Terminal Support Indicator

A data element, which if present in the terminal, indicates that the terminal supports VLP processing.

VLP Terminal Transaction Limit

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.

Table D–1: Initiate Application Processing—Card Data (2 of 2)


Draft 12/18/00



D.3 Terminal RequirementsThe terminal must meet the following requirements:

● 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

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:

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

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




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



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 inTable D–3.

Table D–3: Terminal TACs for VLP (1 of 2)

Card or Terminal Conditions Default Online Denial

Offline Data Authentication not performed 0 0 0

SDA Failure 1 0 1

Chip Data Missing 1 0 1

PAN on terminal exception file 1 0 1

Standard DDA failure 1 0 1

Combined DDA/AC Generation Failure 1 0 1

Chip and terminal are different versions 0 0 0

Expired Application 1 0 1

Application not yet active 1 0 1

Service not allowed for card product 1 0 1

New Card 0 0 0

Cardholder verification failed 1 0 1

CVM not recognized 0 0 0

PIN try limit exceeded 1 0 1

Offline PIN required and pin pad not working 1 0 1

Offline PIN required and no pin entered 1 0 1

Online PIN entered 0 0 0

Transaction exceeds floor limit 0 0 0

Draft 12/18/00




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.

Lower offline limit exceeded 0 0 0

Upper offline limit exceeded 0 0 0

Transaction selected randomly for online 0 0 0

Merchant forced transaction online 1 0 1

Default TDOL used 0 0 0

Issuer Authentication failed 0 0 0

Script Processing failed prior to final AC 0 0 0

Script Processing failed after final AC 0 0 0

Table D–3: Terminal TACs for VLP (2 of 2)

Card or Terminal Conditions Default Online Denial

Draft 12/18/00



Figure D–1: VLP Transaction Flow

Terminal Card

Terminal selects theVIS AID

Card responds toSELECTcommand

SELECT response(includes PDOL requesting VLP

Terminal Support Indicator,Amount Authorized, and

Transaction Currency Code)

Terminal initiatesprocessing by by issuingthe GET PROCESSING

OPTIONS command

Card receives GETPROCESSING

OPTIONScommand

GET PROCESSING OPTIONS command(includes VLP Terminal Support Indicatior,

Amount Authorized, andTransaction Currency Code)

All are true?Txn Type is PurchaseUnder txn limit for VLP

VLP is supported

SELECT command

Terminal provides VLPTerminal Support

Indicator greater than 0in GET PROCESSINGOPTIONS command

Y

Terminal provides VLPTerminal Support Indicator

equal to 0 in GETPROCESSING OPTIONS

command

N

VLPTerminal Support

Indicator > 0?

TxnCurrency Code = Application

Currency Code?

Txn amount < or= to VLP Available

Funds?

Last OnlineATC Register > 0 and PIN Try

Counter > 0?

Issuer Authentication FailureIndicator = 0?

Txn amount <or = to VLP Single Transaction

Limit?

Y

Y

Y

Y

Y

Card deducts the amount of txn from the VLPAvailable Funds

Y

Card responds to GET PROCESSING Optionswith VLP AIP and VLP AFL (pointing to a file andrecord containing the VLP Issuer Authorization

Code and the VLP Available Funds

N

N

N

Card responds withVSDC AIP and AFL

GET PROCESSING OPTIONSresponse

Terminal terminatesinitiate processing

AIP and AFLreceived?

N

Terminal readsrecords from card

VLP IssuerAuthorization Code

present?

Terminal isVSDC capable?

NY

N

Terminal uses VLPTACs and normal

processing continues

Y

N

N

N

Draft 12/18/00


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



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/00E–131 Oct 2001 Visa Public

Acronyms E

Acronym Meaning

a alpha

AAC Application Authentication Cryptogram

AAR Application Authentication Referral

AC Application Cryptogram

ADA Application Default Action

ADF Application Definition File

AEF Application Elementary File

AFL Application File Locator

AID Application Identifier

AIP Application Interchange Profile

AMD Application Management Data

an alphanumeric

ans alphanumeric special

Draft 12/18/00

Acronyms Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

E–2 31 Oct 2001Visa Public

APDU Application Protocol Data Unit

ARPC Authorization Response Cryptogram

ARQC Authorization Request Cryptogram

ATC Application Transaction Counter

ATM Automated Teller Machine

AUC Application Usage Control

Auth. authentication

b binary

BIN BASE Identification Number

C conditional

CA Certificate Authority

CAM Card Authentication Method

CDOL Card Risk Management Data Object List

Cert. certificate

CID Cryptogram Information Data

CLA Class Byte of the Command Message

cn compressed numeric

Cons. consecutive

CPLC Card Production Life Cycle Data

Cum. cumulative

CVM Cardholder Verification Method

Acronym Meaning

Draft 12/18/00


Acronyms

E–331 Oct 2001 Visa Public

CVR Card Verification Results

CVV Card Verification Value

DDA Dynamic Data Authentication

DDF Directory Definition File

DDOL Dynamic Data Authentication Data Object List

DEA Data Encryption Algorithm

DES Data Encryption Standard

DF dedicated file

EEPROM Electronically Erasable Programmable Read-Only Memory

EMV Europay, MasterCard, Visa

ENC MDK Master Data Encipherment DEA Key

ENC UDK Unique Data Encipherment DEA Key

FCI File Control Information

FCP File Control Parameters

FMD File Management Data

GPO GET PROCESSING OPTIONS

hex. hexadecimal

HHMMSS hours, minutes, seconds

HSM host security module

IA Issuer Authentication

IAC Issuer Action Code

Acronym Meaning

Draft 12/18/00



IC integrated circuit

ICC integrated circuit card

IEC International Electrotechnical Commission

IFD interface device

INS Instruction Byte of the Command Message

Int’l international

ISO International Organisation for Standardisation

Lc Length of the Command Data Field

Le Expected Length of the Response Data Field

LD Length of the plaintext data in the Command Data Field

LRC Longitudinal Redundancy Check

M mandatory

MAC Message Authentication Code

MAC MDK Master Message Authentication Code DEA Key

MAC UDK Unique Message Authentication Code DEA Key

MCC Merchant Category Code

MDK Master DEA Key

n numeric

N/A not applicable

NCA Length of the Certification Authority Public Key Modulus

NI Length of the Issuer Public Key Modulus

Acronym Meaning

Draft 12/18/00


Acronyms

E–531 Oct 2001 Visa Public

NIC Length of the ICC Public Key Modulus

No. number

O optional

P1 Parameter 1

P2 Parameter 2

PAN Primary Account Number

PDOL Processing Options Data Object List

PIN Personal Identification Number

PIX Proprietary Application Identifier Extension

PK public key

PKI Certificate Authority Public Key Index

POS point of service

PSE payment system environment

PVV PIN Verification Value

R required

RFU Reserved for Future Use

RID Registered Application Provider Identifier

ROM Read-Only Memory

RSA Rivest, Shamir, Adleman

SAD Signed Static Application Data

SAM Secure Access Module

Acronym Meaning

Draft 12/18/00



SDA Static Data Authentication

SFI Short File Identifier

SW1, SW2 Status Words

TC Transaction Certificate

TDOL Transaction Certificate Data Object List

TLV tag-length-value

Txn. transaction

TSI Transaction Status Information

TVR Terminal Verification Results

UDK Unique DEA Key

var. variable

V.I.P. VisaNet Integrated Payment

VLP Visa Low-value Payment

YDDD year, day where Y = right-most digit of the year (0–9) and DDD = Julian day of the year (001–366)

YYMM year, month where YY = year (00–99) and MM = month (01–12)

YYMMDD year, month, day where DD = day (01–31)

Acronym Meaning

Draft 12/18/00Glossary–131 Oct 2001 Visa Public

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

Glossary Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

Glossary–2 31 Oct 2001Visa Public

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:

● approval

● decline

● pickup

● referral

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


BASE I Authorization System

Glossary–331 Oct 2001 Visa Public

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



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


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



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


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



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.


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


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



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


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



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/00Index–131 Oct 2001 Visa Public

AAAC, 10–8 to 10–9, 11–2, 11–4, 12–7, 13–1,13–5 to 13–11, B–3

AAR, B–3account transfer, 13–7advice message, 13–6, 14–2, 14–5, C–2AFL. See Application File LocatorAID, 3–2, 9–3, D–4, D–9AID matching example, 3–9Amount entry, C–2Amount X, 8–4Amount Y, 8–4Amount, Authorized, 8–7, 9–4 to 9–5, 12–4,D–3 to D–4, D–9

Amount, Other, 12–4APPLICATION BLOCK command, 14–3Application Cryptogram, 11–2, 12–2, 12–4, 13–3Application Currency Code, 8–3, D–2Application Definition File, 3–2, 3–7, B–6 to B–7Application Effective Date, 7–2Application Elementary Files, 3–2, 5–2Application Expiration Date, 7–2Application 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–7Application PAN Sequence Number, 12–4Application Preferred Name, 3–3, B–6 to B–7Application Priority Indicator, 3–3, B–7Application Selection, 1–7, 2–1, 2–7, 3–1 to 3–15, 4–6

card data, 3–2identifying and selecting the application, 3–10processing flow, 3–12 to 3–14terminal data, 3–4

Application Selection Indicator, 1–7, 3–4APPLICATION UNBLOCK command, 14–3, B–2Application Usage Control, 7–2, 7–4 to 7–6Application Version Number (“9F08”), 7–2Application Version Number (“9F09”), 7–3

ARPC, 12–5ARQC, 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–4ATM, 1–7, 6–3, 7–4 to 7–5, 13–7, C–1 to C–2, C–4Authorization Response Code, 10–3, 10–8, 12–5, 13–4, 13–6

Bbalance inquiry, 13–7biometrics, 8–1bypass PIN entry, 8–13, 8–21

Ccandidate list, building the, 3–6Card Action Analysis, 2–4, 2–8, 11–1 to 11–5, 12–10, 13–11

card data, 11–2processing, 11–4terminal data, 11–3

CARD BLOCK command, 14–3card data

for Application Selection, 3–2for Card Action Analysis, 11–2for Cardholder Verification, 8–3for Completion, 13–2for Dynamic Data Authentication, 6–12for Initiate Application Processing, 4–2for Issuer-to-Card Script Processing, 14–2for Online Processing, 12–2for Processing Restrictions, 7–2for Static Data Authentication, 6–7for Terminal Action Analysis, 10–2for Terminal Risk Management, 9–3

card life cycle data, B–4card override of terminal decision, 11–4card reader, 8–7, 8–15Card Risk Management checks, 11–4card velocity checking. See velocity checking, cardcardholder confirmation, 3–10

Index

Draft 12/18/00

D Visa Integrated Circuit CardTerminal Specification, Version 1.4.0

Index–2 31 Oct 2001Visa Public

cardholder selection, 3–10 to 3–11Cardholder Verification, 2–3, 2–7, 4–2, 4–6,8–1 to 8–22, 10–11

card data, 8–3CVM List Processing, 8–9CVM Processing, 8–13processing, 8–9terminal requirements, 8–3

Cardholder Verification Method List. See CVM ListCardholder Verification Method. See CVMcash, 7–5, 8–4cash disbursement, 13–7cashback, 7–5, C–2CDOL1, 10–3, 10–5, 11–2 to 11–3CDOL2, 13–2, 13–4, 13–8Certificate 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–18Chip Condition Code, C–3chip read, C–3CID. See Cryptogram Information Dataclearing message, 13–1, 13–6, 14–2, 14–5, B–3Combined 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–6Combined DDA/AC Generation failure, 12–7,12–10 to 13–1, 13–5

command response, B–2command support requirements, 2–9commands, 14–3

APPLICATION BLOCK, 14–3APPLICATION UNBLOCK, 14–3CARD BLOCK, 14–3EXTERNAL AUTHENTICATE, 12–6, B–2GENERATE AC, 10–5, 11–2 to 11–5, 12–6,13–4 to 13–11, B–3

GET CHALLENGE, 8–8, 8–19, B–3GET DATA, 8–8, 9–5, B–4GET PROCESSING OPTIONS, 4–3, B–5INTERNAL AUTHENTICATE, 6–14, B–5PIN CHANGE/UNBLOCK, 14–4PUT DATA, 14–4READ RECORD, 3–5, B–5SELECT, 3–5, B–5 to B–6UPDATE RECORD, 14–4VERIFY, 8–9, B–7

Completion, 2–5, 2–8, 6–23, 12–7 to 13–11, 14–7card data, 13–2processing flow, 13–10

counters, 13–1credit, 12–1cryptogram, 10–1Cryptogram Information Data, 11–2, 12–2, 12–10,13–3, 13–5, 13–9

cryptogram type, 10–5, 13–9cryptogram version 10, 12–4cryptogram version 14, 1–8, 12–4Cumulative Total Transaction Amount Upper Limit, 1–9

CVM Code, 8–4, 8–10 to 8–22CVM Conditions, 8–4, 8–10CVM Entry, 8–10CVM List, 1–7 to 1–8, 2–3, 8–1, 8–4, 8–9 to 8–10, D–2CVM List processing, 8–3, 8–9

card data, 8–3processing flow, 8–12

CVM results, 8–7CVM Type, 8–4CVR, 8–6, 11–2, 13–3

DData Authentication Code (DAC), 1–7DDA, 2–2, 4–2, 5–1 to 5–2, 6–1, 6–12 to 6–22, 8–5,8–19

card data, 6–12terminal data, 6–13

DDOL, 6–12 to 6–22Dedicated File Name, B–6default CVM, 2–3Default DDOL, 6–13 to 6–22DES, 11–5DES keys, 8–7Directory Definition File, 3–3, 3–7, B–6Directory File, 3–3Directory Selection Method, 1–7, 3–6 to 3–8,3–10 to 3–11

domestic, 7–5dynamic signature, 6–14, 6–17, 12–6

Eeffective date checking, 7–6EMV, 1–3, 1–6 to 1–7, D–4EMV documentation, 1–11Enciphered PIN data, 8–7Enter PIN, 8–14, 8–17expiration date checking, 7–6expired application, 7–6, 10–4EXTERNAL AUTHENTICATE command, 2–9, 12–6, 12–8, B–1 to B–2

Draft 12/18/00


F

Index–331 Oct 2001 Visa Public

FFail CVM, 8–22FCI Issuer Discretionary Data, B–6FCI Proprietary Template, B–6FCI Template, B–6 to B–7File Control Information, 3–3, 3–7, 4–2, 4–4, D–4, D–9final approval by card, D–10floor limits, 9–5fraud risk, 6–7, 12–1, D–1functional overview, 2–1functions

Application Selection, 3–1 to 3–15Card Action Analysis, 11–1Cardholder Verification, 8–1Completion, 13–1 to 13–11Initiate Application Processing, 4–1Issuer-to-Card Script Processing, 14–1 to 14–7Offline Data Authentication, 6–1Online Processing, 12–1Processing Restrictions, 7–1Read Application Data, 5–1Terminal Action Analysis, 10–1Terminal Risk Management, 9–1

functions, mandatory and optional, 2–7

GGENERATE 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–1Terminal 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

Hhash, 6–10, 6–13, 6–15, 6–18, 12–7host-data-capture system, 13–7

IIACs, 10–1 to 10–11, 13–2, 13–8, D–2ICC Dynamic Data, 6–13ICC Dynamic Number, 1–7ICC PIN Encipherment key data, 8–19ICC PIN Encipherment Private Key, 8–5ICC PK Certificate, 6–12, 6–16, 6–19

ICC Private Key, 6–16ICC Public Key, 1–8, 2–2, 6–17, 8–19, 12–6ICC Public Key Exponent, 6–12ICC Public Key Modulus, 6–17ICC Public Key Remainder, 6–12incorrect PIN, 8–17indicators, 13–1Initiate Application Processing, 2–2, 2–7, 3–5, 3–15,4–1, 5–2, 5–5, 6–23, 8–23

card data, 4–2processing, 4–4processing flow, 4–5terminal data, 4–3

Interface Device (IFD) Serial Number, 12–4INTERNAL AUTHENTICATE command, 2–9,6–13 to 6–16, B–1, B–5

international, 7–5ISO documentation, 1–10Issuer Application Data, 11–2, 12–2, 12–4, B–3, D–2, D–9 to D–10

issuer approval, D–10Issuer Authentication, 2–5, 4–2, 12–1, 12–6 to 13–1Issuer Authentication Data, 12–5 to 12–6, 12–8, B–2Issuer Code Table Index, 3–3, B–6 to B–7Issuer Country Code “5F28”, 7–2, 7–4Issuer Discretionary Data, D–9 to D–10issuer host, 12–1, 12–5Issuer Identification Number, 6–9Issuer PK Certificate, 6–7, 6–9, 6–15, 6–18, 8–5Issuer Private Key, 8–5Issuer Public Key, 1–8, 2–2, 6–9, 6–15, 6–18Issuer Public Key Certificate. See Issuer PK CertificateIssuer Public Key Exponent, 6–7, 6–15, 6–18, 8–6Issuer Public Key Modulus, 6–9, 6–15, 6–18Issuer 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–10issuer script commands, B–1 to B–2Issuer Script Identifier, 14–2Issuer Script Results, 13–6, 14–2, 14–5issuer scripts. See Issuer-to-Card Script processingIssuer-to-Card Script Processing, 2–5, 12–1, 13–6,14–1 to 14–7

card data, 14–2commands, 14–3online response data, 14–3processing, 14–4processing flow, 14–6terminal data, 14–2

Draft 12/18/00

K Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


Kkey entered, 12–1

LLanguage Preference, B–6 to B–7Last Online ATC Register, 9–3, 9–5, 9–7 to 9–8, B–4Last PIN Try, 8–3, 8–14, 8–17List of AIDs Method, 1–7, 3–6 to 3–7, 3–9Lower Consecutive Offline Limit “9F14”, 9–3,9–7 to 9–8, 10–4

Mmagnetic stripe read, 12–1, C–3magnetic stripe reader, C–4mandatory, 1–3manual entry, C–4Maximum Target Percentage to be used for Biased Random Selection, 9–4, 9–6

merchant floor limit. See floor limitsMerchant Forced Transaction Online, 9–5, 10–4Merchant type, D–1, D–9multiple commands, 14–4

Nnew card, 9–8, 11–4No CVM Required, 8–23

Ooffline approval, 10–1, 11–4, 13–4 to 13–5, 13–8, D–1Offline Data Authentication, 2–2, 2–7, 4–2, 4–6, 5–5, 6–1, 10–4, 10–11

terminal requirements, 6–3offline 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–19card data, 8–5

Offline Enciphered PIN processing flow, 8–20offline low-value payments, D–1Offline PIN, B–7Offline PIN Processing

card data, 8–5Offline PIN processing

card data, 8–6Offline PIN Processing flow, 8–18Offline Plaintext PIN, 8–1, 8–9, 8–13, 8–15offline-capable terminal, 9–7, C–1offline-only terminal, 13–1, C–1offline-only transaction, D–4online approval, 13–1online authorization, 13–1, 13–4, 13–6, D–1, D–9

Online Authorization Indicator, 1–8 to 1–9online authorization message, 12–4 to 12–5, 14–2,14–5, B–3

Online Card Authentication, 2–5, 12–1online PIN, 8–1, 8–21, 10–4Online Processing, 2–4, 2–8, 4–6, 6–23, 12–1, 13–11, 14–7

card data, 12–2commands, 12–6new response data elements, 12–5Processing, 12–6processing flow, 12–9terminal data, 12–2 to 12–3

Online Processing Requested, Online Authorization Not Completed, 13–8

online request, 10–1, 11–4, 12–6, C–3online response, 12–5 to 12–6online-capable terminal, 9–5, C–1, D–9online-only terminal, 6–3, C–1, D–9optional, 1–3

PPAN, 6–9, 6–16, 6–19, 9–3, 9–5, C–4Payment Systems Directory, 3–7Payment Systems Environment, 3–3, 3–5, 3–7PDOL, 3–3, 3–5, 4–1 to 4–6, B–5, B–7, D–2, D–4, D–9PIN block, 8–19PIN CHANGE/UNBLOCK command, 14–4, B–2PIN encipherment, 8–15PIN OK, 8–17PIN pad, 8–3, 8–7, 8–13 to 8–20PIN Pad Secret Key, 8–7, 8–13, 8–15PIN Try Counter, 8–5, 8–8, 8–13, 8–16, B–4PIN Try Counter checking, 8–15PIN Try Limit, 8–6 to 8–9, 8–16 to 8–18, 8–21PIX, 3–2POS device, 13–7POS Entry Mode, C–3post-issuance updates. See Issuer-to-Card Script Processing

processing overview, 2–1Processing Restrictions, 2–3, 2–7, 7–1, 10–11

Application Effective Date, 7–6Application Expiration Date, 7–6Application Usage Control, 7–4Application Version Number, 7–3card data, 7–2processing flow, 7–7terminal data, 7–3

Draft 12/18/00


Q

Index–531 Oct 2001 Visa Public

PSE File Name, 3–4PUT DATA command, 14–4

Qquasi-cash, 8–4

RRandom Transaction Selection, 9–6, 10–4Read Application Data, 2–2, 4–6 to 5–1, 6–23, 7–8, 8–23, 9–11, 10–11, 11–5

card data, 5–2card files, 5–2processing, 5–3processing 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–5recommended, 1–3Reference PIN, 8–5 to 8–6, 8–9, 8–16, 14–4referrals, 13–6, B–3required, 1–3reversals, 13–7, 14–2, C–2RID, 3–2, 6–7 to 6–9, 6–15, 6–18, 8–6, 8–8RSA, 6–3RSA key management, 6–4

Sscript errors, 14–5scripts, multiple, 14–5SDA, 2–2, 2–7, 4–2, 5–1 to 5–2, 6–1, 6–7SDA or DDA, determining which to perform Offline Data Authentication, 6–4 to 6–6

SDA Tag List, 1–7 to 1–8SELECT command, 2–9, 3–5, 3–7 to 3–15, B–1, B–6, D–9

Service Code, C–3services, 7–5Session Key Generation, 1–8Short File Identifier, 3–3, 3–5, 5–2, B–6signature and offline PIN, 8–1, 8–21 to 8–22signature, cardholder, 13–1Signed Dynamic Application Data, 6–13 to 6–22, 12–6Signed Static Application Data, 6–7, 6–10, 6–12skimming, 6–1Standard DDA, 2–2, 2–7, 6–15, 6–18Standard Online Processing, 12–6 to 12–7Standard VSDC, D–5, D–9Static Data Authentication Tag List, 6–8, 6–10, 6–16, 6–19

static data to be authenticated, 6–8

Subsequent Related ProcessingCard Action Analysis, 8–24, 10–11Completion, 8–24, 11–5, 12–10Issuer-to-Card Script Processing, 8–24, 12–10Online Processing, 11–5Terminal Action Analysis, 8–24, 9–11

TTACs, 10–1 to 10–11, 13–4, 13–8, D–3, D–6tamper-evident device, 8–7Target 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–5Terminal Action Analysis, 2–4, 2–8, 6–23, 7–8, 10–1 to 10–11, 11–5, 13–8

card data, 10–2processing, 10–6processing flow, 10–10terminal data, 10–3

Terminal Capabilities, 6–4 to 6–5, 8–7, 8–10, 12–4Terminal Country Code, 4–3, 7–3, 12–4terminal data

for Application Selection, 3–4for Card Action Analysis, 11–3for Cardholder Verification, 8–7for Completion, 13–4for Initiate Application Processing, 4–3for Issuer-to-Card Script Processing, 14–2for Online Processing, 12–3for Processing Restrictions, 7–3for Terminal Action Analysis, 10–3for Terminal Risk Management, 9–4

Terminal Exception File, 9–5, 10–4, D–7terminal floor limit, 9–4 to 9–6, 10–4, D–3 to D–4terminal 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–6Terminal Risk Management, 2–3, 2–8, 9–1, 10–6,10–11

card data, 9–3processing flow, 9–8terminal data, 9–4

terminal velocity checking, 9–7terminated transactions, 1–3Threshold Value for Biased Random Selection, 9–4,9–6

transaction authorized offline, Completion, 13–5transaction authorized online, Completion, 13–6

Draft 12/18/00

U Visa Integrated Circuit CardTerminal Specification, Version 1.4.0


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–4transaction flow, sample, 2–6Transaction Log, 9–4 to 9–5, D–7Transaction 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–4Transaction Type, 7–3, 12–4, D–4TVR, 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

Uunable to go online, 13–4, 13–8Unpredictable Number, 6–13, 6–16, 8–8, 12–4unrecognized CVM, 8–7, 8–10 to 8–12UPDATE RECORD command, 14–4Upper Consecutive Offline Limit “9F23”, 9–3,9–7 to 9–8, 10–4

Use Chip Reader, C–3

Vvelocity checking, card, 11–1, 11–4velocity checking, terminal, 9–7VERIFY command, 2–9, 8–5, 8–9, 8–16 to 8–20, B–1, B–7

Visa Certificate Authority, 6–3Visa documentation, 1–11Visa Integrated Circuit Card Specification, 1–1

impact summary, 1–7revisions, 1–6update, 1–2

Visa Low-value Payment, 1–7, 1–9, D–1Visa Private Key, 8–5Visa Public Key, 6–9, 6–15, 6–18, 8–8 to 8–9Visa Public Key Modulus, 6–9, 6–15, 6–18VLP

duplicate data elements, D–1 to D–2, D–4, D–6reset 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–9VLP capable, terminal, D–4, D–9VLP Funds Limit, D–1 to D–2, D–10VLP Issuer Authorization Code, D–3 to D–4, D–7VLP processing, D–4VLP Single Transaction Limit, D–1, D–3

VLP Terminal Support Indicator, D–3 to D–4, D–9VLP Terminal Transaction Limit, D–3 to D–4

YY1 Authorization Response Code, 10–9, 13–4 to 13–5Y3 Authorization Response Code, 13–4, 13–8

ZZ1 Authorization Response Code, 10–8, 12–10, 13–4 to 13–5

Z3 Authorization Response Code, 10–9, 13–4, 13–8