Chip Card Acceptance Device Ref Guide 6[1].0

CCHHIIPP CCAARRDD AACCCCEEPPTTAANNCCEE DDEEVVIICCEE RREEFFEERREENNCCEE GGUUIIDDEE

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

Visa Public

Document Changes

Date Ver. Description Page

December 2000 5.0

July 2003 6.0 Updated to reflect EMV2000 Integrated Cir-cuit Car Specification for Payment Systems and Visa Integrated Circuit Card Specifica-tions (“VIS”) 1.4.0.

Entire document

July 2003 Chip Card Acceptance Device Reference Guide, Version 6.0 iii

Visa Public

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

iv Chip Card Acceptance Device Reference Guide, Version 6.0 July 2003

Visa Public

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.2 Application Selection ..................................................................................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.1 Application Selection ..................................................................................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

July 2003 Chip Card Acceptance Device Reference Guide, Version 6.0 v

Visa Public

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

July 2003 Chip Card Acceptance Device Reference Guide, Version 6.0 1

Visa Public

Chapter 1: Introduction

Today, the ongoing deployment of chip technology, com-bined with the increasingly global nature of the payment card industry is creating new requirements for the interop-erability of cards and devices. Interoperability is the corner-stone of Visa brand acceptance and, consequently, a driving 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.

WHAT’S COVERED Scope and Contents Terminology Icons and Cross-

References

http://www.visa.com/cad

2 Chip Card Acceptance Device Reference Guide, Version 6.0 July 2003

Visa Public

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 are also discussed.

Chapter 3: Visa Cash — This chapter describes the physical, security, and functional characteristics of de-vices that process Visa Cash transactions.

Chapter 4: Visa Horizon — This chapter describes the 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.

The requirements and best practices discussed in this book are primarily for de-vices that process chip-card transactions. Information on magnetic-stripe specifi-cations is included as nec-essary.


Visa Public

1.1.1 Caveat While based on the most current EMV specifications and Visa-specific implementation of EMV, the Visa Integrated Circuit Card Specifications (“VIS”), this document should not be used as a substitute for the full specifications. It 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.

For information on testing procedures and how to obtain the EMV and VIS specifica-tions, see Appendix C: “Refer-ence Materials.”


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-tion performed at an unattended acceptance terminal 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-tion performed at an unattended acceptance terminal 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.”


Chapter 2: Visa Smart Debit and Visa Smart Credit

Visa Smart Debit and Visa Smart Credit (VSDC) represents Visa’s chip-based debit and credit payment program.

This chapter provides an overview of requirements and best practices for card acceptance devices capable of processing VSDC transactions.

All devices that process VSDC transactions must be EMV and VIS compliant, to ensure interoperability. VSDC devices may also have to comply with requirements that are specific to individual Visa regions. These require-ments are not included in this document. Regional repre-sentatives work with vendors and Acquirers to ensure card acceptance devices in a given region comply with the requirements for that area.

For more information on the EMV specifications, visit the

WHAT’S COVERED Physical Characteristics Security Characteristics VSDC Transaction

Processing Commercial Cards VLP Feature Early and Full Data Op-

tions Terminal Management

System EMV Approval Consid-

erations Magnetic Stripe Reader Key Chip Migration

Dates

Visa Public

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.

http://www.emvco.com/

http://www.visa.com/smartcardspecs


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.

Acquirers and merchants should consider deploying new and replacement card acceptance devices that permit an 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.

Implementation of products like Visa Horizon may allow the deployment of devices that only accept chip cards.


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 common to all parts of ASCII character set (ISO 8859). This character set allows the card acceptance device to display messages in multiple languages using Latin characters 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.

For more information on ven-dor support for multiple lan-guages and character sets, see Section 2.3.12, “Comple-tion.”


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 cardholder’s PIN.)

The keypad should support one or more of the following types of keys:

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.

A keypad used for PIN entry is considered to be a PIN pad and must adhere to Visa’s PIN Management Require-ments.


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.

The PIN entry device (PED) supporting Visa card with PIN entry must comply with Visa’s PED security.

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 Static Data Authentication (SDA), Dynamic Data Authentica-tion (DDA), and application effective and expiration dates. The date is input to the application cryptogram algorithm and may be used to assure transaction identification uniqueness.

For more information on PED security requirements, see Section 2.2, “Security Charac-teristics.”

For more information on SDA, see Section 2.3.3, “Applica-tion-Processing Initiation and Data Read.”


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-rity characteristics of an online PIN entry device – tamper resistant/responsive. In general, PIN pads must be de-signed and constructed with the following characteristics:

The PIN pads must generate the prompt for PIN entry 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-ess must be separate from the PIN entry process so as to avoid accidental showing of the PIN on the device’s 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).

For information on PED secu-rity requirements, see Section 5.1.3, “PIN Entry Device Re-quirements.”

Tamper-evident provides a lower level of security protection required than by tamper-resistant or tamper-responsive, with the latter providing the highest protection.

http://www.visa.com/pin


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.

When the PIN travels directly from the PIN pad to the chip reader, then the PIN pad does not have to encipher the offline PIN at the point of entry.

− Plaintext Offline PIN The chip reader sends the PIN to the chip as plain-text.

− Enciphered Offline PIN Either the secure component in 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.

If the design of the termi-nal requires that parts of the device be physically separated, i.e., the PIN pad is not integrated into the terminal, and any cardholder instructions and/or processing data passes between the separate parts, there must be an equal level of protection between the different parts that make up the terminal.


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.

http://www.visa.com/


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. Support of CDA in acceptance devices may be needed, as this process has been implemented in specific mar-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.”

CDA is referred to as Com-bined DDA/Generate AC in the VIS specifications.


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.

Visa’s PIN requirements for chip devices include:

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.

ATMs must comply with Visa’s PIN security require-ments.


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:

Must at a minimum support − Online PIN

Must not support

− Signature verification − No CVM required − Combination CVMs (e.g., signature and offline PIN)

2.3.6.6 Unattended Acceptance Devices Visa CVM requirements for these devices are as follows:

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

Must at a minimum support − No CVM required

Must not support

− Signature verification − Combination CVMs (e.g., signature and offline PIN)

Devices Supporting Type C Transactions

Must at minimum support − Online PIN

May optionally support − Offline plaintext PIN − Offline enciphered PIN

For information on the differ-ent types of unattended de-vices, see Section 5.2, “Unat-tended Devices.”


Visa Public

Must not support

− Signature verification − Combination CVMs (e.g., signature and offline PIN)

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 magnetic-stripe transactions. Devices should be capable of 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.

For more information on floor limits, see Section 2.7.5, “Floor Limits.”


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. Devices must be able to recognize Commercial card products and capture new incremental data elements for 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, as needed (e.g., for automated fuel dispensers).

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:

For information on Commer-cial cards, see Section 2.4, “Commercial Cards.”

For information on transaction types, see Section 5.4, “Transaction Types.”


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.

Scenario

EMV Required Message

Visa Recommended Message

1. Device having problem with data on the chip when fallback is supported

CARD ERROR CHIP ERROR, USE MAG STRIPE

2. Device having problem with data on the chip when fallback is not sup-ported

CHIP ERROR; CARD TYPE NOT SUPPORTED

3. EMV card inserted into non-EMV device (e.g., chip phone card) when fallback is supported

CHIP ERROR; USE MAG STRIPE

4. Device with chip functionality not acti-vated. Device has separate readers for chip and magnetic stripe.

CHIP ERROR; USE MAG STRIPE

5. Device not able to accept the card because of no match on the AID

NOT ACCEPTED CARD TYPE NOT SUP-PORTED, USE MAG STRIPE

6. Device prompting for cardholder appli-cation selection/cardholder confirma-tion

SELECT ACCOUNT TO BE USED or USE xxxxxxxx? YES/NO? (Where “xxxxxxxx” is the Applica-tion Label/Application Preferred Name)

7. Device that does not support card-holder confirmation with a chip card that has a single application that re-quires cardholder confirmation

CARD TYPE NOT SUPPORTED

8. Device prompting for clerk or card-holder to enter amount

ENTER AMOUNT ENTER AMOUNT

9. Device prompting for cardholder to enter PIN as well as PIN entry error

ENTER PIN ENTER PIN; 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

ERROR; PIN PAD IN-OPERATIVE

12. Declines DECLINED DECLINED 13. Approvals APPROVED APPROVED 14. Merchant or cardholder removing card

before a transaction is completed PROCESSING ERROR

CARD REMOVED TOO SOON; TRY AGAIN (Do not remove chip card from reader during transaction)

15. Referrals CALL YOUR BANK

CALL BANK FOR AUTHORIZA-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.

2.5.1 VLP Specifications To support VLP, a card acceptance device must:

Be EMV Level 2 approved Contain enhancements to VSDC that allow the process-

ing of VLP transactions Contain the VLP Terminal Support Indicator in its termi-

nal data elements

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.

Adding VLP to a device can change its EMV applica-tion kernel and result in the need for EMV Level 2 retesting. Vendors are responsible for determining whether VLP func-tionality will affect

http://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

Name

Authorization

VIP Sys-tem

Clearing

Base II

POS Entry Mode Mandatory Field 22 Mandatory TCR 0, positions 162-163

Terminal Entry Capability, and POS Terminal Capabilities

Mandatory Field 60.2 Mandatory TCR 0, position 158


Visa Public

TABLE 2-3 DATA ELEMENTS FOR FULL DATA OPTION

Name

Authorization

VIP Sys-tem

Clearing

Base II

Terminal Capability Profile Mandatory Field 130 Mandatory TCR 7, positions 16-21 Terminal Verification Results (TVR)

Mandatory Field 131 Mandatory TCR 7, positions 69-78

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 (CVN)

Mandatory Field 134.2 Mandatory TCR 7, positions 67-68

Card Verification Results (CVR) Mandatory Field 134.3 Mandatory TCR 7, positions 79-86 Issuer Discretionary Data Conditional Field 135 Not applica-

ble Not applicable

Cryptogram Mandatory Field 136 Mandatory TCR 7, positions 49-64 Application Transaction Counter (ATC)

Mandatory Field 137 Mandatory TCR 7, 41-44

Application Interchange Profile (AIP)

Mandatory Field 138 Mandatory TCR 7, 45-48

Authorization Response Crypto-gram (ARPC) and ARPC Re-sponse Code

Conditional Field 139

Authorization Response Crypto-gram (ARPC)

Conditional Field 139.1 Not applica-ble

Not applicable

ARPC Response Code Conditional Field 139.2 Not applica-ble

Not applicable

Issuer Script Optional Field 142 Not applica-ble

Not applicable

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-quire that keys be updated in all devices. Post-deployment data integrity must be verified. Refer to the Visa Public Key Management Principles for more infor-mation on updates and management of public keys.

For information on public key management, see Section 2.2.2, “Key Management.”



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 These parameters target the percentage and threshold values used by devices that support both offline and 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.

For more information on ran-dom selection, see Section 2.7.4, “Random Transaction Selection.”

http://international.visa.com/fb/paytech/smartcard/vsmartspecs/ccpspublickey.jsp


Visa Public

Floor Limits The Acquirer may set floor limits for VSDC chip transac-tions as well as for magnetic-stripe transactions. How-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 Removed expired or revoked keys by expiration date 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.

Distribute keys to deployed devices in a manner that protects their integrity. For more information on key

security, see Section 2.2.2, “Key Management.”

Card acceptance devices should also be able to download software to re-mote terminals.

For information on floor limits, see Section 2.7.5, “Floor Limits.”


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

N/A 20% 15%

Threshold Value for Biased Random Selec-tion

N/A EUR 40 EUR 200

Maximum Target Per-centage for Biased Random Selection

N/A 50% 40%

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

EMV Level 2 and Scheme Settings

Settings Parameters Acquirer

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-ant in the Asia Pacific Region

The terminals must appear in the EMVCo approved list

18-Jan-2003 Visa Asia Pacific intra-regional chip incentive rates introduced, providing a 10-basis points benefit to acquirers accepting mag-netic-stripe cards at chip devices, and to chip card issuers whose cards are accepted at non-chip devices.

Cards and devices must be fully EMV and VIS compliant.

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

Must be completed by 30 Jun 2003

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 point of transaction to Visa Net

Withdrawal of early option data processing. All chip acquirers must send full chip data by January 2006.

01-Jan-2003 Visa Asia Pacific introduces mandatory card and device user-acceptance test process

Contact Visa Asia Pacific to get a 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 have passed testing by a Visa approved laboratory and been ap-proved by Visa

Includes replacement devices

01-July-2004 All newly deployed ATMs and Cash Dispensers must have passed testing by a Visa-recognized laboratory and been approved by Visa.

Includes replacement devices

31-Dec-2004 Visa CA 896-bit Public Key expires

01-Jan-2005 Visa Asia Pacific may invoke financial penalties for non-compliant cards and devices

Visa Asia Pacific specific

01-Jan-2005 All offline-capable devices must support DDA

01-Jan-2005 All new chip devices must be capable of supporting offline PIN (both plaintext and enciphered)


01-Jan-2006 Visa Asia Pacific Intra-regional liability shift. Liability for counter-feit transactions occurring on chip cards passes from the issuer to the acquirer

Not applicable if acquirer deploys EMV device and sends full chip 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 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 devices to TDES

Proposed date


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

Devices with magnetic-stripe readers should have a picto-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 does not require a MSR on devices for Visa Horizon card acceptance. See Chapter 4 “Visa Hori-zon.”


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 provide a quick and easy way for consumers to make low-value purchases—generally under $10. Targeted to replace cash and coins, the cards can be used in the same retail environments as a VSDC card: retail outlets, mail order and telephone order, and online.

This chapter provides an overview of the physical and func-tional characteristics of devices that are capable of process-ing Visa Cash transactions.

WHAT’S COVERED Compliance Require-

ments Physical Characteristics Retail Environments Visa Cash Transaction

Processing


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 Keypad Yes Chip Card Reader Yes

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 Cash devices do not require a magnetic-stripe reader, clock, PIN pad, or printer.


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:


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:


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.

3.4.2 Application Selection 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 developed for markets where the telecommunications infra-structure is not widespread, reliable, or not cost effective.

The Visa Horizon product is a pre-authorized card that cur-rently uses two technologies to ensure ubiquitous accep-tance within a domestic market.

Visa Horizon can be accepted at VSDC devices with PIN 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.

WHAT’S COVERED How It Works Compliance Require-

ments Physical Characteristics Security Characteristics Visa Horizon Transaction

Processing


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

Visa Horizon (COPAC) Terminal Application Specifica-tion Please see your Visa representative to obtain a copy.

Visa Horizon cards have been enhanced to allow acceptance at VSDC de-vices that support PIN and online authorization. Accep-tance at these devices is at 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 Printer Yes Magnetic-Stripe Reader No Chip-Card Reader One or two (ID1 chip card readers), de-

pending on intended operation of the ter-minal

Modem No; dependent upon intended operation of the terminal

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 support graphic alphabet characters may also be required.

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.

As a best practice, Visa Horizon devices should be able to operate from batter-ies, as well as from a per-manent electrical power source. Inexpensive household batteries are recommended to hold down terminal costs.

For more information on nega-tive files, see Section 4.4.3, “Negative File.”


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:

4.5.1 Application Selection 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 card acceptance device types: attended, unattended, and ATM.

This chapter provides an overview of the requirements and best practices that are unique to each type of device. Sec-tion on transaction types and operational considerations for Acquirers are also included.

WHAT’S COVERED General Device Con-

figurations Attended Devices Unattended Devices Automated Teller Ma-

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.

PIN pad — If PIN pads are used, they must meet Visa’s requirements for PIN entry devices (PEDs).

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

For information on PIN pad security requirements, see Section 2.2, “Security Charac-teristics.”


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.

http://www.visa.com/PIN


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. The cardholder verification is obtained, if applicable. The cardholder completes the transaction directly at the

device. The device dispenses goods or services but not cash Authorization, if required, is obtained electronically.

In all cases, the card and the cardholder are present and the 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.

Information on unattended devices that dispense scrip are not included in this section since the Visa International Operating Regulations prohibit Visa cards from being used at scrip devices. Scrip is a two-part paper receipt redeemable for goods, services, or cash.


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-quate PIN security standards. To this end, international standards organizations (ANSI and ISO) and Visa now re-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.

For information on Triple DES, see Section 5.1.3, “PIN Entry Device Requirements.”


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 provide superior security).

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.

For refunds where a card is not present, current proce-dures for magnetic-stripe refunds are followed.


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 Track 1 of the magnetic stripe and the magnetic stripe im-age on the integrated chip. Visa requirements conform to the International Organization for Standardization (ISO) standard 7811/2, Identification cards—Recording tech-nique—Part 2: Magnetic Stripe and ISO standard 7813, Identification cards—Financial transaction cards.

WHAT’S COVERED Track 1 Content Re-

quirements Encoding Examples Data Element Descrip-

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-netic stripe, including field names and lengths. The maxi-mum length of Track 1 is 79 characters.

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.

For more information on Track 1 data fields, see section A.3, “Data Element Descriptions.”


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 Char. Hex P 25 24 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 ‘ 27 0 0 0 0 1 1 1 ( 28 0 0 0 1 0 0 0 ) 29 1 0 0 1 0 0 1 * 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

This coded character set is identical to the coded char-acter set in ISO/IEC 7811-4 and is derived from ASCII


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 Verification Data field. The Visa-Reserved field shows the position of the CVV.

Example 3 (Figure A–6) illustrates encoding with the Discretionary Data field. The Visa-Reserved field shows 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.

These examples represent sample formats only. They should not be followed literally when encoding Track 1 of a magnetic stripe.


Visa Public

FIGURE A–4: ENCODING REQUIRED FIELDS

A.2.2 Example 2: Encoding with PIN Verification Data Field Information to be encoded:

PAN: 4000 0012 3456 2345 (16 digits) Cardholder Name: MR JOHN Q PUBLIC JR 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 Information to be encoded:

PAN: 4000 0012 3456 2345 (16 digits) Cardholder Name: MR JOHN Q PUBLIC JR Expiration Date: 09/98 Service Code: 101 PIN Verification Data: none 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

Information to be encoded:

PAN: 4000 0012 3456 2345 678 (19 digits) Embossed Cardholder Name: MR JOHN Q PUBLIC JR Embossed Expiration Date: 09/98 Service Code: 101 PIN Verification Data: 5 (PVKI) and 4321 (PVV) 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 on Track 1 of the magnetic stripe.

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 on Track 1 of the magnetic stripe.

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-coded on Track 1 of the magnetic stripe.

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

Service Code

Visa Credit, Debit, and

Delta

Visa Electron

Interlink

Co-branded Visa Check

and Interlink

Visa Travel Money

Plus ATM only

Plus Co-branded

with EFT Processor

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 on Track 1 of the magnetic stripe.

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-coded on Track 1 of the magnetic stripe.

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 length = 0

PIN Verification 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-coded on Track 1 of the magnetic stripe.

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 Track 1 of the magnetic stripe.

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 Track 1 of the magnetic stripe.

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-coded on Track 1 of the magnetic stripe.

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 This appendix describes Visa standards for the contents of Track 2 of the magnetic stripe and the magnetic stripe im-age on the integrated chip. Visa requirements conform to the International Organization for Standardization (ISO) standard 7811/2, Identification cards—Recording tech-nique—Part 2: Magnetic Stripe and ISO standard 7813, Identification cards—Financial transaction cards.

WHAT’S COVERED Track 2 Content Re-

quirements Encoding Examples Data Element Descrip-

tions


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 Char. Hex P 23 22 21 20

0 30 1 0 0 0 0

1 31 0 0 0 0 1

2 32 0 0 0 1 0

3 33 1 0 0 1 1

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

This coded character set is identical to the coded char-acter set in ISO/IEC 7811-4 and is derived from ASCII


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.

Example 2 (Figure B–2) illustrates encoding with the PIN Verification Data field and the Discretionary Data field including the CVV in the first three positions of the field. 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 Information to be encoded:

PAN: 4000 0012 3456 2 (13 digits) Expiration Date: 09/98 Service Code: 120 PIN Verification Data: none Discretionary Data: 876234567 (first three positions =

CVV)

These examples represent sample formats only. They should not be followed literally when encoding Track 2 of a magnetic stripe.


Visa Public

FIGURE B–1: ENCODING WITH DISCRETIONARY DATA FIELD

B.2.2 Example 2: Encoding with PIN Verification Data and Discretionary Data Fields


PAN: 4000 0012 3456 7892 (16 digits) Expiration Date: 12/98 Service Code: 101 PIN Verification Data: 5 (PVKI) and 4321 (PVV) 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) Expiration Date: 12/02 Service Code: 120 PIN Verification Data: none 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 Discretionary Data Fields


PAN: 4000 0012 3456 7890 122 (19 digits) Expiration Date: 12/98 Service Code: 120 PIN Verification Data: 5 (PVKI) and 4321 (PVV) 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 on Track 2 of the magnetic stripe.

TABLE B–5: FIELD 3—SEPARATOR

Attributes 1 alphanumber

Description Indicates the end of a variable-length field such as the PAN field; only one separator is generally positioned on the track


Use of multiple separators may cause problems in some Acquirer systems.


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-coded on Track 2 of the magnetic stripe.

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


9 Invalid for Visa card products 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

Service Code

Visa Credit, Debit, and

Delta

Visa Electron

Interlink

Co-brandedVisa Check

and Interlink

Visa Travel Money

Plus ATM only

Plus Co-Branded

with EFT Processor

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-coded on Track 2 of the magnetic stripe.

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-coded on Track 2 of the magnetic stripe.

TABLE B–11: FIELD 7—DISCRETIONARY DATA

Attributes Up to 17 numerics, remaining positions can be for 3-digit CVV.

Description Includes the CVV, plus any valid information that the Issuer wants to transmit in the transaction. CVV is required on Track 2 of all Visa, Visa Electron, and Plus cards.

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.

The three-digit CVV must be encoded in the Discre-tionary Data field. While Visa recommends placing the CVV at the start of this field, any three contiguous positions can be used.


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 Track 2 of the magnetic stripe.

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 and Acquirers may need policy, operational, and technical information not contained in these documents. In addition, 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.

Unless otherwise noted, all materials listed here are available from your Visa regional representative.


Visa Public

Title and Description Audience User EMV2000 Integrated Circuit Card Specification for Payment Sys-tems 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.

Financial Institu-tions, Vendors

Technical

Visa Integrated Circuit Card Specifications (VIS), version 1.4.0, April 2001 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.

Issuers, Acquir-ers, Vendors

Technical

Visa International Operating Regulations, updated versions are pub-lished twice each year in May and November Provides regulations for issuers and acquirers, including rules governing VSDC transactions, dispute processing, and interchange rates.

Visa Members Policy, Op-erations

Visa Regional (and domestic market) Operating Regulations, up-dated versions are published twice each year in May and November 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.

Visa Members Policy, Op-erations

VSDC Member Implementation Guide for Acquirers, Version 3.0 Provides guidelines for acquirers involved in the implementation of new VSDC programs. This document is available from your Visa regional representative.

Visa Members Operations, Technical

Visa Smart Credit/Visa Smart Debit (VSDC) Technical Manual 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. This document is available from your Visa regional representative.

Visa Members Technical





http://www.visa.com/smartcardspecs


Visa Public

Title and Description Audience User Payment Technology Standards, September 2002 Describes the following: Standards applied to PINs (personal identifica-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. This document is available from your Visa regional representative.


Visa PIN Security Requirements 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. This document is available from your Visa regional representative.

Visa Members Technical

Visa PIN Entry Device Security Requirements Provides Visa’s enhanced PIN entry device security requirements, in-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.

Visa Members, Vendors

Technical

Common Electronic Purse Specifications (CEPS) Defines requirements for all components needed by an organization to implement a globally interoperable electronic purse program. These documents are available at www.cepsco.com.


Technical

Visa Cash CEPS Specifications Defines requirements for all components needed by an organization to implement a globally interoperable Visa Cash program, while maintaining full accountability and auditability. These documents are available at www.international.visa.com.


Technical

Terminal Application for PSAM Applications (TAPA) 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.

Vendors Technical

Visa Certificate Authority User’s Guide Outlines activities for requesting Visa public keys from the Visa Certifi-cate Authority. This document is available by contacting Visa Central Approval Authority at [email protected].


Visa Horizon Specifications Defines requirements for all components needed by an organization to implement a globally interoperable Visa Horizon program. This document is available by contacting Visa Central Approval Authority at [email protected].


Technical

http://www.visa.com/pin

http://www.cepsco.com/

http://www.international.visa.com/

http://www.international.visa.com/

mailto:[email protected]

mailto:[email protected]


Visa Public

Title and Description Audience User Acquirer Device Validation Tool (ADVT) Kit User's Guide Contains a set of test scripts and test cards that can be used by Acquir-ers to ensure that chip terminals are configured correctly prior to de-ployment. This document is available from your Visa regional representative.


Global (Open) Platform Specifications Provides core architecture for smart-card infrastructure, as well as secu-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.

Acquirers, Ven-dors

Technical

International Organization for Standardization ("ISO") A network of national standards institutes from 140 countries working in partnership with international organizations, governments, industry, business, and consumer representatives. A bridge between public and private sectors www.iso.ch


Technical

ANSI A private, non-profit organization (501(c)3) that administers and coordi-nates the U.S. voluntary standardization and conformity assessment system. www.ansi.org


Technical

X9 Accredited by the American National Standards Institute (ANSI), XP de-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


Technical

http://www.globalplatform.org/

http://www.iso.ch/

http://www.ansi.org/

http://www.x9.org/


Visa Public

Appendix D: Acronyms and Glossary This section contains a list of acronyms and a glossary of terms used in this book. In general, terminology reflects Visa standard usage or the most common usage in the field. However, certain terms and their definitions may vary from region to region and from one market sector or merchant to another.

WHAT’S COVERED Acronyms Glossary


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.

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

The term “shadow account” may have other meanings within the payment card andfinancial services industry.


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 Cardholder-activated transaction performed at an unat-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 Cardholder-activated transaction performed at an unat-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.

Chip Card Acceptance Device Ref Guide 6[1].0

Documents

Transcript of Chip Card Acceptance Device Ref Guide 6[1].0