Fallback flow with EMV L2 Common Gen kernel

Overview

This article explains the basic EMV fallback flow when using the ID TECH L2 Common Kernel. Fallback occurs when a chip transaction cannot continue and the reader determines whether the transaction may continue as an MSR swipe.

Fallback decision flow

Start the EMV transaction.
Determine whether the chip can be read.
- If the chip is readable, continue with the EMV transaction.
- If the chip is not readable, check the magstripe service code to determine whether a chip is present on the card.
If the magstripe service code indicates that a chip is present, return EMV_RESULT_CODE_FALLBACK_TO_MSR and prompt for MSR fallback.
If the magstripe service code indicates that no chip is present, return EMV_RESULT_CODE_SWIPE_NON_ICC.
If there is no magstripe data, or the magstripe data is unreadable, return EMV_NO_MATCHING_APP.

Setting the MSR fallback retry limit

Use tag DFEF7D in the terminal settings to control how many times the reader allows another chip insert after a bad insert before falling back to MSR or ending the transaction.

Tag	Length	Purpose	Examples

Tag	Length	Purpose	Examples
`DFEF7D`	1 byte	Number of allowed reinsert attempts after a bad chip insert.	`DFEF7D0103` = allow 3 tries to read the chip before fallback to MSR. `DFEF7D0101` = allow 1 try to read the chip before fallback to MSR.

Valid values are 01 or greater. Do not set DFEF7D to 00; on some firmware, a value of 00 is not treated as valid and may be interpreted as the default value, commonly 3, without returning an error.

Related fallback configuration tags

Depending on the product, firmware, and operating mode, the following terminal-setting tags may also be used with MSR fallback behavior:

Tag	Length	Use	Typical value

Tag	Length	Use	Typical value
`DFED0A`	1 byte	Outputs the fallback reason in the returned swipe data.	`DFED0A0101` enables fallback-reason output.
`DFEF65`	1 byte	Enables error reporting, including insert-status reporting such as `DFEF61`.	`DFEF650101` enables error reporting.
`DFEF62`	1 byte	Controls whether a chip card may be accepted as an MSR swipe.	Confirm the required value for the device and use case before deploying.
`DFEF7E`	Variable	Defines ICC response codes that should trigger fallback behavior.	Example: `DFEF7E06500150055036`.

Why set a retry limit?

Improves customer experience: Allows the cardholder to correct a bad insert before requiring a swipe.
Supports certification scenarios: Some brand test cases require multiple insert attempts before fallback.
Prevents endless retry loops: A defined limit gives the reader and host application a predictable point to move to fallback or end the transaction.
Helps the host application display the right prompt: Retry and fallback reason codes allow the application to show messages such as “Insert card again” or “Swipe card.”

Example configuration

The following example enables fallback-reason output, enables error reporting, allows the configured fallback behavior, sets the retry limit to 3, and configures common fallback-trigger status codes:

DF ED 0A 01 01 DF EF 65 01 01 DF EF 62 01 01 DF EF 7D 01 03 DF EF 7E 06 50 01 50 05 50 36

Always verify the required tag values against the product integration guide and firmware version for the specific reader being configured.