EMV Transaction Processing

Elavon supports the following transaction types: Authorization, Pre-authorization with Completion, Balance inquiry, Refunds, Reversals, Voice Referrals, and Partial Authorization.

Transaction scenarios

Authorization

This is the purchase or sales transaction made by the customer at the point of sale. An authorization message is sent to the issuer after the ARQC is generated in the First Generate AC. The issuer responds with a response message containing a response cryptogram (ARPC). When received, the terminal issues a command to the chip to verify the cryptogram.

Elavon has a list of proprietary response codes sent back to the terminal or point of sale (3 digit value of which 2 digits are used).

Pre-Authorization / Completion

Pre-authorization applies to merchant systems that authorize a transaction with a pre-determined amount, and complete the transaction with the actual sales amount, in order to ensure sufficient funds with a cardholder.

This commonly applies to hotels, gas stations, car rental centers, etc.

The terminals may have a pre-defined pre-authorization amount which is used as the transaction amount in the authorization message sent to the issuer.

A completion message is sent to the issuer with the final transaction amount.

Balance Inquiry

Balance inquiry is a zero amount full EMV transaction sent online to the issuer, and the account balance responds back.

Balance inquiry is performed at an ATM or a POS. Such transactions require a CVM (ex: Online PIN) to be entered by the cardholder.

Refunds

This type of transaction is performed in case the cardholder returns merchandise, merchant makes a price adjustment, or a similar scenario.

Whether the EMV transaction is completed over contact or contactless interface, the terminal issues an AAC on the First Generate AC once the Track-2 data (PAN and Expiry date) is read from the chip.

Example of the refund process is below:

• Application Selection
• Processing Restrictions (GPO)
• Read Data
• Request AAC on Generate AC

Best Practice

Elavon recommends that credit returns be processed as partial EMV when possible (e.g. if the card is present).

Reversals

There are scenarios where the EMV transaction is approved by the issuer, but due to some POS or chip card conditions, the transaction is declined or not completed. In this case, the transaction must be reversed to the issuer to ensure that the funds are released for use by the customer.

Possible scenarios are:

Merchant System – At the point of sale, the transaction may be cancelled by the merchant system after receiving the response from the issuer. There may also be situations when the PIN pad is unavailable, the POS system is unavailable, or the merchant host system is down. In these scenarios a reversal must be generated by the merchant POS system. Possible scenarios are summarized below.

1. PIN Pad Unavailable after receiving response from the host and before Second Generate AC.

2. Transaction cancellation by the cardholder or the merchant system before or after receiving response from the host (before Second Generate AC).

Chip Card – The transaction may be declined in the case of a chip error (technical error), card removed after receiving online approval (transaction not completed), or the transaction declined by the card with an AAC (due to issuer risk parameters).

Possible scenarios include:

1. Chip error at Second Generate AC or External Authenticate due to malfunction of the chip.

2. Decline by the card at Second Generate AC due to risk parameters of the card after receiving approval from the host.

3. Premature card removal before Second Generate AC.

Voice referrals

Voice referral is a risk management process that the issuer uses to authenticate the identity of the cardholder when a transaction is attempted at the point of sale. As per ISO-8583, the response code value is ‘01’ (in Field 39) for voice referrals.

Elavon passes the voice referral response from the issuer when received. Elavon has pre-defined decline codes that are passed to the merchant system. Whenever a voice referral response is received, the terminal must request an AAC from the card during Second Generate AC. The merchant then performs a voice authorization and upon receiving the response a new EMV transaction shall be initiated.

Voice referrals are supported by Elavon. The voice referral responses are mapped to unique decline codes.

Partial Authorization

In some transaction scenarios, the host provides an approval for an amount less than the original transaction amount.

For example, in cases of gift cards or pre-paid cards with a balance less than the transaction amount. As a result, the cardholder must be prompted to accept or decline the transaction with the lower amount. Once the selection is made, the transaction proceeds with the Second Generate AC or External Authenticate.

If the cardholder opts to continue the transaction with the lower amount authorized by the host, the merchant POS system may optionally provide the Tag 9F02 (with the updated amount) to the card to be used in Second Generate AC. The authorization response code Tag 8A must be set to approve (0x3030) prior to Second Generate AC process. The terminal may perform External Authenticate in lieu of a Second Generate AC.

If the cardholder does not approve the authorized amount, the transaction should be declined with a subsequent reversal message sent to Elavon.

The merchant system must submit the authorized amount from the Partial Authorization response as the Authorized Amount in the clearing message.

For attended terminals, MasterCard requires support for Partial Authorization in the U.S. region.

Single vs Dual-Message processing

In single message processing, all the transaction information required is sent in one message at the time of authorization. Debit transactions with PIN are sent as single messages. In scenarios when the chip declines the transaction after receiving issuer approval, a reversal must be generated by the merchant’s POS system.

In dual message processing, a clearing message is sent after the online authorization is completed. The clearing information is sent in the form of a batch file. The EMV tags along with the transaction certificate are sent in clearing.

For details on the EMV tags required in single and dual messages see References.

Currently only one processing code for debit and one for credit is supported by Elavon. Prepaid is treated as debit and no separate code is used for this payment type.

US Common debit scenarios

The U.S. Common AID provides routing options to merchants that could potentially reduce the overall processing cost of transactions. Elavon recommends selection of the U.S. Common AID when available.

Any exception will be reviewed on a case by case basis with your relationship manager, representative, solution engineer, and/or certification analyst.

Application selection scenarios

Merchant system may support branded cards with US common AID and route to the debit network(s) when presented at the terminal. When the US common Debit AID is selected, merchant systems and acquirers can route the transaction to appropriate debit network using the BIN. When Global AID is selected, it is routed to the appropriate global network.

As per the EMV processing of application selection, a candidate list is prepared by the terminal using the mutually supported applications by both the card and the terminal. If there is more than one application, the merchant system may choose to display them to the cardholder and provide the ability to select one.

In the United States, merchant systems have the flexibility to either select the Global AID or the US Common Debit AID. Elavon requires that merchants select the US Common Debit AID whenever available. When US Common Debit AID is selected, the logic is built into the reader or terminal. However, if the debit card presented by the customer contains multiple funding accounts (or sources), the merchant system may display the same to the customer to select the source of funds for processing the transaction. Only the US Common Debit AIDs need to be presented to the cardholder for selection when present. The merchant system should have a clear identification and display of funding sources in order to avoid confusion to the cardholder.

There may already be specific auto-selection processes, based on highest priority application, that the merchants may want to review and modify based on their preferences. Merchants may also deploy their preferred methods for cardholder verification at the terminal. When the terminal automatically prompts for a PIN for card present transactions, the merchant system can provide the option to the cardholder to complete the transaction with a signature or No CVM.

Some of the methods to opt out of PIN entry are:

• Displaying Signature button on PIN prompt screen
• Displaying or advising the cardholder to use “cancel,” “enter” or any other key on the PIN pad to opt out of PIN entry or bypass the PIN
• Using “credit” or “debit” buttons on the PIN pad where “credit” can be used to opt out of PIN entry and “debit” to be used to enter PIN to complete the transaction.

Regardless of the verification method (including PIN, signature, and no CVM), merchants are required to use U.S. Common Debit AID for the networks enabled by the card issuer in order to route to the most cost-effective network.

Application selection for Contactless transactions

Application selection on contactless does not work in the same way as over the contact interface.

First, cardholder selection is not supported over contactless due to minimal interaction between the contactless reader and the consumer device (or contactless form factor).

The default AID (or application) is primarily the highest priority AID on the device identified by the issuer. In order for the merchant system to route the transactions to debit networks and/or offer additional options to the customer (like Cashback), the merchant system must override the default AID selection and pre-select the US common Debit AID by deploying a specific logic on the terminal.

Merchant systems should ensure that the terminals pass DF Name (Tag ‘84’) to the acquirer or processors to perform appropriate routing.

In case of contactless MSD, routing can be achieved by using BIN routing functionality since AIDs are not used in this case.

Partial Selection

CVM (Cardholder Verification Method)

The cardholder verification step in the EMV process is performed to determine the authenticity of the cardholder. The card has a prioritized list of CVMs that can be used while the PIN pad has a list of verification methods it can support. Between the card and the terminal, they determine the appropriate CVM to use for the transaction based on whether credit/debit was selected by the cardholder, the transaction amount, and whether cash back was selected as an option.

There are a number of CVMs that can be supported by the card and/or the PIN pad.

• Offline PIN – This CVM is not authenticated by the card issuer in an online authorization; rather, the PIN verification is performed by the ICC (chip). The offline PIN can either be enciphered or plaintext PIN, which means that the PIN value entered may or may not be encrypted by the PIN pad, depending on the type of implementation. The PIN entered in this type of CVM is verified by the ICC via the VERIFY command issued by the terminal.

If Offline PIN is the highest CVM in the card, a transaction with US Common Debit may be processed as below:

1. Using selectable kernel configuration by selecting a kernel that has Offline PIN, and

2. Terminate the transaction, select Global AID and process the transaction with Offline PIN.

• Online PIN – With this CVM, the cardholder enters the PIN which is then encrypted by the PIN pad and sent in the online request message.

• Signature – After the transaction is processed successfully, the cardholder is asked to sign on the signature panel or the printed receipt.

• No CVM – This type of cardholder verification is supported for particular transaction characteristics and merchant type. This is a valid cardholder verification method if both the card and terminal decide and agree on this CVM option. When this option is selected, the consumer is not required to provide either a PIN or a signature.

• CDCVM– In case of contactless payment form factors, consumer device cardholder verification method (CDCVM) is completed on the consumer’s payment device. The cardholder authenticates to their device through either a PIN, PIN-like value, or biometrics.

Best Practice

• Online PIN support is highly recommended for all AIDs. Merchant systems and Third Party Processors will need to work with Elavon in case of an exception.

• In case of a VEPS or QPS transaction, if No CVM is used, the signature line is not required to be printed, but can be if merchant desires to capture the signature.

CVM configuration per product

Key: Online PIN – 1, Offline Plaintext PIN – 2, Offline Enciphered PIN – 3, Signature – 4, No CVM – 5, CDCVM – 6

PIN bypass support

PIN entry bypass is a systematic way for a customer to bypass entering the PIN on a terminal. In such a scenario, no PIN data must be sent and CVM may not be sent as Online PIN in the authorization request message. Customer presses the enter key or a separate key allocated for PIN Bypass.

Best Practice

If the merchant system automatically selects US Common AID and the customer wishes to bypass the PIN, refer to Application selection scenarios.

Low-value payment scenarios (VEPS/QPS)

Regarding the solutions offered by the brands, VEPS and QPS are considered to have the benefits similar to other Faster EMV solutions (like Quick Chip or M/Chip Fast). VEPS and QPS programs benefit merchants and cardholders by allowing for faster, more convenient low-value purchases. With a majority of merchants eligible to implement these solutions, greater efficiency, customer satisfaction, and throughput can be achieved. In such a scenario the merchants must establish a CVM limit under which No CVM can be allowed and over which a PIN or Signature would be required. Signature request is deferred until after the online response is sent back to the terminal, so the final amount can be compared with the VEPS limit.

Terminal Risk processing

Limits

Stand-in floor limits

Best Practice

Elavon recommends merchant systems not to stand-in. If merchants wish to implement stand-in functionality, merchants will be liable for both fraud as well as the risk of Issuer decline for other reasons (e.g. insufficient funds, delinquency etc.).

Terminal Floor limits and CVM limits

Terminal action codes

Terminal action codes are used in the Terminal Action analysis step in the EMV transaction process. If present, bits of Terminal Action Code (TAC) are compared with the corresponding bits of Issuer Action code (IAC) in a bitwise OR processing. The output of this processing is compared with the corresponding bits of TVR in a bitwise AND process to get the final outcome of whether a transaction can result in decline offline, approve offline or sent online for issuer authentication.

It is not mandatory for the merchant system to use Terminal Action codes, but it is strongly recommended to use them, especially the TAC default and TAC online codes

Best Practice

Elavon recommends the terminal action codes (TAC) as specified by the major brands (MasterCard, Visa, AMEX and Discover).

Specific processing

Language Support

The language preference data in the chip indicates the preferred language set by the card issuer. The language at the Point of sale is selected when the terminal compares the preferred language of the chip card with the language options available on the terminal. In case the cardholder intends to choose another language, the selection can only be made if the same language is supported by the terminal.

DCC

Dynamic currency conversion allows the cardholder to know the transaction amount in an alternative currency and an option to choose the alternative currency. The eligibility check and further processing of DCC including checking of current currency conversion rates is performed before the first generate AC.

The POS system performs a check for the currency code. If the merchant currency code (no Issuer Country Code checking today) is different from the Issuing currency code, the POS system sends a message to the Elavon host to see if the card currency is eligible for DCC. If the currency is eligible for DCC, the host sends back the current rate to the terminal and/or merchant POS allowing the customer to opt in or out. The step by step DCC flow is mentioned below.

DCC process flow:

• Step-1: Select Application

• Step-2: GPO processing (In local currency)

• Step-3: Read Record (to get the PAN)

• [Stop EMV]

• Step-4: Execute Eligibility with the host

• [Resume EMV]

• Step-5: Terminal Risk Management

• Step-6: Generate AC in foreign currency (to be verified if possible)

• Step-7: Transaction completion

Elavon supports DCC only for Credit and Signature Debit transactions

Elavon supports DCC for Visa and MasterCard only.

Over contactless interface, a second tap will be required in order to retrieve the final amount (converted).

Best Practice

*The chip card should remain in the terminal in the case of contact EMV transaction.

Terminal should not prompt to remove the card after the eligibility check. This ensures the transaction is processed successfully after DCC opt-in and eligibility checks, and the response is received from the host.*

Figure 22 DCC Flow

When a business is enabled with DCC, there are several components that vary from a normal EMV interaction. DCC is supported only on Visa and MasterCard transactions. The DCC transaction flow starts when the card is inserted.

• Review the card type. If the card is a Visa or MasterCard continue with a DCC transaction. All other card types are not eligible for DCC, proceed with transaction authorization.

• Review the cardholder currency stored on the chip. If the cardholder currency matches the business’s currency, the card is not eligible for DCC. Proceed with normal transaction authorization.

• If the cardholder currency does not match the business’s currency, submit DCC Eligibility Check transaction to the Elavon host to determine if the transaction is DCC eligible. The DCC Eligibility transaction approval response will return all of the needed information to prompt the cardholder to make their DCC currency choice. If the card is not eligible for DCC, the DCC Eligibility transaction will decline. In the event of a decline, proceed with the transaction authorization in the business’s currency.

• The PIN pad or device should present the cardholder with the DCC choice to pay in the business’s currency or the cardholder’s currency; along with required disclosure of the exchange rate and the currency conversion fee. See the DCC Primer for requirements on screen language.

  • Please Note: until the cardholder’s choice is received, the final transaction amount is not determined.

• After the cardholder choice is made, complete the cryptogram with the final amount in the cardholder’s choice of currency.

• Submit the transaction authorization. If the transaction is approved, a DCC receipt should be printed. DCC receipts require additional disclosure language. Please see the DCC Primer for details.

Business segments

In different business segments the DCC and EMV flow may change slightly based on the way of doing business. Use Case flows are included in the DCC Primer. A quick table is provided below for high level details.

DCC Exclusions

Elavon does not support DCC in ATM, cash advance, and some direct marketing Merchant Category Codes (MCCs) such as catalog merchants, insurance services, inbound and outbound telesales, and subscriptions.

DCC is prohibited on contactless transaction at or below the CMV limit or ceiling limit.

Gratuity

Best Practice

American Express recommends that the terminal software enable the cardholder to add gratuity amount to the transaction before entering their PIN. This enables the transaction to be processed as a normal “card present” transaction.

Incremental authorizations

Merchants use incremental authorization when the transaction amount exceeds the original transaction amount limits. For example, when the gratuity amount exceeds 20% of the sales amount. In most cases, incremental authorizations are non-EMV, key entered transactions.

Downgraded transactions

In an EMV transaction the terminal gathers all the transaction data including EMV fields, sends to the acquirer host, and in-turn the issuer host for processing. There may be a possibility that the issuer host is not able to process or validate EMV data and sends the response without EMV data. Such issuers may be magnetic stripe grade or semi-grade. Such issuers do not validate the request cryptogram (ARQC) or generate the response cryptogram (ARPC) and do not achieve the same benefits as full-grade issuers.

Cashback scenarios

Best Practice

Elavon recommends contactless form factors over cashback.

Host capture/terminal capture scenarios

• previousEMV Overview
• nextFallback Scenarios