Elavon supports the following transaction types: Authorization, Pre-authorization with Completion, Balance inquiry, Refunds, Reversals, Voice Referrals, and Partial 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).
The merchant system shall use the response code value to construct Tag 8A to be sent to the chip when the response does not contain a value.
The merchant system must use the authorization response code received from Elavon to reconstruct tag 8A.
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.
For pre-authorization transactions, it is required that merchant systems include chip data in the clearing message whether or not the completion message contained chip data.
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.
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:
Processing Restrictions (GPO)
Request AAC on Generate AC
Elavon recommends that credit returns be processed as partial EMV when possible (e.g. if the card is present).
Merchant systems supporting refunds over contact interface must support contactless as well.
Elavon requires that debit returns must be processed as full EMV.
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.
PIN Pad Unavailable after receiving response from the host and before Second Generate AC.
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:
Chip error at Second Generate AC or External Authenticate due to malfunction of the chip.
Decline by the card at Second Generate AC due to risk parameters of the card after receiving approval from the host.
Premature card removal before Second Generate AC.
Debit reversals - Elavon requires that merchant systems send all the EMV tags that the device (or terminal) sends to the POS system.
Credit reversals - EMV Tags may optionally be returned to Elavon.
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.
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.
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.
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.
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.
Elavon’s Simplify™ solution uses the “credit” approach for Signature Brand Debit AIDs.
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 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.
It is required that the merchant system support cardholder confirmation for application selection.
For Canada region, Account Type must be supported for merchant systems accepting Interac.
Elavon requires partial selection of the application if the kernel supports the functionality. It is recommended that the minimal configuration would use the first 7 bytes of the AID (RID + PIX) for partial selection.
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.
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.
Clients supporting US Common Debit must exclude Offline PIN from the CVM list of Common Debit AID.
PIN Bypass shall not be allowed for Debit transactions. This feature must be turned off on the terminal if not required.
Note: Fusebox does not support Online PIN for Amex direct interface.
Key: Online PIN – 1, Offline Plaintext PIN – 2, Offline Enciphered PIN – 3, Signature – 4, No CVM – 5, CDCVM – 6
|American Express||Credit AMEX||A00000002501||1,2,3,4,5,6|
|Debit Network Alliance (DNA)||U.S. Common Debit||A0000006200620||1,4,5,6|
|Discover||Credit or Debit Discover||A0000003241010||1,2,3,4,5,6|
|Discover||U.S. Common Debit||A0000001524010||1,4,5,6|
|MasterCard||Credit or Debit MasterCard||A0000000041010||1,2,3,4,5,6|
|MasterCard||U.S. Common Debit||A0000000042203||1,4,5,6|
|Visa||U.S. Common Debit||A0000000980840||1,4,5,6|
|UnionPay Debit||UPI (DS)||A000000333010101||1,4,5,6|
|UnionPay Credit||UPI (DS)||A000000333010102||1,4,5,6|
|UnionPay Quasi Credit||UPI (DS)||A000000333010103||1,4,5,6|
|UnionPay Electronic Cash||UPI (DS)||A000000333010106||1,4,5,6|
|UnionPay Common Debit||UPI (DS)||A000000333010108||1,4,5,6|
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.
If the merchant system automatically selects US Common AID and the customer wishes to bypass the PIN, refer to Application selection scenarios.
PIN bypass is only supported if the EMV Payment application is certified for all CVM with PIN Bypass indicator set to indicate it could be on or off.
Elavon requires merchant systems to monitor the use of PIN bypass at the terminals.
PIN Bypass is only for the customer-facing terminals. PIN bypass must not be initiated by the merchant system.
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.
Elavon supports common debit in the VEPS or QPS configuration with the use of No CVM. Such a feature shall be managed by using a No CVM kernel configuration.
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.).
Elavon requires terminal floor limit to be set to $0.
Elavon requires contactless floor limit to be set to $0.
Contactless CVM limits shall be followed as per brand recommended values.
There shall be no Contactless transaction limit for US region. For Canada region, contactless transaction limit shall be set at CAD $100 except for Interac Flash.
The merchants shall be able to modify the limits (ex: CVM limit) without re-certification.
CVM limits are required by Elavon for contact and contactless.
For transactions greater than the CVM limit, online PIN must be supported and CDCVM must not be supported for US Maestro AID. In such a scenario, the merchant system must prompt customer for a PIN to be entered on the terminal or process the transaction with No CVM.
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
If a Merchant or Third Party Processor wants to modify TAC values different that those recommended by the brands, they must contact their Solutions Engineer and Elavon Representative.
Elavon recommends the terminal action codes (TAC) as specified by the major brands (MasterCard, Visa, AMEX and Discover).
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.
For the support of multiple languages Elavon requires merchants to follow EMV guidance and use the Language Preference information, Tag 5F2D from the chip. Elavon does not make any differentiation for the management of multiple languages (based on specific countries like Canada, US, etc.) for the merchants.
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)
Step-4: Execute Eligibility with the host
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).
In a lodging scenario, the cardholder can opt-out of DCC before transaction completion. In this case, Elavon requires that the merchant system discard the initial authorization and make a new authorization in local currency.
Note: In the case of contactless EMV, 2 taps will be required to accommodate DCC. First tap is required to get the PAN and second one to compute ARQC with the final converted amount.
*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.
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.
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.
|Restaurant or Business With a Tip||Hotels|
DCC can only be offered if the cardholder, the card, and the PIN pad or Device are all present:
Pay at the Table
Pay at the Counter
DCC may be presented at the time of check-in
Screen language must disclose that the Final Exchange Rate is determined at checkout.
|The tip amount must be entered prior to completing the DCC Eligibility check||PMS system should store the cardholder’s DCC choice to be used for additional charges to the hotel room|
|Cardholder choice is mandatory and cannot be offered in Waiter Banking options||
Incremental Authorizations are eligible for DCC and require additional DCC Eligibility check transactions.
Card does not have to be present for incremental authorization
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.
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.
If the gratuity amount is not added to the transaction amount, the transaction must be executed in two parts;
The initial authorization is executed with the transaction amount without gratuity
The gratuity must then be added to the second transaction including the EMV data from the original authorization.
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.
For incremental authorizations, Elavon does not require merchant systems to send EMV data. The incremental transaction amount as a percentage of the original transaction amount, should be followed as per brand recommendations.
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.
Elavon supports magnetic stripe grade transactions.
For MasterCard purchase with cashback transactions, if the transaction is declined by the Issuer the response shall be sent back with Response code 87.
Cashback feature is supported for Common debit AIDs with Visa, MasterCard, and Discover.
Elavon does not support Cashback for Credit AIDs.
Elavon recommends contactless form factors over cashback.
In case of host capture, merchant systems are required not to send the TC in the settlement message.
In terminal capture, TC must be captured, printed on the receipt, and sent in the settlement message. In case of Faster EMV, the ARQC from the first Generate AC must be captured, printed on the receipt, and sent in the settlement message.