Use of Chip Data on Chip Transactions. VISA Transaction Acceptance Device
Реклама
Реклама
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
Use of Chip Data on Chip Transactions
Devices with readers that support more than one interface, such as mechanized readers that support both contact chip and magnetic stripe, must ensure that only data appropriate to the transaction is used. For contact-chip transactions, all data elements used must be read from the chip.
Data from one interface may not match equivalent data from another interface and should not be compared. For example, the PAN read from the chip may be different from the PAN on the magnetic stripe (especially for multi-application cards where only one of the applications on the chip will match the magnetic stripe).
Important: There have been situations during a chip transaction where ATM encryption PIN pads have used the PAN from the Track 2 data on the magnetic stripe to derive a session key to encrypt the
Online PIN resulting in Online PIN errors. Developers must ensure that the PAN used to derive the session key is obtained from the Track 2 Equivalent Data (Tag ‘57’) on the chip.
Chip Device Installed Before Chip Transaction Acceptance
An acquirer or merchant may install a contact-chip device before the acquirer or merchant is capable or ready to accept chip transactions. Country or regional rules may require that all new devices be capable of reading contact-chip cards, including merchant and acquirer processing support. In such situations, the chip functionality, including the requirement to examine and act upon the 2xx or 6xx
Service Codes, must not be activated until the acquirer and merchant are ready to accept chip transactions and have the ability to transmit the new chip data elements to the issuer.
Chip Cards with Non-Functioning Magnetic Stripes
Device vendors should also be aware that some chip cards (e.g., V PAY cards) are intended for processing only via the chip and may not have fully functioning magnetic stripes (these cards only contain a magnetic stripe since it may be needed for some types of motorized readers to operate properly). These magnetic stripes may be encoded with nonfunctional information, such as a PAN with all zeroes, but contain a valid Service Code (2xx or 6xx) and expiration date. If the device encounters a card with a magnetic stripe that appears to not be fully functioning, the device should continue to read the chip and, assuming the chip is functioning, perform a standard EMV/VIS chip transaction
(ignoring the magnetic stripe). For more information, refer to Section 3.3.5: V PAY.
November 2016 Visa Public 31
3. Contact Chip Acceptance
3.2 Card Insertion
3.2.2 Fallback Acceptance for Chip Read Failures
Contact chip devices must contain logic that allows the transaction to be completed by reading the magnetic stripe (or key entered as a last resort
10 ) when the transaction cannot be completed by
reading the chip (i.e., the chip or chip reader is inoperable). This function is called Fallback and must be supported unless Fallback is disallowed by local regulation or domestic operating rules.
governing Fallback.
Device vendors should contact their local Visa representative for further information regarding local rules
The following outlines the basic principles related to Fallback:
•
Retry Reading Chip—Before falling back to reading the magnetic stripe, devices should attempt to retry reading the chip three times. If feasible, devices with motorized readers should attempt to restage the card in the chip-reading station or retract and re-land the chip contacts to complete the transaction.
•
Online Authorization and Fallback Data Elements—Fallback transactions are processed as
described in Chapter 5: Magnetic Stripe Acceptance for magnetic-stripe transactions, with the
exception that all Fallback transactions must be authorized online. Fallback transactions must also contain the correct VisaNet data elements, indicating a magnetic-stripe read transaction using a chip card at a chip terminal, so issuers are able to correctly identify and process them accordingly.
Details on the data elements required in a Fallback transaction are provided in Section 8.4:
• Key-Entry/Manual Acceptance As Last Resort—If the magnetic stripe cannot be read, key-entry or manual/paper voucher procedures may be used at the point of service unless prohibited by local regulation or domestic operating rules.
These transactions must be authorized online or by
voice and contain the correct data elements (refer to Section 8.4: Fallback Processing for details).
Key entry should only be used as a measure of last resort and only if Fallback to magnetic stripe is not possible.
•
Fallback Not Permitted—If Fallback is not permitted by local regulation or domestic operating rules, the transaction is terminated.
10
In the Europe Region, if a chip read is not possible, fallback to magnetic stripe is allowed but fallback to key/manual entry is not.
11 See previous footnote.
32 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
• Device Supports Chip but Does Not Yet Support Visa—If the device is adding support for chip processing in stages (i.e., the migration to chip begins by upgrading devices to support a non-Visa payment scheme with plans to upgrade to Visa over time), it may read the service code on the magnetic stripe of a Visa chip card that it does not yet support, identify the card as a chip card through the 2xx or 6xx Service Code, and then read the chip. Upon reading the chip, it will determine that Visa is not supported since the Visa AID has not yet been loaded into the device. In these situations, the device should process the transaction using the magnetic stripe. These transactions should not be identified as fallback; therefore, the Terminal Entry Capability (TEC) value needs to be changed from 5 (chip device) to 2 (magnetic-stripe device) at some point in the transaction lifecycle before the transaction reaches the issuer. However, once migration is completed and the device supports both chip and the required Visa AIDs, the TEC should not be manipulated. Once the device is migrated, there is a risk that the merchant can be exposed to chargeback if the TEC is incorrect.
•
Liability—Issuers are liable for Fallback transactions that have been online approved and correctly identified by the merchant.
Because performing a Fallback transaction circumvents the improved security offered by chip, issuers may choose to decline these transactions based on their individual risk policies.
3.2.3 Merchant Override of Chip Read
Contact-chip devices that accept Visa chip cards must not allow the cardholder or merchant to override the requirement for a chip read by manually prompting the device to read data from the card’s magnetic stripe. Data from the magnetic stripe must be used only to perform the transaction if the chip or chip reader is inoperable.
3.2.4 Support for 19-Digit PANs
Both Visa rules and regulations and the EMV specifications require that all contact-chip devices (POS and ATM) that accept Visa, Visa Electron, Plus, and/or V PAY cards must support variable-length PANs up to and including 19 digits.
In the Europe Region, acquirers must support transactions associated with 19-digit PANs in VisaNet messages. Outside of the Europe Region, the device/ATM is not required to transmit the 19-digit PAN to the acquirer and the acquirer is not required to transmit the 19-digit PAN to VisaNet, unless explicitly mandated, such as for Plus and V PAY transactions. If the acquirer does not support 19-digit
PANs and a 19-digit PAN is read from the chip, the device should indicate that the card type is not supported and end the transaction.
Important: Even in those countries where acquirer support for 19-digit PANs is not required, it is strongly recommended.
12 The merchant/acquirer must clearly identify these transactions as Fallback and, if not, the merchant is liable. Refer to
Section 8.4: Fallback Processing for information on properly identifying fallback transactions.
November 2016 Visa Public 33
3. Contact Chip Acceptance
3.3 Application Selection
3.2.5 Device Messages
The EMV specifications require messages to be displayed on the screen of the device. The messages or their equivalent meaning are intended to ensure consistency in what is displayed by the device and
the PIN entry device. Chip display messages are included in Table 2–1: Transaction Scenarios and
3.2.6 Historical Bytes
Some contact chip cards have values in the historical bytes that are returned to the device in the
Answer to Reset. Although the EMV specifications describe the format of these bytes, their use is outside the scope of the specifications and testing, and there is no cross-industry definition for their usage. It is strongly recommended that devices do not use information from historical bytes in processing; for example, attempting to use these bytes for access to legacy chip applications.
Although such processing may be successful for domestically issued cards at domestic devices, nondomestic issuers (or card vendors) may define the same values in the historical bytes for different purposes. This could lead to cards being rejected or being processed incorrectly especially if usage of this information occurs before the device is able to determine if the card is domestic or non-domestic.
3.3 Application Selection
This section provides general information on Application Selection. For information on applications that require cardholder confirmation and device support for cardholder selection, refer to
Section 3.3.6: Cardholder Selection.
When a card only contains one application (and the application does not require cardholder confirmation) and the device supports the application, the device automatically selects that application for the transaction.
When a multi-application card is presented, the device determines which payment applications are supported by both the card and the device:
•
No Applications in Common—If no applications are mutually supported, the device should display a CARD TYPE NOT SUPPORTED message
and invoke a magnetic-stripe read.
See Table 2–1: Transaction Scenarios and Device Messages for chip-display messages.
•
One Application in Common—If only one application is mutually supported (and the application does not require cardholder confirmation), the device automatically selects that application for the transaction.
13
A device that captures the card for the transaction, such as an ATM, will recognize that there are no applications in common and automatically read the magnetic stripe without displaying a message to the cardholder.
34 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
• Multiple Applications in Common—If more than one application is mutually supported,
the device should offer the cardholder an option to choose which application to use for the transaction (except for U.S. Covered Visa Debit Cards).
This is called cardholder selection. For
more information, refer to Section 3.3.6: Cardholder Selection.
If the card and device have multiple applications in common but the device is unable to allow the cardholder to choose the application for the transaction, the device may automatically select the highest priority, mutually-supported application that does not require cardholder confirmation. In the U.S., the terminal may be configured to utilize the Visa U.S. Common Debit AID.
When the device automatically selects the application, it is important for the device to display the application name the cardholder as an indication of what application is being used to conduct the transaction.
to
The device can display the application name in one of the following ways:
•
PIN Entry—If PIN entry is required, the device can display the application name along with the
ENTER PIN message. The amount of the transaction can also be shown at this point.
•
Amount—If PIN entry is not applicable, the device can display the application name before or at the time that the amount is displayed.
The receipt should include the application name as per the recommendations in Section 2.7:
Note: The EMV Application Selection Indicators supported in the device must indicate support for partial name selection for all Visa Application Identifiers (AIDs).
Important: There may be arrangements in place in a local environment to support specific Application
Selection processing. Special Application Selection processing is allowed under EMV and may be the result of local law, a commercial agreement with Visa, or by Visa’s acceptance of local industry standards. These solutions may allow for the suppression of a Visa AID in favor of another AID linked to the same account (such as one belonging to a domestic scheme). To determine if there are any special local arrangements in place in your environment for Application Selection, contact your Visa
representative. See also Appendix F: Visa U.S. Common Debit AID for a discussion of Application
Selection considerations in the U.S.
14 When building the list of mutually-supported applications (i.e., Candidate List), the device must include all applications common to both the card and device, except when allowed by certain conditions specified in the Visa rules and regulations.
15 In the U.S., certain requirements related to application selection and display do not apply for U.S. Covered Visa Debit
Cards.
16
Alternatively, for U.S. Covered Debit Card transactions, the terminal may be configured to utilize the Visa U.S. Common
Debit AID or other customized Application Selection logic. See also Appendix F: Visa U.S. Common Debit AID.
17
Either the Application Preferred Name (if provided by the card and the character set is supported by the device), the
Name for additional information.
November 2016 Visa Public 35
3. Contact Chip Acceptance
3.3 Application Selection
3.3.1 Application Identifiers
All chip-reading devices (contact and contactless) must contain the appropriate Visa Application
Identifiers (AIDs). The AID consists of two components:
•
Registered Application Identifier (RID)—Represents the payment scheme. Visa’s RID is
A000000003.
•
Proprietary Application Identifier Extension (PIX)—Represents the application.
The following table outlines the RID, PIX, and complete AID for each Visa product.
Table 3–1: Visa Application Identifiers (AIDs)
Product RID
Visa Debit or Credit A000000003
Visa Electron A000000003
Plus A000000003
PIX
1010
2010
8010
AID
A0000000031010
A0000000032010
A0000000038010
Additional digits may be appended to the end of a card’s AID if the card has multiple applications with the same AID (for example, the card supports both Visa Debit and Visa Credit). Because the
Application Selection Indicators for AIDs must indicate support for partial name selection, the device is able to select all applications with the same AID.
Note: AIDs may have a length of 5 to 16 bytes. As per the EMV Specifications, devices must be able to select AIDs that are between 5 to 16 bytes in length.
Devices must not simply use the RID with partial name selection to select applications because this can result in the selection of an application not supported by the device. A number of industry-only, region-only, or domestic-only Visa applications have been defined that use the Visa RID with a PIX defined for that application. For example, AID A0000000034010 is used for Visa Fleet applications, while AID A0000000032020 is used for V PAY applications (Europe-only).
Visa chip-reading devices must contain the Visa Debit/Credit AID and the Visa Electron AID.
Note: In countries where Visa Electron is not issued, Visa Electron cards are accepted and processed as Visa cards but the Visa Electron AID must still be present to enable this.
All ATMs accepting Visa, Visa Electron, and/or Plus, must support the Visa Debit/Credit, Visa Electron, and Plus AIDs. ATMs that accept Plus chip cards but not Visa or Visa Electron chip cards must still support all three AIDs, as a Visa or Visa Electron card registered with the Plus network will likely not contain the Plus AID.
36 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
3.3.2 Transaction Routing
Routing or processing of transactions is normally determined in the same manner as it is for magnetic-stripe transactions, which is primarily through the use of BIN tables. For example, at an ATM, data from a card may be accessed using a Visa AID, but the transaction could be routed to the Plus network. An example is a Visa/Plus card (containing only the Visa Debit/Credit AID) presented at a
Plus-only ATM. For multi-application cards, the device should ensure that the routing is undertaken using the BIN of the application selected; this means that the routing decision must be made only after the application has been selected.
Transactions initiated via Visa AIDs are routed to Visa affiliated networks. Domestic arrangements, such as in the U.S. and Canada, may allow for selection of other AIDs which in turn allows for routing of transactions initiated with these AIDs to alternate networks.
Chip processing should not affect decisions related to routing and, conversely, routing decisions should not affect chip processing. Acquirers and device vendors must ensure that both Visa and Plus routing function normally for chip-initiated transactions. This includes transactions initiated for chip cards that contain only the Plus AID (non-Visa cards that are enrolled to use Plus such as proprietary cards).
There are no EMV or Visa chip-card processing requirements that assume the transaction is routed over a particular network. All information needed to process the transaction is carried in the message.
Certain countries have specific requirements relating to the routing of domestic transactions.
Acquirers should ensure they comply with any domestic requirements relating to transaction routing.
3.3.3 Regional and Domestic Applications
Depending on the country in which it is located, the device may also need to support Visa regional or domestic AIDs.
To support regional and domestic routing, the device may need to send the acquirer (and other downstream routing entities) the AID. The AID is contained in a card data element called the
Dedicated File (DF) Name (Tag ‘84’). Refer to Table D–2: EMV/VisaNet Data Elements and Tags.
3.3.4 Visa Electron
Visa Electron is a Visa product where transactions are always authorized (either offline or online).
In countries where Visa Electron is not issued, and assuming the merchant/acquirer agreement does not contain any specific provisions for Visa Electron, Visa Electron cards are accepted and processed identically to Visa cards. Visa Electron cards may not contain the Visa AID so the Visa Electron AID needs to be loaded into all Visa-accepting devices.
November 2016 Visa Public 37
3. Contact Chip Acceptance
3.3 Application Selection
3.3.5 V PAY
The Europe Region has a chip-only, PIN-based debit card program called V PAY, which has a unique
AID. The V PAY card program was created by the Europe Region for use within the European territories. V PAY cards are being issued by banks and accepted by merchants and ATMs throughout the Europe Region. Acceptance within the Europe Region is provided at EMV-compliant chip devices through the inclusion of the Visa Electron AID on the cards and in devices. For this reason, in the
Europe Region, chip devices accepting Visa Electron also carry the V PAY brand mark.
The V PAY AID is only present on acceptance devices which do not accept Visa or Visa Electron cards.
VPAY cards typically carry the Visa Electron AID to allow for global acceptance and are processed as
Visa Electron transactions outside of the Europe Region territories.
Devices accepting V PAY must accept PANs up to 19 digits that contain a valid BIN registered with the
V PAY program. These devices must be capable of transmitting 19-digit PANs to the acquirer and, in turn, the acquirer must be capable of transmitting the full PAN to VisaNet in the authorization and clearing messages.
V PAY cards are intended for processing only via the chip (unless co-badged with Plus or other payment brands). As a result, V PAY cards may contain minimally functional magnetic stripes
(e.g., magnetic stripes with a PAN that contains all zeroes but with a valid Service Code and expiration date). The purpose of the magnetic stripe on these cards is to allow mechanized readers to read the magnetic stripe, recognize that the card is a chip card from the Service Code, and initiate the transaction using the chip. The device should not terminate processing due to the missing magneticstripe data. Fallback transactions are not applicable to these cards.
Note: V PAY cards typically carry the Visa Electron AID to allow for global acceptance and are processed as Visa Electron transactions outside of the Europe Region territories.
18
EMV-compliant-chip devices that accept Visa products and support PIN, but do not currently support Visa Electron products, will not accept V PAY cards.
38 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
3.3.6 Cardholder Selection
Issuers may deploy cards supporting “cardholder confirmation” (as personalized in the Application
Priority Indicator) except for U.S. Covered Visa Debit Cards.
This setting indicates the cardholder
must be provided an opportunity to select the application in order for the application to be used for transaction processing. If the cardholder is not provided such an opportunity, the related application requiring cardholder confirmation is not eligible for transaction processing. As cards may be personalized with this setting, it is important for devices to support cardholder selection. In addition, cardholder selection allows cardholders with multiple applications to select the one to use for a given transaction. Support for cardholder selection is strongly recommended for all devices that have the capacity (i.e., screens, menu functions) to support it.
Devices should implement support for cardholder selection in one of the following ways:
•
Menu—Device displays a menu of all available applications to the cardholder in order of priority and prompts the cardholder to select one. If the transaction cannot be performed with the selected application, the device should display the TRY AGAIN message and display the remaining mutually-supported applications. If all applications have been displayed to the cardholder and the cardholder has not selected one, the transaction should be terminated and restarted, as necessary.
• Single Name—Device displays, in order of priority, one mutually-supported application which the cardholder may accept or reject. If rejected, the device then displays the next application, in priority order, continuing through the list of mutually-supported applications until the cardholder has selected one or rejected all of them. If the cardholder rejects all of the applications, the device can start the process over or terminate the transaction; the transaction can be restarted, as necessary.
If there is only one application in common between the device and card, or if a domestic arrangement is in place to use only a particular application for domestic cards, cardholder selection is not necessary
(unless the card requires cardholder confirmation) but the application name should be displayed to
receipt (refer to Section 2.7: Transaction Receipts).
For devices with separate cardholder and merchant displays, the application names that appear for selection should be displayed only to the cardholder and not to the merchant (in some Visa regions, this is a requirement). The dual-display device should also not allow the merchant to choose the application on behalf of the cardholder. While the customer is choosing the application, the merchant display should inform the merchant that this is occurring. As soon as the cardholder has completed selection, the application should be identified to the merchant.
19
Cardholder confirmation does not apply to U.S. Covered Visa Debit Cards. The U.S. Personalization Validation
Requirements do not allow the Visa AID and U.S. Common Debit AID to be personalized to require cardholder confirmation.
20 In the Menu and Single Name methods, the application name is displayed to the cardholder using the Application
Preferred Name (if provided by the card and the character set is supported by the device) or the Application Label.
November 2016 Visa Public 39
3. Contact Chip Acceptance
3.3 Application Selection
During the cardholder selection process, the cancel key should only be used to terminate the transaction, unless clear guidance is provided on the effect of using the cancel key.
Note: Cardholder selection may be used in conjunction with domestic application selection processes.
For example, domestic application selection processes may be used to remove one or more
AIDs that point to a common source of funds. Cardholder selection may then be offered if more than one AID remains, such as when the remaining AIDs point to different sources of funds (i.e., credit and debit).
Visa Debit Cards.
Cardholder selection is not required for debit functionality on U.S. Covered
3.3.7 Application Label and Application Preferred Name
Contact chip devices are required to support the character set used by the Application Label, i.e.,
ISO/IEC 8859. Support for displaying/printing the Application Preferred Name depends on whether the device/printer supports the Issuer Code Table Index associated with the application:
•
Device Supports Issuer Code Table Index—The device should display and print the Application
Preferred Name on the receipt.
•
Device Does Not Support Issuer Code Table Index—The device should display and print the
Application Label on the receipt.
Displaying the Application Preferred Name is preferred because it allows the name of the application to be displayed in the cardholder’s local language. However, some cards may be only personalized with the Application Label.
It is important that either the Application Preferred Name or Application Label is consistently used for both the display and the receipt.
Note: Although the wording may be slightly different, this recommendation is consistent with the known recommendations and requirements of the other payment schemes.
For multi-application cards, it is important to display and print the Application Preferred Name or
Application Label so that the cardholder is aware which application is being used for the transaction.
The Application Preferred Name or Application Label can be displayed at any appropriate time in transaction processing; Account Selection or PIN entry are often useful points to display the
Application Preferred Name/Application Label.
21 Cardholder selection is not required for debit functionality on U.S. Covered Visa Debit Cards. If a cardholder presents a multi-funding source (e.g. credit and debit applications) U.S. Covered Visa Debit Card, merchants that wish to maintain routing flexibility will need to deploy specific logic in their readers/terminals to ensure the Common AID is presented to the cardholder for debit functionality, in addition to the non-paired Visa AID for credit functionality. See Appendix F: Visa U.S.
Common Debit AID.
22
In the U.S., an enhanced descriptor may be used in place of the Application Label or Application Preferred Name for U.S.
Covered Visa Debit Cards. These products are typically personalized only with the Application Label and not with the
Application Preferred Name as further described in Section 4.4.2 of the Visa Smart Debit/Credit and Visa payWave U.S.
Acquirer Implementation Guide.
40 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
It can be helpful to have both the Application Preferred Name and Application Label presented to the cardholder. This reinforces to the cardholder that either application name is applicable to this application and prepares the traveling cardholder for times when only the Application Label is displayed due to language constraints.
The formats of the Application Preferred Name and Application Label allow spaces in these data elements. The device must display all characters of the Application Preferred Name or Application
Label. If the Application Preferred Name or Application Label contains an invalid character, this character must be displayed if the device is able to display it. If the device is unable to display the invalid character, it must display a space instead. Devices must not reject cards with spaces or invalid characters in these data elements.
For the specific transaction receipt requirements associated with these data elements, refer to
Section 2.7: Transaction Receipts for details.
3.3.8 Multiple Languages
Devices may offer the cardholder a choice of languages to be used. Devices have traditionally offered a menu of all languages supported by the device and have allowed the cardholder to select the language to be used for subsequent messages.
A chip card may contain a Language Preference data object (accessed when the Application Selection process begins), which contains up to four languages in order of preference. Use of EMV functionality for language selection allows the device to shift quickly to a language most familiar to the cardholder.
At the beginning of the transaction, a device using EMV functionality to support multiple languages must compare the card’s Language Preference with the languages supported in the device:
•
If matches are found, the matching language with the highest preference must be used in the messages displayed to the cardholder.
•
If no match is found and the device supports more than one language, the device must allow the cardholder to select the preferred language at the beginning of the transaction if it has the means for allowing such selection.
A chip card may contain more than one cardholder language option. Depending on the geographic location, devices may need to be capable of recognizing and communicating in multiple languages.
Support for multiple languages and character sets is recommended for all devices. Local requirements may affect the display of languages.
November 2016 Visa Public 41
3. Contact Chip Acceptance
3.4 Initiate Application Processing
3.4 Initiate Application Processing
Once an application is selected, the device sends the GET PROCESSING OPTIONS command to the card to request that the card indicates the data to be used for that application and its supported functions. The device also provides any information requested by the card as indicated by the
Processing Data Object List (PDOL) sent in the Application Selection response. If the PDOL indicated that the transaction amount is to be included in the GET PROCESSING OPTIONS command, obtaining the transaction amount must precede the Initiate Application Processing for attended POS devices.
UCATs and ATMs may either obtain the transaction amount or put zeroes in that field.
Account selection generally follows Application Selection for many ATMs and for those countries
process for account selection is not part of the EMV specifications, EMV has defined an optional data element called Account Type. Using this data element, the device can send the cardholder’s account selection to the card. A card typically requests this information in the PDOL.
3.5 Read Application Data
The device reads the data indicated by the card in the response to the GET PROCESSING OPTIONS command and uses the Application Interchange Profile (AIP) (a list of functions supported by the card) to determine whether to perform the following functions:
•
Offline Data Authentication (optional in certain cards).
•
Cardholder Verification (Visa cards are required to support this function).
• Terminal Risk Management (devices must always perform this function regardless of the application’s AIP settings unless they are online-only devices. Random transaction selection need
not be performed by offline-only devices. See 3.9: Terminal Risk Management for more
information).
• Issuer Authentication using the EXTERNAL AUTHENTICATE command (optional in cards).
3.5.1 Tags
The data retrieved by the device during this step are identified by tags. The EMV specifications define the tags for the data elements.
There may also be payment system-specific tags, issuer-specific tags, and private tags agreed upon by multiple issuers. To process private tags, a device must have the data required to identify the scope of a private tag (i.e., whether it has meaning for the transaction). If the device message format supports a generic EMV data field, such as Field 55 in an ISO message, the private-data tag should be included in that field so that it may be sent to the issuer. If the data element and logic required to identify the scope of the private tag are not correct or available, the device ignores the private tag.
42 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
3.6 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.
The device must check whether the expiration date and, if present, the effective date for the card has been reached. These conditions are later evaluated based on card and device settings to determine the transaction outcome.
ATMs must not return or decline a transaction based on expiration date. They must accept the transaction even if the card has expired and must route the transaction for issuer authorization unless the card is set to decline offline (as configured in the card Issuer Action Codes).
Note: If the ATM is performing Terminal Action Analysis, a setting in the Issuer Action Codes may cause an offline decline.
The Application Usage Control field may be set by an issuer to limit or enable a card’s use for certain transactions (for example, domestic or international, cash, goods or services, or cash back). The device checks the Application Usage Control received from the card to see if the transaction type is allowed.
The two Application Usage Controls “If goods” and “If services” should be treated as equivalent.
A transaction for domestic goods or services is allowed if either a valid control for domestic goods or domestic services (or both) is set; the same is true for international goods and international services.
3.7 Offline Data Authentication
Offline Data Authentication enables authentication of a payment application for offline transactions.
The three types of offline authentication are:
•
Static Data Authentication (SDA)—A counterfeit protection method that ensures a set of static data obtained from the valid issuer has not been modified since initial personalization onto the card. SDA support is required for all contact-chip devices with offline capability.
•
Dynamic Data Authentication (DDA)—Offers a higher level of data authentication than SDA, providing protection against both counterfeiting and the replaying of copied data (comparable to magnetic-stripe-data skimming). DDA support is required for all contact-chip devices with offline capability.
•
Combined DDA/Generate Application Cryptogram (CDA)—Combines DDA with the generation of a card’s Application Cryptogram to assure card validity. CDA is intended to protect offline transactions where there is significant opportunity for interception of chip-to-device communications. Support of CDA in devices may be needed in some countries, as this process has been implemented in specific environments.
November 2016 Visa Public 43
3. Contact Chip Acceptance
3.8 Cardholder Verification
Note: Many Visa countries have adopted a zero floor limit for chip transactions. At devices in these environments, the use of the Authorization Request Cryptogram (ARQC) in the online authorization message provides protection equivalent to the dynamic forms of Offline Data
Authentication. Therefore, Offline Data Authentication and the other offline risk controls do not need to be implemented.
All Visa cards that support DDA or CDA are required to support the Dynamic Data Authentication Data
Object List (DDOL), which contains the list of device data elements that the device must send to the card in the command requesting a dynamic signature. If a DDOL is not received from the card, the device must use its Default DDOL. The Default DDOL must contain only the tag and length for the
Unpredictable Number. No other data objects may be referenced in the Default DDOL.
Note: The Europe Region mandates that contact cards with offline capability must support DDA.
Other regional variations requiring migration from SDA to DDA may exist.
3.8 Cardholder Verification
Cardholder verification is used to evaluate whether the person presenting the card is the legitimate cardholder. The CVMs that may be supported by a contact-chip device for a chip transaction are:
•
Offline Plaintext PIN
•
Offline Enciphered PIN
•
Online PIN
•
Offline Plaintext PIN and Signature
•
Offline Enciphered PIN and Signature
•
Signature
•
No CVM Required
• Fail CVM Processing
Note: All contact-chip devices that support Offline Enciphered PIN must also support Offline Plaintext
PIN.
For the minimum global requirements for CVM support by device type, refer to Section 6.5:
Cardholder Verification Method Requirements.
The device uses a CVM List from the card to determine the type of verification to be performed.
The CVM List establishes a priority of CVMs to be used relative to the capabilities of the device and characteristics of the transaction. The CVM List may contain a CVM called Fail CVM Processing.
Sections 3.8.1 and 3.8.2 discuss processing exceptions for the CVM List and the LAST PIN TRY
display message. (See Table 2–1: Transaction Scenarios and Device Messages for display message
information.) Additional CVM considerations are discussed in Chapter 6: Security Characteristics.
44 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
3.8.1 CVM List Processing Exceptions
Devices need to support an appropriate minimum level of cardholder verification, as determined by Visa or by local law, even when the card does not support CVM processing, no CVM List is present, or the last CVM processed in the CVM List is No CVM Required. If CVM processing does not result in the required CVM, the device may additionally perform the CVM designated in the Visa rules and regulations or in local law for the device and transaction type.
If the terminal determines that CVM Processing has failed (for example, where the cardholder is unable to enter a PIN but the CVM list only supports PIN entry) and the transaction is sent online and the issuer responds with an approval, it is recommended that the device captures a signature/prints a signature line on the receipt. Although the acquirer has no liability for the transaction, given the issuer has approved it, the collection of a signature will reduce the grounds for any potential future disputes.
Visa requires Online PIN for ATMs. ATMs will always request the cardholder to enter his/her Online
PIN.
If the Visa rules and regulations or local laws do not require a particular CVM, merchants should allow
CVM processing to determine the CVM to be used. The Visa rules and regulations prohibit requesting
PIN unless specified in the chip’s CVM List or as noted above.
Easy Payment Service (VEPS) Transactions.
3.8.2 Last PIN Try Message
When the device determines that an Offline PIN is to be entered, the device must either prompt for
PIN entry (without checking the PIN Try Counter) or check the PIN Try Counter. If the PIN Try Counter is checked and it contains a value of 1 indicating one remaining PIN try, the device should display the
Visa proprietary message of LAST PIN TRY or local language equivalent.
3.9 Terminal Risk Management
Prior to sending an authorization decision to the card, the device determines whether Terminal Risk
Management must be performed.
Online-capable devices (i.e., devices capable of both offline and online processing) must support terminal risk management and perform terminal risk management for Visa chip cards, regardless of the parameters in the card. (The EMV specifications allow for cards that do not require terminal risk management.) The two mandatory risk management checks for online-capable devices are: terminal floor limits and random transaction selection.
November 2016 Visa Public 45
3. Contact Chip Acceptance
3.9 Terminal Risk Management
Online-only devices (i.e., devices that always send the transaction online to the issuer for processing) will have a zero floor limit and do not need to perform terminal risk management or random transaction selection.
3.9.1 Terminal Floor Limits
Terminal floor limits are transaction amounts at or above which an online authorization should be performed. Acquirers use the Visa rules and regulations for the country and merchant type to determine the appropriate floor limit.
Online-capable devices must perform floor-limit checking on all transactions. If card parameters indicate that the transaction must be processed online, the device must attempt to send the transaction online regardless of the floor limit, and the transaction may be declined if the device cannot obtain an online authorization.
Because countries may implement different floor limits for chip and magnetic-stripe transactions, devices should be capable of supporting both. Alternatively, devices could have an effective zero floor limit for magnetic-stripe transactions by forcing all magnetic-stripe transactions online (only where the magnetic stripe floor limit is zero) and use a floor limit for chip transactions.
Floor limits for magnetic-stripe transactions are not applicable for Fallback transactions, since all
An acquirer or merchant may have business reasons for setting a different floor limit value from that published by Visa. Setting the device’s floor limit value higher than that published by Visa creates a liability for the merchant and acquirer. In this document, floor limit values are assumed to be set to the values published by Visa in its rules and regulations.
3.9.2 Random Transaction Selection
Random selection of transactions for online processing must be supported by terminals with both online and offline capability. This functionality protects against fraudulent cards designed to operate exclusively offline.
All online-capable devices must randomly select below-floor-limit transactions for online processing.
The values used in this selection are determined per country, balancing two goals:
•
Preventing fraudsters from predicting a device’s online behavior and exploiting the floor limit
• Providing appropriate opportunities for transactions to be approved offline, depending on issuerdetermined card controls
46 Visa Public November 2016
Изтегляне
Публичната връзка е актуализирана
Публичната връзка към вашия чат е актуализирана. You may view and manage your chat links after registration here.
Публична връзка към документа
Реклама
