# EMV - Inside EMV
### Revision History
| Date | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| September 15, 2016 | Initial Documentation Release |
| April 8, 2020 | Added information on contactless EMV, updated address information, support information; added information on Quick Chip. |
## Overview
EMV is the standard for credit card processing. It describes a transaction between a chip card and an EMV-enabled terminal. EMV transactions are much more secure than magnetic-stripe-card transactions.
A Glossary of Terms is provided to assist with understanding content and terminology presented in this Feature Reference.
### Introduction
This document covers how to enable Contact and Contactless EMV transactions. Contact EMV refers to transactions performed by inserting the chip card into the EMV slot on the device. Contactless EMV refers to transactions performed by tapping or waving a card or device by the terminal. This includes ApplePay, GooglePay, and similar services.
During Contactless EMV transactions, an RFID reader built into the screen on the MX 900 and M400 PINpads reads the chip on the card when the Consumer taps on or waves the card near the screen.
{% hint style="info" %}
*Not all Chip Cards are capable of contactless transactions. If the chip is contactless enabled it will have this symbol (a logo owned by EMVCo, LLC.) on the card.*
{% endhint %}
{% hint style="danger" %}
*Prior to initiating Commander Site Controller EMV configuration, contact the Front-End Processor and Merchant Service Provider to confirm the merchant account is ready for EMV processing.*
*Refer to the appendices for processor-specific configuration details.*
{% endhint %}
### System Requirements
#### Supported Hardware
{% hint style="info" %}
*EMV implementation requires PIN pad hardware with EMV Chip Reader capability.*
{% endhint %}
* MX 900 Series: MX 915 and MX 925, M400
* Commander Site Controller/RubyCi with Topaz
* Commander Site Controller/RubyCi with Ruby2
* Sapphire V910/V920 with Topaz (Contact ONLY)
* Sapphire V910/V920 with Ruby (Contact ONLY)
#### Supported Software
**Contact Software Support**
* Commander Site Controller/RubyCi: Production Software Base 42 and higher.
* Sapphire: Production Software Base 188+, and do not support Contactless EMV.
* MX 900 Series devices: Kernel 7.00+.
{% hint style="info" %}
*POS System Software may be eligible to Upgrade through Verifone’s Remote Software Delivery. For more information visit support.verifone.com and select Technical Support > Support Articles > Petro & Convenience > Products and Services > Software Updates (VRSD).*
{% endhint %}
**Contactless Software Support**
* Commander Site Controller/RubyCi: Production Software Base 51+.
* All MX PINpad devices: ViperPAY 4.06.04.03+.
* MX 900 Series devices: Require a PIN pad firmware upgrade in order to support Contactless EMV: CONTACTLESS SUPPORT UPDATE VERSION 1.30.04A6 FOR MX 900 SERIES. You can find this upgrade on the Verifone Premier portal under Manage > Petro Downloads > MX 900 > OS Software.
{% hint style="info" %}
The MX 900 PINpads must have the contactless firmware upgrade applied in order for contactless functionality to work. A Verifone Authorized Service Contractor (VASC) can apply the upgrade, or the Verifone Helpdesk, if the device is using the Service and Maintenance (SAM) feature.
*See* Troubleshooting: System Diagnostics *for details on determining software versions of MX and POS devices.*
{% endhint %}
## Configuring EMV
By default, the Verifone site controller is installed with EMV disabled. How EMV is enabled at the site varies depending on the card processor. Some card processors require an EMV-specific download in order to activate EMV. Others, such as Buypass, may require EMV to be enabled within the site controller's payment controller configuration.
Contact your payment network for more information on enabling EMV at the site level.
{% hint style="info" %}
*Refer to the Network-specific EMV Configuration Guide and/or contact the site’s Electronic Payment Host Provider for additional details on configuring your Verifone solution for EMV.*
{% endhint %}
If your payment network requires EMV to be enabled on the site controller, proceed to the next section. All site-controller enabled EMV configurations are done through Configuration Client.
### **Verifone Commander**
Access the Configuration Client for Verifone Commander at the URL provided by your VASC, or by logging into the Configuration Manager in the CSR Functions on the register. Login to Configuration Client using the Manager login name and current password.
* User Name: Manager
* Password: (\*\* the current valid Manager password \*\*)
### Basic Configuration
The following section provides instructions on how to enable EMV on the Commander Site Controller. Verify the Commander Site Controller is configured with the appropriate hardware and software configurations before proceeding.
#### Enabling EMV
In order to process EMV transactions, EMV must be enabled on the Site Controller. Depending on your specific payment interface, EMV may be configured using Viper table downloads, a host PDL, fixed using files distributed with the payment system, or manually enabled.
1. Navigate to Payment Controller > EPS Configuration > EPS Global Configuration > EMV Configuration.
2. To enable EMV, click on the drop-down for EMV Enable Status. You can select from CONTACT or CONTACT AND CONTACTLESS.
3. Save the configuration.
#### EMV Tables
EMV processing requires EMV supporting tables. The EMV tables are usually provided by the Payment Host through downloads.
{% hint style="info" %}
*Refer to the specific card processing network EMV Configuration Guide for details on how to obtain EMV tables.*
{% endhint %}
After performing the EMV configuration as applicable for your network, confirm the EMV table information.
{% stepper %}
{% step %}
Navigate to **Payment Controller > EPS Configuration > EPS Global Configuration > EMV Configuration.**
{% endstep %}
{% step %}
Application IDs represent the card types supporting EMV processing, and will vary based on the card processing network. Confirm that Application IDs are listed in the AID Configuration section and that the check box is selected for each.
{% hint style="warning" %}
Changes to this section should be considered advanced configuration*. Do not make configuration changes to this section without a complete understanding of AID parameters. See Advanced Configuration for additional details.*
{% endhint %}
{% hint style="warning" %}
Verifone *strongly* advises against making changes in this area without a thorough knowledge of the AID parameters, because it could expose the site to chargebacks!
{% endhint %}
{% endstep %}
{% step %}
The CAPK configuration area is read-only. All configurations shown here are controlled by the card processing network. Ensure that values are listed in the CAPK Configuration. It is best practice to NOT store expiry dates. Current systems do not. The values in your system may differ from what is shown in the screenshot below.
{% endstep %}
{% endstepper %}
#### **Updating PIN pads**
{% stepper %}
{% step %}
Log out of Sales mode and back in to Sales mode on the POS. The PIN pad will download the new EMV tables when you do so.
{% endstep %}
{% step %}
Verify that the EMV card slip is lit up on the PIN pad.
If the PIN pad was not initialized by logging into Sales mode, you can also use the process below to manually initialize individual PIN pads.
{% endstep %}
{% step %}
Navigate to Payment Controller > EPS Configuration > EPS Global Configuration > EMV Initialization.
{% endstep %}
{% step %}
The list of PIN pads that did not update will appear in the Available POP List. Select all PIN pads from the Available POP List, and move them to the Selected POP List using the **\[Add>>]** or **\[Add All]** buttons. This will instruct the system to update the PIN pads.
{% endstep %}
{% step %}
Click **\[Save]** to force an initialization through to the selected PIN pads.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
*In the event PIN pads are not listed in the POP Configuration Status panel on the EMV Initialization screen, see the Troubleshooting section for more information. PIN pads listed here may not be receiving the proper configurations to run EMV transactions.*
{% endhint %}
### Advanced Configuration
{% hint style="warning" %}
*Verifone strongly recommends that clients do not attempt advanced configuration unless they are experts in EMV AIDs. For most customers, this section is included for reference only.*
{% endhint %}
#### Application ID Configuration
Application IDs represent the card types supporting EMV processing, and systems that process EMV transactions must specify which AIDs the system can process.
{% hint style="warning" %}
*Merchants cannot add additional AIDs, and disabling an AID is not recommended. Disabling an existing AID could leave the merchant liable for transactions that should otherwise use that AID.*
{% endhint %}
In order to process a card transaction as an EMV transaction, there must be an AID match between the system's AIDs and the card's (i.e. the same AID must be present on both). The AIDs available on the system are specified by the Acquiring Hosts and placed in the EMV processing terminal by VIPER. The Acquiring Host can only accept the AIDs they have communicated to the system.
**Ensure that when EMV is being enabled, AIDs are listed in the system and are enabled.**
1. The **AID** alpha-numeric string is supplied by the acquiring host and may be a full or partial AID. Merchant level configuration is not available for this field.
2. The **AID Name** is associated with a card type supporting EMV processing and is provided by the acquiring host. The AID Name displays on the PIN pad if an AID selection menu is presented. Merchant configuration is not available for this field.
3. The **AID \** checkbox allows selecting to enable the AID. The AID may be disabled if the merchant should desire. Verifone discourages disabling an AID as this could lead to Merchant liability for transactions that should have been processed through EMV using the AID.
4. **\** Entry is an optional EMV function that if enabled may be invoked when the following occurs:
* The terminal prompts the cardholder for a PIN.
* The cardholder opts to not enter the PIN and invokes this function For these transactions, the approving host is notified with a transaction indicator that the PIN was manually bypassed on a PIN-preferring card.
5. **\** configuration allows selection for the transaction type associated with the AID: Credit Only, Debit Only, Credit & Debit. This configuration option can lead to additional Credit/Debit prompting in the transaction flow. In most cases this value will come from the VIPER table owner.
#### **AID Stand-In Configuration**
{% hint style="warning" %}
*Verifone recommends the* Stand-In TVR Mask *field remain unchanged unless the person editing the configuration is an EMV Expert, and fully understands the ramifications of updates to this field.*
{% endhint %}
As with traditional MSR processing, EMV based transactions may allow stand-in processing to approve transactions even if the online payment host is offline and not available. EMV data in a transaction allows the system to consider many conditions when making a decision to stand in for a transaction. The system still uses the traditional Magnetic
Swipe Read (MSR) data points, but additional EMV data allow for much finer decision points for consideration.
The AID Configuration panel provides the following:
* The **\** setting tells the system whether to allow offline processing for the AID. If this box is left unchecked, stand-in processing is disabled for the card types associated with the AID. \
When Stand-In Processing is turned off for an AID, no offline authorizations will be allowed for any transaction, regardless of what other criteria are present.
* The **\** field allows editing mask definitions that will be logically *ANDed* with the Terminal Verification Results. If this logic results in a non-zero result, the system will not stand-in for the transaction.\
In the example image shown below, the Stand-In TVR Mask value is 80008000. If Offline Data Authentication is not performed, or Cardholder Verification is not performed, the transaction will be declined.
See EMV 4.3 Specification Book 3, at [www.emvco.com/specifications.aspx?id=223](http://www.emvco.com/specifications.aspx?id=223) for details of the five-byte binary bitmap TVR.
* The **\** field operates like the TVR mask but is logically *ANDed*
with the Transaction Status Information.
* The **\** controls the acceptance of foreign cards. When enabled, the terminal’s country code is compared with the card’s AID country code. If the codes match, the transaction will be approved in stand-in.
* The **\** allows setting a dollar amount, such that no transactions over the set Floor Limit will be approved. If the Floor Limit is set to zero (0), that essentially turns off any stand-in option for that AID.
This value is separate from the floor limit present on the card.
#### **CAPK Configuration**
{% hint style="info" %}
*The CAPK configuration area is read-only. There is no action required at the site level to create or maintain these keys.*
{% endhint %}
CAPKs are specific to each card brand and are used by the EMV cryptographic functions during EMV processing. Keys are set to expire, however each FEP has a mechanism to ensure keys are kept current.
**Ensure that when EMV is being enabled, CAPKs are listed in the CAPK Configuration Table.**
{% hint style="info" %}
*Contact the Helpdesk or your VASC if no CAPKs are listed. CAPK errors will compromise system functionality.*
{% endhint %}
#### AID Rules
{% hint style="warning" %}
*Implementing AID Rules should be considered advanced configuration and only undertaken by individuals with a complete understanding of AID selection.*
*Verifone is not responsible for AID Rule configurations. Contact the Front-End Processor and Merchant Service Provider to assist with determining AID order for rules.*
{% endhint %}
The EMV Application ID selection occurs immediately after the Consumer inserts their card. When the card is inserted, the terminal must determine what AIDs are mutually supported between the card chip and the terminal, then select an AID to process the transaction.
For Debit Cards, or when there is more than one AID that is mutually supported between the chip card and the terminal, a choice must be made regarding which AID to select to process the transaction.
AID Rules allow setting preferences for a selected AID over others by configuring a Rules List.
The AID Rules section allows creating the Rules List to define a set of preferred AIDs for use during the AID selection phase.
The functionality is specifically designed to support the U.S. Common Debit AID, allowing the Common AID to be selected by default when multiple AIDs are present.
Multiple AIDs can be included when creating an AID Rule. When viewing a Rule Exclusion List, selection preference is given to the included AIDs from left to right.
#### AID Selection Menu
{% hint style="info" %}
*Verifone systems are designed so that the user should never see this menu. If this menu does appear, it is possible the system is not working correctly. If this menu appears, the EMV settings, particularly the AID Rules, should be confirmed with Verifone or the network processor.*
*AID Menu Selections are derived from the AID name and may be confusing to the Consumer. Use of AID rules reduces or eliminates prompt occurrence.*
{% endhint %}
In most instances, the system uses only the selected AID, but it is possible that there could be more than one AID match. If multiple AIDs are available, and AID Rules have not been established, the system will generate a prompt for the Consumer to select the AID to use. Once the AID is selected, the system will generate prompts to guide the Consumer through the steps in the chip-based transaction.
**Creating AID Rules**
1. Click to select and highlight the first AID to be included in the rule from the Available AID List. AID 980840 is the Visa U.S. Common Debit AID.
2. Click \[**Add>>]** to move the AID to the Selected AID List. \
3. Click to select and highlight the next AID to be included in the rule from the Available AID List. AID 31010 is the Visa Global Debit/Credit AID.
4. Click **\[Add>>]** to move the AID to the Selected AID List.
5. Continue adding AIDs from the Available AID List to the Selected AID List as necessary. Click **\[Move Up]** and **\[Move Down]** to re-order the AIDs as needed, with the AIDs in descending order of preference.
6. Click **\[Add]**.
The new AID Rule is created, assigned a Rule ID number and added to the AID Rules List.
In the example Rule 001 shown above, if after the terminal and card have determined that mutually present AIDs exist, and both AID 31010 and 980840 are present in the candidate list, the rule will be applied. The order the AIDs appear in the list is the order the AIDs will be prioritized, so Rule 001 will prioritize the Visa U.S. Common Debit AID over the Visa Global AID, and the system will select the Visa U.S. Common Debit AID with no menu selection required.
Without the defined rule, this example scenario with two mutually matching AIDs, would generate a menu prompt.
{% hint style="info" %}
*After creating AID Rules, log out and log back in to all POS to update the PIN pad to use the new rules.*
{% endhint %}
## Using EMV
#### Performing an EMV Transaction
EMV transactions progress in the following manner:
* **Card detection and reset:** In this phase:\
Contact EMV: The Consumer inserts the card into the PIN pad. The terminal reads the data from the card and sends a message specifying how it will deal with the card. The Consumer does not remove the card at this stage.\
Contactless EMV: When the Consumer taps or waves the card over the reader sensor, the terminal detects the chip in the card (using NFC), and sends a message specifying how the terminal must interface with the card.\
\&#xNAN;*Even though with Contactless EMV, and Visa’s Quick Chip standard, the Consumer does not keep their card with the PIN pad (as they do when the card is inserted), the PIN pad may still display prompts for the Consumer to take action, such as selecting Credit or Debit, or requesting a Cashback. See “Types of EMV Transactions” below for more information.*
* **AID List Creation:** The card and terminal have lists of AIDs that they compare to find a match, which is also determined by any business rules that are in place. (Please see "Application ID Configuration" and "AID Rules" above for more information.)
* **AID Selection:** The terminal and card determine which AID they are going to use for the transaction.
* **Authentication and Risk Management:** The terminal uses the read chip data to verify that the card is genuine and not modified. and determines actions accordingly.
* **Online Processing:** The terminal sends the information to the card issuer, which checks the card status and determines whether to accept or reject the transaction.
* **Transaction completed:** After the card has been analyzed and the transaction accepted or rejected, the transaction finishes. For Contact EMV, the Consumer removes the card from the PIN pad at this stage.
#### Types of EMV Transactions
**Normal Sale - EMV Chip Read**
When the Cashier begins the transaction, the PIN pad becomes active.
Initial Prompt Instructing Consumer to Insert, Tap, or Swipe the card. The Cashier may monitor the instructions shown on the PIN pad by referring to the PIN pad Prompts To Cashier section of the POS. Verifone recommends enabling these prompts when EMV is initially enabled to aid in the Cashier's understanding of what the Consumer sees on the PIN pad device.
**\** may be turned on or off using Configuration Client. (In Configuration Client, navigate to **Payment Controller > EPS Configuration > EPS Global Configuration > EPS tab > Misc**.
The prompts show in the status window on the POS. PIN pad Messages are Visible to Cashier When the Consumer uses a chip card, it must be inserted in the PIN pad EMV card slot. When the card is inserted, the system will perform AID selection to choose the application from the card that will control the rest of the transaction.
The first instructions advise the Consumer to leave their card in the chip reader.
Depending on the Card Type and configuration settings, a Credit/Debit prompt may be presented to the Consumer. System Prompting for Credit or Debit
When the Consumer confirms the amount, the Cardholder Verification stage of EMV processing begins. There are four CVMs processing can take, depending on the selected AID and terminal configuration.
* Offline PIN: Card validates the PIN
* Online PIN: PIN is validated at the issuing bank
* Signature: Cashier validates the cardholder signature
* NO CVM: no CVM is performed
The Consumer should follow prompts during the Cardholder Verification stage. Prompting at this stage comes directly from the AID, so during this phase the Cashier will not be able to follow what is displayed on the PIN pad. When the CVM phase is complete the transaction will continue processing. Following the Credit/Debit Selection, the system will prompt for a confirmed amount. If the Consumer has requested cash back, the amount will include the Cashback. The Consumer then OKs the amount and the next EMV stage begins.
When the transaction completes, if the Consumer has inserted their card into the POS, the system will instruct the Consumer to remove the card from the slot. The terminal also provides an audible reminder to remove the card.
The final receipt will not print and the transaction will not clear from the POS register until the card is removed. Once the card is removed the receipt prints and the register
will clear the sale. The Cashier should provide guidance to the Consumer at this phase if the transaction does not clear from the register after network approval.
**Other EMV Transactions**
Other transactions are run with EMV cards in very similar fashion. Refunds and Prepay transactions are run just as they are in a magnetic stripe environment with the exception of leaving the card in the slot during the transaction.
#### Normal Inside EMV Flow
1. Consumer brings goods or service requests to the Cashier.
2. The Cashier rings up the goods and services. This can include both prepay and post-pay fuel sales and non-fuel items.
3. **Contact EMV**: The Consumer inserts the EMV card into the PIN pad's EMV card reader. The card remains in the chip reader for the duration of the transaction while the chip is read and while any customer verification prompting is performed. When the EMV card processing is finished, the consumer will be notified to remove the card. In Verifone's Quick Chip flow, the card does not need to remain in the reader for the duration of the transaction. Card insertion, like the MSD swipe ahead, can be done at any time.\
**Contactless EMV**: After being prompted to tap or wave, he Consumer waves or taps the EMV card against the PIN pad's wave/tap card reader. The card only needs to be in proximity to the sensor long enough for the reader to obtain the required data. Reading the card chip is the first interaction between the PIN pad and the chip on the card.
4. The Cashier tenders the transaction for network payment the same as would be done for MSD tendering.
5. The "Network tender" triggers a request for payment to VIPER, which in turn communicates with the PIN pad to process the EMV payment request. This step in EMV processing is referred to as the First Generate AC.\
• The 1st Gen AC is the second communication, after the read, with the card. The 1st Gen AC performs the CVM processing and results in either an offline approval, a request to go online, or a decline. The results of the CVM processing are also returned.
6. VIPER uses card data from the Contact or Contactless EMV card and transaction information from the POS to obtain payment authorization from the payment host.
7. If the transaction is approved, the Approval is indicated to the Consumer and the Cashier.
8. Contact EMV only: Note that the receipt will not print and the transaction will not clear from the POS until the Consumer removes their card. The Cashier should prompt the Consumer to remove the card if they do not do so in a timely manner following the transaction approval.
9. The receipt prints and the transaction is cleared from the POS.
### Exception Flow
#### **Attempting to Swipe a Chip Card**
If an EMV enabled card is swiped instead of inserted into the card reader, the proper response as defined by EMVCo is to prompt the Consumer to insert the card.
For Verifone systems, the expected behavior when attempting to swipe an EMV card is to prompt the Consumer to insert the card.
Verifone systems manage this based on specific Card Table configurations. The Card Table is not site configurable but is either downloaded, distributed, or built from a PDL.
If the system does not behave in the expected manner, the site should confirm with the FEP table owner that the Card Table is configured properly.
**Failed Chip Read**
When an EMV card read fails, the system will indicate the failure with a prompt on the PIN pad for the Consumer.
Depending on the table configuration, the system may allow a magnetic swipe after a contact EMV chip-read failure, or card insertion after a contactless EMV chip-read failure. This process is called a Technical Fallback.
This behavior is defined by the VIPER tables. If the system is not behaving as desired, the merchant will need to contact and work with the table owner.
**Technical Fallback Processing**
Technical Fallback is the exception process whereby in contact EMV, the magnetic stripe, rather than the chip data, is read by an EMV-capable device.
{% hint style="info" %}
*A Contactless EMV Read error does not result in a technical fallback, i.e. the consumer cannot immediately swipe the card. Instead a “Switch Interface” message is generated. If the resulting Contact EMV chip read then fails, a Technical Fallback can occur following the chip read error.*
{% endhint %}
Contact EMV: Two common scenarios exist for this process:
1\. Consumer Attempts to Swipe Card First
* Consumer swipes the EMV card instead of inserting the card into the EMV card slot.
* The system detects a swiped EMV card and instructs the Consumer to insert the card.
* Consumer inserts the card and the read fails.
* System then uses the swiped data to process the transaction. The MSR data is now approved since a chip-read has been attempted.
2\. Consumer Attempts to Insert a Card and the Chip-Read Fails
* Consumer can now swipe the card and MSR swipe data is used. Swiping an EMV card always requires a chip-read be attempted first.
* System will use the swiped data to process the transaction.
The ability to perform technical fallback processing is controlled by the VIPER tables. There is no site configuration allowing modification of the Technical Fallback.
If the system is not processing Technical Fallback in a manner acceptable to the merchant, the site manager must coordinate any changes in functionality with the VIPER table owner.
**Contact EMV: Manual Entry**
If all contact entry modes for EMV cards fail, the system may allow manual entry of the card data. Manual entry is controlled by the VIPER tables.
At this time, there is no way to modify site configuration to enable or disable manual entry for cards. Please contact your card processor to determine if they can modify this setting.
If the system is not processing EMV manual entry in a manner acceptable to the merchant, the site manager must coordinate any changes in functionality with the VIPER table owner.
#### Stand-In Processing
As with traditional MSR processing, EMV-based transactions may allow stand-in processing, that is approvals for transactions even if the Online payment host is offline and not available.
Verifone systems retain all of the logic traditional MSR transactions used to control offline processing. In addition, EMV transactions provide even more data for merchants to use in order to make informed decisions when allowing offline approvals.
Some of the additional data includes the following:
* Stand-in based on the AID, or allowing stand-in at all for a specific AID.
* Base approvals on certain EMV tags, e.g. don't approve offline transactions where the PIN was bypassed.
* Approvals based on a floor limit by AID. This is in addition to traditional MSR floor limits.
Each of these mechanisms may be configured using the Configuration Client.
### Receipts
EMV receipts can vary based on the data required by either the major oil customer or the Acquiring Host specifications. Common fields required on an EMV receipt often include the AID (tag 4F), the TC (tag 9F26) the TSI (tag 9B), and the authorization code (tag 8A). Each of these tags is included on the receipt by the VIPER Receipt table. The receipt table is controlled by the VIPER table owner, so if there are additional fields desired on a site receipt, the site will need to work with the table owner to provide the receipt data.
#### Approved Transaction Receipts
The Network portion of the receipt is controlled by the VIPER Receipt Table. There is no configuration available locally to change the network portion of the receipt. Only the table owner can update the data contained on the receipt. Any EMV tag data may be included on a receipt, but the table owner must define the receipts in the VIPER Receipt Table.
#### Declined Transaction Receipts
Some FEPs require a receipt to print for declined EMV transactions. Verifone systems will generate a declined receipt if required by each FEP. Usually, the receipt contains all of the EMV tags that are available to the system.
If a site experiences higher than expected EMV transaction failures, these failure receipts may be useful in working with the Acquiring Host or the Verifone helpdesk to determine the root cause for EMV transaction failures.
Declined receipts are defined in the Receipt Table by the table owner according to the requirements of the FEP. There is no local configuration for declined receipts.
## Reporting
Verifone provides the following EMV reports:
• Individual EMV transactions
• EMV configuration
• EMV CAPK
• Transaction Statistics
• EMV Failures
EMV reports are available on the POS from the CSR Functions menu by selecting **Network Menu > EPS Network Reports > EMV Reports.**
### EMV Transaction Report
The EMV Transaction Report provides all the EMV data (tags) that the system tracked during execution of a particular transaction. When the report is requested, the system prompts for the System Trace Audit Number (STAN), which is available from the receipt.
A sample report is provided. Actual printed reports may vary.
#### EMV Configuration Report
The EMV Configuration Report contains general EMV configuration data for each Terminal ID including the following:
* Last PIN pad Configuration Time
* Terminal Type
* Terminal Capabilities
* Country Code
* Currency Code
* Transaction Category Code
* Merchant Category Code
This data is set for each installation instance (FEP) and is not site configurable. The information is provided as informational only.
The EMV Configuration Report also contains each Application Identifier's specific configuration. Information provided for each AID includes the following:
* AID Label (will be used if an AID menu is required)
* AID code
* AID floor limit (important for offline processing)
* other configurations unique to each AID.
The report will contain a section for each AID configured in the system. A sample report is provided. Actual printed reports may vary.
Sample EMV Configuration Report, AID Specification
#### EMV Certificate Authority Public Key (CAPK) Report
The system provides reporting to confirm CAPKs for each PIN pad and each Registered Application Provider Identifier, and is primarily used in troubleshooting with Verifone Helpdesk personnel.
The report provides visibility to the PIN pads that have received the CAPKs, the RID, the CAPK Index, the key itself, and the CAPK Exponent.
There is no site level configuration that can be done for CAPK data. A sample report is provided. Actual printed reports may vary.
The report provides visibility to the PIN pads that have received the CAPKs, the RID, the CAPK Index, the key itself, and the CAPK Exponent. There is no site level configuration that can be done for CAPK data. A sample report is provided. Actual printed reports may vary. Sample EMV CAPK Report.
#### EMV Transaction Statistics Report
The EMV Transaction Statistics Report shows all EMV transaction data by Terminal Batch Number for each PIN pad, designated by the Terminal ID. Grand totals for all PIN pads are also included. The report allows the site to track the following transaction data:
* Total EMV Transactions, shown as ICC (Integrated Card Chip)
* EMV Magstripe Fallback, shown as ICC Fallback Swipe
* Swiped (normal MSR)
* Manual Keyed
* RFID Contactless (non-EMV)
A sample report is provided. Actual printed reports may vary.
#### EMV Failure Report
The EMV Failure Report details the EMV transactions that experience the following:
* Chip read failures
* PIN entry errors
* Offline declines
* Transactions processed in technical fallback using the ICC magstripe fallback.
A sample report is provided. Actual printed reports may vary. Sample EMV Failure Report
The EMV Fallback Report shows the total number of EMV transactions, and the number and percentage of transactions processed as Fallback for each PIN pad, designated by the POP ID.
Sample EMV Fallback Report
#### EMV Fallback Report
The EMV Fallback Report shows the total number of EMV transactions, and the number and percentage of transactions processed as Fallback for each PIN pad, designated by the POP ID.
A sample report is provided. Actual printed reports may vary
## Troubleshooting
The following section presents possible problem scenarios and discusses how to troubleshoot possible issues with EMV. It does not cover hardware or PIN pad communication issues that are not directly related to EMV.
### Steps of an EMV Transaction
A fundamental starting point in troubleshooting is to understand the major steps included in an EMV transaction. If issues do arise, then the source of the problem can be more quickly identified. An EMV transaction progresses through the following steps:
1. Prompt at the PIN pad to Read or Insert Card
2. Insert/Tap/Wave EMV Card and Read the Chip
3. EMV AID selection
4. VIPER BIN Match
5. Perform CVM processing and 1st GEN AC
6. Amount Verification
7. Host Authorization According to EMV Quick Chip Rules
8. EMV Completion
9. Card Removal
10. Receipt Printing
### EMV Menu Access Denied
Whenever an existing system is upgraded, and new features requiring configurations are added, administrators *must* update existing user roles to grant access to the new feature. This is not an issue for a new installation, as the default user roles for a fresh install contain the updated configuration settings.
In the event the Controller software was updated through an Auto Upgrade, the EMV menus will be inaccessible.
If accessing the Configuration Client from the POS, and the EMV Configuration and Initialization tabs are grayed out, then this indicates the logged in user account does not have the correct functions added to the associated role.
If accessing the Configuration Client from a PC, and the logged in user account does not have EMV role permissions, then attempting to access the EMV tabs returns a Permissions Denied message. You can update user roles through Configuration Client. (For more information on Configuration Client user roles, please see the full Configuration Client documentation.)
You can update user roles through Configuration Client. (For more information on Configuration Client user roles, please see the full Configuration Client documentation.)
Navigate to **Security > Manage Users**. You will be prompted to enter a One-Time Password. Read it from the status display on the POS, or the Event notification, and enter it in the field provided.
The Configure Users tab will be displayed.
Click to select the User ID and confirm the assigned role.
Click **\[Edit]**.
Scroll down the Functions list and locate:
* uemvcfg - Update EMV Configuration and
* uemvinit - Update EMV Initialization.
*Click the checkboxes to activate the* uemvcfg and uemvinit functions.
*Scroll down the Functions list and locate vemvcfg - View EMV Configuration and vemvinit - View EMV Initialization.*
*Click the checkboxes to activate the* vemvcfg and vemvinit functions.
Click **\[Done]**
*Click **\[Save]**.*
Log out of the Configuration Client.
Log back into the Configuration Client to apply the permission updates.
### Error Saving EMV Configuration Settings
Using an unsupported browser application can cause errors when attempting to save or update configuration settings. If these errors occur, try making changes using Configuration Manager on the POS, or use a supported browser (Firefox or Internet Explorer).
### EMV Initialization
The EMV Initialization tab allows forced initialization on selected POP devices, and provides confirmation of any PIN pad updates that have failed. The Initialize POP process is performed automatically for each PIN pad in the system during initial EMV implementation, which is initiated through a PDL or table download. The POP Configuration Status Panel keeps track of what data has been sent and any error messages that may have occurred. Utilizing the Initialize POP function is only required for new PIN pad terminals that are introduced to a running system, or if errors are detected and shown in the POP Configuration Status panel.
#### **Initialize POP**
1. Navigate to Payment Controller > EPS Global Configuration > EMV Initialization
2. Click to select and highlight the POP ID(s) to be initialized from the Available POP List. 
3. Click \[Add>>] or \[Add All] to move the AID(s) to the Selected AID List. 
4. Click \[Save] to initialize the selected POP devices for EMV use. 
{% hint style="info" %}
*Do not navigate away from the* EMV Initialization *tab before saving, unless you wish to cancel the initialization. Once the user navigates away from the* EMV Initialization *tab, the page is reset.*
*Without saving, all POP devices will be displayed in the*
Available POP List *again.*
*Initialization of selected PIN pad(s) occurs with the corresponding* SAVE*.*
{% endhint %}
### **POP Configuration Status**
You can use the PIN pad Configuration Status section to monitor the PIN pad configuration status, which allows site operators to confirm that all PIN pads in the system have received the proper configuration for AIDs, AID Rules, CAPKs, and EMV. Any PIN pad that has not received specific configuration data will be listed in the applicable Failure POP List section. A PIN pad that appears in the Failure POP List may not operate properly in an EMV environment.
### No "Insert Card" Prompt for Contact EMV
1. The card prompt should contain text that includes verbiage about inserting a card.\
\
If the displayed prompt does not include instructions to “Insert the Card”, see the section for Enabling EMV, and verify EMV is enabled.
2. Use the EMV Configuration Report or check Configuration Client EMV Initialization tab to verify the EMV configuration has been pushed to the PIN pads.
### No Transactions Processing as EMV transactions
1\. See the section for Enabling EMV, and verify EMV is enabled.
2\. Use the EMV Configuration Report or check the Configuration Client EMV Initialization tab to verify that the EMV configuration has been pushed to the PIN pads.
3\. Confirm that AIDs exist in the AID list.
If there are no AIDs, EMV cannot process cards. AIDs cannot be site configured and must be either part of the distribution or downloaded by the table owner. If there are no AIDs present in the system, make sure the system has performed a PDL or Table Download, whichever is appropriate for the FEP.
4\. Confirm that CAPKs exist in the CAPK list and are not expired.
If there are no CAPKs, or if CAPKs are expired, EMV cannot process cards correctly. CAPKs cannot be site configured and must be either part of the distribution or downloaded by the table owner. If there are no CAPKs present in the system, make sure the system has performed a PDL or Table Download, whichever is appropriate for the FEP. If there are expired CAPKs present in the system, perform a PDL or Table Download, as appropriate for the FEP.
5\. Confirm network connectivity as network communications issues could also cause problems.
### Only Some PIN Pads Process EMV
Although not recommended, the system allows split processing between EMV and MSR transactions where some PIN pads are configured to allow EMV, and some are not.
* Verify the PIN pad terminal is EMV capable and has a chip reader.
* Use the EMV Configuration Report or check Configuration Client EMV Initialization tab to verify the EMV configuration has been pushed to the PIN pads.
### Swiping an EMV Card is Allowed Without First Requiring a Chip-Read
1. See the section for Enabling EMV, and verify EMV is enabled. If EMV is not enabled, card swipes may be allowed.
2. The VIPER Card Table may be explicitly allowing this behavior. Table analysis is possible using the VIPER Diagnostics page to display the Card Table. Verify with the table owner the intended operation.
### Swiping Not Allowed After a Failed Chip-Read
The VIPER Card Table may be explicitly preventing this behavior. Table analysis is possible using the VIPER Diagnostics page to display the Card Table. Verify with the table owner the intended operation. This behavior depends on explicit table entries as documented in the Card Table Specifications available from the table owner.
### An Inserted Card is Refused or Declined
1\. If an inserted card is refused or declined before the amount confirmation, see Using EMV: Transaction Steps.
a. The chip-read itself could have failed.
This can be tested by inserting a card with the “chip side out”. This guarantees a chip-read error. If the response is the same, the issue may be a chip-read failure. Attempt a chip-read with the card on another PIN pad to isolate and determine if the PIN pad or the card is bad.
b. The issue may be that no matching AIDs were found between the card and the terminal.
Is this a foreign card?
c. The Card table may not contain an entry for this card. Confirm with the Table Owner that they accept the card.
2\. If an inserted card is refused or declined after the amount confirmation,
a. The Host authentication could have failed. Check for a response code indication.
b. The Host is unavailable and no stand-in was done. Verify AID Stand-In configuration logic.
c. The card may have been removed prior to completing the transaction. EMV processing will decline a transaction, even after host approval, if the terminal and the card cannot communicate after host approval. This is the Complete EMV 2nd Gen AC in the transaction steps. Confirm that the card remains firmly in the reader slot until instructed to remove it.
d. Confirm there are no expired CAPKs present in the system. If there are expired CAPKs present in the system, perform a PDL or Table Download, as appropriate for the FEP.
e. There is a possibility that the chip has failed.
### Receipt is Slow to Print
A receipt will not print, and the transaction will not clear from the POS, until the EMV card is removed from the PIN pad. Ensure the Consumer removes the card when prompted to do so.
### Intermittent Chip Card Read Failure
The PIN pad sometimes fails to read the chip on the card. The chip card reader may need to be cleaned. Verifone recommends that you purchase a Verifone chip card reader cleaning kit (part number 02746-02).
### **Cleaning Process**
Inspect -- First, visually inspect the terminal's Smart Card Reader before attempting o clean the unit. All debris, "foreign objects," and other material must be removed from the Smart Card Reader before using the cleaning cards.
Pre-Test -- If no debris is found in the Smart Card Reader, run the internal Smart Card test using the following steps.
* If an application is already loaded and running, put the terminal into System Mode by pressing keys 1, 5, 9 at the same time. If there is no application loaded, the terminal will boot up to the System Mode Login Screen.
* Navigate to Diagnostics > Card > Smart Card. Insert a card before selecting the tab.
* If the terminal passes the diagnostic test, proceed to the next step.
* If the terminal fails the diagnostic test, make a note of the failure and proceed to the next step.
Cleaning -- Use the Smart Card Reader Cleaning Kit (Verifone PN 02746-02).
Test After Cleaning -- Retest the Smart Card reader in Diagnostic mode using the instructions in step 2.
* If the terminal fails the Smart Card Reader Test, send the terminal in for repair.
* If the terminal passes the Smart Card Reader Test, reboot the terminal's application for regular use.
### System Diagnostics
System Diagnostics provide useful information that may be helpful in troubleshooting.
**Accessing System Diagnostic Information**
For Commander Site Controller and RubyCi systems, in a browser window, open the following address: .
Click \[+ System Information] to expand the menu item list.
Click \[Diagnostics] to display the system diagnostic details.
Scroll down the list to view the POP and POS diagnostic information and details.
#### **POP Status for POP ID**
The POP Status panel shows the following:
• POP ID - PIN pad identifier.
• Status - Online/Offline.
• POP Model - EMV functions require PIN pad hardware with an EMV Chip Reader.
• Software Version - MX devices require ViperPAY 4.xx.xx.
• Kernel Version - MX 900 Series devices require Kernel 7.00+. MX 800 Series devices require Kernel 4.00+.
#### **POS Status for Workstation ID**
The POS Status panel shows the following:
• Workstation ID- POS Terminal Identifier.
• Status- Logged In/ Logged Off.
• POP ID- ID of associated PIN pad.
• POS Name- Device name.
• Software Version- Commander Site Controllers require Base 042.00.00 or higher.Kernel 4.00+.
## GLOSSARY OF TERMS
The following terms and definitions will assist with understanding the contents of the Feature Reference.
| Term | Definition |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| AAC | Application Authentication Cryptogram. Generated whenever a card declines a transaction. This may be generated at the 1st or 2nd GenAC step. |
| AID | Application Identifier, specified by the acquiring host and used to identify the EMV applications that a system can support. Cards and terminals use AIDs to determine which applications are mutually supported, as both the card and the terminal must support the same AID to initiate a transaction. Both cards and terminals may support multiple AIDs. |
| ARC | Authorization Response Code indicates the transaction disposition of the transaction received from the issuer for online authorisations. |
| ARQC | Authorization Request Cryptogram. Generated by the card when it instructs the system to go online for an approval. An ARQC is generated at the 1st Gen AC step. |
| CAPK | Certificate Authority Public Key. The list of keys created by the card issuers used to support EMV cryptographic functions. Each card brand has CAPKs. These keys are loaded into the PIN Pad's during system startup and kept up to date by the system based on data exchanges from the acquiring host. |
| Contact EMV | An EMV transaction where the EMV card data is read by inserting a chipped card into the card reader slot on the PINpad. The card remains inserted in the PINpad for the duration of the transaction. The PINpad and the card communicate several times during the course of a transaction. |
| Contactless EMV | See NFC, Near Field Communications. |
| Term | Definition |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CVM | Cardholder Verification Method. The method that the card instructs the terminal to use in order to validate the cardholder. Consists of online PIN, offline PIN, Signature, and No CVM. |
| EMV | Europay, MasterCard, and Visa. The implementation-oriented global specifications regarding the use of chip card technology for the payments industry; established to ensure interoperability and acceptance of payment system Integrated Circuit Cards on a worldwide basis; the acronym refers to the three organizations that initially collaborated on the specification, now maintained by EMVCo. EMV is now analogous with payment cards with embedded security microchips. Within this document EMV is assumed to mean "Inside Contact EMV". |
| EMV Kernel | A layer of software, specific to the hardware it is running on that handles the actual communication with the EMV chip on the card. It is versioned, it has an expiration date, and is certified by EMVCo. |
| EMV Tag | An EMV identifier. EMV data is maintained in tags - for example 8A and 9F12 are tags representing Authorization Response Code and Application Preferred Name respectively. |
| EPS | Electronic Payment Server |
| Fallback | Fallback in EMV terms means allowing a magnetic stripe swipe if the chip read fails. See Technical Fallback. |
| FEP | Front-End Processor |
| First Generate AC or 1st Gen AC | At a high level this is the stage in an EMV transaction where an approval is first requested from the card. Responses can be a TC (approved by the card), ARQC (request to go online for approval) or an AAC (decline). |
| Global AID | An AID that is owned by the global/international payment network whose logo is on the card. Global Payment Networks include American Express, Discover, MasterCard and Visa. |
| IAD | The Issuer Application Data (IAD) contains proprietary application data for transmission to the issuer in an online transaction. |
| ICC | Integrated Chip Card, or Integrated Circuit Card. |
| Term | Definition |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Magnetic Stripe Fallback | See Technical Fallback. |
| MSA | Merchant Services Account. |
| MSD | Magnetic Stripe Data - The term is used to describe the legacy card entry method requiring a swipe of the card to read the magnetic stripe. |
| MSP | A merchant services provider (MSP) is an umbrella term that covers banks, third-party processors or any other entity that provides businesses and individuals with the products and services necessary to accept credit cards, debit cards and other forms of electronic payment. |
| MSR | Magnetic Swipe Read. |
| NFC | Near Field Communications is used to describe an EMV transaction where the EMV card data is read by tapping or waving the card above the PINpad within the zone, allowing the card and the PINpad to interact. The card is then removed from the zone and the transaction proceeds with no further Card to PINpad interaction. |
| PDL | Parameter Download. Some acquiring hosts supply configuration and other processing data via a PDL. |
| PIN | Personal Identification Number. |
| POP | Point of Purchase hardware, referring to MX 900 Series PINpads used to read EMV cards. |
| POS System | Includes the POS (Point of Sale) terminal(s), site controller and the electronic payment system (EPS). |
| Quick Chip | Quick Chip is a specification enhancement for EMV from Visa that enables chip reads in two seconds or less. |
| Rapid Connect | Rapid Connect is a payment interface that provides single point integration to all First Data payment platforms including Buypass. |
| RCI | Remote Configuration Interface. |
| RID | Registered Application Provider Identifier. The RID is a fixed length unique identifier allocated to each card scheme to identify EMV applications provided by that scheme. The schemes may then suffix this with an optional PIX to further differentiate between multiple products supported by the scheme, and together they form the AID. |
| Term | Definition |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| STAN | The System Trace Audit Number which identifies the transaction number processed through the merchant account. |
| Stand-in | A process whereby a transaction may be approved locally according to specific transaction criteria even if the system cannot approve a transaction online. |
| Table Owner | The entity responsible for maintaining the VIPER tables. Depending on the FEP and the brand, this may be the major oil brand, the processor, Verifone, or a combination of Verifone and brand/processor. |
| TC | Transaction Certificate. Generated at the 2nd Gen AC step for approved transactions. |
| Technical Fallback | This is the exception process whereby an EMV-capable device either reads the chip from an inserted card, or reads the magnetic stripe rather than the chip data. (This latter method is deprecated.) |
| Terminal ID | The PINpad terminal identifier. |
| TPP ID | Third Party Processor ID. This is an ID that uniquely identifies a particular version of a payment application and which also functions as the Project ID during the certification process. It is assigned when the project is created and follows the application through to the production environment. |
| TSI | Transaction Status Information. |
| TVR | Terminal Verification Results. |
| UMF | Universal Message Format. This is the XML-based message format specification for the Rapid Connect application. |
| U.S. Common Debit AID | An AID that is owned by a global card brand, but can be licensed by a debit network. Discover, MasterCard, and Visa all provide a U.S. Common Debit AID. |
| VAP | Value Added Platform. |
| VIPER | Verifone's EPS payment processing application. |
## SUPPLEMENTAL INFORMATION
The following is a list of EMV Application Identifiers that Verifone certifies. Names may vary in downloaded EMV tables and on cards, as the processor and issuer can choose their preferred naming conventions to associate with the AID.
| AID | AID Name | Vendor |
| -------------------- | ---------------- | ---------------------- |
| A00000002501 | Amex Credit | American Express |
| A0000001523010 | Discover | Discover |
| A0000001524010 | Discover Common | Discover |
| A0000000041010 | MC Credit | Mastercard |
| A0000000043060 | Maestro | Mastercard |
| A0000000042203 | Debit Mastercard | Mastercard |
| A0000000031010 | Visa CR/DB | Visa |
| A0000000032010 | Visa Electron | Visa |
| A0000000033010 | INTERLINK | Visa |
| A0000000980840 | US DEBIT | U.S. Common Debit AID |
| A0000000049999C00016 | Voyager | U.S. Bank (fleet card) |
| A0000007681010 | WEX | WEX |
| A0000000033010 | INTERLINK | Interlink |
#### Contactless
| AID | AID Name | Vendor |
| -------------- | ---------------- | --------------------- |
| A0000000033010 | INTERLINK | Interlink |
| A0000000032010 | Visa Electron | Visa |
| A0000000031010 | Visa CR/DB | Visa |
| A0000000980840 | US Debit | U.S. Common Debit AID |
| A0000000041010 | MC Credit | Mastercard |
| A0000000043060 | Maestro | Mastercard |
| A0000000042203 | Debit Mastercard | Mastercard |
| A00000002501 | Amex Credit | |
| A0000001524010 | Discover Common | |
| A0000001523010 | Discover D-PA | |
### EMV Transaction Tags
For a list of EMV Transaction Tags, Verifone recommends referring to EMV Book 3, which can be found here: EMV\_v4.3\_Book\_3\_Application\_Specification\_20120607062110791.pdf
You can also find a complete list of EMV Transaction tags at:
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.verifone.com/feature-references/feature-references/emv-inside-emv.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.