Fallback processing requirements
A fallback transaction occurs when a transaction cannot be processed due to issues with either the chip card, or with a chip-capable (or enabled) terminal.
There are two basic scenarios:
Fallback: When a transaction cannot be completed via contact chip interface due to chip error or chip card reader error, and therefore magnetic stripe is used to complete the transaction. This transaction is sent by the merchant system as fallback. Please refer to the below table for the POS entry mode value(s) to be sent to Elavon in case of fallback.
Empty Candidate List (ECL): If there are no matching AIDs between the chip card and the terminal during application selection process, the transaction cannot be processed via the contact chip interface. The transaction can be completed via magnetic stripe, but is not considered a fallback transaction.
Empty Candidate List
During application selection, the terminal builds the candidate list based on mutually supported applications on both the card and the terminal. A condition may occur where no AID on the card is matched with AIDs supported by the terminal, even though partial AID matching is supported. It is unlikely the brands have specific requirements for how to handle this scenerio.
If there is no matching AID between the terminal and card to use for a chip/EMV transaction AND the card is allowed to be swiped, then the resulting transaction should be processed as follows:
American Express and MasterCard - these transactions should be processed as fallback with all of the appropriate indicators set.
Discover and Visa - these transactions should be processed as a regular swipe transaction (not fallback).
All four brands indicate the terminal should not change the values that identify the capabilities of the terminal. The terminal should continue to identify itself as chip capable.
Fusebox proprietary POS Entry Mode:
|02||Key Entry Card Present|
|04||OCR code read|
|05||Integrated circuit card read - CVV data reliable (smart card)|
|07||Contactless M/Chip or Visa Smart Card read|
|80||Chip Card capable - unaltered track data read (used for EMV fall back to swipe)|
|82||Contactless Mobile Commerce device|
|90||Magnetic Stripe - CVV/CVC certified, unaltered Track Data (1 or 2) included in Authorization Request. Required to participate in PS/2000 or CPS/2000|
|91||Contactless chip magnetic stripe read|
|95||Integrated circuit card read - CVV data unreliable|
|85||Internet (not an ISO value)|
Since fallback transactions are performed with lesser risk management compared to the traditional EMV transaction, merchants should also ensure that fallback is not allowed in certain scenarios as mentioned below:
Transaction declined offline
Card removed prematurely
Transaction cancelled before receiving response from host (acquirer or issuer)
Fallback not supported by the card brand
Chip card blocked
Chip application blocked
Elavon expects that merchant systems abort Fallback processing if the card is inserted during Fallback processing mode. The cardholder will be allowed to swipe the card in this scenario after dipping the card three times.
Elavon supports fallback processing. There is only one fallback value that Elavon requires in POS entry mode.
For a transaction to be processed as fallback, Elavon requires three tries with chip card insertion and then using magnetic stripe when prompted by the terminal (initial dip + two retries).
Fallback transactions must be cancelled when a non-EMV card (the service code is not ‘2xx’ or ‘6xx’) is used when 'swipe' is prompted by the terminal. In this case, the transaction must be processed as magnetic stripe transaction.
Elavon requires merchant systems to send the correct value of point of sale (POS) data code.
In the case of Empty Candidate List (ECL), the terminal shall allow the transaction via magnetic stripe. In such a case, the fallback indicator shall not be sent by the merchant for Discover and/or Visa transactions.