Chip Card Acceptance Device Ref Guide 6 (1) .0

CHIP CARD ACCEPTANCE DEVICE
REFERENCE GUIDE
Requirements and Best Practices, Version 6.0
Visa International
Global Acceptance Infrastructure Migration
July 2003
ii Chip Card Acceptance Device Reference Guide, Version 6.0 July 2003
Document Changes
Date Ver. Description Page
December 2000 5.0
July 2003 6.0 Updated to reflect EMV2000 Integrated Cir- Entire

cuit Car Specification for Payment Systems document
and Visa Integrated Circuit Card Specifica-
tions (“VIS”) 1.4.0.
Visa Public
July 2003 Chip Card Acceptance Device Reference Guide, Version 6.0 iii
Table of Contents
Chapter 1: Introduction ............................................................................................1
1.1 Scope and Contents ...................................................................................................... 2
1.1.1 Caveat .......................................................................................................... 3
1.2 Terminology ................................................................................................................... 4
1.2.1 Key Terms .................................................................................................... 4
1.2.2 Acronyms and Abbreviations ........................................................................ 5
1.3 Icons and Cross-References......................................................................................... 6
Chapter 2: Visa Smart Debit and Visa Smart Credit ..............................................7
2.1 Physical Characteristics................................................................................................ 8
2.1.1 Card Reader ................................................................................................. 8
2.1.2 Display .......................................................................................................... 9
2.1.3 Memory....................................................................................................... 10
2.1.4 Printer ......................................................................................................... 10
2.1.5 Communication Speed ............................................................................... 10
2.1.6 Cardholder Interface Unit............................................................................ 10
2.1.7 Clock........................................................................................................... 12
2.2 Security Characteristics.............................................................................................. 13
2.2.1 PIN Pad ...................................................................................................... 13
2.2.2 Key Management........................................................................................ 15
2.3 VSDC Transaction Processing ................................................................................... 17
2.3.1 Card Insertion ............................................................................................. 17
2.3.2 Application Selection .................................................................................. 20
2.3.3 Application-Processing Initiation and Data Read........................................ 22
2.3.4 Processing Restrictions .............................................................................. 23
2.3.5 Offline Data Authentication ......................................................................... 23
2.3.6 Cardholder Verification ............................................................................... 24
2.3.7 CVM Considerations for Early Markets....................................................... 28
2.3.8 Terminal Risk Management........................................................................ 28
2.3.9 Terminal Action Analysis ............................................................................ 29
2.3.10 Card Action Analysis................................................................................... 30
2.3.11 Online Authorization ................................................................................... 31
2.3.12 Completion.................................................................................................. 31
2.3.13 Issuer-to-Card Script Processing................................................................ 32
2.3.14 Additional Functions ................................................................................... 32
2.4 Commercial Cards ....................................................................................................... 37
2.5 VLP Feature .................................................................................................................. 38
2.5.1 VLP Specifications...................................................................................... 38
2.5.2 VLP Testing ................................................................................................ 38
2.6 Early and Full Data Options ........................................................................................ 39
2.7 Terminal Management System ................................................................................... 41
2.7.1 EMV Functions ........................................................................................... 41
2.7.2 Data Elements ............................................................................................ 41
2.7.3 Offline Data Authentication ......................................................................... 43
2.7.4 Random Transaction Selection................................................................... 44
2.7.5 Floor Limits ................................................................................................. 46
2.7.6 Additional Considerations ........................................................................... 46
Visa Public
iv Chip Card Acceptance Device Reference Guide, Version 6.0 July 2003
2.8 EMV Approval Considerations.................................................................................... 48

2.8.1 EMV Support in a Modular Architecture ..................................................... 48
2.8.2 Considerations for EMV Approvals............................................................. 50
2.9 Key Chip Migration Dates............................................................................................ 51
2.10 Magnetic-Stripe Reader ............................................................................................... 53
Chapter 3: Visa Cash ..............................................................................................55
3.1 Compliance Requirements.......................................................................................... 56
3.2 Physical Characteristics.............................................................................................. 57
3.2.1 Secure Module............................................................................................ 57
3.2.2 Display ........................................................................................................ 57
3.2.3 Memory....................................................................................................... 57
3.2.4 External Communication............................................................................. 58
3.2.5 Function Keys and Keypad......................................................................... 58
3.3 Retail Environments .................................................................................................... 59
3.3.1 Attended Transactions................................................................................ 59
3.3.2 Unattended Transactions............................................................................ 59
3.4 Visa Cash Transaction Processing ............................................................................ 60
3.4.1 Transaction Initiation................................................................................... 60
3.4.3 Card and Data Authentication..................................................................... 60
3.4.4 Transaction Completion and Capture ......................................................... 60
3.4.5 Card with Insufficient Value ........................................................................ 61
3.4.6 Disposable and Reloadable Cards ............................................................. 61
Chapter 4: Visa Horizon..........................................................................................62
4.1 How It Works ................................................................................................................ 63
4.2 Compliance Requirements.......................................................................................... 64
4.3 Physical Characteristics.............................................................................................. 65
4.3.1 Card Reader ............................................................................................... 65
4.3.2 Display ........................................................................................................ 65
4.3.3 Memory....................................................................................................... 65
4.3.4 Printer ......................................................................................................... 65
4.3.5 Cardholder Interface Unit............................................................................ 66
4.3.6 Clock........................................................................................................... 66
4.4 Security Characteristics.............................................................................................. 67
4.4.1 Offline PIN .................................................................................................. 67
4.4.2 Authentication and Integrity Processes ...................................................... 67
4.4.3 Negative File............................................................................................... 67
4.5 Visa Horizon Transaction Processing........................................................................ 68
4.5.2 Cardholder Verification ............................................................................... 68
4.5.3 Transaction Completion and Capture ......................................................... 68
Chapter 5: Device Types ........................................................................................69
5.1 General Device Configurations................................................................................... 70
5.1.1 Hardware .................................................................................................... 70
5.1.2 Software...................................................................................................... 71
5.1.3 PIN Entry Device Requirements ................................................................. 71
5.1.4 Requirements for Private Tags (Not Visa-Specific) .................................... 73
5.2 Unattended Devices..................................................................................................... 74
5.2.1 Unattended Environment ............................................................................ 74
Visa Public
July 2003 Chip Card Acceptance Device Reference Guide, Version 6.0 v
5.2.2 Transaction Types ...................................................................................... 74

5.2.3 Physical Characteristics.............................................................................. 75
5.2.4 Transaction Processing at Unattended Devices......................................... 75
5.3 Automated Teller Machines ........................................................................................ 77
5.3.1 Physical Characteristics.............................................................................. 77
5.3.2 PIN Encryption............................................................................................ 78
5.3.3 Business Requirements.............................................................................. 78
5.4 Transaction Types ....................................................................................................... 80
5.4.1 Purchases................................................................................................... 80
5.4.2 Refunds ...................................................................................................... 80
5.4.3 Cancel/Voids .............................................................................................. 81
5.4.4 Reversals.................................................................................................... 81
5.4.5 Authorization Only (Pre-Authorization) ....................................................... 81
5.4.6 Posts (Post Authorizations, Forced Post) ................................................... 81
5.5 Notes for Acquirers ..................................................................................................... 82
5.5.1 Signature Capture....................................................................................... 82
5.5.2 PIN Storage ................................................................................................ 82
5.5.3 Terminal Recovery for Offline Transactions ............................................... 82
5.5.4 Change in Format for Authorization Response Code ................................. 82
5.5.5 Certification for ATM Acquirers................................................................... 83
5.5.6 Test Keys.................................................................................................... 83
Appendix A: Track 1 Data .......................................................................................84
Appendix B: Track 2 Data .....................................................................................107
Appendix C: Reference Materials.........................................................................121
Appendix D: Acronyms and Glossary .................................................................125
Visa Public
July 2003 Chip Card Acceptance Device Reference Guide, Version 6.0 1
Chapter 1: Introduction
Today, the ongoing deployment of chip technology, com-
WHAT’S COVERED
bined with the increasingly global nature of the payment
Scope and Contents card industry is creating new requirements for the interop-
Terminology erability of cards and devices. Interoperability is the corner-
Icons and Cross-
stone of Visa brand acceptance and, consequently, a driving
References force behind Visa’s long-standing commitment to work with
Members, vendors, and third-party organizations to create
the global infrastructure needed to meet these challenges.
The Chip Card Acceptance Device Reference Guide: Re-

quirements and Best Practices is intended to provide ven-
dors and Acquiring Members (“Acquirers”) or their agents
with a comprehensive overview of the hardware and soft-
ware specifications for devices that process Visa chip-card
transactions. This information will, we hope, help vendors
design devices that meet industry and Visa-specific stan-
dards both now and in the future.
This document will be updated on an as needed basis. Bul-

letins posted on the Visa CAD website, www.visa.com/cad,
may be used on an interim basis, until the next revision to
this document.
Visa Public
2 Chip Card Acceptance Device Reference Guide, Version 6.0 July 2003
1.1 Scope and Contents
The focus of this book is on devices used at the point of

transaction where both the cardholder and card are present;
that is, attended devices, unattended devices, and ATMs.
The contents include:
Chapter 2: Visa Smart Debit and Smart Credit — This

chapter describes the physical, security, and functional
characteristics of devices that process Visa Smart Debit
and Smart Credit (VSDC) transactions – for Visa Flag
and Visa Electron. Terminal management systems and
the Early and Full Data Options for VSDC processing
The requirements and best
are also discussed.
practices discussed in this Chapter 3: Visa Cash — This chapter describes the
book are primarily for de-
vices that process chip-card physical, security, and functional characteristics of de-
transactions. Information vices that process Visa Cash transactions.
on magnetic-stripe specifi-
cations is included as nec- Chapter 4: Visa Horizon — This chapter describes the
essary. physical, security, and functional characteristics of de-
vices that process Visa Horizon transactions using CO-
PAC technology.
Chapter 5: Device Types — This chapter outlines the
physical, security, and functional characteristics that are
unique to individual device types. Requirements and
best practices for attended and unattended devices, and
ATMs are discussed, and sections on transaction types
and operational considerations for Acquirers are also in-
cluded.
Appendix A and B — These sections provide detailed
descriptions of the data encoded on Track 1 and Track 2
of a magnetic stripe, or on the magnetic-stripe image of
the chip.
Appendix C: References — This section includes a list
of references cited in this guide, as well as supplemental
documentation that may be of use to vendors and Ac-
quirers.
Appendix D: Acronyms and Glossary — This section
contains a list of acronyms and a glossary of terms used
in this book.
Visa Public
1.1.1 Caveat
While based on the most current EMV specifications and
For information on testing Visa-specific implementation of EMV, the Visa Integrated
procedures and how to obtain Circuit Card Specifications (“VIS”), this document should
the EMV and VIS specifica- not be used as a substitute for the full specifications. It
tions, see Appendix C: “Refer-
ence Materials.”
does not address technical details such as application soft-
ware, message formatting, and merchant and Acquirer host
systems. Details on the Visa testing and approval process
are also not covered.
Visa Public
1.2 Terminology
The terms used to refer to different kinds of card acceptance

devices and their components may vary widely from region
to region, and from one market sector or merchant to an-
other. To avoid confusion, a unified, consistent terminology
has been adopted for this guide.
1.2.1 Key Terms

The key terms used in this document include the following:
Authorize — When used alone, it can denote that the

transaction has been authorized either online by the is-
suer or its designated card processor, or offline by the
card’s chip. Online or offline will be added to the use of
the word “authorize” whenever a distinction is necessary.
Device or terminal — Generic terms used to refer to
any device, attended or unattended, that accepts and
processes payment card transactions. Commonly
known devices include: POS terminals, ATMs, cash dis-
pensers.
POS system — An electronic system used in an at-
tended retail environment for the processing and capture
of transaction information at the point of sale. A POS
system may consist of a range of components, from a
simple cash register and stand-alone payment device, to
sophisticated integrated POS terminals that perform mul-
tiple business functions. (A POS system may or may not
have a card-acceptance device fully integrated into the
system.)
Integrated POS system — A POS system with an inte-
grated card-acceptance device, supporting automatic
transfer of purchase amount and card’s magnetic stripe
or chip data to the POS system.
(PIN) Integrated POS terminal — A POS device with
built-in PIN entry capability, sharing the terminal’s key-
pad with the entry of PIN and non-PIN data. (The POS
device may also support the use of an external PIN pad
as well.)
Type A Transaction — Cardholder-activated transac-
tion performed at an unattended acceptance terminal
that is less than U.S.$40, or the local currency equiva-
lent, and is not authorized. Cardholder verification is not
performed. See Appendix D.2 Glossary for examples.
Visa Public
Type B Transaction — Cardholder-activated transac-

that is less than U.S.$100, or the local currency equiva-
lent. An authorization is required. Cardholder verifica-
tion is not performed. See Appendix D.2 Glossary for
examples.
Type C Transaction — Cardholder-activated transac-
that is not limited to any dollar amount. An authorization
and PIN verification (online or offline) are both required.
See Appendix D.2 Glossary for examples.
1.2.2 Acronyms and Abbreviations

In general, acronyms and abbreviations are spelled out on
their first appearance in each chapter. Certain widely used
terms are not spelled out, include:
ANSI — American National Standards Institute

ATM — Automated Teller Machine
COPAC — Chip Offline Pre-Authorized Card
EMV — Europay (now part of MasterCard), MasterCard,
and Visa
ISO — International Organization for Standardization
PED — PIN Entry Device
PIN — Personal Identification Number
POS — Point of Sale
TDES — Triple Data Encryption Standard
VIOR —Visa International Operating Regulations
VIS — Visa Integrated Circuit Card Specification
VSDC — Visa Smart Debit and Visa Smart Credit
Visa Public
1.3 Icons and Cross-References
Icons are used in this document to provide readers with vis-

ual cues to vital and helpful information. The icons used in-
clude the following.
Note — A key point to remember or similarly important

information.
Resource —Reference to a primary source or supple-

mental documentation.
In addition to these icons, cross-references to other sections

of this book may also be placed in the left-hand margin.
Cross-references appear as follows:
For information on the EMV

and VIS specifications, see
Appendix C: “Reference Mate-
rials.”
Visa Public
Chapter 2: Visa Smart Debit and Visa Smart

Credit
Visa Smart Debit and Visa Smart Credit (VSDC) represents
WHAT’S COVERED
Visa’s chip-based debit and credit payment program.
Physical Characteristics
Security Characteristics This chapter provides an overview of requirements and best
practices for card acceptance devices capable of processing
VSDC Transaction
Processing VSDC transactions.
Commercial Cards All devices that process VSDC transactions must be
VLP Feature EMV and VIS compliant, to ensure interoperability.
Early and Full Data Op- VSDC devices may also have to comply with requirements
tions that are specific to individual Visa regions. These require-
Terminal Management ments are not included in this document. Regional repre-
System sentatives work with vendors and Acquirers to ensure card
EMV Approval Consid- acceptance devices in a given region comply with the
erations requirements for that area.
Magnetic Stripe Reader
Key Chip Migration
Dates
For more information on the EMV specifications, visit the
EMVCo website at www.emvco.com.
For information on VIS, visit the Visa website at

www.visa.com/smartcardspecs.
For more information on regional requirements, contact your

Visa regional representative.
Visa Public
2.1 Physical Characteristics
This section describes the physical characteristics of the

main components of card acceptance devices that are ca-
pable of processing VSDC transactions – payments made
with Visa Flag and Visa Electron cards. The information
here is adapted from the EMV and VIS specifications.
2.1.1 Card Reader

Card readers allow terminals to establish contact with a card
and to obtain data stored on the card’s chip or magnetic
stripe. Should use terminal or device, rather than swapping
back and forth.
In general, a device that accepts Visa chip cards must con-

tain both a chip-card and a magnetic-stripe reader. If a de-
vice does not contain a chip-card reader, Visa recommends
that the device be chip capable; that is, able to add a chip-
card reader at a later date.
Implementation of products Acquirers and merchants should consider deploying new
like Visa Horizon may allow
the deployment of devices and replacement card acceptance devices that permit an
that only accept chip cards. easy upgrade to chip capabilities. Visa encourages a device
migration strategy that will accommodate chip-based prod-
ucts over time.
2.1.1.1 Chip-Card Reader

To read chip data, sustained contact between the chip and
the reader—such as insertion, dip, or “swipe-and-park”—is
required.
A chip card reader may include related mechanical and

electrical components.
A chip-card reader may be referred to as an interface mod-

ule (IFM) or interface device (IFD), the term used in the
EMV specifications. All chip-card readers must successfully
complete testing and be approved by an EMV test labora-
tory for EMV Level 1, and their associated payment applica-
tion for EMV Level 2.
Visa requirements and best practices for chip-card readers

include the following:
Chip-card readers should have a pictogram near the

card slot indicating how to insert the card into the reader.
You may also wish to consider tactile (raised) images to
address the needs of sight-impaired users.
Visa Public
When a card is inserted, the cardholder or attendant

should not be able to accidentally dislodge it from the
reader. However, if the card is accidentally dislodged,
the chip reader should abort the transaction and ensure
that neither it nor the card is damaged – in accordance
to EMV specifications.
Once a card is inserted, it may not be accessible at all
times, or the reader may have a tight grip to hold it. In
such cases, the device should also have a mechanism
to recall or release the card in the event of a loss of
power, device malfunction, or transaction cancellation.
For more information on EMV-approved chip-card readers,

see EMV2000 Integrated Circuit Card Specification for
Payment Systems, Book 1: Application Independent ICC to
Terminal Interface Requirements.
2.1.2 Display
A display allows a cardholder or attendant to monitor trans-
action flow and data entry, validate transaction-related data,
and select options.
The card acceptance device must have a display for the at-
tendant and may have an additional display for the card-
holder in order to support PIN entry or cardholder applica-
tion selection. Two displays may also be used to allow an
attendant and cardholder to either see different information
or see information in different languages.
Card acceptance devices must support the character set

For more information on ven- common to all parts of ASCII character set (ISO 8859). This
dor support for multiple lan-
character set allows the card acceptance device to display
guages and character sets,
see Section 2.3.12, “Comple- messages in multiple languages using Latin characters
tion.” without accent marks. To facilitate the display of languages
that use other character sets, the card acceptance device
should support a graphic display.
The display screen must be able to hold at least 32 alpha-

numeric characters (two lines of 16 positions each). The
two lines should be simultaneously displayed. A large dis-
play screen that can deliver multiple lines and, perhaps
graphics, has the advantage of enhancing the device’s vis-
ual interface with cardholders when supporting multi-
applications.
Visa Public
2.1.3 Memory
Card acceptance devices must have the minimum memory
required to fully support a VSDC application. The terminal
should have ample spare memory to allow addition of other
applications, as required in future multi-application pro-
grams, and storage of multiple EMV public keys for each
payment scheme. The current EMV requirement is six keys
per payment scheme with a length of 1984 bits and associ-
ated data. Security components of an application may also
require a sufficient level of support for key backup, key re-
covery, and key migration. Payment components of an ap-
plication require that devices be capable of storing the
transaction data.
In general, a card acceptance device needs a minimum of

1.5 megabytes (MB) of memory in order to support multiple
applications, such as magnetic-stripe, VSDC, and other
value-added applications.
2.1.4 Printer
Printers are used for receipt generation. The device must
have the capability to print a receipt for all approved transac-
tions — whether approved offline, online, or after a referral.
The device should always print the Application Label (or Ap-
plication Preferred Name) on the receipt.
2.1.5 Communication Speed

The terminal should support faster baud rates to allow for a
growing number of off-line transactions and potentially big-
ger settlement files and frequent application downloads. A
modem supporting speeds of at least 2400 baud is the
minimum acceptable; 9600 baud is the suggested recom-
mendation.
2.1.6 Cardholder Interface Unit

The cardholder interface unit on a card acceptance device
provides a mechanism for cardholder input, such as PIN en-
try or cardholder application selection. The most common
types of interface units are keypads and PIN pads.
Cardholder payment devices that incorporate interface units

that enable cardholders to retain their cards while inputting
information are becoming more popular. In markets or
countries where the cardholders are able to retain posses-
sion of their card during the payment transaction, the card
reader should placed or mounted to facilitate ease of use by
the cardholder.
Visa Public
2.1.6.1 Keypad
A card acceptance device should have a keypad to enter
data, select commands, and perform functions. For
example, entry of transaction amounts may be required. A
touch screen is considered to be a keypad. (An integrated
POS terminal may also share its keypad for entry of the
A keypad used for PIN cardholder’s PIN.)
entry is considered to be
a PIN pad and must
adhere to Visa’s PIN
The keypad should support one or more of the following
Management Require- types of keys:
ments.
Numeric: 0 – 9
Alphabetic and special: A - Z, *, #, etc.
Command: ENTER, CANCEL, and CLEAR.
If colored keys are used for these command keys, the
following colors should be used:
− ENTER: Green
− CANCEL: Red
− CLEAR: Yellow
The EMV Level 2 requirements state that the above col-

ors, if used, shall be reserved for the command keys, ei-
ther for the lettering or for the keys themselves. If a ven-
dor submits the device for testing with non-colored keys
(that is, not green, red or yellow), this color test will not
be performed. A vendor can submit a device to EMVCo
with non-colored keys and then for production, make mi-
nor color changes to the keys as appropriate to the tar-
get market.
Function: Application-dependent keys, such as F1, F2,

BACKSPACE, and ESCAPE.
2.1.6.2 PIN Pad

The PIN pad is used for the entry of a cardholder’s PIN in
completing certain payment and financial transactions. The
PIN pad can be an external unit, attached to a port of a card
acceptance device (usually via a tethered cable), or can be
integrated into an acceptance device – sharing the latter’s
keypad for both PIN and non-PIN data entry. All card accep-
tance devices should be PIN capable that, at minimum, has
a port available to support the use of an external PIN pad, or
the PIN entry functionality built into the device.
The PIN pad must include numeric keys as well as ENTER

and CANCEL command keys. A CLEAR key is optional.
Visa Public
The numeric layout must comply with ISO 9564-1 (Personal

Identification Number Management and Security); however,
mapping of alpha characters onto the numeric layout is not
required.
The key for the number “5” should have a tactile identifier
(for example, a notch or raised dot) to indicate to the sight
impaired that this is the central key from which all others
may be deduced.
For more information on PED The PIN entry device (PED) supporting Visa card with PIN
security requirements, see entry must comply with Visa’s PED security.
Section 2.2, “Security Charac-
teristics.” If the PIN entry function is implemented on a touch screen
display, it must still meet the Visa PED security require-
ments.
2.1.7 Clock
Card acceptance devices that can process offline transac-
tions must have a clock with the local date and time. The
time should be accurate to within one minute per month.
The date is used for checking certificate expiration dates for

For more information on SDA,
see Section 2.3.3, “Applica- Static Data Authentication (SDA), Dynamic Data Authentica-
tion-Processing Initiation and tion (DDA), and application effective and expiration dates.
Data Read.” The date is input to the application cryptogram algorithm
and may be used to assure transaction identification
uniqueness.
Visa Public
2.2 Security Characteristics
Security characteristics for VSDC devices include require-

ments for handling sensitive data such as a Cardholder’s
PIN. They also include PIN pad requirements and key man-
agement requirements for both the secret keys for a sym-
metric algorithm and the public key for an asymmetric algo-
rithm.
This section provides an overview of PIN pad and key man-

agement security characteristics.
For complete security characteristics and requirements, see

the PIN Management Requirements. This document con-
tains two parts: Visa PIN Security Requirements manual and
Visa PIN Entry Device Security Requirements manual. The
PIN Security Requirements may be obtained by contacting
your Visa regional representative. The PIN Entry Device
Security Requirements can be downloaded via the Visa PIN
website at www.visa.com/pin.
2.2.1 PIN Pad

The PIN pad used for offline PIN entry must be, at minimum,
a tamper-evident device, and for online PIN entry must be
tamper resistant/responsive. A PIN pad that can support
both offline and online PIN entry must meet the higher secu-
Tamper-evident provides
rity characteristics of an online PIN entry device – tamper
a lower level of security resistant/responsive. In general, PIN pads must be de-
protection required than signed and constructed with the following characteristics:
by tamper-resistant or
tamper-responsive, with The PIN pads must generate the prompt for PIN entry
the latter providing the
highest protection. messages displayed on the PIN pad. The PIN pad must
reject any unauthorized message display.
If a keypad is being also shared for PIN entry, as in an
integrated POS device, the payment amount entry proc-
For information on PED secu-
rity requirements, see Section ess must be separate from the PIN entry process so as
5.1.3, “PIN Entry Device Re- to avoid accidental showing of the PIN on the device’s
quirements.” display. The cardholder should validate the transaction
amount before PIN entry is allowed.
The PIN pad must provide privacy and confidentiality so
that, during normal use, only the cardholder sees the ac-
tual entry on the PIN on the keypad. The values of the
entered PIN must not be displayed or disclosed by visi-
ble or audible feedback means.
The PIN pad must automatically clear its internal buffers
upon completion of a transaction or in a time-out situa-
tion (including when a pre-defined period of time has
elapsed since a PIN character was entered).
Visa Public
2.2.1.1 Offline PIN

When a card acceptance device supports offline PIN verifi-
cation, the device and the PIN pad are either integrated into
a single device or are configured as two separate devices,
e.g., using an external PIN pad. In addition, depending on
the device’s design, the PIN entered may either travel di-
rectly from the PIN pad to the chip reader within a secure
environment, which is the preferred design, or travel indi-
rectly (via a tethered cable or some distance is involved) to
the chip reader.
If the design of the termi-
nal requires that parts of When the PIN travels directly from the PIN pad to the
the device be physically chip reader, then the PIN pad does not have to encipher
separated, i.e., the PIN the offline PIN at the point of entry.
pad is not integrated into
the terminal, and any
cardholder instructions − Plaintext Offline PIN
and/or processing data The chip reader sends the PIN to the chip as plain-
passes between the text.
separate parts, there
must be an equal level of
protection between the − Enciphered Offline PIN
different parts that make Either the secure component in the terminal,
up the terminal. (e.g., chip reader) or the PIN pad itself will encipher
the PIN using an (authenticated) encipherment Pub-
lic key from the chip. The enciphered PIN will then
be sent to the chip, where the PIN will be deciphered
using the Private key from the chip.
When the PIN travels indirectly from the PIN pad to the
chip reader (e.g., via a tethered cable or a “lengthy”
travel path), the PIN pad must immediately encipher the
offline PIN at the point-of-entry, in accordance to
ISO 9564, including the degree of proper tamper protec-
tion for the acceptance device(s), before sending the
PIN to the chip reader (in order to protect the PIN during
transport).
− Plaintext Offline PIN

The chip reader will decipher the enciphered PIN
and send the PIN to the chip as plaintext.
− Enciphered Offline PIN

The chip reader may then need to decipher the enci-
phered PIN; and re-encipher the PIN using an au-
thenticated encipherment Public key from the chip.
The enciphered PIN will then be sent to the chip
where the PIN will be deciphered using the Private
key from the chip.
Visa Public
2.2.1.2 Online PIN

Without exception, if the card acceptance device supports
online PIN verification, then the online PIN must be pro-
tected immediately upon entry by encipherment, in accor-
dance to ISO 9564, including the degree of proper tamper
protection for the device(s). The card acceptance device
then transmits the encrypted PIN according to Visa ‘s pay-
ment system rules.
Card acceptance devices that support PIN entry should ad-

here to the following design practices:
The cardholder should perform the card insertion.

The card insertion slot should be minimal in size and be
in full view of the cardholder.
The internal path from the buttons pressed to the chip
card should be free of points where it is easy to tap into
the circuitry to determine the PIN.
Any tampering with the card acceptance device should
stop the device from working.
2.2.2 Key Management

Key management plays an essential role in integrating the
components of a working security architecture. It provides
critical security support for card life cycle and transaction
processing to ensure the integrity of all cryptographic proc-
esses. The security of data is dependent upon the preven-
tion of disclosure and unauthorized modification, substitu-
tion, insertion, or deletion of keys.
2.2.2.1 Visa CA Public Key Distribution

The process for secure distribution of Visa Certificate Au-
thority (CA) public keys is as follows:
Step 1 — Visa CA delivers the Visa CA public keys to

the Regional Visa key representative in a manner that
protects their integrity. The representative must store
keys in a secure manner.
Step 2 — An Acquirer, third-party processor, or vendor
contacts the Regional Visa key representative to request
Visa CA public keys.
Step 3 — Regional Visa key representative sends the
Visa CA public keys to the Acquirer, third-party proces-
sor, or vendor in a secure manner.
Step 4 — For validation, the Acquirer, third-party proc-
essor, or vendor compares the SHA-1 hash calculated
by the terminal from the key received with the appropri-
ate hash published on the Visa website.
Visa Public
Step 5 — The Acquirer, third-party processor, or vendor

delivers valid Visa CA public keys to devices in a man-
ner that protects key integrity.
2.2.2.2 Visa Public Keys

On an annual basis, Visa International Risk Management re-
evaluates the expiration dates of the Visa Certification Au-
thority (CA) Public Keys. Following the review and within 90
days of receipt of EMVCo recommendations, Visa Interna-
tional publishes and makes available to the members the
Visa policy details including key lengths, exponent values,
expiration dates and planned revocation schedule.
In line with EMV Public Key Revocation Principles and Poli-

cies, a six-month grace period is given to acquirers to com-
plete the removal of expired Visa CA keys from terminals,
following the Visa CA Public Key expiration date.
Refer to the document Principles for Deploying Visa CA

Public Keys to Deployed Terminal Base Version 1.0, dated
June 2002 for more details.
2.2.2.3 Asymmetric Key Management

The card acceptance device must have the capability to en-
able the secure load, update, and maintenance of the Visa
public keys.
The card acceptance device must be able to select the cor-

responding key and algorithm in conjunction with the regis-
tered application provider identifier of the selected applica-
tion.
2.2.2.4 Symmetric Key Management

A card acceptance device performing PIN encipherment
must support key management techniques for symmetric
key algorithms as described in ISO 11568-2 (Banking Key
Management – Retail) and ISO 9654 (. The secret keys of a
symmetric key algorithm must be protected from disclosure
and must be unique.
Visa supports the following key management techniques:
Derived Unique Key Per Transaction (DUKPT)

Master Key / Session Key (MK/SK)
Fixed Key
Visa Public
2.3 VSDC Transaction Processing
To complete a VSDC transaction, a chip card and a pay-

ment device engage in a series of processing steps, which
include:
1. Card Insertion
2. Application Selection
3. Application Processing Initiation and Data Read
4. Processing Restrictions
5. Offline Data Authentication
6. Cardholder Verification
7. Terminal Risk Management
8. Terminal Analysis
9. Card Action Analysis
10. Online Authorization
11. Completion
12. Issuer-to-Card Script Processing
These steps and the Visa best practices associated with

them are discussed in the following sections. While the fo-
cus here is primarily on VSDC chip-card transactions, infor-
mation on magnetic-stripe processing is included as appro-
priate.
2.3.1 Card Insertion

A card acceptance device must:
Provide the capability to accept a chip card through one

of the following methods: Should have names that are
globally used. Examples include:
− “Swipe-and-park”
− Dip (and leave-in)
− Insertion (for motorized readers)
The cardholder or attendant may be required to interact with

the device before it can accept the card. For example, the
cardholder may be required to press a function key to select
the application or the card type.
Establish contact by activating the chip and reading the

available applications.
Visa Public
Whenever a card is presented, the card acceptance device

should always check for the presence of a chip first. If the
device is unable to read the chip, or if no chip is present,
then the device should read the magnetic stripe. If neither
the chip nor magnetic stripe can be read, key entry proce-
dures should be used unless disallowed under applicable
card product, Visa regional, or national market rules.
Recognize account numbers up to 19 digits in length.
ATMs accept Visa and Visa Electron cards must be able to

recognize variable length account numbers up to and includ-
ing 19 digits. Visa’s compliance dates are:
January 1, 2005, an Acquirer must ensure that all new

chip-reading devices that accept Visa and Visa Electron
cards support variable length account numbers up to,
and, including 19 digits.
January 1, 2007, an Acquirer must ensure that all chip-
reading devices that accept Visa and Visa Electron
cards support variable length account numbers up to,
and, including 19 digits.
2.3.1.1 Merchant Override of Chip-Read Requirement

A card acceptance device capable of accepting chip-card
transactions must not provide any opportunity for merchants
to avoid processing chip-card transactions, unless the chip
or the device does not work.
Chip devices that accept VSDC cards must not allow the
merchant (or cardholder) to override the requirement for a
chip read by manually prompting a device to read data from
the card’s magnetic stripe. The magnetic stripe must only
be read in the event of the chip or chip reader being inoper-
able.
An Acquirer or merchant may install a VSDC chip-reading

device before the Visa Member or merchant is actually ca-
pable or ready to accept VSDC chip-read transactions. In
such situations, the override prohibition should not be acti-
vated until the Acquirer and merchant are ready to accept
chip transactions.
Visa Public
2.3.1.2 Fallback Acceptance for VSDC Chip-Read Fail-

ures
Chip devices that accept VSDC cards must contain logic
that allows for fallback to magnetic stripe-read or key entry
(and online authorization) when a chip card-read has been
unsuccessful. (In the event that online authorization
capability is not available, the merchant may be given the
option to perform voice authorization to complete the
transaction.) Specifically, a fallback to magnetic stripe or
beyond should be allowed if any of the following are
inoperable:
The chip
The chip-card reader
The chip (VSDC) application
The magnetic-stripe fallback is determined by regional re-
quirements. Specifically, individual Visa Members, coun-
tries, or merchants may determine the number of unsuc-
cessful chip-card reads a device may make before falling
back to magnetic stripe.
Other scenarios in which a fallback to magnetic stripe may

occur include:
Non-Matching Application Identifier (AID)

When a chip card is inserted into a device’s chip-card
reader, the terminal checks to see if it supports the AID
loaded on the card. If it does, the transaction is proc-
essed as a chip transaction. If no match is found be-
tween the card and the device, the device should prompt
the merchant to fall back to magnetic stripe and process
the transaction as a magnetic-stripe transaction, ignoring
the chip designation in the service code.
Any nonstandard response, such as to a “GET PROC-

ESSING OPTIONS” command
An Acquirer or merchant may install a VSDC chip-
reading device before the Visa Member or merchant is
actually capable or ready to accept VSDC chip-read
transactions. In such situations, the fallback requirement
should not be activated until the Acquirer and merchant
are ready to accept chip transactions.
2.3.1.3 Application Identifier

The Application Identifier (AID) consists of two components:
Registered Application Identifier (RID)—This component

represents the payment scheme. Visa’s RID is
A000000003.
Visa Public
Proprietary Application Identifier Extension (PIX)—This

component represents the application. The Visa PIXs
are:
− Visa (e.g., Visa Credit or Visa Debit) – 1010
− Visa Electron - 2010
− Plus - 8010
Where a chip card contains more than one application with

the same AID, an additional suffix is used; for example, a
card that supports both Visa Credit and Visa Debit may con-
tain the following two AIDs:
A000000003 1010 01 – first Visa application

A000000003 1010 02 – second Visa application
2.3.2 Application Selection

When a VSDC card is presented to a card acceptance de-
vice, the device determines which payment applications
both it and the card support by determining the common
Application Identifiers (AIDs). Application selection may oc-
cur in one of two ways:
1. The device displays all mutually supported applications

to the cardholder, who then selects the application to be
used for payment. This feature is called ‘Cardholder
Application Selection’, or CAS, and is described in more
detail in Section 2.3.2.1.
2. If the device does not support CAS, the device selects
the highest-priority application as designated by the Is-
suer during card personalization that can be selected
without cardholder confirmation. If all the mutually sup-
ported applications require cardholder confirmation,
none of them can be selected to perform the transaction.
If no application can be selected, the device should display

a message such as “Not Accepted” and terminate the trans-
action.
If the Application Label (or Application Preferred Name) is

not displayed to the cardholder during application selection,
it is recommended that it be displayed in an informative
message but not require cardholder confirmation. (For ex-
ample, the application name could be included in an amount
confirmation message.)
A device capable of accepting VSDC transactions must:
Contain appropriate AIDs to support VSDC products.
Visa Public
As common practice, many Visa merchants with online

capability accept Visa Electron without displaying spe-
cific signage. Therefore, all POS chip card devices that
contain the Visa AID must also contain the Visa Electron
AID, unless a merchant specifically excludes this appli-
cation. All Visa ATMs must contain the Visa Electron
AID.
Visa has made available a Plus AID to facilitate accep-

tance of Plus in ATMs that accept chip cards. This AID
ensures Plus acceptance for ATMs and cards that do not
contain a Visa AID.
ATMs with Plus mark acceptance must support the Plus

AID. Plus ATMs must be able to recognize the Plus AID
and route Plus chip transactions the same as magnetic-
stripe Plus transactions.
Facilitate access to all appropriate applications that are

provided on the card’s chip and are supported by the
device.
A device should not discriminate in favor of one or an-
other of the available options, except as stipulated by the
cardholder or by Issuer-specified chip parameters. How-
ever, as allowed by EMV, the device may know other
ways that are not described in the EMV specifications to
locate proprietary applications or to eliminate specific ap-
plications in the chip from consideration. This is permit-
ted as long as al interoperable applications can be located
in the chip using the techniques described in the specifica-
tions.
2.3.2.1 Cardholder Application Selection

Visa recommends that devices support Cardholder Applica-
tion Selection (CAS), which allows cardholders to select or
confirm their preferred application for that transaction.
A device that supports CAS may use a menu to display all

available applications to the cardholder and prompts the
cardholder to select one. If, for some reason, the transac-
tion cannot be performed with the application the cardholder
has selected, the device should display a message such as
“Try Again” and re-list the remaining mutually supported ap-
plications.
Visa Public
Alternatively, a device that supports CAS may display a

single application name, which is then either accepted by
the cardholder or rejected. If rejected, the terminal then dis-
plays the next application name, continuing through the list
of common applications until the cardholder has selected
one or rejected all of them. This method is sometimes re-
ferred to as “Cardholder Confirmation,” although this term is
not recognized by the EMV and VIS specifications.
The card application requirement for ‘confirmation required’

in the Application Priority Indicator can be satisfied by either
of the above methods.
Where only one application is held in common between the

terminal and card, and that application does not require
cardholder confirmation, the device automatically selects
that application. The terminal must not override any applica-
tion selection that the cardholder has chosen.
2.3.2.2 Application Label and Application Preferred

Name
The device should always print the Application Label (or Ap-
plication Preferred Name) on the receipt.
The formats of the Application Label and Application Pre-

ferred Name have been changed to allow spaces in these
data elements, which identify the application to the card-
holder during application selection. This change supports
Issuers who issue cards with application names that include
spaces and devices must not reject cards with spaces in
these data elements.
For more information on these format changes, see Change

to format specification for the Application Label and Appli-
cation Preferred Name (EMVCo Specifications Update Bul-
letin #14).
2.3.3 Application-Processing Initiation and Data Read

When a VSDC application is selected, the device requests
that the card indicate the data to be used for that application
and the functions supported. The device reads the data and
uses the supported-function list in the Application Inter-
change Profile to determine whether to perform the following
functions:
Offline data authentication

Cardholder verification (cards should always support this
function)
Terminal risk management (cards should always support
this function)
Issuer authentication
Visa Public
If the tag of any data object identified in the Data Object

Lists is unknown to the terminal, the terminal shall provide a
data element with the length specified and a value of all
hexadecimal zeroes.
2.3.4 Processing Restrictions

The device must perform the Processing Restrictions check,
based on data provided by the chip, to determine whether
the transaction should be allowed.
To comply with Visa requirements and best practices for this

step, the device must:
Check whether the effective date, if present, or expira-

tion date for the card has been reached
Check whether the application version on the card
matches its own version of the application
When new chip programs are implemented, they may
have different application version numbers than existing
programs. Whenever device software is upgraded, the
application version number should be checked to ensure
it matches the upgrade number. A mismatch may cause
an increased number of declines or, if supported, trans-
actions being sent online for authorization.
Check whether any Application Usage Control restric-

tions are in effect
An Issuer may set these controls to limit a card’s use to
certain kinds of transactions, for example, domestic or
international, cash, goods or services, or cash-back.
− Allow a purchase transaction only if both goods and

services are allowed in the Application Usage Con-
trol.
The device checks the Application Usage Control (2-
byte field) received from the card to see if the trans-
action type (the first two digits of the ISO 8583-1987
Processing Code) is allowed. The transaction type
classifies goods and services as one type. However,
in the Application Usage Control, goods and services
are separated.
2.3.5 Offline Data Authentication

The processes used for offline authentication include:
Static Data Authentication (SDA) — A counterfeit-

protection method that ensures that a set of static data
has not been modified since initial personalization onto
the card. SDA support is required for all chip-card ac-
ceptance devices, with the exception of online-only de-
vices such as ATMs.
Visa Public
Dynamic Data Authentication (DDA) — Offers an even

higher level of data validation than SDA, providing pro-
tection against both skimming and counterfeiting. Sup-
port for DDA is required in some regions. DDA support
is not required for ATMs and online-only devices. Visa’s
compliance dates are:
− January 1, 2003, an Acquirer must ensure that DDA
is active in all new or recycled chip reading devices
that accept Visa and Visa Electron cards, unless the
device obtains an online authorization for all transac-
tions
− January 1, 2005, an Acquirer must ensure that DDA
is active in all chip reading devices that accept Visa
and Visa Electron cards, unless the device obtains
an online authorization for all transactions
Combined DDA/ Generate Application Cryptogram

(AC) (CDA) — Combines DDA with the generation of a
card’s application cryptogram to assure card validity.
CDA is referred to as Com- Support of CDA in acceptance devices may be needed,
bined DDA/Generate AC in as this process has been implemented in specific mar-
the VIS specifications. kets.
2.3.6 Cardholder Verification

Cardholder verification ensures that the cardholder is legiti-
mate and that the card is not lost, stolen, or misused by an
unauthorized person. The device uses a cardholder
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 to
be used relative to the capabilities of the device and
characteristics of the transaction.
The CVMs that may be supported by the device are:
Signature
Offline plaintext PIN
Offline enciphered PIN
Offline plaintext PIN and signature
Offline enciphered PIN and signature
Online PIN
No CVM Required
Requirements and best practices for this step include the
following:
For information on PED secu-

rity requirements, see Section
5.1.3, “PIN Entry Device Re-
quirements.”
Visa Public
2.3.6.1 PIN Security

The device must ensure security of a cardholder’s PIN from
the keypad to transmission to the Acquirer. Acquirers who
deploy PEDs for Visa card acceptance using a PIN must
comply with the PIN Management Requirements as docu-
mented in Visa’s PIN Security Requirements and PIN Entry
Device Security Requirements manuals.
Individual Visa regions and countries may have additional

requirements for PEDs. For additional information on re-
quirements in your local market, contact the appropriate Ac-
quirer or Visa regional office. Additional information can be
accessed from the Visa PIN website.
2.3.6.2 PIN Pad Support

January 1, 2005, the device must be capable of accepting a
PIN, with offline (either plaintext, enciphered, or both) PIN
as the minimum requirement, for verification of Visa chip-
card transactions.
ATMs must comply with Visa’s PIN requirements for chip devices include:
Visa’s PIN security require-
ments. Chip devices must have a PIN pad present, or at a mini-
mum, must be equipped with a port that can support a PIN
pad.
If a PIN pad is present and active, the device must:
Apply encryption to Visa requirements

Act on the cardholder verification method (CVM) list
If the PIN pad port only (for example, RS 232) or PIN pad is
inactive for Visa, the device must be capable of supporting
software to provide the above-stated functions.
If the PIN pad is active for other chip-enabled payments, it

must be active for Visa.
Exceptions to the above requirements are:
When cardholder interaction is inherently impractical, such

as road tolls and transit applications.
Where cardholders traditionally do not expect interaction

with the device, such as at a fine dining establishment.
Visa Public
2.3.6.3 Offline PIN Verification

Offline PIN is available to Issuers in one of two versions:
plaintext (unencrypted) or enciphered (encrypted).
In an offline PIN verification, a cardholder-entered PIN is

compared to a reference PIN stored in a secure location on
the card’s chip, which then returns a pass or fail indicator to
the device. This indicator is one of many used to determine
whether the transaction can be approved or declined offline,
or must be sent online for authorization.
All chip-reading devices placed in service on or after

April 1, 2001 that support offline enciphered PIN must also
support offline plaintext PIN.
It is strongly recommended that all devices other than ATMs

support both plaintext and enciphered offline PIN. ATMs
may need to support offline PIN as dictated by local market
requirements for non-Visa transactions.
2.3.6.4 CVM Defaults or Device Requirements

Card acceptance devices need to support an appropriate
minimum level of cardholder verification whether or not the
chip card used in a specific transaction supports a CVM list.
Cards and devices may agree on a higher level of CVM.
However, Visa rules concerning the level of cardholder veri-
fication required for certain types of transactions (e.g., man-
ual cash, quasi-cash) apply regardless of whether the trans-
action is initiated from a chip or magnetic stripe.
A VSDC transaction may not request CVM processing or

may not request a CVM if:
1. The VSDC card has been incorrectly coded (a very in-

frequent occurrence) so that the CVM bit in the applica-
tion interchange profile (AIP) is set to “0.”
2. CVM processing between a VSDC card and a chip-
reading device defaults to “No CVM required” because,
for example, no other CVM options are matched.
In these situations, a device should use the default CVM for

its given market. The default CVM is the minimum CVM re-
quired for a device to support.
Attended Chip POS Devices in Merchant Locations
Visa CVM requirements for these devices are as follows:
Must at a minimum support

− Signature verification
May optionally support
Visa Public
− Online PIN
− Offline plaintext PIN
− Offline plaintext and enciphered PIN
− No CVM required
− Combination CVMs (e.g., signature and offline PIN)
Must not support

− None identified at this time.
2.3.6.5 ATMs
Visa CVM requirements for these devices are as follows:

− Online PIN
Must not support

− No CVM required
For information on the differ- 2.3.6.6 Unattended Acceptance Devices

ent types of unattended de-
vices, see Section 5.2, “Unat- Visa CVM requirements for these devices are as follows:
tended Devices.”
Please note that a device could support type A, B, and C
transactions. Therefore, you cannot say that a device that
supports type A transactions cannot support online PIN, or
that a device that supports type C transactions cannot sup-
port ‘No CVM’.
Devices Supporting Type A and B Transactions

− No CVM required
Must not support

Devices Supporting Type C Transactions
Must at minimum support

− Online PIN
May optionally support

− Offline plaintext PIN
− Offline enciphered PIN
Visa Public
Must not support

2.3.7 CVM Considerations for Early Markets

Devices in Early Option markets may not retain data ele-
ments, such as the Terminal Verification Results and Card
Verification Results, which contain the results of offline PIN
processing and may be needed as proof that the offline PIN
was entered and verified. Device vendors should consider
how the merchant would be protected against potential
charge-backs in these situations. Either some means of re-
taining these critical data elements must be implemented or
the terminal should also request the minimum CVM required
in the market to protect the merchant, such as signature.
2.3.8 Terminal Risk Management

Terminal Risk Management (TRM) is a key component of
EMV processing. During normal processing, the terminal,
prior to any authorization decision being passed to the card,
determines the first two risk management checks that a
transaction will pass through. These two checks, both man-
datory, are:
Terminal Floor Limits

Random Transaction Selection
Terminal Risk Management (TRM) allows the device to

check a number of factors associated with transaction risk,
including:
Device account-exception list (if one exists)

Limit for consecutive offline transactions (velocity check-
ing)
New-card status
Merchant-forced online transaction
Merchant floor limits
Visa Public
Floor limits are transaction amounts above which an online

authorization should be performed. They are specified by
Acquirers, based on merchant type and Visa rules. VIS
mandates that offline-capable terminals perform floor-limit
checking on all transactions. Note that if the card parame-
ters indicate that the transaction must be processed online,
it will be sent online regardless of the floor limit, and the
transaction may be declined if it cannot obtain an online au-
thorization. Magnetic-stripe-transaction floor limit is not ap-
plicable for fallback transactions with chip cards at chip ter-
minals, as all fallback transactions need to go online, or to
be terminated if unable to go online.
Regions may implement different floor limits for chip and

For more information on floor magnetic-stripe transactions. Devices should be capable of
limits, see Section 2.7.5,
“Floor Limits.” supporting both.
Random selection of transactions for online processing must

be supported. This functionality protects against fraudulent
cards designed to operate exclusively offline.
Visa requires that all chip-reading devices capable of per-

forming online authorization perform a TRM (terminal risk
management) analysis for VSDC transactions regardless of
the TRM setting in the card's AIP (application interchange
profile).
2.3.9 Terminal Action Analysis

The device uses the results of previous processing steps
and the rules set in itself and the card to determine whether
a transaction should be approved offline, sent for online au-
thorization, or declined offline. After determining transaction
disposition, the device requests an application cryptogram
from the card, corresponding to the transaction disposition:
Transaction Certificate (TC): Offline approval

Authorization Request Cryptogram (ARQC): Online au-
thorization
Application Authentication Cryptogram (AAC): Offline
decline
2.3.9.1 Terminal Action Code - Denial

The Terminal Action Code (TAC) – Denial shall contain a
value of hex ’0010000000’, which causes a decline for the
Service Not Allowed condition. Early Data Option terminals
shall set TAC-Denial to a value of X’0810000000’, which
causes a decline if DDA fails.
Visa Public
2.3.9.2 Terminal Action Code - Online

The TAC – Online shall contain a value of hex
’D84004F800’. This generates an online authorization
when:
Offline data authentication is not performed

Offline static data authentication failed
The PAN is on the terminal exception file
Offline dynamic data authentication failed
The application has expired
An online PIN is entered
The transaction value exceeds the floor limit
Lower consecutive offline limit (‘9F14’) is exceeded
Upper consecutive offline limit (‘9F23’) is exceeded
The transaction is randomly selected for online process-
ing
The merchant forced the transaction online
2.3.9.3 Terminal Action Code - Default

The TAC – Default shall contain a value of hex
’D84000A800’. This generates a decline if the transaction
cannot be sent online for authorization when:
Offline data authentication is not performed

The PAN is on the terminal exception file
The application has expired
The transaction exceeds the floor limit
Upper consecutive offline limit (‘9F23’) is exceeded
The merchant forced the transaction online
2.3.10 Card Action Analysis

After receiving an application cryptogram request, the card
performs a series of risk management checks to determine
whether to change the transaction disposition sent by the
device. The card may convert a request for offline approval
to a request for online authorization or offline decline. It can
also change an online request to an offline decline.
If the device requests an AAC in the first cryptogram request

and the card converts the request to either an ARQC or TC
or if the device requests an ARQC and the card converts the
request to a TC, the device must terminate the transaction.
(If the device requests an AAC in the second cryptogram re-
quest and the card converts the request to a TC, the device
shall consider that the card responded with an AAC.)
Visa Public
2.3.11 Online Authorization

All card acceptance devices should be capable of obtaining
an online authorization from the card Issuer or a third party
designated by the Issuer.
2.3.11.1 Cash-Back Identification

If a purchase transaction includes cash-back, the cash-back
amount must be uniquely identified in the authorization and
clearing messages.
Authorization Response Cryptogram Consideration

In some markets, an Authorization Response Cryptogram
(ARPC) may accompany an authorization response to allow
validation of the Issuer by the card. If the ARPC fails valida-
tion, and the card declines the transaction, market factors
may require the terminal to generate a reversal.
2.3.12 Completion
The card and device perform final processing to complete
the transaction.
If the device requests an AAC in the second cryptogram re-

quest and the card converts the request to a TC, the device
shall consider that the card responded with an AAC.
A device capable of accepting VSDC transactions must:
Provide the capability to enter additional transaction data

as specified in the appropriate Visa product or process-
ing rules, via manual entry if need.
For information on Commer- Devices must be able to recognize Commercial card
cial cards, see Section 2.4, products and capture new incremental data elements for
“Commercial Cards.” these transactions.
Support electronic transmission of financial messages to
the Acquirer for clearing.
Optionally provide support for refunds, reversals, and
pre-authorization) and post-authorization transactions,
For information on transaction as needed (e.g., for automated fuel dispensers).
types, see Section 5.4,
“Transaction Types.” Provide the capability to receive parameter updates
electronically, including public-key parameters for all
published key lengths.
As a best practice, a device capable of accepting VSDC
transactions should also:
Provide the capability to produce a transaction receipt.

Regional requirements may apply regarding the need for
a receipt (printed or hand-written), as well as the specific
data printed on the receipt. Some examples include:
Visa Public
− Truncated card number

− Deletion of signature line (if PIN is used)
− Application Label or Application Preferred Name
Optionally provide the capability to capture data obtained

through a voice authorization at attended POS devices
Although most authorizations occur electronically, occasion-

ally merchants need to authorize transactions over the tele-
phone as a result of Issuer referrals, network problems, or
system outages. Card acceptance devices should provide
the capability to enter an authorization number (e.g., via a
keypad) and add it to the electronic capture file for later
posting.
Generate the appropriate Authorization Response

Codes for transactions that are processed offline, as
listed in Table 2-1.
TABLE 2-1: AUTHORIZATION RESPONSE CODES

Authorization
Response Code Transaction Disposition
Y1 Offline approved
Y3 Unable to go online (offline approved)
Z1 Offline declined
Z3 Unable to go online (offline declined)
2.3.13 Issuer-to-Card Script Processing

The device must be capable of receiving Issuer scripts in the
authorization response message and passing Issuer script
commands to the card.
Post-issuance script updates can only be processed if both

the Issuer and Acquirer support full chip data.
2.3.14 Additional Functions

The processing of VSDC transactions may also require
additional functionalities.
To ensure Visa compliance with these requirements, the de-

vice should:
Provide fast, efficient processing of chip-card transac-

tions. As a best practice, the application transaction
time for VSDC cards should not exceed the time for the
same type of transaction performed online with mag-
netic-stripe cards. Targeted transaction times for differ-
ent national markets may vary.
Visa Public
Enable a cardholder or sales associate to cancel a

transaction in progress at any time
If required by national market rules, the device may need
to provide the capability of generating a receipt for a
canceled transaction.
Be able to generate standard reports, including detailed

and summary transaction logs, and detailed reports by
card type and application type
Allow merchants to balance batches, whether captured
in the device or in the host system
Ensure the card acceptance device (or the merchant-
level controller or host system) is programmable and ca-
pable of verifying and accepting software changes to
add functionality.
Support the changes for backward compatibility as
stated in the current EMV and VIS specifications. It
means that careful attention should be placed to any
backwards compatibility items noted in VIS and EMV.
2.3.14.1 Multiple Language and Currency Support

The following optional functionalities are recommended for
markets in which multiple language and currency capabili-
ties can help merchants improve customer service and prof-
itability.
These best practices include:
Support for multiple languages and multiple character

sets at the point of transaction’s display, e.g., for PIN en-
try or cardholder application selection
A VSDC card may contain more than one cardholder
language option. Depending on the market, card accep-
tance devices may need to be capable of recognizing
and communicating in multiple languages. Support for
multiple languages and character is recommended as a
best practice for all devices.
Support for multiple currencies.

In some markets merchants may process transactions in
more than one currency.
2.3.14.2 AID and TVR on Receipt

It is recommended that the application (AID) selected and
the Terminal Verification Results (TVR) be printed on the
merchant receipt. These fields will aid in any merchant help
desk analysis.
Visa Public
It is also recommended that the application (AID) selected

be printed on the cardholder receipt to assist the cardholder
should the cardholder contact the Issuer. The Application
Preferred Name or Application Label may also be useful to
the cardholder.
2.3.14.3 Application Performance Considerations

A VSDC device must provide fast, efficient processing of
chip-card transactions. Much can be won in transaction
time by optimizing the software in the terminal.
As a best practice, the application transaction time for VSDC

cards should not exceed the time for the same type of
transaction performed online with magnetic-stripe cards.
Targeted transaction times for different national markets
may vary.
Much of the communication between terminal and chip card

can already take place while waiting for a manual action
from either cardholder or merchant. Examples include:
Initiate a transaction at the moment the card is inserted

in the terminal
Prompt for the PIN-code before the transaction amount
is known
Switch the power off after completion of the transaction
instead of waiting on the receipt to be printed, so the
cardholder can take out his card while the receipt is be-
ing printed
Process the steps ‘Offline Data Authentication’, ‘Proc-
essing Restrictions’, ‘Cardholder Verification’ and ‘Ter-
minal Risk Management.’
2.3.14.4 Device Error Messages

The purpose of displaying device messages is to communi-
cate to a clerk or cardholder the status of a transaction and
to instruct them on what action to take. To help define clear
and effective error messages for EMV devices, it is impor-
tant that device vendors follow a few basic principles listed
below:
The error message displayed must clearly indicate what

is happening with the transaction.
The status of transactions essentially falls into four cate-
gories: 1) the transaction is approved; 2) the transaction
is declined; 3) the transaction is referred; or 4) the trans-
action experienced an error.
The error message displayed must clearly instruct a
clerk or cardholder on what action to take.
Visa Public
Once the status of the transaction is determined, the de-

vice must be able to communicate the next action. Par-
ticularly, when the transaction experienced an error.
Error messages for chip transactions should be closely
aligned with messages for magnetic stripe transactions.
However, maintaining clarity in the status and instruc-
tional messages displayed is of paramount importance.
Messages for magnetic stripe transactions should be
upgraded if they do not already meet these principles.
These fundamental principles will help guide networks and

device vendors to maintain clarity in their device error mes-
sages, even through language translation and as limited by
message length constraints.
Visa Public
Below is a list of transaction scenarios and their EMV stan-

dard messages that devices are required to display (or their
equivalent meaning). Also included, are Visa recommenda-
tions on how messages should be displayed based on the
principles mentioned above.
EMV Required Visa Recommended Message

Scenario Message
1. Device having problem with data on CARD ERROR CHIP ERROR, USE MAG
the chip when fallback is supported STRIPE
2. Device having problem with data on CHIP ERROR; CARD TYPE
the chip when fallback is not sup- NOT SUPPORTED
ported
3. EMV card inserted into CHIP ERROR; USE MAG
non-EMV device (e.g., chip phone STRIPE
card) when fallback is supported
4. Device with chip functionality not acti- CHIP ERROR; USE MAG
vated. Device has separate readers STRIPE
for chip and magnetic stripe.
5. Device not able to accept the card NOT ACCEPTED CARD TYPE NOT SUP-
because of no match on the AID PORTED, USE MAG STRIPE
6. Device prompting for cardholder appli- SELECT ACCOUNT TO BE
cation selection/cardholder confirma- USED
tion
or
USE xxxxxxxx? YES/NO?
(Where “xxxxxxxx” is the Applica-

tion Label/Application Preferred
Name)
7. Device that does not support card- CARD TYPE NOT SUPPORTED
holder confirmation with a chip card
that has a single application that re-
quires cardholder confirmation
8. Device prompting for clerk or card- ENTER AMOUNT ENTER AMOUNT
holder to enter amount
9. Device prompting for cardholder to ENTER PIN ENTER PIN;
enter PIN as well as PIN entry error INCORRECT PIN, RE-ENTER
PIN
10. Device where PIN try limit is exceeded INCORRECT PIN; PIN TRY LIM-
ITED EXCEEDED; DECLINED
11. Device where PIN Pad is detached PROCESSING ERROR; PIN PAD IN-
ERROR OPERATIVE
12. Declines DECLINED DECLINED
13. Approvals APPROVED APPROVED
14. Merchant or cardholder removing card PROCESSING CARD REMOVED TOO SOON;
before a transaction is completed ERROR TRY AGAIN
(Do not remove chip card from

reader during transaction)
15. Referrals CALL YOUR CALL BANK FOR AUTHORIZA-
BANK TION
Visa Public
2.4 Commercial Cards
Visa commercial cards—Visa Corporate, Visa Business,

etc.—are payment cards used by companies for a range of
business-related purchases; for example, office supplies,
travel, and food and entertainment. While fundamentally
similar to consumer payment cards, Commercial cards allow
for the capture of additional, enhanced data for each trans-
action, to help business cardholders track and manage ex-
penses.
The specific types of enhanced data captured may vary by

Commercial card product. Examples include:
Purchase order number or merchant order number

Cardholder reference number or tax identification num-
ber
Tax amount
Purchase line item detail
To support Commercial card transactions, the merchants’

POS system must be able to recognize that a card is a
Commercial card product and obtain and submit the appro-
priate enhanced data. Enhanced data capture and process-
ing may occur in a number of ways, depending on a mer-
chant’s system.
Key entered — If a stand-alone device is used, en-

hanced data may be manually input by merchant staff.
Data extraction — If the POS system is more integrated,
the data may be available for extraction from the mer-
chant host systems or a third-party system used by the
merchant.
Separate process — The enhanced data may be trans-
mitted separately from transaction-processing data.
Detail requirements are made available when a merchant

enrolls for Commercial card acceptance. If a merchant does
not support the enhanced data requirements, Commercial
card transactions are processed the same as consumer
card transactions.
Visa Public
2.5 VLP Feature
The Visa Low-Value Payment (VLP) feature is an extension

of VSDC developed by Visa to allow for the use of payment
cards in traditionally cash-based markets, such as fast-food
restaurants, parking garages, and convenience stores. With
this feature, cardholders have a pre-authorized spending
amount that is reserved for transactions at or below a spe-
cific small-ticket amount determined by the Issuer, for ex-
ample, U.S.$20.
Adding VLP to a2.5.1 VLP Specifications

device can change To support VLP, a card acceptance device must:
its EMV applica-
tion kernel and Be EMV Level 2 approved
result in the need Contain enhancements to VSDC that allow the process-
for EMV Level 2 ing of VLP transactions
retesting. Vendors
Contain the VLP Terminal Support Indicator in its termi-
are responsible for nal data elements
determining
whether VLP func-
tionality will affect
For more information on VLP device specifications, see the

Visa Integrated Circuit Card Terminal Specification (VIS),
version 1.4.0, Appendix D.
2.5.2 VLP Testing

Because VLP is a supplemental extension of an application
unique to Visa, card acceptance devices capable of proc-
essing these transactions must satisfy Visa functional test-
ing requirements. Devices must be submitted for VLP test-
ing to a Visa-recognized laboratory. VLP does not require a
separate Application Identifier (AID).
You may contact any of the Visa-recognized laboratories di-

rectly for information on testing schedules and fees. To ob-
tain a list of Visa-recognized laboratories, visit
www.visa.com/caa.
Visa Public
2.6 Early and Full Data Options
VSDC processing requires host system changes for Issuers

and Acquirers. These changes may be implemented in one
of two ways:
Early Data Option. Issuers or Acquirers make minimal host

system changes when their VSDC programs begin, and mi-
grate to the Full Data Option changes at a later time. The
host system should support new values in existing fields for
authorization and full financial transactions, in addition to
new data in existing Transaction Component Records
(TCRs) for clearing and settlement. Please check with
Visa’s regional office for any information supporting the
Early Data Option.
Full Data Option. Issuers or Acquirers make all of the

needed host system changes to transmit and receive chip
data when their VSDC programs begin. This option may be
mandatory in some Visa regions.
EMV approval requires that all devices produce the manda-

tory chip data elements regardless of whether or not the Full
Data Option is being implemented. Chip data truncation in
an Early Data Option market may occur either in the device,
prior to transmission to the Acquirer, or in the Acquirer host.
For more information on the required data elements, see

Visa Smart Debit and Visa Smart Credit Member Implemen-
tation Guide for Acquirers or contact your Visa regional rep-
resentative.
TABLE 2-2 DATA ELEMENTS FOR EARLY DATA OPTION

VIP Sys-
Name Authorization tem Clearing Base II
POS Entry Mode Mandatory Field 22 Mandatory TCR 0, positions 162-
163
Terminal Entry Capability, and Mandatory Field 60.2 Mandatory TCR 0, position 158
POS Terminal Capabilities
Visa Public
TABLE 2-3 DATA ELEMENTS FOR FULL DATA OPTION

VIP Sys-
Name Authorization tem Clearing Base II
Terminal Capability Profile Mandatory Field 130 Mandatory TCR 7, positions 16-21
Terminal Verification Results Mandatory Field 131 Mandatory TCR 7, positions 69-78
(TVR)
Unpredictable Number Mandatory Field 132 Mandatory TCR 7, positions 33-40
Terminal Serial Number Optional Field 133 Mandatory TCR 7, positions 25-32
Visa Discretionary Data Mandatory Field 134
Derivation Key Index (DKI) Mandatory Field 134.1 Mandatory TCR 7, positions 65-66
Cryptogram Version Number Mandatory Field 134.2 Mandatory TCR 7, positions 67-68
(CVN)
Card Verification Results (CVR) Mandatory Field 134.3 Mandatory TCR 7, positions 79-86
Issuer Discretionary Data Conditional Field 135 Not applica- Not applicable
ble
Cryptogram Mandatory Field 136 Mandatory TCR 7, positions 49-64
Application Transaction Counter Mandatory Field 137 Mandatory TCR 7, 41-44
(ATC)
Application Interchange Profile Mandatory Field 138 Mandatory TCR 7, 45-48
(AIP)
Authorization Response Crypto- Conditional Field 139
gram (ARPC) and ARPC Re-
sponse Code
Authorization Response Crypto- Conditional Field 139.1 Not applica- Not applicable
gram (ARPC) ble
ARPC Response Code Conditional Field 139.2 Not applica- Not applicable
ble
Issuer Script Optional Field 142 Not applica- Not applicable
ble
Issuer Script Results Conditional Field 143 Conditional TCR 7, positions 159-
168
Cryptogram Transaction Type Mandatory Field 144 Mandatory TCR 7, positions 5-6
Terminal Country Code Mandatory Field 145 Mandatory TCR 7, positions 22-24
Terminal Transaction Date Mandatory Field 146 Mandatory TCR 7, positions 10-15
Cryptogram Amount Mandatory Field 147 Mandatory TCR 5, positions 20-31;
or
TCR 7, positions 87-98
Cryptogram Currency Code Mandatory Field 148 Mandatory TCR 5, positions 32-34
Cryptogram Cash-Back Amount Conditional Field 149 Conditional TCR 1, positions 158-
166
Visa Public
2.7 Terminal Management System
According to the EMV specifications and Visa Smart Debit

and Visa Smart Credit Member Implementation Guide for
Acquirers, device terminal management systems needs to
be updated for VSDC and other chip programs. Terminal
management system architecture needs to be sophisticated
and flexible enough so that modifications can be made with-
out requiring large device infrastructure changes. The more
supportive and robust a terminal management system is, the
easier it will be to respond to future market needs, new re-
quirements, and the inevitable change requests.
2.7.1 EMV Functions

Once a device is deployed, Acquirers must not be able to
change EMV functionality by setting or resetting parameters
in non-EMV applications. Most EMV functions are manda-
tory, and any post-deployment change could affect a de-
vice’s interoperability.
The terminal management system of a device must not al-

low deletion of any mandatory function. The system may
control optional functions, provided that a set (EMV-
approved) configuration is loaded into the device.
2.7.2 Data Elements

While a complete terminal management system uses many
data elements, only those that are new for VSDC chip de-
vices are discussed here. As specified in the Visa Smart
Debit and Visa Smart Credit Member Implementation Guide
for Acquirers, the following data elements may require post-
deployment updates:
Visa Certificate Authority (CA) Public Keys

These public keys are used for supporting SDA, DDA,
and enciphered PIN transactions. While key lengths can
be up to 1,984 bits, the currently implemented lengths
can be found on the EMVCo website. Any participating
payment scheme can have six public keys in force at
any time; consequently, terminal management systems
have to have six slots for keys. For each payment
scheme support for all keys and key lengths is also rec-
ommended.
Planned updates and accelerated key revocations re-

For information on public key quire that keys be updated in all devices. Post-
management, see Section
deployment data integrity must be verified. Refer to the
2.2.2, “Key Management.”
Visa Public Key Management Principles for more infor-
mation on updates and management of public keys.
Visa Public
Vendors obtain public keys from Acquirers, who, in turn,

get them from their Visa regional representatives. Visa
public keys can be validated on the Visa International
website, Click here.
Because of the potential for future updates, it is impor-

tant that these data elements be treated as updateable
parameters, and not as a component of the payment ap-
plication.
Visa Terminal Action Codes (TACs)

Used in Terminal Action Analysis, TACs are values de-
fined by Visa and listed in VIS. They indicate the action
the card acceptance device should take, based on ter-
minal verification results.
The terminal management system should be set up to

track TAC settings and update settings through downline
loads, when appropriate. Merchants must not be able to
update TACs.
Application Identifiers (AIDs)

Application identifiers indicate the card applications a
device can support, such as Visa, Visa Electron, Plus, or
a merchant loyalty program. Devices supporting VSDC
must include the Visa Electron AID; they must also sup-
port deactivation of the application for cases where a
merchant does not accept Visa Electron cards.
Random Transaction Selection Parameters

For more information on ran-
dom selection, see Section These parameters target the percentage and threshold
2.7.4, “Random Transaction values used by devices that support both offline and
Selection.” online transactions. They are used in the random selec-
tion of transactions to be sent online for authorization,
independent of transaction characteristics.
All offline-capable terminals must randomly select below-

floor-limit transactions for online processing. The values
used in this selection will be determined per market, bal-
ancing two goals:
− Preventing fraudsters from predicting terminal online

behavior and exploiting the floor limit
− Providing appropriate opportunity for transactions to
be approved offline, dependent on Issuer-determined
card controls.
Processing Restrictions
These data elements are defined in EMV version 3.1.1.
Visa Public
Floor Limits
For information on floor limits, The Acquirer may set floor limits for VSDC chip transac-
see Section 2.7.5, “Floor
tions as well as for magnetic-stripe transactions. How-
Limits.”
ever, the chip card can override an Acquirer set floor
limit.
Early and Full Data Option Parameters

If the Acquirer is implementing the Early Data Option by
truncating the new chip data at the device level, they
may want to consider managing this through a parame-
ter in the terminal management system. During migra-
tion to the Full Data Option, this parameter can be
turned on in order to begin sending full data from the de-
vice to the Acquirer host. This process eliminates the
need to make changes to individual devices or to inter-
mediate merchant host systems when migrating to the
Full Data Option.
A terminal management system may also need to support

other chip-based applications in card acceptance devices, in
addition to VSDC.
2.7.3 Offline Data Authentication

To support offline data authentication, the terminal man-
agement system should:
Download keys to devices prior to and after deployment

Download new keys prior to their effective date
Card acceptance devices
should also be able to Removed expired or revoked keys by expiration date
download software to re-
mote terminals. Notify all deployed terminals when a key is to be
downloaded or removed
Managing keys manually across a large terminal base
can pose significant difficulties; therefore, notification of
key updates should be automatic. Notification may be
done during an authorization response, a batch settle-
ment acknowledgement, an end-of-day response, or an
explicit call by the terminal management system. Alter-
natively, devices may regularly contact the terminal
management system for outstanding updates.
Once notification is received, the device should auto-

matically implement a scheduled process that results in
a timely update of the keys.
For more information on key

Distribute keys to deployed devices in a manner that
security, see Section 2.2.2, protects their integrity.
“Key Management.”
Visa Public
The secure distribution of keys to devices is critical to

ensure that the keys are not corrupted during delivery.
For example, a device could validate the keys by check-
ing the SHA-1 hash. Alternatively, the terminal man-
agement system could validate key integrity by using its
own validation technique, such as a check sum.
Maintain status of keys in deployed devices
2.7.4 Random Transaction Selection

Random Transaction Selection is based on three factors:
Target Percentage for Random Selection (a value be-

tween 0 and 99). This value will determine the percent-
age of transactions below the Threshold Value that will
be sent online for authorization by the terminal. It will
also determine the minimum percentage of above-
threshold transactions to be sent online.
Threshold Value for Biased Random Selection (a value
between 0 and a number less than the Floor Limit in de-
nominated currency; e.g., EUR 50). Below this thresh-
old, transactions are subject to Random Selection,
above this, to Biased Random Selection.
Maximum Target for Biased Random Selection (a value
between 0 and 99, equal to or greater than Target Per-
centage for Random Selection). This value is used to
weight the above-threshold selection criteria to increase
the percentage of selected transactions the closer the
transaction value approaches the Floor Limit.
Random Transaction Selection works in the following way:
The terminal generates a random number between 1

and 99.
If the transaction amount is less than the Threshold
Value for Biased Random Selection and if the terminal-
generated number is higher than the Target Percentage
Value, the transaction may be approved offline by the
card if the card controls permit. (The card, using its own
parameters, may require the transaction to be sent
online for authorization). If the terminal-generated num-
ber is lower than or equal to the Target Percentage
Value, the transaction will be sent online by the terminal
for authorization; if online processing is unavailable, the
transaction may be approved offline by the card, if the
card controls permit.
If the transaction amount is greater than or equal to the
Threshold Value for Biased Random Selection, the
transaction will be subject to Biased Random Selection,
whereby the higher the transaction amount, the greater
the likelihood the transaction will be selected by the ter-
Visa Public
minal for online authorization. The Target Percentage

for Random Selection sets the minimum percentage se-
lected and the Maximum Target Percentage for Biased
Random Selection determines the maximum.
As an example, a market may use the following values:
International Regional Domestic

Floor Limit EUR 0 EUR 100 EUR 300
Target Percentage for N/A 20% 15%
Random Selection
Threshold Value for N/A EUR 40 EUR 200
Biased Random Selec-
tion
Maximum Target Per- N/A 50% 40%
centage for Biased
Random Selection
Assuming a random distribution of below-floor-limit transac-

tions, for each category, the percentage of under-Floor-Limit
transactions going online using the above parameters would
be:
100% of international transactions (no under-Floor)

Approximately 30% of all regional transactions
Approximately 19% of all regional transactions
Assuming the terminal has generated a random number of
25, the following examples are given:
1. The amount for an international transaction is 15. Since

there is a zero-floor-limit for international transactions,
the transaction is selected for online processing.
2. The amount for a domestic transaction is 15. Since the
transaction amount (15) is less than the threshold for Bi-
ased Random Selection, random selection is performed.
The terminal random number (25) is compared to the
target percentage (20%), and because the random num-
ber is higher the transaction is not selected for online
processing.
3. The amount for a regional transaction is 60. This is
above the threshold for Biased Random Selection but
below the terminal floor limit, so Biased Random Selec-
tion is performed. The transaction amount is 20 above
the threshold, which is one-third of the difference be-
tween the terminal floor limit and the threshold for biased
random selection (100 - 40 = 60, 20/60 = 1/3). There-
fore, 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 weighted target for this transaction value of
Visa Public
30% (10% + 20%). The terminal’s random number is 25

(less than the weighted target of 30), so the transaction
is selected for online processing.
4. The amount for a regional transaction 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.
5. Random Selection and Biased Random Selection is dis-
cussed in Visa Integrated Circuit Card Terminal Specifi-
cationV1.4 Section 9.7 “Random Transaction Selection”
and EMV 4.0, Book 3, Section 6.6.2.
Contact the Visa member for the values suitable to the mar-
ket deployment.
2.7.5 Floor Limits

Merchant floor limits are transaction amounts above which
an authorization must be performed. They are specified by
Acquirers, based on merchant type and Visa scheme rules.
Separate floor limits for magnetic stripe and chip should be

supported, even if the limits currently in use are the same.
To provide maximum flexibility, devices and terminal man-
agement systems should support the following floor limits:
International floor limit for magnetic-stripe transactions

International floor limit for chip-initiated transactions
Domestic floor limit for magnetic-stripe transactions
Domestic floor limit for chip-initiated transactions
In addition, market needs may dictate additional floor limits,
such for regional economic zones.
Note that a zero floor limit and online authorization are re-
quired for all fallback transactions, including magnetic-stripe
fallbacks that occur at chip-card devices.
The added security features of chip may allow differentiation

in floor limit requirements. For example, Acquirers and mer-
chants may want to set higher floor limits for chip transac-
tions and lower limits for magnetic stripe transactions, where
fraud is concentrated.
2.7.6 Additional Considerations

Visa International also recommends the following best prac-
tices for terminal management systems:
Mandatory functionality by terminal type
Visa Public
The EMV specifications include mandatory requirements

for all devices that are associated by terminal type.
These requirements may vary from terminal to terminal,
but any individual terminal must support the minimum
requirements for its type.
To ensure EMV compliance, terminal software should in-

clude a profile or logic validating that all mandatory func-
tions for that terminal type are active.
Optional function configuration

System support for some optional functions may require
other optional functions to become mandatory. For ex-
ample, if a terminal supports DDA, support for SDA be-
comes required.
Terminal software should contain logic to ensure that

when an optional function is turned on, its associated
functions are also active.
To ensure interoperability, most functions that are op-

tional for cards are mandatory for devices.
Programmable functions
If an optional function is programmable—that is, if it can
be turned on or off—it must be able to work properly as
configured. Software for the function should be identi-
fied as programmable and should be tested in both on
and off modes.
During vendor quality assurance testing, application kernels

that are developed for multiple terminal types should be
tested using all EMV scripts for those terminals. Compre-
hensive quality assurance testing ensures proper support for
mandatory and optional functions across terminal types.
Visa Public
2.8 EMV Approval Considerations
2.8.1 EMV Support in a Modular Architecture

Terminal software for card acceptance devices should be
configured so that the EMV application kernel is isolated
from other terminal application functionalities (see Figure
2-1). This type of modular architecture is recommended be-
cause:
1. It preserves vendors’ business investment.

EMV Level 1 and Level 2 functionalities from one device
can be used to develop a new product. In such in-
stances, Level 1 or Level 2 testing might not be required.
(See 2.8.2 Considerations for EMV Approvals)
2. Software updates are easier.

By keeping EMV and non-EMV functionalities separate
and self-contained, vendors can ensure that EMV func-
tionality is not affected when Acquirer or payment
scheme applications are updated or changed.
Functions that could change should be “parameterized,”

that is, set up using parameters that are outside the
EMV module. For example, with a properly configured
modular architecture, a change in Visa Terminal Action
Codes (TACs) would not affect a device’s EMV compli-
ance. If not modularized, such a change might require
retesting for Level 2.
FIGURE 2-1: TERMINAL MANAGEMENT SYSTEM WITH MODULAR ARCHI-

TECTURE
RETAIL PAYMENT APPLICATION / POS
Credit/Debit Purse Loyalty
Settings
EMV Level 2 and Parameters Acquirer
Scheme Settings Interface
Drivers/ Peripherals
O/S
Hardware (EMV Level 1 Reader)
For more information on modular architecture, see the EM-

VCo Type Approval Terminal Level 2 Administrative Process
on the EMVCo website.
Visa Public
The following best practices are recommended to help en-

sure that a device with modular architecture supports EMV:
EMV kernel functionality should be configured using ei-

ther the application program interface (API) or the inter-
preter approach described in the EMV specifications.
These two approaches allow EMV application kernel
functionality to be dynamically incorporated into the full
terminal application while maintaining the interoperability
and predictability gained from the use of the EMV speci-
fications.
The EMV module must be identified with a unique label

or version number (e.g., the application provider’s inter-
nal naming convention).
All interfaces and interactions between device logical
components (hardware or software) and the EMV appli-
cation kernel should be identified.
Identification of interfaces and interactions ensures that
EMV functions can be clearly differentiated from non-
EMV functions.
A device must have an IFM (interface module) that is

EMV Level 1-approved before its EMV application kernel
can be tested for Level 2.
An IFM consists of the hardware and software that pow-
ers the chip card and supports communication between
the terminal and the card up to the transport layer. The
three main functional components are the mechanical,
electrical, and logical chip-card interfaces.
EMV Level 2 test cases are performed only against EMV

functions. Acquirer, payment system, and national scheme
specifications are not part of EMV testing. An application
provider may simulate any non-EMV functions necessary for
the completion of the test cases (for example, message for-
mats, communications protocols, device prompt sequences,
or payment scheme settings). However, these other func-
tionalities do not necessarily represent the end product, as
some level of customization may be required for each Ac-
quirer, market, or payment card scheme.
Rigorous testing needs to be performed to ensure that cus-

tomizations and application changes have no adverse im-
pact on the EMV kernel and functions.
For more information on ensuring EMV support within in a

modular architecture, see EMV Integrated Circuit Card
Terminal Specification for Payment System, version 3.1.1;
and EMV2000 Integrated Circuit Card Specification for
Payment Systems, version 4.0.
Visa Public
2.8.2 Considerations for EMV Approvals

2.8.2.1 EMV Level 1
EMV Level 1 approval is given for the Interface Module
(IFM), rather than for the device on which it is tested. An
approved IFM can be used for any device, as long as the
IFM is not modified, and can be used with any approved
EMV application kernel. It is important to identify the IFM
component separately from the device, using a unique iden-
tifier.
2.8.2.2 EMV Level 2

EMV Level 2 approval is not tied to a particular model of a
particular type of hardware, but in practice it is tied to a par-
ticular “family” of hardware (same processor chip, configura-
tion, and operating system) an to a particular chip reader
(IFM). An application kernel is approved to run on any de-
vice, using an approved IFM, that supports the environment
used during testing. As a rule of thumb, if the kernel can be
used on a device without recompilation, the kernel retains its
EMV approval.
2.8.2.3 Testing Recommendation

Vendors should leave the device containing the IFM or ap-
plication kernel at the EMVCo–recognized testing laboratory
until the approval letter is received from the EMVCo secre-
tariat. Minor issues found in the testing report review can be
easily resolved if the device has remained under control of
the testing laboratory. If the device has left the laboratory,
significant re-testing may be required to ensure no changes
have been introduced since the device left the laboratory.
Visa Public
2.9 Key Chip Migration Dates
Date Item Comments

31-Dec-1999 Visa CA 768-bit key no longer used to sign Issuer certificates
01-Oct-2000 10 basis-points inter-regional issuer and acquirer interchange
incentives introduced
01-Jan-2001 All new Visa chip programs must be EMV and VIS compliant
31-Dec-2002 Visa CA 768-bit Public Key expires
01-Jan-2003 All new stand-alone POS terminals must be EMV and VIS compli- The terminals must appear in the
ant in the Asia Pacific Region EMVCo approved list
18-Jan-2003 Visa Asia Pacific intra-regional chip incentive rates introduced, Cards and devices must be fully
providing a 10-basis points benefit to acquirers accepting mag- EMV and VIS compliant.
netic-stripe cards at chip devices, and to chip card issuers whose
cards are accepted at non-chip devices.
01-Jan-2003 Begin withdrawal of Visa CA 768-bit Public Key from chip devices Must be completed by 30 Jun 2003
01-Jan-2003 Begin introduction of the new Visa CA 1152-bit Public Key to all Must be completed by 30 Jun 2003
chip devices
01-Jan-2003 All newly deployed ATMs must support Triple DES (TDES) Includes replacement devices
01-Jan-2003 All new offline-capable chip devices must support DDA All offline capable chip devices
must support DDA by January 2005
01-Jan-2003 All new chip acquirers must send all chip data elements from the Withdrawal of early option data
point of transaction to Visa Net processing. All chip acquirers must
send full chip data by January 2006.
01-Jan-2003 Visa Asia Pacific introduces mandatory card and device user- Contact Visa Asia Pacific to get a
acceptance test process copy of the UAT pack
01-Jan-2003 Visa Asia Pacific may require acquirers to deactivate or replace
chip devices causing interoperability problems.
01-Jul-2003 Visa CA Public Key exchange completed 1152-bit Public Key has replaced
768-bit Public Key
01-Jan-2004 All existing Visa chip programs must be EMV and VIS compliant Includes cards and devices
01-Jan-2004 All newly deployed PIN entry devices must support TDES Includes replacement devices
01-Jan-2004 All newly deployed point-of-sale PIN entry device models must Includes replacement devices
have passed testing by a Visa approved laboratory and been ap-
proved by Visa
01-July-2004 All newly deployed ATMs and Cash Dispensers must have passed Includes replacement devices
testing by a Visa-recognized laboratory and been approved by
Visa.
31-Dec-2004 Visa CA 896-bit Public Key expires
01-Jan-2005 Visa Asia Pacific may invoke financial penalties for non-compliant Visa Asia Pacific specific
cards and devices
01-Jan-2005 All offline-capable devices must support DDA
01-Jan-2005 All new chip devices must be capable of supporting offline PIN Visa Asia Pacific specific
(both plaintext and enciphered)
01-Jan-2006 Visa Asia Pacific Intra-regional liability shift. Liability for counter- Not applicable if acquirer deploys
feit transactions occurring on chip cards passes from the issuer to EMV device and sends full chip
the acquirer data
01-Jan-2006 Domestic liability shifts introduced in Taiwan and Korea
01-Jan-2006 All chip acquirers must be certified by Visa to process full chip
data
01-Jan-2007 All chip-reading devices shall be capable of supporting offline PIN Visa Asia Pacific specific
processing (both plaintext and enciphered)
31-Dec-2008 Target date for maturity (critical mass of chip cards and devices)
2010 Proposed deadline for migration of all PIN based Point of Sale Proposed date
devices to TDES
Visa Public
01-Jul-2010 All point-of-sale PIN entry device models must have passed test-
ing by a Visa approved laboratory and been approved by Visa
Visa Public
2.10 Magnetic-Stripe Reader
In general, card acceptance devices must be equipped with

a magnetic-stripe reader (“MSR”), except if another payment
scheme says otherwise. This reader also includes any re-
lated mechanical and electrical components. To read mag-
netic-stripe data, the card is physically moved through the
reader, for example, by swiping, dipping, or insertion via a
Visa does not require a
motorized track.
MSR on devices for Visa
Horizon card acceptance.
See Chapter 4 “Visa Hori- Devices with magnetic-stripe readers should have a picto-
zon.” gram (and possibly a tactile image) near the card slot indi-
cating how to move the card through the reader. The mag-
netic-stripe reader must be able to read full Track 1 or Track
2 data from the magnetic stripe and process this information
according to the Visa payment system rules. The magnetic-
stripe reader should read the tracks appropriate to the mar-
ket. If a track is read, the full track data must be transmitted
for processing.
The card acceptance device must not update, erase, or alter

any magnetic encoding on Track 1 or Track 2 of the card.
The device must read and act upon service codes on the
magnetic stripe in order to determine whether online proc-
essing is required.
2.10.1.1 Service Code Compliance

A card acceptance device capable must:
Be able to read and act upon the service codes on the

card’s magnetic stripe (applicable to all card acceptance
devices, not just VSDC capable devices). See Appendi-
ces A and B for a listing of the service codes.
When a chip card is swiped through the magnetic-stripe
reader of a chip-card device, the cardholder or merchant
must receive a prompt to insert the card into the chip
reader. This prompt is generated by specific service
codes (2xx or 6xx) on the magnetic stripe, which recog-
nize the card as a chip card. Service codes also com-
municate to the terminal card-specific attributes desig-
nated by the Issuer, such as PIN policy, authorization
rules, sending transactions with an xx6, or an x2x ser-
vice code for an online authorization.
Attempt to process transactions using the chip before

reading the magnetic stripe.
If the device is unsuccessful in reading the chip, regional
requirements may determine the fallback for the device
to read the magnetic stripe.
Visa Public
An Acquirer or merchant may install a VSDC chip-

reading device before the Visa Member or merchant is
actually capable or ready to accept VSDC chip-read
transactions. In such situations, the requirement to ex-
amine and act upon the 2xx or 6xx service codes may
not need to be activated until the Acquirer and merchant
are ready to accept chip transactions. Or preferably, the
terminal should act on the 2xx or 6xx service codes,
read the chip data, but not send the requested chip in-
formation. If the terminal is not capable of reading and
acting on the service code, then the transaction must go
online. The terminal cannot reject the transaction be-
cause the device does not recognize the service code.
2.10.1.2 Magnetic-Stripe Service Codes Related to CVM

A device must be capable of examining and acting upon
valid magnetic-stripe service codes related to cardholder
verification and authorization, including:
xx0: Application requires online PIN verification in con-

junction with online magnetic-stripe authorization (PIN
required).
xx6: Application expresses preference for online PIN
verification in conjunction with online magnetic-stripe au-
thorization (prompt for PIN if a PIN pad is present).
x2x: Application requires online magnetic-stripe authori-
zation.
Service codes that are not recognized by a card acceptance

device must not be blocked or automatically result in a de-
clined or rejected transaction. If the device does not recog-
nize the service code, the transaction should be submitted
online for authorization.
In some regions, the terminal may always go online instead

of reading and acting upon the service code.
For more information on Visa service codes, see Appendi-

ces A and B, or the Visa Payment Technology Standards
manual.
Visa Public
Chapter 3: Visa Cash

Visa Cash cards are chip-based electronic purse cards that
WHAT’S COVERED provide a quick and easy way for consumers to make low-
Compliance Require- value purchases—generally under $10. Targeted to replace
ments cash and coins, the cards can be used in the same retail
Physical Characteristics environments as a VSDC card: retail outlets, mail order and
Retail Environments
telephone order, and online.
Visa Cash Transaction This chapter provides an overview of the physical and func-
Processing tional characteristics of devices that are capable of process-
ing Visa Cash transactions.
Visa Public
3.1 Compliance Requirements
Devices that process Visa Cash transactions must comply

with the following specifications:
EMV2000, Book 1: Application independent ICC to Ter-

minal Interface Requirements
In particular, devices must comply with the electrome-
chanical and protocol requirements in these specifica-
tions.
Visa Cash CAD/Service Payment Terminal Specification

These specifications define the requirements for the de-
sign and functionality of Visa Cash devices.
Visa Cash CEPS Business Requirements

These specifications define the requirements for devices
that accept Visa Cash CEPS cards.
Visa Public
The requirements and best practices for the components of

Visa Cash devices include:
TABLE 3-1: PHYSICAL CHARACTERISTICS OF VISA CASH DEVICE

Physical Characteristics Requirement
Secure Module Yes
Display Yes
Memory 125K KB minimum
Function Keys Yes
Visa Cash devices do not Keypad Yes
require a magnetic-stripe
reader, clock, PIN pad, or Chip Card Reader Yes
printer.
3.2.1 Secure Module

The device must be able to connect to a Secure Access
Module (SAM) and the Visa Cash card at the same time.
The SAM may be either hardware (for example, a micro-
processor chip) or software, and may reside in the device or
on a server connected to the device.
The SAM must fully support the latest version of the Visa
Cash merchant card (Mcard). Visa Cash devices must also
be able to accept a Purchase Secure Application Module
(PSAM) or Mcard provided by Visa.
3.2.2 Display
The device must have access to a display. The display
should be alphanumeric and should be able to show at least
6 digits or at least 30 alphanumeric characters at a time.
The display should be able to show the digits 0 to 9, and
numbers with two decimal places, where applicable. Any
text in the display should be visible for a minimum of 3 sec-
onds.
Displays may not be required in certain payment environ-

ments, such as mass transit, to accelerate processing.
3.2.3 Memory
The device must store purchase transaction detail for later
transmission to an external device. The data store should
be able to hold at least 125 kilobytes (KB) of data. The data
store should use nonvolatile storage and be able to with-
stand a power failure without losing data.
Visa Public
3.2.4 External Communication

A Visa Cash device must be able to initiate communication
with an external device, and an external device must be able
to initiate communication with a Visa Cash device. In the
case where the modem is internal to the device, the default
communication rate between the device and a modem shall
be no less than 2,400 bits per second (bps). If the Visa
Cash device uses a telephone line to communicate with an
external device, it should be possible to share this line with
other applications, such as a telephone.
3.2.5 Function Keys and Keypad

The device requires an ACCEPT button to allow the card-
holder to approve the selection of goods or services. A de-
vice that is either unattended or locks the card requires an
EJECT button. The device must also provide a keypad to
enter transaction amounts and perform functions
(e.g., APPROVE or CANCEL).
Visa Public
3.3 Retail Environments
Visa Cash transactions occur in both attended and unat-

tended retail environments.
3.3.1 Attended Transactions

The following transaction scenario is typical of a Visa Cash
purchase in an attended environment:
The cardholder inserts the Visa Cash card into the de-
vice.
The device displays the balance on the card.
The merchant enters the transaction amount.
The cardholder reads the entered transaction amount
and, if correct, presses a button to indicate approval.
The device deducts the value from the card and displays
the new card balance.
3.3.2 Unattended Transactions

The following transaction scenario is typical of a Visa Cash
purchase in an unattended environment:
vice.
The device displays the card’s current balance and pur-
chase amount, and prompts the cardholder to select a
product.
The cardholder pushes a button to select a product.
The device dispenses the product, deducts the value
from the card (or vice versa), and displays the new card
balance.
In some instances, for example, a mass transit application,

balance display and cardholder confirmation may not be re-
quired, to accelerate processing. The processing scenario
in such cases would be as follows:
vice.
The device deducts the value from the card.
Visa Public
3.4 Visa Cash Transaction Processing
Transaction-processing functionalities that are required for

devices that accept Visa Cash cards include the following:
3.4.1 Transaction Initiation

A Visa Cash device must provide the capability to insert the
card into the device. The cardholder or attendant may be
required to select the application or card type before the
card is inserted.
If the device holds or locks the card in place, cardholders

must be able to remove the card by pressing a function key,
such as CANCEL or EJECT.

A Visa Cash device must provide cardholders with the op-
tion of selecting an application at the point of transaction or
accepting a card-specified default, if needed.
3.4.3 Card and Data Authentication

A Visa Cash device must be able to authenticate and vali-
date the data on the card.
Visa Cash products require the use of either SDA or DDA.

Both shared-key and public-key technology may be used to
support the data authentication method.
3.4.4 Transaction Completion and Capture

A Visa Cash device must provide the following functional-
ities to support transaction completion and capture:
The device must prompt the cardholder to approve the

transaction, for example, by pressing an ACCEPT but-
ton, before deducting the value from the card.
In an unattended environment where the product can be
dispensed prior to debiting the purchase from the card,
the card reader must be able to lock the card and pre-
vent its removal during the payment sequence.
The device must be able to store purchase transactions.
It must also be able to communicate with an external de-
vice for the collection of purchase transactions and the
receipt of date data, key data, and transaction informa-
tion.
Visa Public
3.4.5 Card with Insufficient Value

A Visa Cash device must allow for situations where the card
presented does not contain sufficient value to pay the full
purchase amount. In such instances, the device should
prompt the cardholder to insert another Visa Cash card or to
pay by another method.
3.4.6 Disposable and Reloadable Cards

Visa Cash products are either disposable or reloadable, and
Visa Cash devices must accept both.
Disposable cards are issued with a monetary value estab-

lished at the time of manufacture and cannot be replen-
ished. Reloadable cards are capable of having their mone-
tary value replenished.
Visa Public
Chapter 4: Visa Horizon

Visa Horizon is a chip only domestic payment application
WHAT’S COVERED developed for markets where the telecommunications infra-
How It Works structure is not widespread, reliable, or not cost effective.
Compliance Require-
ments The Visa Horizon product is a pre-authorized card that cur-
Physical Characteristics
rently uses two technologies to ensure ubiquitous accep-
tance within a domestic market.
Security Characteristics
Visa Horizon Transaction Visa Horizon can be accepted at VSDC devices with PIN
Processing pads under the VSDC AID without any Acquirer changes to
VSDC. Currently, Visa Horizon also uses COPAC technol-
ogy which is a card-to-card transaction – well suited for a
completely offline terminal environment.
Visa Public
4.1 How It Works
Visa Horizon cardholders first open debit or credit accounts

with Member banks and request a pre-authorized amount of
purchasing power. This pre-authorized spending power is
stored in the chip on the cardholder’s PIN-protected Visa
Horizon card. Once the pre-authorized amount has been
established, the bank's system automatically sets up a
shadow account where the pre-authorized funds are stored.
Funds are deducted from the shadow account when the

cardholder's cash and purchase transactions have cleared
the system.
Regardless of whether the transaction occurs in an online or

offline environment, the cardholder’s pre-authorized spend-
ing power is decremented on the card’s chip.
Cardholders can update spending power on the card at any

time in both VSDC and COPAC, at locations equipped with
online capable terminals.
Visa Horizon requires that Issuers and Acquirers support

Full Data option since the spending power cannot be up-
dated in an early market.
Visa Public
4.2 Compliance Requirements
Devices that process Visa Horizon transactions must comply

with the following specifications:
EMV2000, Book 1: Application independent ICC to Ter-

minal Interface Requirements
Visa Horizon devices must comply with EMV Level 1
specifications especially with the electromechanical and
protocol requirements. Due to the unique processing
requirements of the application, Level 2 compliance is
Visa Horizon cards have not required.
been enhanced to allow
acceptance at VSDC de- Visa Horizon (COPAC) Terminal Application Specifica-
vices that support PIN and tion
online authorization. Accep-
tance at these devices is at Please see your Visa representative to obtain a copy.
the discretion of the Issuer.
Visa Public
Table 4-1 summarizes the unique hardware requirements

for VSDC and COPAC devices that accept Visa Horizon.
Additional requirements and best practices include:
TABLE 4-1: PHYSICAL CHARACTERISTICS OF VISA HORIZON DEVICE

Physical Characteristics Requirement
Key Pad Yes
PIN Pad Yes
Display Yes
As a best practice, Visa Printer Yes
Horizon devices should be Magnetic-Stripe Reader No
able to operate from batter-
ies, as well as from a per- Chip-Card Reader One or two (ID1 chip card readers), de-
manent electrical power pending on intended operation of the ter-
source. Inexpensive minal
household batteries are Modem No; dependent upon intended operation of
recommended to hold down the terminal
terminal costs.
Key Pad Yes
4.3.1 Card Reader

Depending on operating environment, a Visa Horizon device
that uses the COPAC terminal application must provide
support for one or two chip-card readers capable of reading
full-sized ID1 chip cards. If an additional slot is used to
store the full-sized merchant chip card, it must be encased
to limit visibility and protect the merchant card from being
dislodged accidentally.
4.3.2 Display
The device must support at least one display as defined in
the EMV specifications. The set of common display charac-
ters are also described in these specifications. The ability to
For more information on nega- support graphic alphabet characters may also be required.
tive files, see Section 4.4.3,
“Negative File.”
The device must also support the display requirements for
the credit and debit applications.
4.3.3 Memory
The device must have sufficient memory to support a nega-
tive file with 5,000 entries. A minimum required amount to
support this functionality is 128 kilobytes (KB).
4.3.4 Printer
The device must be equipped with a printer as defined in the
EMV specifications.
Visa Public
The printer is used to print a receipt of the transaction for

both the cardholder and the merchant. The receipt includes
the card number, the amount of the transaction, date, the
merchant identification, an employee ID, the transaction cer-
tificate, type of currency used, and a transaction number
than can be used for tracking purposes if needed later.
The COPAC terminal application also prints or displays the

cardholder’s remaining spending power. Also, it may have
the capability to provide a list of the cardholder’s last
ten (10) transactions. These additional data elements do
not appear on the merchant’s log or receipts.
The printer is also used to produce various informational re-

ports, requested by either the consumer or merchant.
4.3.5 Cardholder Interface Unit

A Visa Horizon device must have a PIN pad or a keypad
that can be used for PIN entry.
4.3.6 Clock
The device must be equipped with a clock capable of keep-
ing the local date and time.
Visa Public
4.4 Security Characteristics
Security requirements and best practices for Visa Horizon

devices include the following:
4.4.1 Offline PIN

A Visa Horizon device must support offline PIN for card-
holder and merchant verification. Specifically, offline PIN
must be supported for all cardholder financial transactions
(that is, any transaction resulting in a decrease in available
spending power) and for some non-financial transactions.
Acquirers are responsible for defining a list of merchant

transactions that are PIN protected.
4.4.2 Authentication and Integrity Processes

The COPAC equipped device must support Visa Horizon
authentication and integrity processes, which are based on
the generation of cryptograms and Message Authentication
Codes (MACs) passed between various system compo-
nents. Security is based on secret key technology using the
Data Encryption Standard (DES) and Triple DES (TDES);
however, the cryptographic keys are stored in the card-
holder card, the merchant card, and the Issuer and Acquirer
hardware security modules. A Visa Horizon (COPAC) de-
vice itself performs no cryptographic functions.
4.4.3 Negative File

A device containing the COPAC terminal application must
contain a negative file that is used in offline transactions to
block lost and stolen cards or to decline cards from certain
Issuers.
The negative file should contain information about primary

account numbers (PANs), Issuer identifiers (commonly
known at Visa as bank identification numbers [BINs]), and
the ranges of PANs to be rejected during an offline financial
transaction. The device must be able to store and manage
this information in the file.
Visa Public
4.5 Visa Horizon Transaction Processing
Transaction-processing functions required for devices that

accept Visa Horizon cards include the following:

A device that uses the COPAC terminal application must be
able to select the Visa Horizon AID in both the cardholder
and merchant cards.
4.5.2 Cardholder Verification

A Visa Horizon device must support offline PIN verification,
regardless of whether the terminal application is VSDC or
COPAC.
The amount of purchase is input and verified by the card-

holder when the cardholder enters the PIN. After the PIN
has been verified, the amount is then debited from the card-
holder’s available balance. The transaction is recorded on
the cardholder’s chip. In a VSDC environment, the Visa Ho-
rizon transactions are batched, cleared, and settled with all
other Visa card transactions. In a COPAC environment, the
transactions are added to the merchant’s chip card.
4.5.3 Transaction Completion and Capture

A Visa Horizon device must be able to store purchase and
cash transactions. It must also be able to print receipts for
both the cardholder and the merchant.
In the COPAC application, the merchant card collects the

transaction details in an offline environment. When the mer-
chant visits the bank for a deposit, the device at the bank
then transfers the transaction amounts received from the
merchant’s card into the merchant’s bank account.
For merchants who have a dial-up connection, the merchant

can perform clearing and settlement, along with getting the
updated negative file.
The merchant’s Visa Horizon device may also be used as

the uploading device for batch settlement transactions. If a
phone connection is available, then the merchant can settle
the batch transactions to the merchant’s bank account di-
rectly from the merchant site.
Visa Public
Chapter 5: Device Types

Visa chip card transactions may be processed by all major
WHAT’S COVERED card acceptance device types: attended, unattended, and
General Device Con- ATM.
figurations
Attended Devices This chapter provides an overview of the requirements and
Unattended Devices
best practices that are unique to each type of device. Sec-
tion on transaction types and operational considerations for
Automated Teller Ma- Acquirers are also included.
chines.
Transaction Types
Notes for Acquirers
Visa Public
5.1 General Device Configurations
All devices with chip-card readers must fully comply with the
EMV specifications and be approved for EMV Level 1.
Level 1 compliance is required regardless of whether the
device supports VSDC, Visa Electron, Plus, Visa Cash, or
Visa Horizon, or any other applications.
EMV Level 2 compliance may be required, depending on the

specific applications the device supports. For example,
Level 2 compliance is required for VSDC devices, but not for
the Visa Horizon devices that use the COPAC terminal ap-
plication.
Visa-specific requirements and best practices for device

hardware and software include the following:
5.1.1 Hardware
Requirements and best practices for device hardware in-
clude the following:
Magnetic-stripe reader — Capable of reading full track

data (Track 1, Track 2, or both).
Chip-card reader — EMV Level 1 approved, and capa-
ble of supporting the T=0 and T=1 communication proto-
cols.
Processor — Transaction processing time is influenced
by many factors, such as use of a co-processor. The
terminal should have a fast processor, as this impacts
the merchant and user experience. The primary de-
mand on processing power is the mathematical compu-
tation of the Rivest, Shamir, Adleman (RSA) algorithm.
Timeliness in completing transactions involving Static
Data Authentication (SDA), Dynamic Data Authentication
(DDA), and enciphered offline PIN, is directly related to
data word size (8 bit, 16 bit, etc.) and clock speed
(megahertz). While 16-bit or 32-bit processors are rec-
ommended, 8 bit processors may be acceptable for sup-
porting VSDC and Visa Cash, using a Physical Secure
Application Module (PSAM) or co-processor. In any
case, the processing time for EMV transactions should
be similar to that experienced today for magnetic-stripe
transactions.
Memory — The terminal should have ample spare
memory to allow:
− Addition of other applications, as required in future
multi-application programs and
Visa Public
− Storage of multiple EMV public keys for each pay-

ment scheme. The current EMV requirement is six
keys per payment scheme with a length of 1984 bits
and associated data.
Printer — Capable of printing receipts.
Display — Ability to display 32 alphanumeric characters
simultaneously.
Keypad or touch screen — Used to enter data, select
commands, and perform functions. A touch screen is
considered to be a keypad.
For information on PIN pad
security requirements, see PIN pad — If PIN pads are used, they must meet Visa’s
Section 2.2, “Security Charac- requirements for PIN entry devices (PEDs).
teristics.”
Clock — If the device is capable of processing offline,
the clock must have local date and time, and be accu-
rate to within one minute per month.
External communications — Capable of connecting
online, with a minimum communications speed of 2400
bits per second (bps), 9600 bps is recommended.
Voltage — The release of low voltage and multi-voltage
payment cards should have minimal impact on the de-
sign of card acceptance devices in the short term. The
voltage of a device determines the voltage at which a
card must be able to operate. For example, 3-volt (V)
cards must be able to operate in 5 V devices as well as
3 V devices such as cell phones and personal digital as-
sistants (PDAs).
In addition, 5 V devices will remain valid even after all
cards have been converted to multi-voltage (second
quarter 2009).
5.1.2 Software
In additional meeting EMV Level 2, requirements and best
practices for device software include the following:
The device software should be able to recognize Visa

account numbers up to 19 digits in length, beginning with
a “4.”
Device software that supports Visa chip applications
must have, at a minimum, an application database for
any application that understands and responds to mes-
sages received.
5.1.3 PIN Entry Device Requirements

If the terminal does not have an integrated secure PIN pad,
there should be a spare port to support a secure PIN pad
that can be used for online PIN transactions (e.g. for debit
cards).
Visa Public
If a solution is implemented using an external PIN pad, the

application needs to ensure that the PIN pad is always con-
nected to the terminal and is functional. The application
must detect detachment or failure of an external PIN pad
and respond appropriately.
PIN pads and POS devices that also function as PIN-entry

devices (PEDs) must undergo a physical and logical security
evaluation performed at a Visa-recognized laboratory.
Visa milestones for compliance with PIN security require-

ments include the following:
5.1.3.1 PIN Entry Device Testing Requirements

January 1, 2004 — All newly deployed POS PIN-entry
devices, including replacements, must have passed test-
ing by a Visa-recognized laboratory and been approved
by Visa.
July 1, 2004 — All newly deployed ATMs and Cash Dis-
pensers (including replacements), must have passed
testing by a Visa-recognized laboratory and been ap-
proved by Visa.
January 1, 2010 — All POS PIN-entry devices must
have passed testing by a Visa-recognized laboratory and
been approved by Visa.
5.1.3.2 TDES Requirements

January 1, 2003 — All newly deployed ATMs (including
replacement devices) must support TDES.
January 1, 2004 — All newly deployed POS PIN accep-
tance devices using DES (including replacement de-
vices) must support TDES.
Visa strongly recommends Member completion of the migra-

tion to TDES in accordance with the following dates, recog-
nizing that Visa’s Regions may adopt separate compliance
dates in consideration of commercial or regulatory require-
ments, including coordination of TDES with other strategic
initiatives:
July 1 2007 — All ATMs should support TDES.

July 1, 2007 — All transactions initiated at TDES capa-
ble devices should be TDES encrypted from the point of
acceptance (e.g., from the POS, ATM, cash dispenser,
etc.) to Visa.
Use of TDES encryption by Member Issuers is also strongly

recommended, but the Member Issuer will determine the
encryption standard used between Visa and the Issuer host
Visa Public
July 1, 2010 — All POS PIN acceptance devices should

support TDES.
For more information on Visa requirements for PED security,

visit the Visa PIN website.
5.1.4 Requirements for Private Tags (Not Visa-Specific)

When private tags are used, a card acceptance device must
have the data required to identify the scope of the private
tag, that is, whether it has meaning for the transaction.
If the data element required to identify the scope of the pri-

vate tag is not correct or available, the device ignores the
private tag.
Visa Public
5.2 Unattended Devices
This section describes the unique physical and functional

characteristics of unattended devices that process Visa chip
card transactions.
5.2.1 Unattended Environment

The sales environment for unattended devices is as follows:
The card is present.

The cardholder is present.
Information on unattended The cardholder verification is obtained, if applicable.
devices that dispense
scrip are not included in The cardholder completes the transaction directly at the
this section since the Visa device.
International Operating
Regulations prohibit Visa The device dispenses goods or services but not cash
cards from being used at
Authorization, if required, is obtained electronically.
scrip devices. Scrip is a
two-part paper receipt
redeemable for goods, In all cases, the card and the cardholder are present and the
services, or cash. cardholder handles the transaction process independent of
a sales associate.
Transaction completion may be viewed as the point in the

process where the device has gathered all the data neces-
sary to process the transaction. It may also be viewed as
the point in the dialogue between cardholder and device
where goods or services are exchanged for payment, or the
transaction is terminated. Evidence of transaction comple-
tion is the generation of a receipt – a record (paper or elec-
tronic) that confirms the exchange of goods or services for
payment. Visa requires that the merchant set indicators
(transaction types) in the transaction message as proof that
the transaction was completed in an unattended environ-
ment
The transaction amount is generally known at the time the

transaction is initiated. In cases where the amount is not
known, the process of obtaining an authorization may vary,
based on regional or national practices. Typically, a pre-
authorization message is required.
5.2.2 Transaction Types

Visa categorizes acceptance devices by the types of trans-
actions they process. Transaction categories are based on
risk level.
Type A Transactions — Are less than U.S.$40, or local

currency equivalent. Type A transactions are not author-
ized, and cardholder verification is not performed.
Visa Public
Type B Transactions — Are less than U.S.$100, or lo-

cal currency equivalent. Type B transactions are author-
ized, but cardholder verification is not performed.
Type C Transactions — Are not limited to any dollar
amount. Type C transactions are authorized and PIN
verification is required.
5.2.3 Physical Characteristics

The basic hardware components of unattended devices in-
clude:
Card Reader — Capable of reading magnetic stripe and

chip cards.
Display — Should support all selection and data entry
functions, including PIN entry. The display should sup-
port menus, product information, pictures, and text. The
display may be a touch screen.
Keypad — Used for data entry. If it supports PIN entry,
then the keypad must comply with Visa’s PIN entry de-
vice requirements.
PIN Pad — Required for devices that process Type C
transactions.
Printer —Required, if transaction receipt needed to be
produced.
5.2.4 Transaction Processing at Unattended Devices

Transaction-processing requirements and best practices for
unattended devices include the following:
5.2.4.1 Type A Transactions

Examples of these are card payments accepted at parking
garages, toll roads, transit stations, taxis, prepaid-ticket dis-
pensers at movie theaters, and public phones.
When processing a Type A transaction, the device must:
Perform data capture of the account number, transaction

date, and transaction amount. Please reference the
most current VSDC System Technical manual for a com-
plete listing of data. A copy may be obtained through
your regional Visa representative.
Validate the service code, account number, and card
expiration date.
Check the account number against a negative file for au-
thorization, if the device supports this information.
Limit the transaction amount to a maximum of U.S.$40,
or the local currency equivalent.
Visa Public
Produce a transaction receipt, except for public tele-

phones.
An authorization is not required. Also, Type A transactions

must not be performed using Visa Electron cards, service
code x2x. However, some Visa Flag cards may have ser-
vice code x2x, which may be used to perform Type A
transactions.
5.2.4.2 Type B Transactions

Type B transactions occur primarily at gas pumps that ac-
cept payment cards.
To process a Type B transaction, the device (pump) must:
Limit the transaction amount to U.S.$100, or the local

currency equivalent.
Authorize all transactions.
Produce a transaction receipt upon cardholder request.
5.2.4.3 Type C Transactions

Type C transactions occur at machines that dispense airline
tickets.
To process a Type C transaction, the device must:
Authorize all transactions.

Accept PINs and perform online or offline PIN verifica-
tion.
Be capable of displaying the following information to
cardholders:
− Card invalid for this service
− Service unavailable now
− Invalid PIN; re-enter
− Card retained (if the device can retain cards)
The exact wording for these messages may vary. In gen-

eral, standard formats are used, but some flexibility is al-
lowed.
Obtain approval from Visa for PIN handling and security

before accepting a card
Produce a transaction receipt
Visa Public
5.3 Automated Teller Machines
An ATM device is an unattended terminal that has electronic

capability, accepts PINs, and disburses currency and travel-
ers cheques.
5.3.1 Physical Characteristics

The unique physical characteristics of ATMs include:
Card Reader
Card retention or capture is optional. If an ATM has the
ability to capture a card, the card-release function is not
required.
Keypad
The ATM keypad is a single pad that is used for both
data and PIN entry. Keypads must comply with the Visa
PIN Security Requirements.
Speaker
The speaker gives cardholders auditory feedback when
using the keypad, in order to meet any requirements to
assist cardholders who may have impaired vision.
Display
The display screen must be able to communicate the fol-
lowing messages:
− Card invalid for this service

− Service unavailable for now
− Invalid PIN; re-enter
− Card retained
The exact wording for these messages may vary. In

general, standard formats are used, but some flexibility
is allowed.
Deposit Slot
The deposit slot accepts deposit envelopes, if the device
can accept deposits.
Cash Dispenser
The ATM cash dispenser should include:
− A safe
− An electronic eye that counts each bill as it leaves
the dispenser
Visa Public
− A sensor that evaluates the thickness of each bill to

ensure bills are not stuck together
− A reject bin for bills that are stuck together, worn,
torn, or folded
5.3.2 PIN Encryption

PIN confidentiality depends on the implementation of ade-
For information on Triple DES, quate PIN security standards. To this end, international
see Section 5.1.3, “PIN Entry standards organizations (ANSI and ISO) and Visa now re-
Device Requirements.” quire migration from the DES using single-length keys, to
the TDES algorithm.
To balance the business impacts of TDES migration with the

security risks of delayed implementation, Visa has estab-
lished milestones for the introduction of TDES. The aim of
this strategy is to improve PIN-based transaction security
and support Acquirer business plans for replacing ATM de-
vices and upgrading host systems.
January 1, 2003, all newly deployed ATMS, including re-

placement devices, must support TDES. Visa also strongly
recommends that Members develop TDES implementation
plans for all currently deployed ATMs.
5.3.3 Business Requirements

The unique functional requirements of ATMs include:
5.3.3.1 Transaction Initiation

For chip-card transactions, an ATM must first attempt to
read the chip. If the chip cannot be read, the ATM may at-
tempt to read the magnetic stripe and transmit the entire un-
altered contents of Tracks 1 and 2. If both the chip and the
magnetic stripe cannot be read, the transaction must be
canceled.
5.3.3.2 Cardholder Verification

All ATMs must support online PIN verification for all transac-
tions. Chip-reading ATMs must support online PIN only.
They must not support signature or “No CVM required.” Cur-
rently, if an offline PIN is used for the transaction, the trans-
action still needs to include an encrypted PIN block in the
authorization message; otherwise, VisaNet will reject it.
ATMs must be able to accept PINs of 4 to 6 digits in length.

Acquirers may process PINs up to 12 digits long.
5.3.3.3 Application Selection

For chip-card transactions, ATMs should provide cardhold-
ers with the option of selecting an application at the point of
transaction.
Visa Public
5.3.3.4 Authorization
ATMs must support online authorization for all transactions,
although offline declines are permitted for transactions initi-
ated by chip cards.
5.3.3.5 Transaction Completion and Capture

All transactions must be transmitted electronically. A trans-
action cannot be completed manually.
A transaction must be canceled if network problems or sys-

tem outages occur.
5.3.3.6 Additional Requirements

ATMs should support the following additional functionalities:
Ability to display the type of currency dispensed, includ-

ing travelers cheques.
Ability to display messages in multiple languages.
Visa Public
5.4 Transaction Types
In addition to purchases in attended and unattended de-

vices, card acceptance devices may be required to process
a range of transactions. This section contains brief descrip-
tions of the different transaction types and their unique
processing requirements.
5.4.1 Purchases
A purchase is defined as the transaction between a card-
holder and a merchant where goods or services are ex-
changed for money.
5.4.2 Refunds
A refund is the opposite of a purchase transaction. The
cardholder returns goods to a merchant and receives credit
for their value. Full or partial refunds of the original transac-
tion are possible. However, Refunds are generally not au-
thorized and are simply stored as a clearing transaction.
Therefore, refunds should be a protected function, requiring
a password or a supervisor card (where a chip card would
For refunds where a card is provide superior security).
not present, current proce-
dures for magnetic-stripe
refunds are followed.
At this time, neither EMVCo nor Visa has formally defined
how refunds should be handled. Please check with the Visa
regional office for any updated information. The following
processing sequence is one recommendation that Visa has
for a VSDC refund (credit) transaction:
The cardholder may either insert the card into the device
or hand the card to the clerk for processing.
− For single-application cards, the card may process
the transaction, using that application.
− For cards with more than one application, the card-
holder or the clerk (if the card was handed to the
clerk) may select the appropriate application for the
refund transaction. Application selection proceeds in
the same manner as for a purchase transaction. The
account used for the credit or refund should be the
same as the one used for the original purchase.
The terminal reads the data from the card as for a pur-
chase transaction; however, subsequent functions —
card authentication, cardholder verification, terminal risk
management, card action analysis, and cryptogram gen-
eration — are not performed.
The terminal creates the appropriate clearing record for
the credit transaction, using information provided by the
selected application.
Receipts are generated as appropriate.
Visa Public
5.4.3 Cancel/Voids
A cancel/void occurs when a previous purchase transaction
is matched in order to cancel its authorization or settlement,
usually when an error is made. This type of transaction is a
function of the POS application and does not require interac-
tion with the card.
5.4.4 Reversals
Reversals are sent to Issuers when a previous authorization
response is not delivered or has been annulled. Reversals
are a function of the POS application or the transaction net-
work and do not require interaction with the card.
5.4.5 Authorization Only (Pre-Authorization)

Authorization-Only occurs when a request is sent to the Is-
suer for pre-approval of a purchase amount before the
transaction is settled. The total transaction amount may
change from the pre-authorized amount, as in self-service
petroleum station environments with a subsequent transac-
tion submitted with the final amount for settlement. Depend-
ing upon regional operating regulations and merchant floor
limit, the subsequent transaction may be submitted only for
settlement.
An Authorization Only request should contain all the chip

data elements appropriate to the Member’s host system,
that is, either early or full data option. The card and terminal
process Authorization Only transactions in the same manner
as purchases transactions.
5.4.6 Posts (Post Authorizations, Forced Post)

Posts are the financial settlement of previously authorized
transactions. The authorization can be a voice authorization
or an implicit authorization, which occurs when the transac-
tion amount is under the relevant floor limit.
Posts may also occur as part of an Authorization Only

transaction. If the Authorization Only is completed using a
chip card, the chip data elements must be retained for set-
tlement. Since the card is no longer available to generate a
Transaction Certificate (TC), the Authorization Request
Cryptogram (ARQC) is used in its place.
Visa Public
5.5 Notes for Acquirers
Acquirer support for Visa requirements and best practices

for card acceptance devices is essential. This section pro-
vides a brief discussion of Acquirers’ unique responsibilities
for chip infrastructure support.
5.5.1 Signature Capture

A card acceptance device that captures electronic signa-
tures must provide adequate security for the capture and
storage of the signatures.
Merchants incorporating electronic-signature capture into

their POS systems must ensure the security of the stored
signatures. Please check with the regional Visa office to
see if signature capture is permitted.
5.5.2 PIN Storage

A POS system must not retain the encrypted PIN blocks af-
ter the online authorization has been made, except when
used for store-and-forward transactions, and only for the
minimum time necessary to complete the transaction.
5.5.3 Terminal Recovery for Offline Transactions

As a best practice, Acquirers should ensure that POS termi-
nals receive regular maintenance, such as battery replace-
ment.
If a power failure occurs and the battery in the terminal is

dead, the merchant will have to manually enter information
from the receipts of captured transactions. The merchant
will be at risk of losing payment for those transactions since
the full magnetic stripe information and chip information will
not be printed on the receipt. To reduce the size and impact
of risk, Acquirers should ensure that their terminals settle
every day.
5.5.4 Change in Format for Authorization Response

Code
The Issuer or the VisaNet Integrated Payment (V.I.P.) sys-
tem generates the Authorization Response Cryptogram
(ARPC) using the ASCII Cryptogram Authorization Re-
sponse Code. This response code is transmitted through
VisaNet in EBCDIC format. It must be sent to the card in
ASCII format. The Acquirer must convert the Cryptogram
Authorization Response Code from EBCDIC to ASCII for
proper operation of the terminal.
Visa Public
5.5.5 Certification for ATM Acquirers

Before acting as an ATM Acquirer, Members must meet the
certification requirements in the Visa/Plus International
ATM Member Guide, Chapter 6, “Acquirer Participation Re-
quirements.”
5.5.6 Test Keys

Test keys must be removed from devices before they are
deployed in the field.
Visa Public
Appendix A: Track 1 Data

This appendix describes Visa standards for the contents of
WHAT’S COVERED Track 1 of the magnetic stripe and the magnetic stripe im-
age on the integrated chip. Visa requirements conform to
Track 1 Content Re- the International Organization for Standardization (ISO)
quirements
standard 7811/2, Identification cards—Recording tech-
Encoding Examples nique—Part 2: Magnetic Stripe and ISO standard 7813,
Data Element Descrip- Identification cards—Financial transaction cards.
tions
Visa Public
A.1 Track 1 Content Requirements
Requirements for the contents of the magnetic stripe con-

form to ISO 7813 (Identification cards -- Financial transac-
tion cards).
Specifications for the physical placement of the magnetic

stripe on a card are in Visa International Operating Regula-
tions, Volume III—Card and Marks Specifications.
The Visa International Operating Regulations conform to in-

dustry standards and are consistent with the standards rec-
ognized by magnetic stripe vendors.
A.1.1 Record Format

Figure A–1 displays the Track 1 record format for a mag-
For more information on Track
netic stripe, including field names and lengths. The maxi-
1 data fields, see section A.3, mum length of Track 1 is 79 characters.
“Data Element Descriptions.”
All fields are required in Track 1, with the following excep-
tions:
The PIN Verification Data field is optional for all cards,

with the exception of Visa Gold/Premier cards.
The Discretionary Data field is optional.
The Authorization Control Indicator (ACI) in the Visa-
Reserved field is optional.
A Card Verification Value (CVV) is required in the Visa-
Reserved field on all Visa, Visa Electron, and Plus cards.
It may be optional on other card types.
Visa Public
TABLE A–1: TRACK 1 RECORD FORMAT
A.1.2 Character Set

Figure A-2 illustrates the bit-sequence pattern for the let-
ter K.
FIGURE A–2: LETTER K BIT-SEQUENCE PATTERN*

* bn = bit position number n
Figure A–3 on the next page describes the Track 1 charac-

ter set. This table corresponds to the comparable table in
Section 10.1.3 of ISO standard 7811/2.
Visa Public
Data formats to be provided to an encoding machine are

specified by the hardware manufacturer. The encoding de-
vice must use odd parity to encode data characters. Clock-
ing bits for synchronization are not considered as data.
Additionally, an even-parity Longitudinal Redundancy Check

(LRC) character must be the last character in a track record.
The parity bit is automatically generated and encoded by the

encoding machine.
The encoding equipment must encode the magnetic stripe

data of Track 1 in accordance with the bit-sequence patterns
specified in Figure A–3. This coded character set is identi-
cal to the coded character set in ISO/IEC 7811-4 and is de-
rived from ASCII.
Visa Public
FIGURE A–3: TRACK 1 CHARACTER SET

Binary
5 4
Char. Hex P 2 2 23 22 21 20
space 20 1 0 0 0 0 0 0
! 21 0 0 0 0 0 0 1
“ 22 0 0 0 0 0 1 0
# 23 1 0 0 0 0 1 1
$ 24 0 0 0 0 1 0 0
% 25 1 0 0 0 1 0 1
& 26 1 0 0 0 1 1 0
This coded character set is ‘ 27 0 0 0 0 1 1 1
identical to the coded char- ( 28 0 0 0 1 0 0 0
acter set in ISO/IEC 7811-4 ) 29 1 0 0 1 0 0 1
and is derived from ASCII * 2A 1 0 0 1 0 1 0
+ 2B 0 0 0 1 0 1 1
, 2C 1 0 0 1 1 0 0
- 2D 0 0 0 1 1 0 1
. 2E 0 0 0 1 1 1 0
/ 2F 1 0 0 1 1 1 1
0 30 0 0 1 0 0 0 0
1 31 1 0 1 0 0 0 1
2 32 1 0 1 0 0 1 0
3 33 0 0 1 0 0 1 1
4 34 1 0 1 0 1 0 0
5 35 0 0 1 0 1 0 1
6 36 0 0 1 0 1 1 0
7 37 1 0 1 0 1 1 1
8 38 1 0 1 1 0 0 0
9 39 0 0 1 1 0 0 1
: 3A 0 0 1 1 0 1 0
; 3B 1 0 1 1 0 1 1
< 3C 0 0 1 1 1 0 0
= 3D 1 0 1 1 1 0 1
> 3E 1 0 1 1 1 1 0
? 3F 0 0 1 1 1 1 1
@ 40 0 1 0 0 0 0 0
A 41 1 1 0 0 0 0 1
B 42 1 1 0 0 0 1 0
C 43 0 1 0 0 0 1 1
D 44 1 1 0 0 1 0 0
E 45 0 1 0 0 1 0 1
F 46 0 1 0 0 1 1 0
G 47 1 1 0 0 1 1 1
H 48 1 1 0 1 0 0 0
I 49 0 1 0 1 0 0 1
J 4A 0 1 0 1 0 1 0
K 4B 1 1 0 1 0 1 1
L 4C 0 1 0 1 1 0 0
M 4D 1 1 0 1 1 0 1
N 4E 1 1 0 1 1 1 0
O 4F 0 1 0 1 1 1 1
Visa Public
Binary
Char. Hex P 25 24 23 22 21 20
P 50 1 1 1 0 0 0 0
Q 51 0 1 1 0 0 0 1
R 52 0 1 1 0 0 1 0
S 53 1 1 1 0 0 1 1
T 54 0 1 1 0 1 0 0
U 55 1 1 1 0 1 0 1
V 56 1 1 1 0 1 1 0
W 57 0 1 1 0 1 1 1
X 58 0 1 1 1 0 0 0
Y 59 1 1 1 1 0 0 1
Z 5A 1 1 1 1 0 1 0
[ 5B 0 1 1 1 0 1 1
\ 5C 0 1 1 1 1 0 0
] 5D 0 1 1 1 1 0 1
^ 5E 0 1 1 1 1 1 0
_ 5F 1 1 1 1 1 1 1
Visa Public
A.2 Encoding Examples
This section contains four examples of Track 1 encoding.
Example 1 (Figure A–4) illustrates encoding with the re-

quired fields. The optional PIN Verification Data and
Discretionary Data fields are not used in this example.
The Visa-Reserved field shows the position of the CVV.
Example 2 (Figure A–5) illustrates encoding with the PIN
These examples represent Verification Data field. The Visa-Reserved field shows
sample formats only. They the position of the CVV.
should not be followed
literally when encoding Example 3 (Figure A–6) illustrates encoding with the
Track 1 of a magnetic Discretionary Data field. The Visa-Reserved field shows
stripe.
the position of the CVV.
Example 4 (Figure A–7) illustrates encoding with both
optional fields. The Visa- Reserved field shows the posi-
tion of the CVV.
A.2.1 Example 1: Encoding Required Fields

Information to be encoded:
PAN: 4000 00l2 3456 2 (13 digits)

Cardholder Name: MR JOHN Q PUBLIC JR
Expiration Date: 09/98
Service Code: 101
PIN Verification Data: none
Discretionary Data: none
Visa-Reserved: 11 characters with 876 for the CVV; the
remaining positions are zero filled.
Visa Public
FIGURE A–4: ENCODING REQUIRED FIELDS
A.2.2 Example 2: Encoding with PIN Verification Data Field

PAN: 4000 0012 3456 2345 (16 digits)

Expiration Date: 09/98 Service Code: 101
PIN Verification Data: 5 (PVKI) and 4321 (PVV)
Discretionary Data: none
Visa-Reserved: 11 characters with 876 for the CVV and
the remaining positions are zero filled
Visa Public
FIGURE A–5: ENCODING WITH PIN VERIFICATION DATA FIELD
A.2.3 Example 3: Encoding with Discretionary Data Field

PAN: 4000 0012 3456 2345 (16 digits)

Service Code: 101
Discretionary Data: 999999999
Visa-Reserved: 11 characters with 876 for the CVV and
the remaining positions are zero filled
Visa Public
FIGURE A–6: ENCODING WITH DISCRETIONARY DATA FIELD
A.2.4 Example 4: Encoding with PIN Verification Data and

Discretionary Data Fields
PAN: 4000 0012 3456 2345 678 (19 digits)

Embossed Cardholder Name: MR JOHN Q PUBLIC JR
Embossed Expiration Date: 09/98
Service Code: 101
Discretionary Data: 999999999
Visa-Reserved Field: 11 characters with 876 for the CVV
and the remaining positions are zero filled
Visa Public
FIGURE A–7: ENCODING WITH PIN VERIFICATION AND DISCRETIONARY

DATA FIELDS
Visa Public
A.3 Data Element Descriptions
This section describes the data elements encoded on Track

1 of the magnetic stripe.
A.3.1 Field 1 — Start Sentinel

Table A–1 describes the Start Sentinel.
TABLE A–1: FIELD 1—START SENTINEL

Attributes 1 alphanumeric
Description Indicates the initial data position on the track.
Valid value %
A.3.2 Field 2— Format Code

Table A–2 describes the Format Code data element en-
coded on Track 1 of the magnetic stripe.
TABLE A–2: FIELD 2—FORMAT CODE

Description Specifies the format for Track 1 encoding
Valid value B
A.3.3 Field 3 — Primary Account Number (PAN)

Table A–3 describes the PAN data element encoded on
Track 1 of the magnetic stripe.
TABLE A–3: FIELD 3—PRIMARY ACCOUNT NUMBER

Description A number identifying the cardholder account
Valid value 0 to 9
The ISO standard accommodates PANs of up to 19 digits.

In practice, however, a minimum of three blanks is included
in embossed PANs for human readability and data entry
purposes. Thus, the encoding specification is limited to a
16-digit PAN with no blanks included. On a card, the em-
bossed PAN is 19 characters: a 4-4-4-4 grouping with three
blank spaces (4XXX XXXX XXXX XXXX).
A.3.4 Field 4 — Separator

Table A–4 describes the Separator data element encoded
on Track 1 of the magnetic stripe.
Visa Public
TABLE A–4: FIELD 4—SEPARATOR

Description Indicates the end of a variable-length field such as the PAN
field.
Valid value ^ (caret)
Usage The separator used in Fields 4 and 6 of the track record is
identically defined.
Table A–5 describes the Cardholder Name data element

encoded on Track 1 of the magnetic stripe.
TABLE A–5: FIELD 5—CARDHOLDER NAME (1 OF 2)

Attributes 2 to 26 alphanumeric
Description Cardholder’s name.
Valid value Surname:
Hyphen (-) for hyphenated surnames
Suffix (optional)
Surname separator (/)
First name and/or initials
Title separator (.) if a title is to be encoded
Title (optional)
Usage Two delimiters are used in this field to mark the end of the
surname (or surname and suffix) and to mark the presence of
a title: the surname separator (/) and title separator (.). The
format is the same as that specified in ISO 7813, Identification
Cards—Financial Transaction Cards. CHECK CAPITALIZA-
TION AND ITALS HERE.
It is recommended that no spaces be encoded between the
last character of the name or title and the beginning of the next
field.
If Track 1 on a Visa Electron card does not contain a specific
cardholder name, the generic name ELECTRON VISA
CARDHOLDER must be encoded in this field.
For airline ticketing, the cardholder name is the same as that
encoded on the stripe. Therefore, an airline would identify a
passenger by the encoded surname, with other names and
any title used in the order in which they are encoded, that is,
the data following the surname separator (/).
The format of the name on Track 1 allows for a minimum field
length of two positions. The minimum accommodates cases in
which a cardholder has a one-character name. Therefore, the
second character must be the surname separator to mark the
end of the surname.
While the formats of encoded names and embossed names
will differ, Issuers should try to keep the content of the en-
coded and embossed names the same.
Visa Public
A.3.5 Cardholder Name Usage Examples

In Figure A–8, the cardholder’s name is embossed as DR
THOMAS A HARRIS JR. Note that the title separator “.” fol-
lows the first name THOMAS and the initial A.
FIGURE A–8: CARDHOLDER NAME USAGE EXAMPLE 1
In Figure A–9, the cardholder’s name is embossed with ini-

tials, such as MRS J L YOUNG.
In Figure A–10, the cardholder’s name is embossed without

a title, such as PAT B SMITH. No title separator (.) or title is
encoded.
In Figure A–11, the cardholder’s surname is hyphenated,

such as L AL-SHAMARI.
In Figure A–12, the generic name ELECTRON VISA

CARDHOLDER is encoded.
Table A–6 describes the Separator data element encoded

TABLE A–6: FIELD 6—SEPARATOR

Description Indicates the end of a variable-length field such as the PAN
field.
Valid value ^ (caret)
Usage The separator used in Fields 4 and 6 of the track record is
identically defined.
Visa Public
A.3.6 Field 7 — Card Expiration Date

Table A–7 describes the Card Expiration Date field encoded
TABLE A–7: FIELD 7—CARD EXPIRATION DATE

Attributes 4 numeric in the format: YYMM.
Description Year and month after which the card can no longer be used.
Valid value YY must be 00 to 99
MM must be 01 to 12
Usage The YYMM format follows ISO conventions for machine-
processable dates. All cards with a Visa, Visa Electron, or
Delta mark must have a finite expiration date that is no more
than 20 years from the date of card issue.
A.3.7 Field 8 — Service Code

Table A–8 describes the Service Code data element en-
TABLE A–8: FIELD 8—SERVICE CODE

Attributes 3 numerics
Description A sequence of digits that, taken as a whole, defines various
services; differentiates cards used in international or national
interchange; designates PIN requirements; and identifies card
restrictions.
Valid value The values allowed are made up of three individual digits: 1, 2,
and 3. To be valid, each digit must be one of the acceptable
values listed in Table A–9. These service code values apply to
Visa card products (Visa, Plus, Visa Electron, Interlink, and
Delta cards).
Not all combinations of individually valid digits result in a

valid service code. Also, while a large number of service
codes can be constructed from the allowed values, only
specific service codes are authorized for individual Visa card
products.
Visa Public
Table A–9 describes the service code values encoded on

Track 1 that are currently valid for Visa card products.
TABLE A–9: SERVICE CODE DIGIT VALUE DESCRIPTIONS

Digit Value Description
1 0 Invalid for Visa card products
1 International card
2 International card—alternate technology (EMV-approved chip card containing VSDC applications)
3 Invalid for Visa card products
5 National use only
6 National use only—alternate technology (EMV-compliant chip card containing VSDC applications)
7 Private cards—invalid for Visa card products
2 0 Normal authorization
2 Positive authorization mandatory
3 0 PIN required
1 Normal verification
3 Valid at ATMs only
6 Prompt for PIN if PIN pad present
Visa Public
A.3.7.1 Service Code Usage

As other uses are identified, Visa International occasionally
assigns additional service codes. An Issuer, group of Issu-
ers, or country can apply to Visa International for the as-
signment of additional service codes for local, national, or in-
ternational usage. .
TABLE A–10: VALID SERVICE CODES BY CARD PRODUCT

Visa Plus
Credit, Co-branded Co-branded
Debit, Visa Check Visa Plus with EFT
Service and Visa and Travel ATM Processor
Code Delta Electron Interlink Interlink Money only Marks
101 Valid Valid

106 Valid Valid
120 Valid1 Valid Valid Valid Valid
121 Valid
123 Valid
126 Valid
201 Valid
206 Valid Valid
220 Valid Valid
221 Valid
223 Valid
226 Valid
501 Valid
506 Valid
520 Valid1
521 Valid
526 Valid
601 Valid
606 Valid
621 Valid
626 Valid
1
Service codes 121, 126, 521, and 526 are recommended for Visa Electron cards. Issuers who plan to use service code
values 120 and 520 for Visa Electron cards should consult their Visa Customer Services Representative.
Visa Public
A.3.8 Field 9 — PIN Verification

Table A–11 describes the PIN Verification element encoded
TABLE A–11: FIELD 9—PIN VERIFICATION

Description Information needed to verify a PIN, using the Visa PIN Verifi-
cation Value (PVV)
Valid value Numerics 0 to 9
Position 1: PIN Verification Key Index (PVKI) = 0 or 1-6
Positions 2-5: PIN Verification Value (PVV)
Usage The PIN verification data is required on Visa Gold/Premier

cards. It is optional on other cards.
If not required or needed, this field can be omitted from the
stripe.
If the Issuer uses the PIN Verification Service (PVS) for

some, but not all issued cards, the PIN Verification field
(both PVKI and PVV) should be zero-filled on those cards
not using the PVS. If the Issuer does not use the PVS for
any cards in a card range, the zero-fill requirement is not
needed.
For more information on the PVKI and PVV, see the Visa
Smart Debit and Visa Smart Credit Member Implementation
Guide for Acquirers.
Visa Public
A.3.9 Field 10 — Discretionary Data

Table A–12 describes the Discretionary data element en-
TABLE A–12: FIELD 10—DISCRETIONARY DATA

Attributes 8 to 10 alphanumerics
Description Information that the Issuer uses for on-us transactions and
wants to have transmitted through the V.I.P. System for inquir-
ies on interchange transactions.
Visa fleet service purchasing cards with a BIN range of
448450 to 448699 are required to use the last three positions
of the discretionary data field to provide instructions for cus-
tomized prompts.
Valid value Any value in the character ranges 0 to 9 and A to Z, a space, a
comma, or a slash (/) .
For Visa fleet service purchasing cards, valid values are as
follows:
Position 1: Reserved = 0
Position 2: Service Enhancement Indicator = 0, 1, or 2
Position 3: Service Prompt = 0, 1, 2, 3, 4, or 5
Usage On Track 1, the length of this optional field is based on the
lengths of the Cardholder Name field and on the presence or
absence of the PIN Verification Data field and fleet service
field.
If the Cardholder Name field contains 26 characters (the

maximum allowed), then positions 8, 11, 13, or 16 are avail-
able for discretionary data as shown in Table A–13.
Table A–13 describes the matrix for the Discretionary data

field encoded on Track 1 of the magnetic stripe.
TABLE A–13: MATRIX FOR DISCRETIONARY DATA FIELD

PIN Verification PIN Verification
length = 0 length = 5
16-digit PAN 13 8
Visa Public
Figure A–13 illustrates a 16-digit PAN, 26-position name,

and 5-position PIN Verification field.
FIGURE A–13: PIN VERIFICATION FIELD
When the Cardholder Name field contains less than

26 characters, the Issuer can increase the length of the Dis-
cretionary Data field by the number of unused positions.
At the Issuer's option, the CVV located in the Visa-Reserved

field can also be placed in the Discretionary Data field. This
option provides the Issuer additional ease of verification.
Visa Public
A.3.10 Field 11 — Visa-Reserved

Table A–14 describes the Visa-Reserved data element en-
TABLE A–14: FIELD 11—VISA-RESERVED

Attributes 11 alphanumerics
Description Last 11 positions of Track 1, excluding the End Sentinel and
LRC character. Track 1 can vary in length depending on the
presence or absence of the PIN Verification Data and Discre-
tionary Data fields. The location of the last 11 positions of the
track varies accordingly. See Figure A–4 through Figure A–7
for examples.
This fixed-length, required field is used by Visa for the follow-
ing subfields:
11.1 Card Verification Value
11.2 Authorization Control Indicator (ACI)
Valid value Positions 1–2: zeroes

Positions 3–5 (CVV): 3 numerics
Position 7: zero
Position 8 (ACI): A to Z or zero
Positions 9–11: zeroes
Table A–15 describes the CVV data element encoded on

TABLE A–15: FIELD 11.1—CARD VERIFICATION VALUE

Attributes 3 numerics (positions 3 to 5 of the Visa-Reserved field)
Description CVV is required on Track 1 of all Visa, Visa Electron, and Plus
cards.
It is a unique check value calculated from the data encoded in
the stripe, using a secure cryptographic process and a key
known only to the Issuer and Visa.
Valid value 0 to 9
CVV is required on Track 1 of all Visa, Visa Electron, and

Plus cards. Once encoded on the stripe, the CVV deters
counterfeit card usage by validating encoded card informa-
tion during the authorization process.
When the CVV is first implemented, Issuers using Visa veri-

fication must supply Visa with the expiration date of the card
series. All cards expiring on or after this date are encoded
with the CVV.
Visa Public
Table A-16 describes the Authorization Control Indicator

data element encoded on Track 1 of the magnetic stripe.
TABLE A–16: FIELD 11.2—AUTHORIZATION CONTROL INDICATOR

Attributes 1 alphanumeric (position 8 of the Visa-Reserved field)
Description Used for optional processing for the Positive Cardholder Au-
thorization Service (PCAS), which describes the risk level and
Issuer PIN policies associated with individual cardholders.
The risk levels reflect the lowest to the highest risk, from A to
D, respectively.
Valid value Zero, C, Z, Y, or X. Use zero when an ACI code is not in-
cluded. If the ACI code is included, select C, Z, Y, or X as
appropriate for the risk level (see Table A–17).
Table A–17 describes the ACI data element encoded on

TABLE A–17: ACI VALUES

ACI Risk Level PIN Policy
C A Optional
Z B Optional
Y C Optional
X D Optional
A.3.11 Field 12 — End Sentinel

Table A–18 describes the End Sentinel data element en-
TABLE A–18: FIELD 12—END SENTINEL

Description Character that follows the final character of data recorded on
the track.
Valid value ? (question mark)
Visa Public
A.3.12 Field 13 — Longitudinal Redundancy Check

Table A–19 describes the Longitudinal Redundancy Check
(LRC) data element encoded on Track 1 of the magnetic
stripe.
TABLE A–19: FIELD 13—LONGITUDINAL REDUNDANCY CHECK

Attributes 1 character
Description Verification value that ensures that no data has been lost in
the stripe-reading process. The LRC is equivalent to a check
digit of the entire track, including the control characters.
Valid value Any computed value
Usage With the exception of the parity bit, the value of each bit in the
LRC character is defined so that the total count of “1” bits
encoded in the corresponding bit locations of all the characters
of the data message, including the Start Sentinel, the track
data, the End Sentinel, and LRC characters, is even.
The parity bit in the LRC character is not a parity bit for the
individual parity bits of the data message; it is the parity bit for
the LRC character.
Visa Public
Appendix B: Track 2 Data

WHAT’S COVERED This appendix describes Visa standards for the contents of
Track 2 of the magnetic stripe and the magnetic stripe im-
Track 2 Content Re- age on the integrated chip. Visa requirements conform to
quirements the International Organization for Standardization (ISO)
Encoding Examples standard 7811/2, Identification cards—Recording tech-
Data Element Descrip- nique—Part 2: Magnetic Stripe and ISO standard 7813,
tions Identification cards—Financial transaction cards.
Visa Public
B.1 Track 2 Content Requirements
Requirements for the contents of a magnetic strip conform

to ISO 7813.
Visa specifications conform to national and industry stan-

dards and are consistent with the standards recognized by
magnetic-stripe vendors.
B.1.1 Record Format

Table B–1 displays the Track 2 record format. The maxi-
mum length of Track 2 is 40 characters. The track must in-
clude the Start Sentinel, field separator, End Sentinel, and
Longitudinal Redundancy Check (LRC).
TABLE B-1: TRACK 2 RECORD FORMAT
Visa Public
B.1.2 Character Set

Table B–2 describes the Track 2 character set. This table
corresponds to the character set table in ISO standard
7811/2, Section 10.1.3. It is also identical to the coded char-
acter set in ISO/IEC 7811-4 and is derived from ASCII.
The hardware manufacturer specifies the data formats pro-

vided to an encoding machine. The encoding device must
encode data characters using odd parity. Clocking bits for
synchronization are not considered data.
An even-parity LRC character must be the last character in

a track record.
TABLE B–2: TRACK 2 CHARACTER SET

Binary
3
Char. Hex P 2 22 21 20
0 30 1 0 0 0 0
1 31 0 0 0 0 1
2 32 0 0 0 1 0
This coded character set is
identical to the coded char- 3 33 1 0 0 1 1
acter set in ISO/IEC 7811-4
and is derived from ASCII 4 34 0 0 1 0 0
5 35 1 0 1 0 1
6 36 1 0 1 1 0
7 37 0 0 1 1 1
8 38 0 1 0 0 0
9 39 1 1 0 0 1
: 3A 1 1 0 1 0
; 3B 0 1 0 1 1
< 3C 1 1 1 0 0
= 3D 0 1 1 0 1
> 3E 0 1 1 1 0
Visa Public
B.2 Encoding Examples
This section contains four examples of Track 2 encoding.
Example 1 (Figure B–1) illustrates encoding the required

fields without the PIN Verification Data field, but with the
Discretionary Data field, including the CVV in the first
three positions of the field.
These examples represent
sample formats only. They Example 2 (Figure B–2) illustrates encoding with the PIN
should not be followed Verification Data field and the Discretionary Data field
literally when encoding including the CVV in the first three positions of the field.
Track 2 of a magnetic
stripe.
It is an example of an Interlink mark appearing on a Visa
debit card.
Example 3 (Figure B–3) illustrates encoding without the
PIN Verification Data field and with the Discretionary
Data field that contains only the CVV (remainder of the
field is truncated). This example also contains an expi-
ration date of December 2002.
Example 4 (Figure B–4) illustrates encoding with the PIN
Verification Data field and the Discretionary Data field
that contains Issuer information in the first three posi-
tions of the field, followed by the CVV. This example
represents a Track 2 using the maximum allowable posi-
tion.
B.2.1 Example 1: Encoding with Discretionary Data Field

PAN: 4000 0012 3456 2 (13 digits)

Service Code: 120
Discretionary Data: 876234567 (first three positions =
CVV)
Visa Public
FIGURE B–1: ENCODING WITH DISCRETIONARY DATA FIELD
B.2.2 Example 2: Encoding with PIN Verification Data and

PAN: 4000 0012 3456 7892 (16 digits)

Service Code: 101
Discretionary Data: 87623456 (first three positions =
CVV)
FIGURE B–2: ENCODING WITH PIN VERIFICATION AND DISCRETIONARY

DATA
Visa Public
B.2.3 Example 3: Encoding with Discretionary Data Field

(CVV Only)
PAN: 4000 0012 3456 7892 (16 digits)

Service Code: 120
Discretionary Data: 876 (CVV only)
FIGURE B–3: ENCODING WITH DISCRETIONARY DATA
Visa Public
B.2.4 Example 4: Encoding with PIN Verification Data and

PAN: 4000 0012 3456 7890 122 (19 digits)

Service Code: 120
Discretionary Data: 999876 (first three positions = issuer
information; second three positions = CVV; remaining
positions are truncated)
FIGURE B–4: ENCODING WITH PIN VERIFICATION AND DISCRETIONARY

DATA
Visa Public
B.3 Data Element Descriptions
This section describes the data elements encoded on

Track 2.
B.3.1 Field 1 — Start Sentinel

Table B–3 describes the Start Sentinel.
TABLE B–3: FIELD 1—START SENTINEL

Attributes 1 alphanumeric (numeric values only)
Description Indicates the initial data position on the track
Valid value See Table B-2
B.3.2 Field 2 — Primary Account Number

Table B–4 describes the Primary Account Number (PAN)
data element encoded on Track 2 of the magnetic stripe.
TABLE B–4: FIELD 2—PRIMARY ACCOUNT NUMBER

Attributes 12 to 19 numerics
Description Cardholder account number; the last digit is a mod-10 calcu-
lated digit
Valid value Any valid ISO cardholder account number
Usage When encoded on the magnetic stripe, the PAN must not have
any spaces.
B.3.3 Field 3 — Separator

Table B–5 describes the Separator data element encoded
TABLE B–5: FIELD 3—SEPARATOR

Attributes 1 alphanumber
Use of multiple separators Description Indicates the end of a variable-length field
may cause problems in such as the PAN field; only one separator is
some Acquirer systems. generally positioned on the track
Visa Public
B.3.4 Field 4 — Card Expiration Date

Table B–6 describes the Card Expiration Date data element
encoded on Track 2 of the magnetic stripe.
TABLE B–6: FIELD 4—CARD EXPIRATION DATE

Attributes 4 numerics in the format YYMM
Description Year and month after which the card can no longer be used
Valid value YY must be 00 to 99.
MM must be 01 to 12.
Usage The YYMM format follows ISO conventions for machine-
processed dates. All cards with a Visa, Visa Electron, or Delta
mark must have a finite expiration date that is no more the 20
years from the date of card issue.
B.3.5 Field 5 — Service Code

Table B–7 describes the Service Code data element en-
TABLE B–7: FIELD 5—SERVICE CODE

Description A sequence of digits that is used to:
Define various service attributes
Differentiate cards used in international and national
interchange
Designate PIN requirements
Identify card restrictions
Valid value The values allowed are made up of three individual digits: 1, 2,
and 3.
To be valid, each digit must be one of the acceptable values in
Table B–8. These service code values apply to Visa card
products (Visa, Plus, Visa Electron, Interlink, and Delta cards).
Not all combinations of individually valid digits result in a

valid service code. Also, while a large number of service
codes can be constructed from these values, only specific
service codes are authorized for individual Visa card prod-
ucts.
Visa Public
Table B–8 describes the service codes that are currently

valid for Visa card products. Table B–8 describes the Ser-
vice Code Digit Value data element encoded on Track 2 of
the magnetic stripe.
TABLE B–8: SERVICE CODE DIGIT VALUE DESCRIPTIONS

DIGIT VALUE DESCRIPTION
1 0 Invalid for Visa card products
1 International card
2 International card—alternate technology (EMV-approved chip card containing VSDC applications)
5 National use only
6 National use only—alternate technology (EMV-compliant chip card containing VSDC applications)
7 Private cards—invalid for Visa card products
2 0 Normal authorization
2 Positive authorization mandatory
3 0 PIN required
1 Normal verification
2 Invalid for Visa card products.
3 Valid at ATMs only
5 Invalid for Visa card products1
6 Prompt for PIN if PIN pad present
7 Invalid for Visa card products1
1
This code has been defined for future use. No Visa card products are to be issued with this value until spe-
cific approval is given by the Visa International Board of Directors.
Visa Public
B.3.5.1 Service Code Usage

Visa International occasionally assigns additional service
codes as other uses are identified. An Issuer, group of Is-
suers, or country can apply to Visa International for the as-
signment of additional service codes for local, national, or in-
ternational usage.
Tables B–9 describes the preferred service codes by card

product.
TABLE B–9: VALID SERVICE CODES BY CARD PRODUCT

Visa Plus
Credit, Co-branded Co-Branded
Debit, Visa Check Visa Plus with EFT
Service and Visa and Travel ATM Processor
Code Delta Electron Interlink Interlink Money only Marks
101 Valid Valid
106 Valid Valid
120 Valid1 Valid Valid Valid Valid
121 Valid
123 Valid
126 Valid
201 Valid
206 Valid Valid
220 Valid Valid
221 Valid
223 Valid
226 Valid
501 Valid
506 Valid
520 Valid1
521 Valid
526 Valid
601 Valid
606 Valid
621 Valid
626 Valid
1
Service codes 121, 126, 521, and 526 are recommended for Visa Electron cards. Issuers who plan to use service code
values 120 and 520 for Visa Electron cards should consult their Visa Customer Services Representative.
Visa Public
B.3.6 Field 6 — PIN Verification

Table B–10 describes the PIN Verification data field en-
TABLE B–10: FIELD 6—PIN VERIFICATION

Description Used to verify a PIN; generally called Visa
PVV or PIN offset value
Valid value Numbers 0 to 9
Position 1: PIN Verification Key Index
(PVKI) = 0 or 1 to 6
Position 2: PIN Verification Value (PVV)
Usage The PIN verification data is required on
Visa Gold/Premier cards. It is optional on
other cards, depending upon the Issuer’s
PIN verification process.
If not required or needed, the field can be
omitted from the stripe.
If the Issuer uses the PIN Verification Service (PVS) for

some, but not all issued cards, the PIN Verification Data
field (both PVKI and PVV) should be zero-filled on those
cards not using the PVS. If the Issuer does not use the PVS
for any cards in a card range, the zero-fill requirement is not
needed.
Figure B–5 illustrates a 16-digit PAN, 26-position name, and

5-position PIN Verification field.
FIGURE B–5: PIN VERIFICATION FIELD
Visa Public
B.3.7 Field 7 — Discretionary Data

Table B–11 describes the Discretionary Data element en-
TABLE B–11: FIELD 7—DISCRETIONARY DATA

Attributes Up to 17 numerics, remaining positions can be for 3-digit CVV.
The three-digit CVV must
be encoded in the Discre- Description Includes the CVV, plus any valid information that the Issuer
tionary Data field. While wants to transmit in the transaction.
Visa recommends placing CVV is required on Track 2 of all Visa, Visa Electron, and Plus
the CVV at the start of this cards.
field, any three contiguous
positions can be used. Valid value Any valid non-control or non-reserved character in Table B–2
Usage On Track 2, the maximum length of this optional field is based
on the length of the PAN and on the presence or absence of
the PIN Verification field. Because Discretionary Data fields
are optional, they should not be filled with pad characters,
which are meant solely to fill all positions on Track 2.
The 3-digit CVV must be encoded in the Discretionary Data
field. While Visa recommends placing the CVV at the start of
this field, any three contiguous positions can be used. Figure
B–6 illustrates the recommended placement of the CVV in an
8-digit Discretionary Data field.
If Visa is to provide CVV validation for an Issuer, the Issuer

must provide Visa with the location of the CVV on Track 2.
The CVV location is described by its displacement from the
end of the Service Code field. In Figure B–6, for example,
the displacement is 5. If the PIN Verification Field were not
to be encoded on the stripe, the displacement would be 0.
For more information on calculating the Track 2 CVV, see

the Visa Smart Debit and Visa Smart Credit Acquirer Im-
plementation Guide.
Visa Public
Figure B–6 illustrates the recommended placement of the

CVV in an 8-digit Discretionary Data field.
FIGURE B–6: DISCRETIONARY DATA FIELD
B.3.8 Field 8 — End Sentinel

Table B–12 describes the End Sentinel element encoded on
TABLE B–12: FIELD 8—END SENTINEL

Description Indicates the final data position on the track.
B.3.9 Field 9 — Longitudinal Redundancy Check

Table B–13 describes the Longitudinal Redundancy Check
(LRC) element encoded on Track 2 of the magnetic stripe.
TABLE B–13: FIELD 9—LONGITUDINAL REDUNDANCY CHECK

Attributes 1 digit 0 to F
Description Verification value that ensures that no data has been lost in
the stripe-reading process. The LRC is equivalent to a check
digit of the entire track, including the control characters.
Valid value Any computed value
Usage With the exception of the parity bit, the value of each bit in the
LRC character is defined so that the total count of “1” bits
encoded in the corresponding bit locations of all characters of
the data message, including the Start Sentinel, the track data,
the End Sentinel, and LRC characters, is even.
The parity bit in the LRC character is not a parity bit for the
individual parity bits of the data message; it is the parity bit for
the LRC character.
Visa Public
Appendix C: Reference Materials

This section contains a list of the primary references cited in
this book, as well as additional documents that may be use-
ful and relevant for card acceptance device vendors and for
Acquirers. A thorough understanding of these documents is
recommended.
This list should not be considered definitive. Vendors

Unless otherwise noted, all and Acquirers may need policy, operational, and technical
materials listed here are information not contained in these documents. In addition,
available from your Visa
regional representative. the documents referenced here are updated periodically. To
ensure that you have the most recent version, contact your
Visa representative or visit the Visa websites mentioned in
this document.
Visa Public
Title and Description Audience User

EMV2000 Integrated Circuit Card Specification for Payment Sys- Financial Institu- Technical
tems tions, Vendors
Provides specifications developed jointly by Europay, MasterCard, and
Visa for chip-based payment processing. Individual volumes include:
Book 1 – Application Independent ICC to Terminal Interface Require-
ments, version 4.0, December 2000
Book 2 – Security and Key Management, version 4.0, December 2000
Book 3 – Application Specification, version 4.0, December 2000
Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements,
version 4.0, December 2000
Analysis of EMV2000 Changes for Backwards Compatibility, December
2000
EMV Minimum Data Elements Requirements, 1998
EMV Principles and Policies for Scheduled and Unscheduled Payment
System Public Key Revocation, March 1999
EMV Terminal Payment System Public Key Management Requirements,
version 1.0, March 1999
The following are related to the vendor product-approval process:
EMVCo Type Approval Terminal Level 1 Administrative Process
EMVCo Type Approval Terminal Level 2 Administrative Process
EMVCo approved vendor products
These documents are available on the EMVCo website.
As EMV is updated periodically, please ensure that you have the most
recent version by checking with your Visa representative or the EMVCo
website. Check for bulletins on the EMVCo website.
Visa Integrated Circuit Card Specifications (VIS), version 1.4.0, April Issuers, Acquir- Technical
2001 ers, Vendors
Furnishes the specifications for Visa chip cards and terminals and serves
as a companion guide to EMV. Individual volumes include:
VIS Application Overview
VIS Card Specification
VIS Terminal Specification
These documents are available on the Visa website at
www.visa.com/smartcardspecs.
Visa International Operating Regulations, updated versions are pub- Visa Members Policy, Op-
lished twice each year in May and November erations
Provides regulations for issuers and acquirers, including rules governing
VSDC transactions, dispute processing, and interchange rates.
Visa Regional (and domestic market) Operating Regulations, up- Visa Members Policy, Op-
dated versions are published twice each year in May and November erations
Provides regulations for Issuers and Acquirers, including rules governing
VSDC transactions, dispute processing, and interchange rates. Indi-
cates Visa region and market-specific regulatory requirements that may
involve a variance from the Visa International Operating Regulations.
VSDC Member Implementation Guide for Acquirers, Version 3.0 Visa Members Operations,
Provides guidelines for acquirers involved in the implementation of new Technical
VSDC programs.
This document is available from your Visa regional representative.
Visa Smart Credit/Visa Smart Debit (VSDC) Technical Manual Visa Members Technical
Delineates the requirements and necessary changes to process VSDC
transactions online, through Base I/Base II and SMS. The manual sup-
plements the standard series of VIP and BASE manuals.
Visa Public

Payment Technology Standards, September 2002 Visa Members Operations,
Describes the following: Standards applied to PINs (personal identifica- Technical
tion numbers), Cardholder Verification Value (CVV) techniques, and the
management of cryptographic keys. Guidelines for encoding account
and cardholder data on Track 1 and Track 2 of the magnetic stripe of the
Visa card. Visa Smart Debit/Visa Smart Credit (VSDC) chip and the
Track 2 equivalent data, and the Track 1 discretionary data.
Visa PIN Security Requirements Visa Members Technical
Describes the minimum security requirements for online PIN-based Visa
transactions. Outlines the minimum acceptable requirements for secur-
ing PINs and encryption keys. Assists all participants in the retail elec-
tronic payment system in establishing assurances that cardholder PINs
will not be compromised.
Visa PIN Entry Device Security Requirements Visa Members, Technical
Provides Visa’s enhanced PIN entry device security requirements, in- Vendors
cluding procedures for laboratory evaluation and PED testing. Individual
documents include:
PIN Entry Device Testing and Approval Program Guide
PIN Entry Device Security Requirements Manual
PIN Entry Device Online Evaluation Vendor Questionnaire
PIN Entry Device Offline Evaluation Vendor Questionnaire
Visa PED Test Process Flow
Visa Online Derived Test Requirements
Visa Offline Derived Test Requirements
These documents are available at www.visa.com/pin.
Common Electronic Purse Specifications (CEPS) Visa Members, Technical
Defines requirements for all components needed by an organization to Vendors
implement a globally interoperable electronic purse program.
These documents are available at www.cepsco.com.
Visa Cash CEPS Specifications Visa Members, Technical
implement a globally interoperable Visa Cash program, while maintaining
full accountability and auditability.
These documents are available at www.international.visa.com.
Terminal Application for PSAM Applications (TAPA) Vendors Technical
Defines the architecture for multiple-application card acceptance termi-
nals that use Purchase Secure Application Modules (PSAMs).
This document is available at www.international.visa.com.
Visa Certificate Authority User’s Guide Visa Members Operations,
Outlines activities for requesting Visa public keys from the Visa Certifi- Technical
cate Authority.
This document is available by contacting Visa Central Approval Authority
at caa@visa.com.
Visa Horizon Specifications Visa Members, Technical
implement a globally interoperable Visa Horizon program.
This document is available by contacting Visa Central Approval Authority
at caa@visa.com.
Visa Public

Acquirer Device Validation Tool (ADVT) Kit User's Guide Visa Members Operations,
Contains a set of test scripts and test cards that can be used by Acquir- Technical
ers to ensure that chip terminals are configured correctly prior to de-
ployment.
Global (Open) Platform Specifications Acquirers, Ven- Technical
Provides core architecture for smart-card infrastructure, as well as secu- dors
rity and card management technology. These card and terminal specifi-
cations collectively define a smart-card platform upon which standard-
ized applications can be added. Individual volumes include:
GlobalPlatform Device Framework, version 2.0
GlobalPlatform Profile Specification, version 1.0
GlobalPlatform Scripting Specification, version 1.0
These documents are available at www.globalplatform.org.
International Organization for Standardization ("ISO") Financial Institu- Technical
A network of national standards institutes from 140 countries working in tions, Vendors
partnership with international organizations, governments, industry,
business, and consumer representatives. A bridge between public and
private sectors
www.iso.ch
ANSI Financial Institu- Technical
A private, non-profit organization (501(c)3) that administers and coordi- tions, Vendors
nates the U.S. voluntary standardization and conformity assessment
system.
www.ansi.org
X9 Financial Institu- Technical
Accredited by the American National Standards Institute (ANSI), XP de- tions, Vendors
velops Standards for check processing, electronic check exchange, PIN
management and security, financial industry use of data encryption, and
wholesale funds transfer, among others.
The X9 organization has recently updated and released its ANSI X9.24
(Part 1) - 2002 standard (Financial Services - Retail Management) to
include requirements for TDES, including the use of TDES for DUKPT.
www.x9.org
Visa Public
Appendix D: Acronyms and Glossary

WHAT’S COVERED This section contains a list of acronyms and a glossary of
terms used in this book. In general, terminology reflects
Acronyms Visa standard usage or the most common usage in the field.
Glossary However, certain terms and their definitions may vary from
region to region and from one market sector or merchant to
another.
Visa Public
D.1 Acronyms
For the purpose of this document, the following acronyms

apply:
Acronym Meaning
AAC Application Authentication Cryptogram
ADT Automated Dispensing Transaction
AID Application Identifier
AIP Application Interchange Profile
API Application Programming Interface
ARPC Authorization Response Cryptogram
ARQC Authorization Request Cryptogram
ATM Automated Teller Machine
BIN BASE or Bank Identification Number
BPS Bytes per Second
CA Certificate Authority
CAA Central Approval Administration
CAD Card Acceptance Device
COPAC Chip Offline Pre-Authorized Card
CVM Cardholder Verification Method
CVV Cardholder Verification Value
DDA Dynamic Data Authentication
DES Data Encryption Standard
DUKPT Derived Unique Key Per Transaction
EMV Europay, MasterCard, Visa
ICC Integrated Circuit Card
IFM Interface Module
ISO International Standards Organization
KB Kilo Byte
LAT Limited Amount Transaction
LRC Latitudinal Redundancy Check
MB Mega Byte
MAC Message Authentication Code
MSI Magnetic Stripe Image
PAN Primary Account Number
PC Personal Computer
PED PIN Entry Device
PIN Personal Identification Number
Visa Public
Acronym Meaning
POS Point-of-Sale
PSAM Purchase Secure Application Module
RSA Rivest, Shamir, and Adleman Algorithm
SAM Secure Access Module
SDA Static Data Authentication
SET Secure Electronic Transaction
SMS Single-Message System
SST Self Service Transaction
TAC Terminal Action Code
TC Transaction Certificate
TDES Triple Data Encryption Standard
TRM Terminal Risk Management
TVR Terminal Verification Results
VIS Visa Integrated Circuit Card Specification
VSDC Visa Smart Debit and Visa Smart Credit
Visa Public
D.2 Glossary
For the purpose of this document, the following terms apply:
Acquirer
A bankcard association member that initiates and maintains
relationships with merchants that accept Visa or MasterCard
cards.
Application Authentication Cryptogram (AAC)

A cryptogram generated by the card at the end of offline and
online declined transactions. It can be used to validate the
risk management activities for a given transaction.
Application Identifier (AID)

A data element that indicates the application, such as Visa
Smart Debit and Visa Smart Credit or Visa Electron.
Application Program Interface (API)

A set of routines, protocols, and tools for building software
applications.
Asymmetric Algorithm
An algorithm or series of algorithms that utilizes two different
keys: a secret one for encrypting a message and a public
one for decrypting it.
Attendant
The sales or service associate present at the point of trans-
action.
Attended
An environment where the sales or service associate is pre-
sent when a transaction occurs at the device.
Authorization
A process where an Issuer, or a representative of the Issuer,
approves, declines, or refers a transaction.
Visa Public
Authorization Request Cryptogram (ARQC)

A cryptogram used for a process called Online Card Authen-
tication. This cryptogram is generated by the card for trans-
actions requiring online authorization. It is the result of card,
terminal, and transaction data encrypted by a Data Encryp-
tion Standard (DES) key. It is sent to the Issuer in the au-
thorization or full financial request. The Issuer or Issuer’s
representative validates the ARQC to ensure that the chip
card is authentic and card data was not copied from a
skimmed card.
Authorization Response Cryptogram (ARPC)

A cryptogram used for a process called Online Issuer Au-
thentication. This cryptogram is the result of the ARQC and
the Issuer’s authorization response encrypted by a DES key.
It is sent to the card in the authorization response. The card
validates the ARPC to ensure that it is communicating with
the valid Issuer.
Automated Teller Machine (ATM)

An unattended terminal that has electronic capability to send
transactions online for authorization, accepts PINs, proc-
esses transactions, and disburses currency.
Card Acceptance Device (CAD)

A device capable of reading and processing the magnetic
stripe or chip on a card for the purpose of performing a ser-
vice, such as obtaining an authorization or processing a
payment.
Cardholder
The individual to whom a financial institution has issued a
Visa card product.
Cardholder Verification Method (CVM)

A method used to confirm the identity of a cardholder and to
signify cardholder acceptance of the transaction, such as
signature, offline PIN, and online PIN.
Cash-Back
A transaction that provides incremental cash to the card-
holder when making a purchase. Cash-back transactions
are subject to Visa International and Regional Operating
Regulations.
Certificate Authority
A trusted central administration that issues and revokes cer-
tificates according to an advertised policy and is willing to
vouch for the identities of those to whom it issues certifi-
cates and their association with a given key.
Visa Public
Chip
An integrated circuit designed to perform processing and/or
memory functions.
Chip Capable
A card acceptance device that is designed and constructed
to facilitate the addition of a chip card reader. This means
that the device has a port at its back into which a peripheral
chip card reader could be plugged, as well as enough mem-
ory to enable chip card processing.
Chip Card
A plastic card embedded with an integrated circuit, or micro-
processor, that communicates information to a card accep-
tance device.
Chip Offline Pre-Authorized Card (COPAC)

A payment card that allows offline, PIN-protected purchase
approval and payment processing, using two chip cards, one
for the merchant and one for the cardholder. The Visa Hori-
zon card is a COPAC. See also Visa Horizon.
Clearing
All of the functions necessary to collect a clearing record
from an Acquirer in the transaction currency and deliver it to
the Issuer in the billing currency, or to reverse this process.
Combined Data Authentication (CDA)

A security technique for offline transactions that combines
DDA with the generation of a card’s application cryptogram
to assure card validity. CDA is referred to as Combined
DDA/Generate AC (application cryptogram) in the VIS speci-
fications.
Cryptogram
A numeric value that is the result of data elements entered
into an algorithm and then encrypted – commonly used to
validate data integrity. Cryptograms used for VSDC are the
Authorization Request Cryptogram (ARQC), Authorization
Response Cryptogram (ARPC), Transaction Certificate, and
Application Authorization Cryptogram (AAC).
Data Encryption Standard (DES)

A cryptographic algorithm in which two users share the
same secret key. This algorithm is used in VSDC transac-
tions for various functions, such as Online Card Authentica-
tion.
Visa Public
Derived Unique Key Per Transaction (DUKPT)

A symmetric algorithm encryption technique that uses a
unique DES key derived from the previous DES key to en-
crypt the PIN for each new transaction.
Device
Generic term used to refer to any device, attended or unat-
tended, that accepts and processes payment card transac-
tions. See also Terminal.
Dynamic Data Authentication (DDA)

A security technique used in offline transactions to establish
that the parameters on a chip card are genuine.
Early Data Option

A VSDC implementation in which the Issuer or Acquirer
makes minimal host system changes at the beginning of
their chip program and migrates to Full Data Option changes
at a later time. See also Full Data Option.
EMV
Commonly used abbreviation for Europay International,
MasterCard International, and Visa International, the organi-
zations that jointly developed the EMV specifications for
global chip infrastructure.
EMV Approved
A device that has been tested and certified by an EMVCo-
approved laboratory to conform to all security, interoperabil-
ity, and functionality requirements of the EMV and VIS
specifications.
EMV Compliant
A claim made to meet EMVCo’s Type Level specification,
but the device may not have gone through the EMV testing
and approval process.
EMV Specifications
Technical specifications developed jointly by Europay Inter-
national, MasterCard International, and Visa International,
outlining the interaction between chip cards and card accep-
tances devices to ensure global interoperability. The EMV
specifications are upgraded and maintained by EMVCo.
Encryption
The use of algorithms to encode plaintext data, such as
PINs, to ensure that the data cannot be read by unauthor-
ized parties.
Visa Public
Fallback
A set of procedures used to process transactions in the
event the primary method of card acceptance fails. For ex-
ample, when a chip card is accepted via its magnetic stripe
at a chip device, due to an inoperative chip on the card or a
malfunction of the terminal chip reader. A fallback may also
occur in situations where a magnetic-stripe card cannot be
read due to a defective magnetic stripe or magnetic-stripe
reader. The fallback is to personal account number (PAN)
key entry, voice authorization, and paper voucher, and is
subject to scheme rules and local market practices.
Floor Limit
A currency amount that is established by Visa or an Acquirer
for single transactions at specific types of merchants, below
which an authorization is not required.
Full Data Option

A VSDC implementation in which the Issuer or Acquirer
makes all of the needed host system changes to transmit
and receive the new chip data at the beginning of their pro-
gram.
Interoperability
The ability for all card acceptance devices and terminals to
accept and read all chip cards that are properly pro-
grammed.
(PIN) Integrated POS terminal

A POS device with built-in PIN entry capability, sharing the
terminal’s keypad with the entry of PIN and non-PIN data.
(The POS device may also support the use of an external
PIN pad as well.)
Issuer
A Member that initiates and maintains the cardholder rela-
tionship.
Issuer Script
A process by which Issuers can update the electronically
stored contents of chip cards without reissuing the cards.
Scripts may be sent with authorization responses and may
be used for blocking or unblocking an account, blocking the
entire card, or changing the cardholder’s PIN or authoriza-
tion controls. Also known as dynamic data updates or post-
issuance updates.
Visa Public
Loyalty Program
A marketing program, usually offered by financial institutions
to cardholders or by merchants or retailers to customers,
that rewards specific purchasing behavior. Examples in-
clude airline frequent flyer programs, rental car programs,
frequent shopper programs, and video store frequent rental
programs.
Magnetic Stripe
A stripe on a Visa card containing magnetically encoded in-
formation.
Magnetic-Stripe Image (MSI)

A duplicate of magnetic-stripe data that is loaded onto a chip
as a baseline feature of any VSDC card. The MSI repre-
sents the fundamental information needed for transaction
processing and account access. The CVV may be different
between the magnetic stripe and chip.
Offline
A state in which a device is not communicating with or con-
trolled by a computer.
Online
A state in which a device is communicating with or controlled
by a computer.
Online Card Authentication

Validation of a chip card by the Issuer during online authori-
zation to protect against data manipulation and skimming.
Also known as Card Authentication Method.
Online Issuer Authentication

Validation of Issuer by the card to ensure the integrity of the
Issuer. Also known as Issuer Authentication or Host Authen-
tication.
Payment Device
A device capable of reading magnetic-stripe and chip data,
obtaining authorization through online or offline processing,
and formatting a financial clearing message for transmission
to a processing switch for input into financial settlement.
Personal Identification Number (PIN)

An alphanumeric code of 4 to 12 characters that is used to
identify cardholders at a cardholder-activated PIN pad.
PINs can be verified online by the Issuer or sent to the chip
card for offline PIN verification.
Visa Public
PIN Capable
A card acceptance device that is designed and constructed
to facilitate the addition of a PIN pad; or a device with a
spare port into which a PIN pad can be plugged.
PIN Entry Device (PED)

A secure card acceptance device that allows cardholders to
enter their PINs.
PIN Ready
A card acceptance device that contains a PIN pad.
Plaintext
Data in its original, unenciphered form, also called cleartext.
POS System
An electronic system used in an attended retail environment
for the processing and capture of transaction information at
the point of sale. A POS system may consist of a range of
components, from a simple cash register and stand-alone
payment device, to sophisticated integrated POS terminals
that perform multiple business functions. (A POS system
may or may not have a card-acceptance device fully inte-
grated into the system.)
Point-of-Sale (POS) Terminal

A card acceptance device that is most commonly used in at-
tended retail environments. A POS terminal or device is ca-
pable of reading magnetic-stripe and chip card data to elec-
tronically authorize and sometimes capture transaction data.
Point of Transaction
The physical location at which a merchant or Acquirer in at-
tended or unattended terminal completes a transaction.
Private Key
The key that is known only to the user in an asymmetric
cryptographic system.
Public Key
The key that is known to all users in an asymmetric crypto-
graphic system.
Purchase Secure Application Module (PSAM)

A microprocessor chip card supplied by card product man-
agement that resides in a device and provides security
management for Visa Cash purchase transactions. It may
also be used for VSDC transactions at the same device, if
supported.
Visa Public
Rivest, Shamir, and Adleman (RSA)

A widely used public key algorithm developed by Rivest,
Shamir, and Adleman. In VSDC transactions, the RSA algo-
rithm is used in Offline Data Authentication.
Service Code
A three-digit number encoded on the magnetic stripe and
replicated in a VSDC magnetic stripe image that identifies
the rules that must be applied during authorization (for ex-
ample, valid for international use, online authorization re-
quired, and PIN required).
Shadow Account
An account established for the purpose of transferring funds
to cover Visa Horizon purchases or cash disbursements.
The account may only be debited when a Visa Horizon
transaction completed by the cardholder has cleared.
The term “shadow account”
may have other meanings Spending Power
within the payment card and
financial services industry.
The amount stored in the Visa Horizon cardholder account
that has been pre-authorized for purchasing by the card Is-
suer and is frozen in a shadow account.
Static Data Authentication (SDA)

A security technique that establishes that the data on a chip
card has not been altered.
Stored Value
Funds held in an account or on a chip card for future use.
Symmetric Algorithm
An algorithm or series of algorithms that utilize the same se-
cret key for encrypting and decrypting a message.
Terminal
Generic term used to refer to any device, attended or unat-
tended, that accepts and processes payment card transac-
tions. See also Device.
Terminal Management System

A system used by Acquirers and merchants to drive point-of-
transaction terminals.
Transaction
The act between a cardholder and a merchant where money
is exchanged for goods or services. Visa transactions result
in the generation of a transaction receipt, either paper or
electronic. A transaction may occur in either an attended or
unattended retail environment.
Visa Public
Transaction Certificate (TC)

A cryptogram generated by a card at the end of all offline
and online approved transactions. The cryptogram is the
result of card, terminal, and transaction data encrypted by a
DES key. The TC provides information about the actual
steps and processes executed by the card, terminal, and
merchant during a given transaction; it can be used during
dispute processing.
Triple DES (TDES)

A sophisticated implementation of DES, in which the proce-
dure for encryption is the same, but repeated three times.
First, the DES key is broken into three subkeys. The data is
then encrypted with the first key, decrypted with the second
key, and encrypted again with the third key. TDES has
been adopted by Visa International as the encryption stan-
dard for all Visa PEDs.
Type A Transaction
Cardholder-activated transaction performed at an unat-
tended acceptance terminal that is less than U.S.$40, or the
local currency equivalent, and is not authorized. Cardholder
verification is not required.
Examples of Type A transactions included payments ac-

cepted for parking garage fees, road tolls, movie theater
admissions, and magnetic stripe telephone cards.
Type B Transaction
tended acceptance terminal that is less than U.S.$100, or
the local currency equivalent. An authorization is required,
but cardholder verification is not.
Type B transaction occurs primarily at gas pumps that ac-

cept payment cards, used to dispense fuel at petrol stations.
Type C Transaction
tended acceptance terminal that is not limited to any dollar
amount. An authorized and PIN verification (online or off-
line) are both required.
Type C transactions may include any sort of goods or ser-

vices, except currency, for any amount. For example, Type
C transactions may be used to produce the dispersal of air-
line tickets or other high dollar amount items that can be de-
livered in an unattended environment.
Visa Public
Unattended
An environment in which the transaction is completed by the
cardholder at the device without a sales associate present.
Visa Cash CEPS

Visa’s implementation of the Common Electronic Purse
Specifications (CEPS) for Visa Cash cards and terminals.
Visa Certificate Authority (CA) Public Key

The Visa public key signed by the secret key of a trusted
third party, also known as the Certificate Authority.
Visa Integrated Circuit Card Specification (VIS)

Chip card and terminal specifications developed by Visa for
VSDC programs that serve as a companion guide to the
EMV standards.
Visa Public

Chip Card Acceptance Device Ref Guide 6 (1) .0

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chip Card Acceptance Device Ref Guide 6 (1) .0

Transféré par

Droits d'auteur :

Formats disponibles

CHIP CARD ACCEPTANCE DEVICE

Requirements and Best Practices, Version 6.0

Date Ver. Description Page

December 2000 5.0

July 2003 6.0 Updated to reflect EMV2000 Integrated Cir- Entire

2.8 EMV Approval Considerations.................................................................................... 48

5.2.2 Transaction Types ...................................................................................... 74

The Chip Card Acceptance Device Reference Guide: Re-

This document will be updated on an as needed basis. Bul-

1.1 Scope and Contents

The focus of this book is on devices used at the point of

Chapter 2: Visa Smart Debit and Smart Credit — This

The terms used to refer to different kinds of card acceptance

1.2.1 Key Terms

Authorize — When used alone, it can denote that the

Type B Transaction — Cardholder-activated transac-

1.2.2 Acronyms and Abbreviations

ANSI — American National Standards Institute

1.3 Icons and Cross-References

Icons are used in this document to provide readers with vis-

Note — A key point to remember or similarly important

Resource —Reference to a primary source or supple-

In addition to these icons, cross-references to other sections

For information on the EMV

Chapter 2: Visa Smart Debit and Visa Smart

For information on VIS, visit the Visa website at

For more information on regional requirements, contact your

2.1 Physical Characteristics

This section describes the physical characteristics of the

2.1.1 Card Reader

In general, a device that accepts Visa chip cards must con-

2.1.1.1 Chip-Card Reader

A chip card reader may include related mechanical and

A chip-card reader may be referred to as an interface mod-

Visa requirements and best practices for chip-card readers

Chip-card readers should have a pictogram near the

When a card is inserted, the cardholder or attendant

For more information on EMV-approved chip-card readers,

Card acceptance devices must support the character set

The display screen must be able to hold at least 32 alpha-

In general, a card acceptance device needs a minimum of

2.1.5 Communication Speed

2.1.6 Cardholder Interface Unit

Cardholder payment devices that incorporate interface units

The EMV Level 2 requirements state that the above col-

Function: Application-dependent keys, such as F1, F2,

2.1.6.2 PIN Pad

The PIN pad must include numeric keys as well as ENTER

The numeric layout must comply with ISO 9564-1 (Personal

The date is used for checking certificate expiration dates for

2.2 Security Characteristics

Security characteristics for VSDC devices include require-

This section provides an overview of PIN pad and key man-

For complete security characteristics and requirements, see

2.2.1 PIN Pad

2.2.1.1 Offline PIN

− Plaintext Offline PIN

− Enciphered Offline PIN

2.2.1.2 Online PIN

Card acceptance devices that support PIN entry should ad-

The cardholder should perform the card insertion.

2.2.2 Key Management