Misdispense. VISA Transaction Acceptance Device
Werbung
Werbung
3. Contact Chip Acceptance
3.18 EMV in Online-Only Environments
• AAC as Final Cryptogram—Unlike cash transactions, the final cryptogram requested will be an
AAC regardless of the issuer approval or non-approval. Therefore, non-cash ATM transactions cannot be used to reset offline counters, unless specific PIN and card management transactions have been implemented. At this time, Visa does not provide global support for PIN and card management transactions, but does allow implementations in some countries.
•
Issuer Authentication—Issuer Authentication may be performed, but the results cannot be considered in regards to execution of the related function. For example, if Issuer Authentication fails, an approved balance inquiry transaction will still result in display of the balance returned by the issuer.
Sales of goods and services, as well as related transaction types that support purchases, if performed at an ATM, fall under the rules and procedures for UCATs and are not considered ATM transactions.
Dispensing, or reloading, prepaid cards should be treated in an appropriate manner. If the prepaid card supports cash access, this is considered quasi-cash and should be managed as a cash disbursement. If the prepaid card does not support cash access, it can be treated as a purchase and
UCAT rules will apply.
Misdispense
For a misdispense, the ATM acquirer must advise the issuer as follows:
•
Single-Message ATM Acquirers—They must use an adjustment transaction with a message reason code to indicate that a misdispense has occurred.
• Dual-Message ATM Acquirers—They must process an ATM partial reversal for the actual amount dispensed if the misdispense is detected prior to the submission of the BASE II clearing record. If the error is identified after submission of the clearing record, the acquirer must reverse the original TC 07 and resubmit a new TC 07 with the actual dispensed amount.
Important: The adjustment transaction does not need to contain any chip data.
3.18 EMV in Online-Only Environments
Many merchants operate in a zero floor limit environment where, in most cases, transactions are sent online to be authorized by the issuer. Online-only devices are not required to support many of the EMV functions which are used for offline approvals, such as Offline Data Authentication.
Online-only devices follow a more streamlined EMV flow, using EMV mandatory functions as required.
These devices will always attempt to send the transaction online by requesting an ARQC in the first
GENERATE AC command. If online is not available, the device will request an AAC in the second
GENERATE AC command.
76 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
Also, transactions may always be sent online by setting the floor limit to zero (in conjunction with the
Visa TAC settings), or through other means. Devices configured in such a way can be considered functionally equivalent to online-only devices.
The following sections outline the EMV functions and processes which are different for onlineonly environments. Otherwise, other EMV functions are the same as outlined in previous sections.
3.18.1 Offline Data Authentication
Online-only devices are not required to support Offline Data Authentication. Since all transactions are sent online for authorization by the issuer, the ARQC will confirm to the issuer the authenticity of the card.
3.18.2 CVM Support
Online-only devices must support signature at a minimum. Optionally, these devices can support offline and/or Online PIN. Support for particular types of PINs may be may be necessary to meet domestic requirements. Acquirers should check with their Visa representative on local CVM requirements.
For the global minimum CVM requirements, refer to 6.5: Cardholder Verification Method
3.18.3 Terminal Risk Management
Terminal Risk Management consists of a series of checks to protect the acquirer, issuer, and system from potential fraud by forcing some transactions online. The nature of online-only devices means that all transactions have to be approved by the issuer and the functions in Terminal Risk
Management are not necessary.
3.18.4 Terminal Action Analysis
An online-only device always attempts to go online with the authorization request, unless declined offline due to TAC/IAC-Denial settings. During IAC-Denial and TAC-Denial processing, if a Terminal
Verification Results (TVR) bit is set and the corresponding IAC-Denial and/or TAC-Denial bits are set, the device declines the transaction. The only TAC-Denial setting for a transaction at an online-only device is “Service not allowed”.
Note: “Service not allowed” is the only TAC-Denial setting for an online-only device because most of the other TAC settings focus on offline results, such as the outcome of Offline Data
Authentication and Offline PIN processing which are not applicable to an online-only device.
November 2016 Visa Public 77
3. Contact Chip Acceptance
3.19 Visa Easy Payment Service (VEPS) Transactions
An online-only device may perform or omit IAC-Online and TAC-Online processing and IAC-Default and TAC-Default processing. For IAC-Online and TAC-Online processing, if performed, the only relevant TVR setting for an online-only device is “Transaction value exceeds the floor limit”. Because the floor limit is set to zero, the transaction always goes online and all other values in TAC-Online or
IAC-Online are irrelevant.
The IAC-Default and TAC-Default processing, if performed, always causes a transaction to be declined if an online authorization could not be performed.
Visa strongly recommends that online-only devices omit the IAC-Online and TAC-Online processing and request an ARQC after IAC-Denial and TAC-Denial processing. If unable to go online, the device should request an AAC and notify the cardholder that the service cannot be performed due to communications failure. The device should not perform the IAC-Default and TAC-Default processing.
The TAC values do not need to be present if the associated processing is omitted.
For the TAC values, refer to Section 7.2.2: Terminal Action Codes.
3.18.5 VSDC CA Public Key Support
Since online-only devices are not required to support Offline Data Authentication or Offline
Enciphered PIN,
support for asymmetric keys is not required. The processes for loading and removal
of VSDC CA Public keys as outlined in Section 6.9: Key Management are not applicable.
3.19 Visa Easy Payment Service (VEPS) Transactions
Transactions that qualify under the Visa Easy Payment Service (VEPS) program have specific requirements that device vendors need to ensure they meet:
• Offline or Online Authorization—VEPS transactions must be offline or online authorized:
– Online transactions must contain a valid authorization code.
– Offline approved transactions must indicate offline approval with an authorization response code of Y1 or Y3.
•
Chip Data and POS Entry Mode—Chip data must be provided unaltered in the authorization message or in the clearing message for offline approved transactions and identified by a
POS Entry Mode of 05.
•
No Cardholder Verification—VEPS transactions do not require cardholder verification. Device vendors and acquirers need to set up devices to only indicate support for the “No CVM Required”
CVM on transactions equal to or below the VEPS country amount limit.
31 Offline Enciphered PIN is required in some countries.
78 Visa Public November 2016
3. Contact Chip Acceptance
Transaction Acceptance Device Guide (TADG)
– One way to manage this type of processing is via an EMV selectable kernel. When the device determines that the transaction qualifies for VEPS, it can invoke a different kernel configuration that only supports the “No CVM Required” CVM. This will allow the transaction to take place without cardholder verification (assuming the card supports the “No CVM
Required” CVM in its CVM List). When the transaction does not qualify for VEPS, the device can use its standard kernel configuration where it may support signature, PIN, etc.
– Countries may also use the selectable kernel solution to facilitate PINless transactions that comply with local business requirements or regulations.
VEPS transactions may not be permitted in all countries or may not be permitted for some merchant categories. Check with your Visa representative.
3.20 Lower Voltage Card Migration
The release of low-voltage and multi-voltage payment cards will have minimal impact on the design of devices in the short term. The voltage of a device determines the voltage at which a card must be able to operate.
At present, all transaction acceptance devices must support 5V operation.
For further information, visit the EMVCo website.
November 2016 Visa Public 79
3. Contact Chip Acceptance
3.20 Lower Voltage Card Migration
80 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4. Contactless Acceptance
This section provides an overview of the requirements and recommendations for devices that are compliant to VCPS and process Visa payWave transactions.
Visa offers two ways to conduct payment over the contactless interface:
• Magnetic stripe contactless payment (Magnetic Stripe Data, MSD)
• quick Visa Smart Debit/Credit (qVSDC)
Important: Global interoperability is achieved by requiring newly issued cards and newly deployed devices to support qVSDC.
The two approaches to contactless payment are briefly introduced in the following sections.
This chapter also describes the processing steps for a contactless transaction and Visa recommendations relating to contactless readers (dongle, card reader, or other terminal device).
While MSD acceptance may currently be supported in some countries, Visa payWave acceptance is transitioning to qVSDC as the global standard. Acquirers and vendors should refer to their local Visa representatives for guidance on the Visa payWave acceptance requirements for specific regions.
Additionally, vendors developing products that support Visa payWave have the option of using the
VCPS documents or alternatively the EMV Contactless Specifications, Book C-3. Acquirers and vendors can discuss their approach in more detail with their local Visa representative.
4.1 MSD
The MSD contactless transaction operates under magnetic stripe payment service rules according to Visa rules and regulations. As for magnetic stripe processing, routing for MSD transactions can be accomplished through the use of BIN routing logic.
MSD offers a magnetic stripe payment service using Track 2 Equivalent Data acquired from the chip
(or Track 1 constructed from data acquired from the chip) over the contactless interface.
MSD operates under magnetic stripe payment rules and offers the following additional risk management features:
•
MSD Legacy offers Dynamic Card Verification Value (dCVV), as defined by VCPS. MSD Legacy is defined in VCPS to support backwards compatibility with VCPS 1.4.2 cards and readers.
•
MSD CVN17 offers an EMV strength application cryptogram.
While not EMV-compliant, MSD uses EMV methodology for selecting applications, initializing transaction processing, and reading records to obtain the application data. MSD uses a subset of EMV commands and requirements. MSD does not require all mandatory EMV data elements to be present in the card.
November 2016 Visa Public 81
4. Contactless Acceptance
4.2 qVSDC
Note: Magnetic Stripe Image (MSI) is sometimes confused with MSD. MSI is EMV-compliant, and is the minimum implementation of VIS. MSI is not allowed as a contactless magnetic stripe solution.
4.2 qVSDC
qVSDC is based on EMV concepts and uses the existing Visa chip systems and rules of operation. qVSDC reduces the reader to card processing time by minimizing the number of commands and responses that must be exchanged between the reader and the card. It offers an offline quick low value (LV) payment feature, Offline Data Authentication, and Online Card Authentication using the current Cryptogram Version Number 10, the minimized Cryptogram Version Number 17, or
Cryptogram Version Number 18. qVSDC uses the EMV methodology for selecting applications, initializing transaction processing, and reading records to obtain the application data. qVSDC uses a subset of EMV commands and requirements. The GET PROCESSING OPTIONS command response uses EMV Format 2, but is not fully EMV-compliant because it does not always contain the Application File Locator (AFL). qVSDC does not require that all mandatory contact EMV data elements be present in the card or if present, that they be included in the card data that is read.
Streamlined qVSDC is a simplified, online-only version of qVSDC which eliminates some of the internal card decision making steps. From the perspective of the device, however, a streamlined qVSDC transaction is similar to regular qVSDC and there are no additional requirements.
4.2.1 Fast Dynamic Data Authentication (fDDA)
qVSDC offers support for Offline Data Authentication using fDDA, which is similar to Dynamic Data
Authentication (DDA), with the following differences:
•
Generation of the dynamic signature is initiated by the GET PROCESSING OPTIONS command.
The INTERNAL AUTHENTICATE command is not used and no DDOL is used.
•
The results of fDDA are not provided online to the issuer within the TVR or protected by the online authorization or clearing cryptograms.
Using card and reader dynamic data, fDDA validates that card data has not been fraudulently altered and that the card is genuine and has not been created from skimmed data. In addition to signing the
(reader) Unpredictable Number, which is signed in most EMV contact chip applications, fDDA also signs additional transaction dynamic data. The Amount, Authorized, Transaction Currency Code, and (card) Unpredictable Number are all signed using fDDA.
82 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
To optimize processing power and reduce transaction times, the fDDA dynamic signature is generated during the GET PROCESSING OPTIONS command, rather than generating the dynamic signature at the end of the transaction when the card may be moving away from the reader Radio Frequency (RF) field.
4.3 Global Interoperability
All newly issued Visa payWave cards and newly deployed readers are required to support qVSDC.
While MSD support may be allowed for legacy programs in some countries, support for MSD is not recommended as its use is prohibited in some countries and may be in a sunset phase in others.
As part of our efforts to improve interoperability and payment security, Visa is committed to the eventual migration of all contactless payments away from MSD processing to more reliable and secure EMV-based qVSDC processing. Visa is currently evaluating time frames under which to establish a global sunset date for the contactless MSD processing path.
Table 4–1 describes the possible interactions between contactless cards and readers.
Table 4–1: Summary of Possible Reader and Card Interactions
Reader Configuration
qVSDC-only qVSDC and MSD
MSD-only
Card (supports qVSDC and
MSD) Method Selected
qVSDC qVSDC
MSD
Visa requires that newly deployed devices comply with VCPS 2.1.x. or the EMV Contactless Specification
for Payment Systems, Book C-3.
4.4 Processing Overview
This section provides an overview of a VCPS transaction. Functions are mandatory unless otherwise
noting both MSD and qVSDC steps. Functions noted as Conditional are functions that are followed if the various conditions relating to the function are met. Functions that are noted as Optional are those which may be enabled at the discretion of the acquirer or due to local requirements.
32
For legacy reasons and to accommodate special arrangements, some MSD form factors may exist in select countries. These form factors can be supported by readers that support qVSDC and MSD but not those that only support qVSDC. All newly deployed Visa payWave devices must support qVSDC.
November 2016 Visa Public 83
4. Contactless Acceptance
4.4 Processing Overview
Figure 4–1: Sample Contactless Transaction Flow Diagram
84 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4.5 Initiating a Visa payWave Transaction
During a Visa payWave transaction, consumers briefly hold their Visa payWave card near the reader, when prompted, instead of inserting their card in the reader as with contact chip transactions or swiping the magnetic stripe. The Visa payWave card is embedded with an antenna and a chip.
The chip, through the antenna, communicates with the merchant’s contactless reader to enable the transaction. Acquirers should be aware that Visa payWave transactions may be initiated not only from a traditional plastic card but also from other contactless form factors and devices (e.g., NFCenabled mobile devices and key fobs).
The transaction processing will then differ depending on whether it is a qVSDC or MSD transaction.
The following sections outline the processing for each scenario.
4.6 qVSDC Transaction Flow
4.6.1 Preliminary Processing
Before the card and reader begin their interaction, the transaction amount is typically received by the reader before it performs its preliminary processing. Preliminary Processing expedites the transaction by allowing the reader to perform several risk management steps prior to interacting with the card.
During preliminary processing, the reader may use the transaction amount to perform the following checks:
• Reader Contactless Transaction Limit—Transactions for amounts above this limit are terminated and may be processed only by using a different interface. All new contactless readers must have this limit disabled or set to its maximum value
contactless devices at a later date.
and this will become a requirement for all
•
Reader Cardholder Verification Method (CVM) Limit—Transaction amounts above this limit require cardholder verification for the contactless transaction. This limit is normally set to the VEPS limit.
•
Reader Contactless Floor Limit—Transactions above this limit require an online authorization by the card issuer. This limit is generally the same as the magnetic stripe and contact chip floor limits. For online-only countries, this limit is set to zero or is not supported by the reader.
The reader sets the results of these checks in the Terminal Transaction Qualifiers (TTQ), a reader data element. The TTQ provides the card with the reader’s capabilities and requirements.
33 This is a requirement in Visa AP and CEMEA.
November 2016 Visa Public 85
4. Contactless Acceptance
4.6 qVSDC Transaction Flow
4.6.2 Application Selection
Once the reader has completed Preliminary Processing, the reader signals to the consumer that the reader is ready for the contactless card. The cardholder briefly waves or holds the Visa payWave card close to the contactless reader to initiate the transaction. The reader determines whether it shares a contactless application with the card by selecting the card’s list of contactless applications called the
Proximity Payment Systems Environment (PPSE). If there is an application in common, that application is automatically selected; otherwise, the reader terminates the transaction and the transaction may proceed via another interface such as contact chip or magnetic stripe.
An Application Identifier (AID) is an identifier of the application. The reader compares the AIDs that it supports to the ADF Names in the PPSE on the card to determine which application to use for the
transaction. The reader must contain the applicable Visa AIDs. Refer to Section 7.2.3: Application
Note: If there are two or more applications in common, the application with the highest priority can be automatically selected.
For example, a card may have both credit and debit applications, in which case the issuer or consumer will have defined one of those applications as a higher priority than the other.
Note: AIDs may have a length of 5 to 16 bytes. As per the EMV Specification, devices must be able to select AIDs that are between 5 to 16 bytes in length.
4.6.3 Dynamic Reader Limits (Optional)
Once the application has been selected, readers that support Dynamic Reader Limits (DRL) examine the Application Program Identifier (Program ID) returned by the application to determine the applicable reader limits for the transaction.
When the Program ID returned by the card does not match a reader Program ID (or the card does not return a Program ID), the reader processes the transaction using the default reader limits and results determined during Preliminary Processing.
If a Program ID is returned by the card and it matches a reader Program ID (full or partial), the reader uses the reader limits associated with the matching Program ID to process the transaction.
34 Special logic may allow selection of alternate AIDs as further described in the Sections 4.4.3, 4.5.1. and Appendices D and E of the Visa Smart Debit/Credit and Visa payWave U.S. Acquirer Implementation Guide and the Visa Reference on Application
Selection for the U.S.
86 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
For example, the default reader limits in Preliminary Processing may use a global reader CVM limit of $25, and the reader may have a Reader CVM Limit of $100 for domestic cards (as identified by the matching Program ID). In this case, the Reader CVM limit will be $100 for domestic cards and $25 for international cards.
DRLs may be mandatory in some regions and acquirers should confirm this with their local Visa representative. Acquirers should also confirm if there is an applicable Program ID for their country and acceptance environment.
4.6.4 Card Requests Terminal and Transaction Data
Once the application is selected, the Visa payWave card responds by requesting information such as the transaction amount, TTQ, and the reader’s currency code for use during the transaction. The reader responds with the requested information.
The TTQ advises the Visa payWave card of the reader’s requirements and capabilities for processing the specific transaction. This includes, but is not limited to:
•
Whether it supports qVSDC or MSD as well as whether it supports contact VSDC
•
Whether it supports Signature, Online PIN, (Contact Chip) Offline PIN, and/or Consumer Device
CVM
Note: A Consumer Device CVM is a CVM performed on, and validated by, the consumer’s payment device, independent of the reader.
•
Whether the reader supports Issuer Update Processing
•
Whether cardholder verification is required for the transaction
In qVSDC transactions, the card uses the information provided in the TTQ to make risk management decisions before responding to the reader. Visa does not require the use of a Transaction Certificate
Data Object List (TDOL). As such Visa does not have a defined value for the default TDOL and vendors or acquirers may set the default TDOL to any value since it is not used for processing of Visa contactless transactions.
4.6.5 Fast Dynamic Data Authentication (Conditional)
fDDA is required for readers supporting offline transactions or for environments such as transit where the card needs to be authenticated before the transaction is authorized online. During fDDA, the reader verifies the dynamic signature returned by the card and authenticates data from the card.
Refer to Section 4.2.1: Fast Dynamic Data Authentication (fDDA) for more information.
November 2016 Visa Public 87
4. Contactless Acceptance
4.6 qVSDC Transaction Flow
4.6.6 Cardholder Verification (Conditional)
Cardholder Verification is required for readers implementing qVSDC. During Cardholder Verification, the reader determines the Cardholder Verification Method to be performed (if any).
The cardholder may be validated using one of the following methods:
•
No cardholder verification. The cardholder does not have to provide a signature or PIN. For example, transactions that qualify for VEPS may take place without cardholder verification.
•
Signature
•
Online PIN
•
Consumer Device CVM (CDCVM)
Note: A CDCVM is a CVM performed on the consumer’s payment device independent of the reader.
For further information see Section 6.4: Consumer Device CVM (CDCVM).
4.6.7 Transaction Terminated
Rather than decline a transaction needlessly, if a Visa payWave transaction cannot be completed as a contactless transaction but may be completed via another interface, the contactless transaction may be terminated and may be processed as a physical contact chip or magnetic-stripe transaction.
Terminated transactions differ from declined transactions because declined transactions may not be reinitiated. The acquirer’s merchant environment may have specific best practices or requirements for situations where it is preferred to terminate the transaction and proceed with a contact interface.
4.6.8 Online Processing
The reader indicates to the cardholder that the card can be removed from the reader’s field. The reader uses the information provided by the card and transmits the transaction to the acquirer.
The reader sends the data from the transaction including the cryptogram, information regarding the selected application, and the interface used together with standard transaction data to the acquirer.
The acquirer then formats the corresponding VisaNet authorization message including the relevant data fields with the additional chip data sent in V.I.P. Field 55.
35
Most countries require the acquirer to support the chip data in Field 55 although some allow support for the expanded third bit map. Check with your Visa representative for the rules in your country.
88 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
During a qVSDC transaction, the issuer, or Visa on the issuer’s behalf, validates the card using the appropriate Cryptogram Version Number.
Based on the results of Online Card Authentication, along
with other standard risk management checks (such as ensuring that the card is not expired, and verifying that the account is in good standing and has available funds), the issuer either approves or declines the transaction in the authorization response.
The authorization response is sent to the acquirer which logs the response and forwards the response to the merchant terminal.
4.6.9 Transaction Outcome
The reader conveys the issuer’s authorization response by displaying whether the transaction is approved or declined. If approved, depending on Visa and domestic rules, the transaction may not require a cardholder signature or a receipt. If the transaction is approved, this includes capturing the cryptogram and the associated data are captured and later submitted as part of clearing and settlement.
4.7 MSD Transaction Flow
MSD support may be allowed for legacy programs in some countries, but it is not recommended. Its use is prohibited in some countries and may be in a sunset phase in others. If support for contact chip is already present, restricting support to the qVSDC path for contactless will simplify the contactless implementation.
MSD transactions follow magnetic-stripe processing and rules, with routing accomplished through the use of BIN routing logic, except that they may include enhanced Online Card Authentication using
CVN 17. Depending on local requirements and rules, transactions below a certain defined value may not require cardholder verification (signature or Online PIN) or a receipt. Regional rules and requirements define the cardholder verification method for particular transactions. Acquirers should contact their Visa representative for specific information.
The following sections outline the steps involved in a MSD transaction.
36
Current Cryptogram Version Numbers include CVN 10 (‘0A’), CVN 17 (’11), CVN 18 (’12’), and CVN ‘43’. Acquirers are not required to perform any analysis related to the Cryptogram Version Number; they should simply pass the cryptogram to
VisaNet/issuer for processing.
November 2016 Visa Public 89
4. Contactless Acceptance
4.7 MSD Transaction Flow
4.7.1 Application Selection
Unlike qVSDC, MSD readers do not support preliminary processing but otherwise Application
Selection is very similar.
First, the reader determines whether it shares a contactless application with the card by selecting the card’s list of contactless applications (the PPSE). If there is an application in common, that application is automatically selected. If there are no applications in common, the contactless transaction is terminated and the transaction may proceed via another interface (magnetic stripe or contact chip).
In the event that there are two or more applications in common, the application with the highest priority is automatically selected. For example, if a card contains both a credit and debit application, the issuer defines one of those applications with a higher priority and the higher priority application is automatically selected.
The reader compares the AIDs that it supports to the AIDs in the PPSE on the card to determine which application to use for the transaction. The reader must contain the applicable Visa AIDs.
Note: AIDs may have a length of 5 to 16 bytes. As per the EMV Specification, devices must be able to select AIDs that are between 5 to 16 bytes in length.
4.7.2 Card Requests Terminal and Transaction Data
Once the contactless application is selected, the Visa payWave card requests information from the reader to use during the transaction by sending the Processing Options Data Object List (PDOL) to the reader. The reader responds with the requested information.
The information includes the transaction amount, the reader’s capabilities and requirements in the
Terminal Transaction Qualifiers and other transaction data. The card uses the TTQ to ascertain the capabilities of the reader including whether the reader supports MSD CVN17. After reviewing the TTQ, the card completes its part of the MSD transaction by sending data to the reader such as the Track 2 data. The reader then indicates to the cardholder that the card can be removed from the reader’s field.
After the exchange, the reader prompts the cardholder to remove the card from the reader’s field.
4.7.3 Cardholder Verification (Conditional)
The terminal determines the cardholder verification requirement as per magnetic-stripe processing rules. The cardholder may be validated using one of the following methods:
•
No cardholder verification. The cardholder does not have to provide a signature or a PIN. For example, transactions that qualify for VEPS take place without cardholder verification.
• Signature
•
Online PIN
90 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4.7.4 Online Processing
The reader sends the data from the transaction including the cryptogram to the acquirer. If the transaction is to be routed to VisaNet, the acquirer then formats the corresponding VisaNet authorization message including the relevant data fields such as the PAN Sequence Number in V.I.P
Field 23 (when returned by the card) and the additional chip data in V.I.P Field 55.
Note: For MSD transactions where a MSD legacy card was used, Field 23 and Field 55 are not sent.
The issuer (or Visa, on the issuer’s behalf) performs enhanced Online Card Authentication using
CVN 17 or dCVV (if a legacy card was used). The authorization response is determined by the cryptogram results along with other standard risk management checks such as checking the cardholder’s Online PIN, if applicable, ensuring that the card is not expired, and making sure that the account is in good standing and has available funds. The issuer sends the authorization response to the reader.
4.7.5 Transaction Outcome
The acquirer formats the issuer response and forwards it to the terminal. The terminal or reader conveys the issuer’s authorization response by displaying whether the transaction is approved or declined. If approved, depending on whether the transaction qualifies for VEPS, the transaction may not require a cardholder signature or a receipt.
If the transaction is approved, it is later submitted as part of clearing and settlement.
4.8 Visa payWave for Mobile
From an acceptance perspective, mobile devices containing a Visa contactless payment application can be accepted in any version of contactless readers that are developed to different versions of the
Visa Contactless Payment Specification (VCPS) such as VCPS 1.4.2, VCPS 2.0.2, and VCPS 2.1.x.
However, only readers developed to the VCPS 2.1.x are able to accept the Consumer Device CVM
(CDCVM) as a recognized Cardholder Verification Method (CVM). CDCVM is a CVM type performed and verified on the consumer’s payment device (usually a mobile handset), requiring no additional action by the reader.
Visa payWave transactions that originate from mobile devices have the same processing requirements as Visa payWave transactions that originate from cards. There is no difference between a card and a mobile Visa payWave transaction from the point of view of the transaction processing, authorization, and settlement data that is passed through V.I.P. and BASE II systems.
Acquirers can obtain more information from their Visa representative.
November 2016 Visa Public 91
4. Contactless Acceptance
4.8 Visa payWave for Mobile
4.8.1 Pre-tap and CDCVM
Although a contactless transaction is normally completed with a single presentment of the contactless payment card, when the consumer’s payment device is a mobile handset, the initial presentment of the mobile handset may result in what is referred to as a “pre-tap.” A pre-tap is defined as the first presentment of the mobile handset to the reader wherein the mobile handset requires some consumer interaction to complete the transaction. For example, this may occur when a CDCVM is required for the transaction and one has not yet been performed. After the consumer interaction has been completed, the mobile handset is re-presented to the contactless payment reader to conduct the payment transaction.
Note: Pre-tap and CDCVM as a recognized Cardholder Verification Method are supported by readers compliant to VCPS 2.1 and above.
The following is a description of the processing flow when a CDCVM is required and was not performed by the cardholder prior to presenting the mobile handset to the contactless reader:
1. The mobile handset is presented to the contactless reader and a CDCVM is required to complete the transaction. A CDCVM may be required for many reasons, including but not limited to the following:
•
Mobile handset is configured to require a CDCVM for every transaction. This may be the result of cardholder or issuer configuration settings.
•
CVM was required for the transaction and CDCVM is the common CVM supported by both the mobile handset and the contactless reader. Note that the CDCVM is performed and verified entirely on the mobile handset. No additional action is required of the merchant to capture CVM, unlike with Signature and Online PIN.
2. The mobile handset sends an indication to the contactless reader that some form of consumer interaction is required to complete the transaction (that is, a pre-tap has occurred). This indication is conveyed by the mobile handset by sending a GET PROCESSING OPTIONS (GPO) response with
Status Word = '6986'.
3. Upon receipt of this indication, the contactless reader displays a message instructing the cardholder to consult their mobile handset for further instructions, and after a short duration
(usually a couple seconds), the contactless reader returns to Discovery Processing to await the representment of the mobile handset to reattempt the transaction.
4. Once the cardholder has performed the necessary action on the mobile handset (e.g., successfully performed a CDCVM), the cardholder re-presents the mobile handset to the contactless reader and the transaction is completed.
Note: An indication is sent to the reader and to the issuer that a CDCVM was performed for the transaction.
Similarly, following is a description of the processing flow when a CDCVM is required and was performed by the cardholder prior to presenting the mobile handset to the contactless reader:
92 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
• The mobile handset is presented to the contactless reader, the mobile handset determines that a
CDCVM is required to complete the transaction and that a CDCVM has already been performed, and the transaction is completed.
In this latter scenario, although a CDCVM was required for the transaction, a CDCVM had already been performed, there was no pre-tap, and the transaction was completed on the initial presentment of the mobile handset.
4.9 Reader User Interface Recommendations
Since contactless cards are generally new to the market, it is important that the process of the cardholder presenting their card for use at the merchant is made as easy and intuitive as possible. To avoid confusion, it is also important to have a consistent way to inform the cardholder about when and where to present their card and when to remove it.
EMVCo has developed a set of user interface recommendations that provide best practices on how to design a reader user interface that will provide a consistent consumer experience. Some of the recommendations include:
•
The cardholder interface should provide a visual and audio indication of the appropriate status of a contactless transaction.
•
The reader should support language selection as defined in the EMV Specifications.
•
The reader should support a standard set of display messages. The EMV specifications provide a suggested set. The messages may also be complemented by corresponding visual and audio indications.
Certain regions will also have specific user interface requirements and it is important to contact the local Visa representatives to confirm local or regional requirements in this regard.
The best practices outlined in this section are noted in greater detail in the EMV Contactless
Specifications for Payment Systems—Book A, which can be obtained from EMVCo.
4.10 Contactless Processing for Industry Specific Transactions
The following sections provide some guidelines and best practices on how to handle specific industry
VisaNet Data Element Mapping provides information on how to map EMV data elements mentioned
in these sections to the VisaNet (V.I.P. and BASE II) messages.
November 2016 Visa Public 93
4. Contactless Acceptance
4.10 Contactless Processing for Industry Specific Transactions
4.10.1 Pre-Authorizations
If an authorization takes place before the final amount is determined, then it is known as a preauthorization; pre-authorizations are subject to payment system rules. The amount presented to the card in the GET PROCESSING OPTIONS command of a pre-authorization should be an estimated amount and should be the same amount and currency that is sent to the issuer in the authorization request message (if required). MSD merchants may present a zero for the Cryptogram Amount, while using the estimated amount in the authorization message itself. Note that in unattended environments, this estimated amount is likely to be the maximum dispensable value of goods or services.
The Pre-Authorization process will perform all the VCPS functions and the online request message (if generated) should contain all the appropriate contactless chip data elements. The card and device interact in an identical fashion to the purchase process, including CVM processing. The appropriate contactless chip data elements from both the Pre-Authorization request and response should be retained for the Sale Completion transaction. These elements include the TC or ARQC. The full Track 2 data should not be retained (in line with Payment Card Industry Data Security Standard (PCI DSS)) but the PAN and expiry date will be required. If a pre-authorization is performed without the card being present, the introduction of VCPS has no impact and existing practices should continue.
4.10.2 Sale Completion
A Sale Completion is the financial settlement of a previously pre-authorized transaction, often where the cardholder and card are no longer present.
The final transaction amount may differ from the pre-authorized amount, within a range defined in the
Visa rules by country. Where a cryptogram and its associated data are provided in clearing,
retained contactless chip data elements from the associated Pre-Authorization transaction, including all fields needed to validate the cryptogram, should be populated into the clearing message. It is recommended that the authorization approval code from the original pre-authorization response message (as opposed to those obtained from incremental authorizations) be used in this message as this code will generally be for the highest value.
The Sale Completion will contain an ARQC for online approved transactions or a TC for offline approved transactions.
37 In some instances, the cryptogram data is not required in clearing.
94 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4.10.3 Deferred Authorizations
Deferred Authorization is where an online authorization is performed after the card is no longer available, typically because the device temporarily does not have a connection (i.e., communications failure or device is on a transit vehicle) or the amount is over the floor-limit and the device has no online capability. The acquirer is at risk for those transactions that are subsequently declined, or if cleared, is liable for these transactions in the event that they are charged back for no authorization.
Note that submission of unauthorized transactions into clearing may not be allowed in some countries, such as in the U.S.
Deferred Authorization is the recommended process for dealing with temporary outage situations.
Where the environment supports offline authorization, Deferred Authorization can be supplemented with offline approvals for transactions under the floor limit. (Note that offline approvals for a transaction over the floor will still leave the acquirer liable for chargebacks for no authorization.)
In a zero-floor limit (always online) country, an ARQC is requested and retained for the subsequent authorization request. In a country supporting offline approvals, a TC may be requested for underfloor-limit transactions.
Deferred Authorization requests that receive an approval may be cleared. Those that do not must be discarded. Transactions in a non-zero-floor-limit environment that received a TC may be cleared.
4.10.4 Acquirer Stand-in
Acquirer stand-in (also called authorization truncation) may be done because the acquirer or the device temporarily does not have a connection (communications failure) or the acquirer deems the risk of chargeback to be less than the cost of authorization. The acquirer “stands in” for the issuer and returns a positive authorization response. However, because the acquirer does not have the issuer’s authorization decision criteria, the acquirer is liable for these transactions in the event that they are charged back for no authorization
4.10.5 Status Check and Account Number Verification
In a card present environment, VCPS functions such as Offline Data Authentication (fDDA, if supported by the card application) can be used to validate a card against the possibility of counterfeit. However, offline validation will not protect against lost and stolen, nor can it ensure that funds are available.
Status Checks (an authorization request for a single unit of currency was traditionally invoked to validate that the card used to make a reservation, or to pay for goods in advance of delivery is authentic. In a card present environment, VCPS functions such as Offline Data Authentication (fDDA, if supported by the card application) should be sufficient to ensure a card is not counterfeit (i.e., a non-
VCPS transaction should be used and a status check may no longer be necessary). Except for a few specific merchant categories, if an online validation is desired, use of a Status Check has been replaced by an Account Number Verification (an authorization request for a zero amount).
November 2016 Visa Public 95
4. Contactless Acceptance
4.10 Contactless Processing for Industry Specific Transactions
4.10.6 Refunds
The recommended method for performing a contactless refund is to start a contactless transaction and follow the normal VCPS transaction flow in order to obtain the Track 2 Equivalent Data field from the contactless chip. An ARQC should be requested.
MSD merchants may present a zero for the Cryptogram Amount. For qVSDC merchants, if the PDOL indicates that the transaction type is to be included in the GET PROCESSING OPTIONS command, the terminal should send the transaction type as '20' and should use the refund amount. If the transaction type is not requested, the Cryptogram Amount should be set to zero.
Once the terminal has read the Track 2 Equivalent Data from the contactless chip, the subsequent decision of the contactless chip to approve or decline the transaction is not relevant. Therefore, merchant systems should be able to process the refund irrespective of the cryptogram produced by the card (ARQC or AAC). The decision to approve or decline the refund should be made by the acquirer or merchant in the same way as for magnetic stripe.
If an attempted contactless refund fails (for example, if the contactless chip cannot be read or contactless technology fails at some point in the transaction), the merchant should re-initiate the refund transaction either by using the magnetic stripe or by using Key Entry procedures (if available).
4.10.7 Reversals
Reversals are a function of the transaction network or of the device application and do not require interaction with the card for generation of the reversal message itself.
The authorization reversal is an online message indicating the amount (the difference between the authorized amount and the dispensed amount) that is to be credited back to the cardholder’s account.
No contactless chip data needs to be included in the authorization reversal.
In the settlement message, the Cryptogram Amount should contain the original estimated authorization amount, while the transaction amount should reflect the dispensed goods amount. In a single-message system, the original transaction will contain the estimated amount and the contactless chip data (including ARQC).
A partial reversal reverses a portion of the original transaction amount. Acquirers and merchants submit a partial reversal when an estimated amount exceeds the final value of the completed transaction. For instance, if the estimated amount is USD$200 but the final amount is USD$100, then a partial reversal can be submitted for the USD$100 difference between the estimated and final amounts. The chip-related requirements for partial reversals are similar to those of full reversals.
96 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4.10.8 Cancellations
Cancellations may occur when a purchase or sale completion is aborted during processing or after processing and may occur due to a number of reasons. In all cases, initiation of a cancellation should result in the cessation of processing and clearing of any data elements.
If the transaction has not reached the point where an application cryptogram has been requested, the card reader can simply be powered off.
If an ARQC has been requested and the transaction has been routed online, then cancellation processing should also generate an authorization reversal. The transaction should simply be removed from the clearing batch or marked void.
If the device has received a TC or AAC from the card, the transaction is completed and can now be cancelled (removed from the batch or marked as void).
Visa recommends that the device produce a receipt for the cardholder showing that the original transaction has been cancelled.
4.10.9 Referrals
A referral is intended as a fraud control tool for issuers to use when more information is needed to verify the identity of the cardholder prior to approving a transaction. A referral is not a transaction; it is an exception process for a purchase.
In most cases, the referral process involves a discussion between the cardholder and the issuer, and will result in a completely new transaction taking place once the issuer has lifted the authorization block.
4.10.10
VCPS Transactions using Magnetic Stripe Data
Visa payWave transactions performed as defined in the VCPS 1.4.2 specifications are referred to as
MSD Legacy transactions. MSD Legacy transactions are processed identically to magnetic-stripe-read transactions, with the exception that the POS Entry Mode is set to 91.
All other data and processing is identical to a magnetic-stripe read (except that dCVV is used instead of CVV).
Note: VCPS 2.x products may perform MSD Legacy transactions to be backwards compatible with
VCPS 1.4.2 products that are already deployed or issued.
38 The Terminal Entry Capability for all transactions from these devices will be set to either 5 (contact support; may support contactless) or 8 (contactless support; does not support contact) depending on the capabilities of the device.
November 2016 Visa Public 97
4. Contactless Acceptance
4.11 Contactless Transactions at ATMs
4.10.11 Non-VCPS Transactions Using VCPS Functionality
Similar to contact chip and EMV, it is possible to use VCPS functionality to undertake non-VCPS transactions. These transactions will use the VCPS functionality to obtain information from the card
(such as the card number) and to also verify the validity of the card for identification purposes.
Various VCPS functions can be used in this case including Application Selection, Initiate Application
Processing, Read Application Data, Online Processing, and Issuer Update Processing.
Transaction Amounts for these transactions should be set to zero and there are no clearing records.
Non-VCPS transactions using VCPS functionality should follow the VCPS transaction flow and follow all relevant VCPS requirements.
POS balance inquiries and POS deposits are examples of non-VCPS transactions using VCPS functionality.
4.11 Contactless Transactions at ATMs
This section provides an overview of considerations for contactless ATM transactions. For details, refer
to Appendix G: Contactless ATM Requirements.
4.11.1 Contactless ATM Transaction Processing
ATMs have some unique characteristics that need to be considered when performing contactless transactions. This section provides a summary of these items:
•
ATM Card Read—Unlike contact-chip initiated and magnetic-stripe initiated transactions, contactless chip-initiated transactions do not require the card be inserted into the reader.
Contactless cards may simply be presented to the contactless landing pad to initiate a contactlesschip transaction.
•
Online Authorization—ATMs are online-only devices; they will always go online for Cash
Disbursement and Balance Inquiry authorizations.
•
No Offline Data Authentication—Because transactions are always sent online, ATMs do not perform Offline Data Authentication.
•
No Pre-Processing—Unlike typical POS contactless transactions, ATMs do not perform any Pre-
Processing.
39
This does not preclude implementations where the contactless card can be inserted into the ATM, with a contactless chip read occurring while the card is within the body of the ATM. However, requiring that the contactless chip card be inserted into the ATM may physically preclude the ATM from being able to accept contactless capable consumer payment devices that have other form factors (for example, mobile handsets, key fobs, wearables). For this reason, such an implementation is not recommended.
98 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
• Online PIN—The CVM is Online PIN and no other CVMs are currently supported for ATM transactions. Online PIN will always be requested regardless of the CVMs supported by the card.
The Terminal Transaction Qualifiers (TTQ, Tag '9F66') data element on the ATM, however, must be configured to indicate that the ATM does not require a CVM for the transaction and that the ATM supports Signature, CDCVM, and Online PIN. This is done to ensure that the contactless card does not unnecessarily terminate the transaction.
•
Online Card Authentication—Enhanced security is achieved by performing Online Card
Authentication Method where an ARQC is generated by the chip and validated by the issuer as part of online authorization processing.
•
Processing Restrictions—ATMs supporting contactless transactions may implement the ATM
Offline Check to determine whether contactless ATM transactions are supported by the card, and if not supported, whether the issuer prefers ATM transactions for their cards to be switched to contact chip or declined offline.
Note: The ATM Offline Check is strongly recommended in the Europe Region and optional in other countries. Check with your Visa representative.
•
Amount, Authorized—The Amount, Authorized, also referred to as the Cryptogram Amount, is the amount sent from the ATM to the card for generation of the ARQC. In most instances, during a contactless ATM transaction, the amount of the transaction is not known at the time that the
ATM sends the cryptogram data to the issuer so the Cryptogram Amount is usually zero. (If the amount is known, e.g., when performing a subsequent transaction using Transaction Chaining, the actual amount of the transaction, rather than a zero, is used.
•
Transaction Chaining—ATMs often support Transaction Chaining, where a transaction is completed by offering another service. Re-tapping the card on the contactless landing pad is recommended for financial transactions and optional for non-financial transactions. For both financial and non-financial transactions, cardholders must re-enter their PIN.
•
No Data Mixing—For implementations where transaction data can be read from multiple interfaces, the transaction data should not be mixed (e.g., when the data is read from the contactless interface, only data from that interface should be used on the transaction).
Other than what is described above, the ATM should only perform the minimum and mandatory Visa payWave functions required to send the transaction online using Online PIN.
Note: Sales of goods and services and related transaction types, if performed at an ATM, fall under the rules and procedures for UCATs and are not considered ATM transactions. The Processing Code will be 00 and an appropriate MCC other than 6011 (such as 6012, if the transaction is a purchase) should be used.
For details, refer to Appendix G: Contactless ATM Requirements.
November 2016 Visa Public 99
4. Contactless Acceptance
4.11 Contactless Transactions at ATMs
4.11.2 Contactless ATM Processes Not Defined by VCPS
Processes that are not defined by VCPS such as Transaction Selection or Account Selection may be executed at any appropriate time:
•
Transaction Selection—Transaction Selection allows the cardholder to select the type of transaction that is to be performed. Choices typically include cash disbursement, balance inquiry, and funds transfer or other functions provided by the Acquirer.
•
Account Selection—If Account Selection is supported, Account Selection must be supported for contactless chip just as it is for magnetic-stripe. Although not part of the Visa payWave processing flow, Account Selection will generally follow Application Selection (and Transaction Selection).
Account Selection allows the cardholder to select one of the multiple sources of funds associated with the primary account (such as checking, savings, or credit card account).
Online PIN entry is also not defined in the Visa payWave specifications. Online PIN entry may occur at any point in the user interface flow prior to Online Processing.
4.11.3 Additional Contactless ATM Transaction Types
ATMs generally support other financial management transactions such as Balance Inquiries and Funds
Transfers, as well as customer-specific transactions offered by the acquirer. Visa payWave functions that extract information or request identification or authentication can be used to complete these transactions. Transaction types supported on the Visa network should follow the full Visa payWave processing flow. Currently, the Visa network supports Cash Disbursements, Funds Transfers, Balance
Inquiries, and Shared Deposits (Plus only). Transactions not supported by the Visa network are not considered Visa payWave transactions.
Transactions using Visa payWave functions must follow all relevant Visa payWave requirements. Non-
Visa payWave transactions using Visa payWave functionality should follow the Visa payWave transaction flow.
100 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4.12 Other Processing Considerations for VCPS
The following sections address other processing considerations for VCPS.
4.12.1 Forcing a CVM
Where a POS device is allowed to bypass CVM processing (i.e., merchant participates in VEPS) or where the ATM always forces Online PIN, the device will need to ensure the card does not unnecessarily reject the transaction.
This can be accomplished by indicating in byte 1 of the Terminal Transaction Qualifiers (TTQ) that both
Online PIN and Signature are supported, and in byte 2 that CVM is not required. A new setting in byte 3 of the TTQ should also indicate that the contactless reader can accept a Consumer Device CVM
(CDCVM).
The VCPS specifications provide more detail on the use of the TTQ.
4.12.2 Premature Card Removal
If the card is removed before the transaction is complete (i.e., the transaction has not reached Card
Read Complete step), then the current transaction data is discarded and the reader returns to
Discovery Processing.
4.12.3 Gratuities or Tips
Gratuities/tips may be handled as described in Section 3.15.5.
4.12.4 Placement of Contactless Readers
Visa has developed a set of recommendations as general guidance for the placement of contactless card reading devices in a merchant retail environment. They are intended to provide guidance to expedite contactless card reader integration into a merchant POS environment and ensure efficient
operation. Refer to Appendix E: Placement of Contactless Readers, for more details.
November 2016 Visa Public 101
4. Contactless Acceptance
4.12 Other Processing Considerations for VCPS
4.12.5 Visa Easy Payment Service (VEPS) Transactions
Transactions that qualify under the VEPS program have specific requirements that device vendors need to ensure they follow.
• Authorization—VEPS transactions must be authorized (either online or offline):
– Online transactions must contain a valid Authorization Code.
– Offline approved transactions must indicate offline approval with an Authorization Response
Code of Y1 or Y3.
•
POS Entry Mode—Chip data must be provided unaltered in the authorization message or in the clearing message for offline approved transactions and identified by:
– POS Entry Mode 07 (for qVSDC).
– POS Entry Mode 91 (for MSD).
•
qVSDC Reader CVM Required Limit—The Reader CVM Required Limit should be set to the VEPS limit.
With this configuration, the reader will require a CVM for transactions above the VEPS limit,
and will not require a CVM for transactions below the VEPS limit.
Note: qVSDC readers may support a feature called Dynamic Reader Limits (DRL), allowing the reader to support multiple CVM limits. These qVSDC readers may be configured with a Reader
CVM Required Limit for domestic transactions and a different Reader CVM Required Limit for international transactions. In this scenario, the Reader CVM Required Limit for domestic cards should be set to the VEPS country limit
and the Reader CVM Required Limit for international cards should be set to the VEPS international limit.
• MSD—For MSD transactions, handling of VEPS is performed in exactly the same manner as for physical magnetic stripe transactions (i.e., when the amount is equal to or below the VEPS limit, the transaction may take place without cardholder verification or a receipt).
Device vendors and acquirers should consult with their local Visa representative for the best approach in their region.
40
Because the reader requires a CVM when the transactions amount is less than or equal to the Reader CVM Required Limit, the Reader CVM Required Limit should more accurately be set to the VEPS Limit plus one minor unity of currency. For example, with a VEPS limit or $25.00, the Reader CVM Required Limit should be set to $25.01
41 See previous footnote.
42 See previous footnote.
102 Visa Public November 2016
4. Contactless Acceptance
Transaction Acceptance Device Guide (TADG)
4.12.6 Dynamic Currency Conversion (DCC)
Dynamic Currency Conversion (DCC) is described in Section 2.16: DCC may be performed for Visa
payWave transactions, subject to the rules and recommendations outlined in that section.
Note: DCC is permitted for POS transactions in both card present and card absent environments, and is not allowed at ATMs in Visa Inc. regions in accordance with the Visa Core Rules and Visa
Product and Service Rules. The Europe Region has separate rules for DCC.
If and when DCC is performed for Visa payWave, this section describes the procedures to be performed, in order to minimize the number of the times the card is presented to the acceptance device:
1. The cardholder presents the Visa payWave card to the acceptance device, transaction data is exchanged between card and acceptance device (including any amount and local currency information requested by the card), and the cardholder removes the card.
2. The acceptance device determines whether the transaction is eligible for DCC and offers DCC to the cardholder.
3. If the cardholder accepts DCC, the acceptance device performs an online authorization and the online authorization message (and any subsequent clearing records) contains:
•
Converted amount in V.I.P. Field 4 and the cardholder’s billing currency in V.I.P. Field 49.
•
Unconverted amount and the local currency, as used in the card-and-acceptance device interaction, in V.I.P. Field 55.
November 2016 Visa Public 103
4. Contactless Acceptance
4.12 Other Processing Considerations for VCPS
104 Visa Public November 2016
5. Magnetic Stripe Acceptance
Transaction Acceptance Device Guide (TADG)
5. Magnetic Stripe Acceptance
This section provides an overview of the requirements for a transaction acceptance device that accepts magnetic-stripe cards.
5.1 Card Acceptance Methods
A device accepts a magnetic-stripe card through one of the following methods:
• Swipe or slide
• Dip
• Insert (for motorized readers)
Note: A motorized reader with card retention capability may be needed to support requirements to capture cards.
The cardholder or merchant 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.
When a card is presented at a magnetic-stripe-only device, the device should always attempt to read the magnetic stripe. If the magnetic stripe cannot be read, key-entry procedures may be used at the point of service unless disallowed under the Visa rules and regulations or prohibited by local law.
5.2 Magnetic Stripe Data Processing
A device that accepts magnetic-stripe transactions must:
• Read a magnetic stripe that conforms to Track 1 (refer to Appendix A) or Track 2 (refer to
Appendix B) data specifications.
•
Not erase or alter any magnetic encoding on a card.
• Transmit all data encoded on either Track 2 or 1 of the magnetic stripe to the acquirer. It is strongly recommended that Track 2 is sent, with or without Track 1.
•
Be able to distinguish the magnetic stripe containing Visa payment data from other proprietary magnetic-stripe data on a card (for devices with multiple reader heads).
November 2016 Visa Public 105
5. Magnetic Stripe Acceptance
5.3 Service Codes
5.3 Service Codes
The Service Code on the magnetic stripe indicates the circumstances under which the card can be accepted (for example, international transactions, domestic-only transactions, ATM-only transactions).
The code also defines requirements for processing a transaction with the card (for example, chip enabled, PIN required, or always authorize).
A device with online capability must either read and act upon the Service Code value on a card’s magnetic stripe or send the transaction online to the issuer for authorization. Offline-only devices must both read and act upon the Service Code value.
5.3.1 Service Code Values
For a description of the Service Code, refer to Appendix A: Track 1 Data Specifications and
Appendix B: Track 2 Data Specifications.
The following outlines specific information for Service Code values:
•
2xx and 6xx—When reading a card via the magnetic-stripe reader, contact-chip-capable devices must examine the Service Code on the magnetic stripe to determine if the card is chip enabled
(2xx or 6xx). If the Service Code indicates that the card is chip enabled, the device must prompt the cardholder or merchant to insert the card into the contact chip reader, unless operating under
•
5xx and 6xx—Service Codes 5xx and 6xx indicate that the magnetic stripe is restricted to domestic-use only. The device, however, does not necessarily know in which country the card was issued and is not required to do so.
•
x2x—For transactions processed using data read from the magnetic stripe, Service Codes requiring online authorization (x2x) must be respected regardless of floor limit. Offline-only devices, or a device that is temporarily unable to send a transaction online, cannot authorize the transaction when the card’s magnetic stripe is encoded with an x2x Service Code. A merchant could, however, complete the transaction by obtaining a voice authorization.
•
xx0, xx6, and x20—A device that supports a PIN pad should use the Service Codes relating to PIN entry (xx0 and xx6) to determine if a PIN should be requested prior to initiating the online authorization. If an x06 (PIN, if PIN pad present) or x20 (PIN required) Service Code is read, the device should request PIN entry and transmit the transaction online. If the device is unable to process the transaction online, it should process the transaction as normal for an x06 Service Code or reject the transaction for an x20 Service Code.
106 Visa Public November 2016
5. Magnetic Stripe Acceptance
Transaction Acceptance Device Guide (TADG)
Note: When discussing Service Codes, references to PIN mean Online PIN. An offline-PIN-only PIN pad (which is to be used for contact-chip transactions) is considered “PIN Pad Not Present” when evaluating the applicability of Service Codes. Also, if the acceptance device does not support PIN for Visa and Visa Electron, even if PIN is supported for other acceptance marks, the PIN pad is considered not present.
•
xx3—POS devices processing transactions for amounts below the floor limit should ensure that the Service Code is not xx3, ATM only.
5.3.2 Service Code Not Recognized
If the device does not recognize the Service Code, the transaction must be submitted for online authorization if the device has online capability. Offline-only devices or a device that temporarily cannot authorize a transaction should reject a transaction when the device does not recognize the
Service Code or the merchant may be liable for certain chargebacks.
5.3.3 Magnetic-Stripe Service Code Chargebacks
Magnetic-stripe transactions submitted into clearing without online authorization are subject to chargebacks for Service Code violation if the Service Code was ignored.
5.4 Visa Easy Payment Service (VEPS) Transactions
Merchants that meet specific qualification criteria may participate in the VEPS programs. On qualifying
VEPS transactions, merchants are not required to perform cardholder verification and a receipt is optional, unless requested by the cardholder.
VEPS transactions that are completed with a magnetic-stripe card must be authorized online and contain a valid authorization code. The data transmitted in the authorization message must be full and unaltered with a POS Entry Mode of 90.
November 2016 Visa Public 107
5. Magnetic Stripe Acceptance
5.4 Visa Easy Payment Service (VEPS) Transactions
108 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
6. Security Characteristics
This chapter provides an overview of security requirements and characteristics relating to acceptance devices, such as PIN Entry Devices (PEDs), key management, and security best practices for mobile payment acceptance solutions.
Devices must be able to ensure the security of sensitive data, such as cardholder PINs and secret keys for symmetric algorithms, and to ensure the integrity of public keys for asymmetric algorithms.
Similarly devices must ensure data security when cardholder data is transmitted over wireless networks or when used in mobile payment acceptance solutions.
EMVCo has produced the EMV Acquirer and Terminal Security Guidelines to assist acquirers with terminal security and acceptance processing. The document can be downloaded from the EMVCo website at www.emvco.com.
Additionally, acquirers and device vendors are required to comply with various requirements of the
PCI Security Standards Council (PCI SSC) which owns, maintains, and distributes the PCI Data Security
Standard (DSS), PCI PIN Transaction Security (PTS), and all their supporting documents. Various PCI requirements are outlined in this section and relevant PCI documentation is available from the PCI website at www.pcisecuritystandards.org.
6.1 Cardholder Verification Methods
The CVMs that may be supported by a transaction acceptance device are outlined in the following table:
Table 6–1: Allowable CVMs by Environment
CVM
Signature
Offline Plaintext PIN
Offline Enciphered PIN
Offline Plaintext PIN and Signature
Offline Enciphered PIN and Signature
Online PIN
Consumer Device CVM (CDCVM)
No CVM Required
Magnetic Stripe
Contact Chip
Contactless Chip
November 2016 Visa Public 109
6. Security Characteristics
6.2 Signature
Cards and devices may also agree on a higher level of CVM than the minimum. The Visa rules and regulations concerning the level of cardholder verification required for certain types of transactions
(for example, manual cash or quasi-cash) apply regardless of whether the transaction is initiated from a chip or magnetic stripe.
The Visa rules and regulations allow some transactions to be performed without cardholder verification under certain conditions, such as VEPS transactions. Merchants that participate in VEPS need to take steps to ensure their terminals do not request a Cardholder Verification Method (i.e., signature or PIN) for qualifying transactions.
6.2 Signature
All attended devices must support signature. At attended devices, where a PIN has not been entered, the device must capture the cardholder’s signature (either by having the cardholder sign the receipt or capturing it electronically using a touch screen and a pen-like device or stylus to write the signature) where CVM List processing requires it, unless the Visa rules and regulations allow an exception, such as for VEPS transactions. The merchant is required to compare the signature on the receipt with that on the signature panel of the card. If the two signatures match, the cardholder’s identity is deemed to have been correctly verified.
Note: A contact chip card may require both PIN and signature for a given transaction.
If the transaction is verified and approved via a PIN, the terminal should state “Verified by PIN” or
“PIN Verified” on the receipt in place of the signature line. However, in the instance where the selected
CVM is a combination of Offline PIN and signature, the device may print (in addition to the PIN verification message) a signature line for the cardholder’s signature or capture the cardholder’s signature electronically. If signature is to be captured on a printed receipt and there is no signature line on the receipt, the merchant may collect the signature anywhere on the receipt.
6.3 Personal Identification Number (PIN)
PIN verification is performed by verifying the PIN entered at the point of transaction, either online by the issuer or offline using a chip card.
•
Online PIN—When the PIN is to be verified online, the PIN is entered, encrypted, transmitted, translated, and verified against the reference PIN data available in the issuer’s processing center or verified using the PVV method of verification (in which the cardholder's PIN entry is compared against a cryptographic transformation of the PIN). If the PINs match, the cardholder’s identity is deemed to have been correctly verified.
•
Offline PIN—When the PIN is to be verified offline, the PIN is entered and verified against the reference PIN stored on the card’s chip. If the PINs match, the cardholder’s identity is deemed to have been correctly verified.
110 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
The PIN requirements in this section apply only to VisaNet interchange transactions. Client financial institutions may develop and comply with their own standards for PINs used in on-us transactions.
Note: During a chip transaction, devices must use the PAN received from the chip application and not that encoded on the magnetic stripe when building PIN blocks.
The Visa Transaction Acceptance Device Requirements document and the Visa rules and regulations contain Visa’s requirements for PIN entry. For more information on security characteristics and requirements, see www.visa.com/pinsecurity and www.pcisecuritystandards.org.
6.3.1 PIN Length and Character Set
The minimum PIN length is 4 digits. Visa specifies that ATMs and POS PEDs must be able to accept
Online PINs of 4, 5, and 6 digits (and can accept up to 12 digits).
An ATM acquirer conducting business in the U.S. must be able to accept and transmit Online PINs that are 4 to 12 digits long.
Offline PINs may be between 4 and 12 digits long and are validated offline between the card and the device. Per EMV and VIS, chip devices must be able to handle Offline PINs with these lengths.
PEDs may visually indicate that a digit has been entered, such as with an asterisk (*). This visual indication should occur for each digit entered by the cardholder. For example, a PED should not display only four asterisks when six digits have been entered. Similarly, if audible tones are used, the tone should be generated each time that a digit is entered. The PIN character set is 0 to 9. For more information, refer to PCI PTS.
6.3.2 Online PIN
For devices such as ATMs and POS devices where Online PIN is supported, the PIN must be protected immediately upon entry by encryption in accordance to ISO 9564 and must be processed as specified in the PCI PIN Security Requirements and protected as specified in the PCI PTS POI Modular Security
Requirements.
Online PIN entry may occur at any point in the user interface flow prior to online processing; the encrypted PIN may remain in the encrypting PIN pad (EPP) until needed for online processing.
Devices that support Online PIN entry should be constructed so that any tampering with the device stops it from working. See PCI PTS for additional details.
November 2016 Visa Public 111
6. Security Characteristics
6.3 Personal Identification Number (PIN)
The process of entering an Online PIN for chip-initiated transactions is outside the scope of EMV processing. The use of a CVM that is not required by the card but is required by the Visa rules and regulations should have no effect on the TVR. If the result of CVM List processing is “cardholder verification was not successful”, the corresponding bit should still be set in the TVR. Similarly, the
“Online PIN entered” bit should not be set even when Visa rules and regulations require that an Online
PIN be requested. For example, an ATM always requests an Online PIN regardless of CVM List preferences.
There are two situations where PIN capability specifically refers to Online PIN for Visa products:
1. PIN Entry Capability—An acquirer must only use PIN Entry Capability (V.I.P. Field 22, Position 3) to identify support for Online PIN. If a device only supports Offline PIN and/or only supports Online
PIN associated with a domestic payment scheme, this field must be set to indicate that the device cannot accept and forward a PIN.
2. Service Code—For transactions initiated via the magnetic stripe, the PIN settings in the Service
Code only refer to Online PIN capability. Note: The Service Code value is not used during a chip transaction except to identify the card as a chip card via 2xx/6xx.
6.3.3 Offline PIN
When a device supports 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.
The Offline PIN must be processed as specified in the EMV specifications and the PCI PIN Security
Requirements and protected as specified in the PCI PTS POI Modular Security Requirements.
Offline PIN verification may occur in one of two ways:
•
Offline Plaintext PIN—The chip reader sends the PIN to the chip as plaintext.
• Offline Enciphered PIN—Either the secure component in the device (for example, the chip reader) or the PIN pad itself enciphers the PIN, using an authenticated encryption public key from the chip. The enciphered PIN is sent to the chip, where the PIN is deciphered using the private key on the chip.
The encrypting PIN pad (EPP) and the chip reader are either integrated into a single device or configured as two separate devices (for example, using an external EPP). In addition, depending on device design, the PIN entered may either travel directly from the EPP to the chip reader within a secure environment or travel indirectly (via a tethered cable if some distance is involved) to the chip reader.
112 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
When the EPP and the chip reader are integrated and the PIN travels directly from the EPP to the reader within a protected environment as defined in ISO 9564-1, the PIN does not need to be encrypted at the point of entry.
When the environment from the PIN pad to the chip reader is unprotected (for example, via a tethered cable or a lengthy travel path), the EPP must immediately either encrypt the PIN at the point of entry using a Triple Data Encryption Standard (TDES) key or encipher the PIN using an appropriate
RSA public key from the chip, before sending the PIN to the chip reader. This allows protection of the
PIN during transport. For more information, refer to the PCI PTS.
For Offline Plaintext PIN, the EPP encrypts the entered PIN using TDES, sends the encrypted PIN to the chip reader, which decrypts the encrypted PIN, and sends the PIN to the chip as plaintext.
For Offline Enciphered PIN, one of two situations may occur:
•
Public Key—The chip reader extracts the chip card public key and sends it to the EPP. The EPP enciphers the entered PIN using the RSA public key and sends the enciphered PIN to the chip reader. The chip reader sends the RSA-enciphered PIN to the chip.
•
TDES—The EPP encrypts the entered PIN using TDES and sends the encrypted PIN to the chip reader. The chip reader decrypts the encrypted PIN using TDES and then enciphers it using the appropriate RSA public key from the chip.
All contact-chip devices placed in service that support Offline Enciphered PIN must also support
Offline Plaintext PIN. It is strongly recommended that devices supporting Offline PIN support both plaintext and enciphered.
Offline PIN is not allowed for ATMs, which must support and transmit only Online PINs.
6.3.4 EMV PIN Entry Bypass
EMV PIN Entry Bypass is a mechanism that is available to environments that are transitioning from signature to PIN at the point of sale. During the transition period, if cardholders forget their PIN, they can cancel out of PIN entry. The device will set the “PIN entry required, PIN pad working, but PIN not entered” bit in the TVR and this bit setting will be provided in the online authorization message to the issuer. Refer to EMV v4.3, Book 4, Section 6.3.4.3 for more information on PIN Entry Bypass.
Note: The card needs to be personalized correctly to allow PIN Entry Bypass. Acquirers should check with their Visa representative to determine if this mechanism applies to their market.
Note: Some countries do not allow PIN Entry Bypass and device vendors should ensure their devices comply with local requirements.
November 2016 Visa Public 113
6. Security Characteristics
6.4 Consumer Device CVM (CDCVM)
6.3.5 Online PIN Retries
Certain transactions, such as ATM withdrawals or balance inquiries, may involve Online PIN retries by the cardholder following entry of an incorrect PIN. Acquirers may accompany the PIN retry with the same chip data as was sent during the first attempt, or they may restart the chip transaction for each
PIN retry using the AID selected in the initial Application Selection process.
6.4 Consumer Device CVM (CDCVM)
VCPS 2.1.x readers must enable support for the Consumer Device CVM (CDCVM). The CDCVM is a
CVM performed on the consumer's payment device (independent of the reader).
Reader support for the CDCVM is mandatory for VCPS 2.1.x readers, as is indication of its support in the Terminal Transaction Qualifiers. In addition to supporting the CDCVM, the reader may then support other CVMs such as signature and/or Online PIN.
As part of application processing, if a mobile device with Visa payWave capabilities is being used, the mobile device may respond to the reader that a CDCVM is required for the transaction and has not yet been performed. This is referred to as a pre-tap. Once the consumer performs the CDCVM, the mobile device is (re)presented to complete the transaction.
114 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
6.5 Cardholder Verification Method Requirements
The following table outlines the minimum global requirements for CVMs that devices must support by device type (M = Mandatory, O = Optional, – = Not Applicable or Not Allowed). The items outlined as optional in the following table may be conditional or required in certain countries. Check with your
Visa representative to understand the specific requirements for your country.
Table 6–2: Global Minimum CVM Requirements by Device Type
Attended POS
UCAT
ATM
CVM
Magnetic
Stripe
Device
O
Contact
Chip
Device
O
Contactless
Chip Device
Magnetic
Stripe
Device
O
Contact Chip
Device
Contactless
Chip Device
No CVM
Signature M M
O
M –
M
(all new devices must support; all existing must support as of
July 1, 2015)
–
M
(all new devices must support; all existing must support as of
July 1, 2015)
–
–
–
Online PIN
Offline Plaintext
PIN
Offline
Enciphered
PIN
O
–
–
O
O
O
(Must also support
Offline
Plaintext
PIN)
–
O
–
–
O
–
–
O
O
O
(Must also support
Offline
Plaintext
PIN)
–
O
–
– –
CDCVM – M
(only applicable to VCPS
2.1.x devices)
– M
(only applicable to VCPS
2.1.x devices)
Note: If the merchant is a VEPS merchant and the transaction qualifies for VEPS, the merchant may optionally process the transaction without a CVM.
–
M
–
43
The CVM requirements listed in this table for ATMs are only applicable when dispensing cash. ATMs may also dispense goods and services; in which case, they would adhere to the CVM requirements for UCAT purchases. In addition, an ATM may be configured to indicate support for other CVMs in addition to Online PIN to ensure acceptance of chip cards although these other CVMs will never be used for transaction processing; only Online PIN will be used.
November 2016 Visa Public 115
6. Security Characteristics
6.6 PIN Entry Devices (PED)
6.6 PIN Entry Devices (PED)
A PED is any device at which a cardholder enters their PIN. It may have other functions. For example, to enter a loyalty program number. For a contact-chip device, it may contain an EMV kernel.
If a device is configured with an external PED, the application needs to ensure that the PED is always connected to the device and is functional. The PED must be protected against unauthorized removal as defined in PCI PTS.
A PED that supports Online PIN, Offline Plaintext PIN, or Offline PIN (both Offline Plaintext PIN and
Offline Enciphered PIN) where the PED and chip reader are not integrated must contain an encrypting
PIN pad (EPP) used for entering a cardholder PIN. The PED and EPP may be integrated, as in some standalone POS devices, or the EPP may be just one component of a PED, as in an ATM.
The following sections discuss the chip-reading device requirements for PEDs and PED testing requirements.
6.6.1 Chip-Reading Device Requirements for PEDs
Contact-chip devices should be capable of accepting a PIN for verification of Visa transactions. At a minimum, chip devices must be equipped with a port that can support a PED if the devices do not have a PED present.
If a PED is present and active, the chip device must use a PIN pad that meets Visa requirements. It must also act on the CVM List, except as specified in the Visa rules and regulations.
Support for PIN may not be required in situations where interaction between a device and cardholder is inherently impractical (for example, road tolls and transit applications). Some countries may have other specific exceptions. For information on exceptions in a specific country, contact the appropriate regional Visa representative.
If the design of the device requires that parts of the device be physically separated (for example, the
PED is not integrated into the device) and any cardholder instructions or processing data pass between the separate parts, there must be equal levels of protection between the different parts that make up the device.
When a device has a PIN pad that is not used for chip transactions (for example, if it processes only magnetic-stripe-based domestic debit transactions), the EMV Terminal Capabilities data element should indicate that the device does not support Offline or Online PIN.
116 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
6.6.2 PED Testing Requirements
Visa requires testing of PEDs against the PCI PTS security requirements if they are used in the acceptance of Visa card products with PIN verification. PEDs and EPPs must undergo a physical and logical security evaluation performed at a PCI recognized test laboratory.
For information on PCI PIN entry device security requirements, see www.pcisecuritystandards.org/security_standards/ped/
6.7 Terminal Security and Risk Policy
Acquirers should develop a terminal security and risk policy that considers the various issues associated with the deployment of terminals, threats to their operation, and the policies required for their secure operation. This policy should then be socialized with the acquirer’s device vendors and payment system providers as well as internal risk and operations teams.
Parts of the policy may then also be included as part of the commercial agreement between acquirers and merchants to ensure merchants comply with any requirements that are their responsibility.
The policy should, wherever possible, reference Visa and industry guidelines and recommendations such as those from PCI.
6.8 Terminal Deployment and Management
Acquirers should develop a terminal deployment process which safeguards the use of the terminals and minimizes any potential misuse which may lead to interoperability problems or possible fraud.
Acquirers should maintain an inventory of all their terminals and be able to identify each terminal uniquely, including its location and software version. This will ensure that any potential problems can be pinpointed and resolved in an expedited manner. This will also aid in replacing or upgrading terminals once their EMV kernels expire or require renewal.
EMVCo has outlined a set of guidelines in relation to deployment and management of terminals.
Some of these guidelines are noted below:
•
Acquirers should maintain an inventory of all the terminals from which they process transactions and should be able to identify each terminal uniquely, know where it is located, and which software versions it is running.
•
Acquirers should establish a terminal management policy with merchants, such that terminal replacement and maintenance procedures are clearly defined.
November 2016 Visa Public 117
6. Security Characteristics
6.9 Key Management
• For terminals in exposed environments and especially those with a high level of staff turnover, such as garages and fast food outlets, acquirers should recommend to merchants to physically secure the terminals, using a lock under control of the site management. Information can be found in the PCI SCC document Skimming Prevention Best Practices for Merchants available from the PCI SCC website at www.pcisecuritystandards.org/security_standards/.
•
Acquirers should review the EMV Acquirer and Terminal Security Guidelines document which is available from the EMVCo website for further details.
6.9 Key Management
Key management plays an essential role in integrating the components of a working security architecture. It provides critical security support to ensure the integrity of all cryptographic processes involved in card life cycle and transaction processing. The security of data is dependent upon the prevention of disclosure and unauthorized modification, substitution, insertion, or deletion of keys.
Key management requirements are described in the PCI PIN Security Requirements and in the EMV
Specifications including EMV’s security guidelines.
Sections 6.9.1 through 6.9.9 describe the symmetric and asymmetric key management requirements,
the management of Visa Smart Debit/Credit (VSDC) Certification Authority (CA) Public Keys, and Issuer and ICC keys.
Important: Acquirers are responsible for ensuring that test keys are removed from terminals prior to production deployment.
6.9.1 Symmetric Key Management
PIN confidentiality depends on the implementation of adequate PIN security standards. To this end,
ANSI, ISO, and Visa require migration from the DES algorithm using single-length keys to the TDES algorithm using at least double-length keys.
TDES support is required for any device supporting Online PIN as well as for any device that uses DES encryption to transport an Offline PIN (both Offline Plaintext PIN and Offline Encrypted PIN) from the
PIN pad to the card reader. Visa requires that all Online PINs (and Offline PINs where applicable) be protected with TDES.
6.9.2 Asymmetric Key Management
It is the acquirer’s responsibility to ensure that VSDC CA Public Keys are loaded or deleted from devices that support SDA, DDA, CDA, fDDA, or Offline Enciphered PIN according to annually published
Visa schedules.
118 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
To ensure sufficient levels of support for RSA key backup, key recovery, and key migration, offlinecapable devices must be capable of securely storing six VSDC CA Public Keys and their associated data elements. A device should enable the secure loading, updating, and maintenance of the VSDC CA
Public Keys. In this context, secure means that the keys should be protected from unauthorized modification.
Terminals supporting offline cryptography must be able to support key lengths up to 1984 bits. The current implemented lengths can be found on the EMVCo website at www.emvco.com and at the Visa technology partner site at https://technologypartner.visa.com. The 1984-bit key has been published, meaning that if all keys are installed at the time of deployment, the acquirer might not require any further key installation. However, acquirers should retain the ability to do so if required. Acquirers whose terminal base does not currently include all the keys must add the missing keys.
A device must be able to select the corresponding key and algorithm in conjunction with the RID and the Public Key Index (PKI) of the selected application. Planned updates and accelerated key revocations require that keys be updated in all devices. Unauthorized changes to the algorithms, keys, and insertion of an unauthorized key should not be possible. Devices must comply with the Visa and
EMV requirements for withdrawal and introduction of the VSDC CA Public Keys.
6.9.3 Obtaining VSDC CA Public Keys
The VSDC CA Public Keys are available for public download from Visa’s website, www.visa.com/pubkeys or at the Visa technology partner site at https://technologypartner.visa.com/Library/Specifications.aspx.
The websites contain the VSDC CA Public Keys via a link to an Adobe format (PDF) document.
Before an acquirer relies on the downloaded information (for example, by loading it onto the device population), it should check the information with a secondary source. Acquirers may check the Visa
Smart Debit/Credit Certification Authority Technical Requirements. This document contains the current
VSDC CA Public Keys, including a SHA-1 hash digest of each key, and explains how to validate the
VSDC CA Public Keys against a secondary source.
Validating the VSDC CA Public Keys against a secondary source is essential to counter the risk of the
Visa website (or the particular page with the VSDC CA Public Keys) being compromised (hacked) while an acquirer downloads the keys.
The acquirer can also use the checks to verify the continued integrity of the VSDC CA Public Keys while they are stored with the acquirer.
November 2016 Visa Public 119
6. Security Characteristics
6.9 Key Management
6.9.4 Loading VSDC CA Public Keys
Visa does not mandate specific loading processes for the VSDC CA Public Keys and their associated data. EMVCo, however, provides some guidelines on this process (see EMV ICC Specifications for
Payment Specifications Book 2) and acquirers and device vendors should ensure their processes comply with these guidelines. Acquirers should also periodically ensure the integrity of each key component, including the public exponent, the CA Public Key Index, and others.
Once loaded, EMVCo suggests that terminals should include a mechanism to allow acquirers to determine which keys are present at any given time to assist in the ongoing management, including removal, of keys through the lifetime of the terminal.
Since Offline Data Authentication and Offline Enciphered PIN are not supported at ATMs, there is no need to set up a public key management system to support ATM acquiring.
6.9.5 Planned Revocation of VSDC CA Public Keys
Once a Certification Authority Public Key pair has reached its planned expiration date, it must be removed from service. Visa has a planned revocation process to remove older keys. At an appropriate time prior to the planned revocation/expiration date, Visa will stop signing Issuer Public Keys with the corresponding Certification Authority Private Key.
Acquirers and device vendors must also ensure that any test keys that may have been loaded to undertake testing prior to production rollout are removed from the device.
6.9.6 Expired VSDC CA Public Keys
Based on developments at EMVCo, Visa periodically reviews and determines the expiration dates of the VSDC CA Public Keys. Acquirers’ key management must support removal of expired keys from their devices based on the expiration and removal dates.
A Visa International Member Letter or Visa Business Review is sent to acquirers advising them of the planned expiration and removal dates. Generally, an 18-month grace period is provided to assist acquirers in these efforts.
6.9.7 Accelerated Revocation of VSDC CA Public Keys
Visa analyzes and determines if an accelerated or emergency key revocation is required due to public key attacks. Should this occur, clients are advised of Visa’s findings and associated procedures. For more information, refer to the EMV specifications.
120 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
6.9.8 Managing VSDC CA Public Keys Distribution
To ensure the integrity of the VSDC CA Public Keys as acquirers are distributing them to their deployed device base, Visa has established the following principles:
•
If the keys are being distributed across a communication channel that is not under the control of an acquirer, the receiving device should be able to authenticate the communication originating from the acquirer.
Devices not on a private network should perform some kind of authentication. For example, manually updated devices require log in; remotely managed devices need to validate the device management system. This could be done with a cryptographic challenge or any reasonable validation method. The proprietary nature of device management systems and devices will likely result in the use of proprietary validation systems.
Any time that a key is distributed across an uncontrolled channel when it is not possible to authenticate the acquirer or authorized agent, it should be validated against an alternate channel.
Recipients should always double check the key against a secondary source.
•
Valid keys should be delivered to the device in a manner that protects their integrity.
Note: The primary purpose of this principle is to ensure that keys are not corrupted or modified during delivery and to ensure that their integrity is maintained. For example, the device could validate the key by checking a hash generated from the key such as SHA-1.
Alternatively, the device management system could do the integrity validation using its own validation technique such as check sum as long as the device management system completely controls the software updates to the device.
•
Ensure that new keys are loaded prior to the effective date.
Note: All deployed devices should have new keys prior to cards being circulated. A manual or automated procedure should be in place to begin deployment of keys in sufficient time to ensure that all deployed devices accept cards with the new keys as they are issued.
•
Ensure that expired or revoked keys are removed or disabled within 18 months of expiration or revocation.
Note: As above, a manual or automated procedure should be in place to ensure that all keys are removed or disabled within 18 months of the expiration date.
• Within a reasonable timeframe, acquirers should be able to determine which VSDC CA Public Keys are active in each of their devices.
Note: Acquirers should be able to report on the status of their installed device base to assure issuers that cards with new keys are accepted and to protect against attacks based on devices whose expired or revoked keys have not been removed. Visa strongly recommends that the process be automated.
November 2016 Visa Public 121
6. Security Characteristics
6.10 Data Security
6.9.9 Issuer and ICC Keys
Issuer and ICC keys, extracted during Offline Data Authentication and Offline Enciphered PIN processing, may have lengths up to 1984 bits. Devices must be able to support issuer and ICC keys that are not based on 8-byte boundaries. For example, a key may be 127-bytes long.
6.10 Data Security
This section describes the industry security standards for cardholder data and payment application data.
6.10.1 Cardholder Data Security
When customers offer their cards at the point of service, they want assurance that their account information is safe. Cardholder data must be protected wherever it resides.
The Payment Card Industry Data Security Standard (PCI DSS) resulted from a cooperative effort among Visa, MasterCard, American Express, Discover, and JCB to offer a single approach to safeguarding sensitive data for all card brands. The PCI Security Standards Council (PCI SSC) owns, maintains, and distributes the PCI Data Security Standard (DSS) and all its supporting documents.
Compliance with the PCI DSS is validated under two programs within Visa:
•
Cardholder Information Security Program (CISP) for U.S.-based entities (www.visa.com/cisp)
• Account Information Security (AIS) for non-U.S.-based entities
Europe Region entities can find more information at: http://www.visaeurope.com/en/businesses_retailers/payment_security.aspx, while other non-U.S.based entities can access http://corporate.visa.com/st/.
It is a requirement of Visa acquirers that they must ensure the compliance of their merchants and service providers to the PCI standards where they may store, process, or transmit Visa account numbers.
More information can be found at www.pcisecuritystandards.org/security_standards/.
6.10.2 Payment Application Data Security
Payment applications must not retain full magnetic-stripe data, Card Verification Value (CVV), Card
Verification Value 2 (CVV2), or PIN data and must support a merchant's and agent’s ability to comply with the PCI DSS.
Note: Payment Application-Data Security Standard (PA-DSS) compliant payment applications never handle unencrypted PIN data.
122 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
Merchants and agents using vulnerable payment applications are at heightened risk of compromise attacks. The PCI SSC adopted Visa’s PCI Payment Application Best Practices and released the standard in April 2008 as the Payment Application Data Security Standard (PA-DSS).
Per Visa mandates, all new merchants must use payment application software that uses PA-DSS compliant applications or be PCI-DSS compliant. Acquirers must ensure that their merchants and agents use PA-DSS compliant payment applications. For purposes of the mandates, payment applications apply only to third-party payment application software that stores, processes, or transmits cardholder data as part of an authorization or settlement of a payment card transaction. POS devices are an example of this. PA-DSS does not apply to merchant or agent in-house developed applications, standalone hardware terminals, or PEDs. Payment application vendors must validate the conformance of their products to the PA-DSS. Acquirers should insist that their merchants and agents use compliant applications and upgrade or patch applications that cause the storage of sensitive cardholder data to meet the Visa mandates.
More information can be found at www.visa.com/pinsecurity and www.pcisecuritystandards.org/security_standards/
6.10.3 Data Processing and Transmission Security and Integrity
Any data that passes through the acquirer to VisaNet or the issuer must not be altered, especially chip data related to the cryptogram and its generation. This relates to online authorization requests and responses which may include additional data such as Issuer Scripts. Issuer Scripts must be forwarded to the card by the terminal, if present.
Similarly, acquirers will collate transaction data for clearing and settlement purposes. Typically, the data is collated and then batched for processing on a regular basis (generally daily). All data should be protected against unauthorized alteration and deletion.
Any processing and storage of data must also comply with PCI requirements as outlined in previous sections.
6.10.4 Wireless Security
The PCI Standards Council has developed guidance and recommendations for the deployment of wireless networks, including 802.11 Wi-Fi and 802.15 Bluetooth technologies to ensure protection of cardholder data. The PCI DSS Wireless Guidelines are designed to help organizations understand and interpret how PCI DSS applies to wireless environments, how to limit the PCI DSS scope as it pertains to wireless, and to provide practical methods and concepts for deployment of secure wireless in payment card transaction environments.
Merchants and device vendors that use or develop devices that transmit payment card information over wireless technology should have these controls in place to protect those systems and reduce the risk of data compromises.
November 2016 Visa Public 123
6. Security Characteristics
6.11 Card Verification Value 2
The PCI guidelines recommend the use of technologies such WPA2 or secure pairing for Bluetooth devices for encrypting and authenticating wireless LANs. Wireless networks are also considered to be public networks meaning all cardholder data must be encrypted as required in PCI DSS if it is to be transmitted over a wireless network. Encryption methods can include, but are not limited to, SSL/TLS,
IPSEC, and WPA2-AES.
Further information can be found in the PCI DSS Wireless Guidelines supplement available at https://www.pcisecuritystandards.org/security_standards/documents.php.
6.11 Card Verification Value 2
The CVV2 is a card verification tool designed to reduce fraud losses on transactions. It consists of three digits printed either on the signature panel or on the card to the right of the signature panel.
Although CVV2 is primarily used for Card Not Present transactions (for example, mail order, telephone order, electronic commerce), in some countries, the CVV2 is also used in card-present transactions.
6.12 Random Number Generation
EMV devices are required to provide random values as part of several steps in the EMV process, such as the generation of the cryptogram. EMVCo has specific recommendations on the effective generation of random numbers. Device vendors and acquirers should review the EMV Acquirer and
Terminal Security Guidelines available from the EMVCo website for further information.
6.13 Security Best Practices for Mobile Payment Acceptance Solutions
Visa has developed a set of security best practices for vendors, merchants, acquirers, and service providers of mobile payment acceptance solutions. The goal of the recommendations is for vendors and service providers to design and implement secure solutions and limit exposure of account data that could be used to commit fraud.
Some of the best practices that vendors, merchants, acquirers, and service providers of mobile payment acceptance solution vendors should follow are outlined below. The Visa Security Best
Practices for Mobile Payment Acceptance Solutions provides a full list and explanation of Visa’s recommended best practices. These guidelines may be requirements in certain Visa regions. Acquirers should contact their Visa representative to determine whether these guidelines are requirements in their region.
124 Visa Public November 2016
6. Security Characteristics
Transaction Acceptance Device Guide (TADG)
Solution Vendors:
• Provide payment acceptance applications and any associated updates in a secure manner, with a known chain of trust.
•
Develop mobile payment acceptance applications based on secure coding guidelines.
•
Protect encryption keys that secure account data against disclosure and misuse, in accordance with industry-accepted standards.
• Provide the ability to disable the Mobile Payment Acceptance Solution.
•
Provide functionality to track use and key activities within the Mobile Payment Acceptance
Solution.
•
Provide the ability to encrypt all public transmission of account data.
•
Ensure that account data electronically read from a payment card is protected against fraudulent capture and use by unauthorized applications in a Consumer Mobile Device.
•
Ensure chip acceptance devices are implemented correctly.
•
Provide the ability to truncate or tokenize the Primary Account Number (PAN) after authorization, to facilitate cardholder identification by the merchant.
•
Protect stored PAN data and/or sensitive authentication data.
•
Provide security for Account on File Systems.
Merchants:
•
Only use Mobile Payment Acceptance Solutions as originally intended by an acquiring bank and solution provider.
•
Limit access to the Mobile Payment Acceptance Solution.
•
Immediately report the loss or theft of a Consumer Mobile Device and/or hardware accessory.
•
Install software only from trusted sources.
• Protect the Consumer Mobile Device from malware.
Acquirers and Payment Service Providers (PSPs):
• Provide the ability to uniquely identify a transaction coming from a merchant.
• Restrict manual PAN key-entered transactions on a Consumer Mobile Device to a minimum.
•
Ensure appropriate due-diligence when on-boarding and monitoring merchants, including adequate Know Your Customer (KYC) and Anti-Money Laundering (AML) procedures.
•
Where network connectivity is available, ensure that all authorizations are processed online.
•
Develop fraud-monitoring capability specifically for mobile payment acceptance.
November 2016 Visa Public 125
6. Security Characteristics
6.13 Security Best Practices for Mobile Payment Acceptance Solutions
Vendors, merchants, acquirers, and service providers should contact their Visa representative to obtain a copy of the best practices document. Best practice information can also be found at the following locations:
• http://usa.visa.com/merchants/risk_management/cisp_overview.html
• http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
• http://usa.visa.com/download/merchants/bulletin-updates-pin-framework-111809.pdf
6.13.1 Security for Account on File Systems
Some solutions involve account data being captured and retained in a central system where this retained data can subsequently be used to authorize new transactions. With some services, a cardholder can make payments using the data stored on a central system through the use of credentials, such as passwords or tokens, to pay at the point of sale. A Quick Response (QR) code would be an example of a token. Such solutions must also comply with PCI DSS principles, if storing any card information.
In registering new card details, the solution should take steps to establish the legitimacy of the enrolling card/cardholder. If available, Verified by Visa and address verification checks should be performed as part of the registration process. The registration process should not occur on the merchant’s mobile device.
When accepting payments, the solution should clearly provide a means to capture the cardholder’s intent to make a payment.
Where tokens are used, tokens should be time-bounded and be revocable. Where possible, the solution vendor should take steps to limit the value of the stolen tokens for fraudulent users. For example, in a parking garage, the token could be bound to the cardholder’s registered vehicle license plate. The registration of additional benefactors should follow a similar process to that of registering new card details with the solution.
For Account on File solutions, CVV2 must never be retained after initial authorization.
To avoid disruption in customer relationships due to Visa account information changes, when making
Account on File based payments, solutions vendors should consider subscribing to Visa Account
Updater (VAU), if the vendor’s operating environment supports the solution. Acquirers and vendors should contact their local Visa representative to discuss possible use of the VAU service.
126 Visa Public November 2016
7. Device Management Systems
Transaction Acceptance Device Guide (TADG)
7. Device Management Systems
This section provides recommended functions to be supported by a device management system (also known as Terminal Management Systems or TMS) in a chip environment (contact and contactless).
Device management system architecture should be sophisticated and flexible enough so that modifications can be made without requiring large device infrastructure changes. The more supportive and robust a device management system is, the easier it is to respond to future market needs, new requirements, and change requests.
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 mandatory, and any postdeployment change could affect a device’s interoperability.
The device management system must not allow deletion of mandatory functions. The system may add or delete optional functions provided that the final configuration loaded into the device has been
EMV-approved.
7.2 Data Elements
Although a complete device management system uses many data elements, only those that apply to contact and contactless chip devices are discussed here.
7.2.1 VSDC CA Public Keys
VSDC CA Public Keys are used to support SDA, DDA, CDA, fDDA, and Offline Enciphered PIN transactions. Device management systems should allow for six VSDC CA Public Keys.
Planned changes and accelerated key revocations require that keys be updated in all devices.
Consequently, these data elements should be treated as variable parameters, not as components of the kernel. Post-deployment data integrity must also be verified. Failure to load the correct production
VSDC CA Public Keys or a newly introduced key will result in failure to correctly process SDA, DDA or
CDA which may lead to a declined transaction depending on the risk parameters setup in the card or the issuer host.
To ensure effective management of VSDC CA Public Keys, the device management system should:
•
Download keys to devices prior to and after deployment
•
Download new keys prior to their effective date
•
Remove expired or revoked keys by the Visa published date
November 2016 Visa Public 127
7. Device Management Systems
7.2 Data Elements
• Notify all deployed devices when a key is to be downloaded or removed
•
Distribute keys to deployed devices in a manner that protects their integrity
• Maintain status of keys in deployed devices
Managing keys manually across a large device base can pose significant difficulties. The device management system should, therefore, automatically notify all affected devices when a key is to be downloaded or removed. Notification may be done during an authorization response, a batch upload acknowledgement, an end-of-day response, or an explicit call by the device management system.
Alternatively, devices may regularly contact the device management system for outstanding updates.
Once notification is received, the device should automatically implement a scheduled process that results in a timely update of the keys.
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 checking the SHA-1 hash. Alternatively, the device management system could validate key integrity by using its own validation technique as a check sum. Acquirers should ensure that the terminals detect and report unexpected modification of the key set.
For more information on updates and management of public keys, refer to Section 6.9: Key
7.2.2 Terminal Action Codes
Used in Terminal Action Analysis, TACs are mandatory device data elements with values defined by
Visa. They indicate the action that the device should take based on the TVR.
Note: For online-only devices (devices that process all transactions online), there are different TAC settings depending on whether the device supports TAC/IAC-Online and TAC/IAC-Default processing.
Table 7–1: Terminal Action Codes
AID Offline-Capable Device
Visa ISO AID TAC Denial: x0010000000
TAC Online: xDC4004F800
TAC Default: xDC4000A800
Visa U.S.
Common
Debit AID n/a
Online-Only Device
(Does Not Support
TAC-Online and TAC-
Default Processing)
TAC Denial: x0010000000
TAC Online: n/a
TAC Default: n/a
TAC Denial: x0000000000
TAC Online: n/a
TAC Default: n/a
Online-Only Device
(Supports
TAC-Online and TAC-
Default Processing)
TAC Denial: x0010000000
TAC Online: x584004F800
TAC Default: x584000A800
TAC Denial: x0000000000
TAC Online: xFFFFFFFFFF
TAC Default: xFFFFFFFFFF
44 The TAC values in this column are defined for Visa Inc. countries; they are not applicable to the Europe Region.
128 Visa Public November 2016
7. Device Management Systems
Transaction Acceptance Device Guide (TADG)
The Visa TAC-Online and TAC-Default values are the hexadecimal representation of the minimum bit settings required by Visa. Acquirers may deploy TAC-Online and Default values in which additional bits are set. (This logic does not apply to the TAC-Denial value as this could result in unnecessary declines.)
The device management system should be set up to track and update the settings in the TACs through downline loads, when appropriate. Merchants must not be able to update the TACs. If the device does not have the correct TACs, the acquirer may be subject to compliance requirements as with any violation of the Visa rules and regulations, and may be subject to penalties as outlined in the
Visa rules and regulations.
7.2.3 Application Identifiers
AIDs indicate the card applications that a device can support, such as Visa, Visa Electron, Plus, or a merchant loyalty program. All contact and contactless chip devices that include the Visa Debit/Credit
AID must also include the Visa Electron AID, unless specifically excluded by the merchant.
For the list of Visa AIDs, refer to Section 3.3.1: Application Identifiers.
7.2.4 Random Transaction Selection Parameters
The parameters for random transaction selection define the percentage and threshold values used by devices that support both offline and online transactions. They are used specifically in the random selection of transactions to be sent online for authorization, independent of transaction characteristics.
For more information on random selection, see Section 3.9.2: Random Transaction Selection.
7.2.5 Floor Limits
In conjunction with the Visa-published floor limits for specific country and MCC combinations, the acquirer may set floor limits for chip and magnetic-stripe transactions. The chip card can request, however, that a transaction to be transmitted online for a transaction that is under the acquirerestablished floor limit.
To provide maximum flexibility, devices and device management systems should support the following floor limits:
•
International floor limit for non-chip transactions
• International floor limit for chip-initiated transactions
•
Domestic floor limit for non-chip transactions
• Domestic floor limit for chip-initiated transactions
For more information on floor limits, see Section 3.9.1.
November 2016 Visa Public 129
7. Device Management Systems
7.2 Data Elements
Additionally, terminals supporting Visa payWave need to support the following contactless limits:
•
Reader CVM limit
•
Reader Contactless Floor Limit
For more information on contactless limits, refer to Section 4.6.1: Preliminary Processing.
7.2.6 Terminal Transaction Qualifiers (TTQ)
For devices supporting contactless transactions, the TTQ advises the Visa payWave card of the reader’s requirements and capabilities for processing the specific transaction, including:
•
Whether the qVSDC and/or MSD is supported
•
Whether contact VSDC is supported
•
What CVMs are supported
•
Whether cardholder verification is required for the transaction
•
Whether the reader supports Issuer Update Processing
The acquirer should have the capability to update the TTQ when the reader capabilities change or if there is a Visa mandate or requirement to change the supported values.
7.2.7 Application Version Number
The Application Version Number relates to the version of VIS. It is the version, release, and modification number in binary of VIS supported by the card. It is recommended that the terminal
Application Version Number match the most current VIS-specified card Application Version Number at the time the terminal received its EMVCo approval.
The current version of VIS is 1.5.0 which would be coded in binary as ‘0096’. Previous versions, 1.4.1
(binary ‘008D’) and 1.4.0 (binary ‘008C’) would also be acceptable. Version 1.3.2 (binary ‘0084’) remains valid for older devices.
130 Visa Public November 2016
Herunterladen
Öffentlicher Link aktualisiert
Der öffentliche Link zu Ihrem Chat wurde aktualisiert. Sie können Ihre Chat-Links nach der Registrierung hier einsehen und verwalten.
Öffentlicher Dokumentenlink
Werbung
