Peculiarities of host EMV integrations

on Feb3
EMV integrations
Written by
James Davis
Written by James Davis
Senior Technical Writer at United Thinkers
Author of the Paylosophy blog, a veteran writer, and a stock analyst with extensive knowledge and experience in the financial services industry that allows me to cover the latest payment industry news, developments, and insights. Read more
EMV integrations
Reviewed by
Kathrine Pensatori
Product Specialist at United Thinkers
Product specialist with more than 10 years of experience in the Payment Processing Industry. I help payment facilitators and PSPs solve their various payment processing issues. Read more

Every day the number of companies, working on EMV integrations, increases. There are several common misconceptions, that people have when starting integration, so we’ve decided to a closer look at the integration process and address some of those.

Briefly speaking, in order to go through the integration process successfully, one needs a terminal with a terminal application, which is going to be integrated with a gateway, while the gateway, in its turn, is integrated with a processor.

We’ve already written articles about EMV standards and technologies, as well as their advantages. In this particular article we are going to focus on some details, particularly related to EMV integrations. The article is targeted at payment gateway developers, who need to add EMV capability. We shall look at the changes, which need to be introduced into payment gateway logic in order for the gateway to be able to support EMV.

Support of EMV-specific fields in the request

In order for a gateway to support EMV (exchange EMV information), it needs to support fields, which are specific for EMV data processing. These fields are grouped into two key sets. One set of fields is the tag data read from the chip (usually sent as a single field). Another set includes information about general terminal capabilities, particularly, its EMV capabilities, as well as the entry mode, that was used when transaction was processed. Mostly processors will be asking whether a transaction was processed using integrated circuit (ICC), or it was a fallback using swipe, or a fallback using manual entry. These fields are also used for contact-less processing.

One of the EMV tags (9F26 – Application Cryptogram) must include the Authorization Request Cryptogram, which is responsible for the integrity of all of the other fields in the request message.

Support for updates in the response

It is important to understand that the issuer can return a configuration script which needs to be passed back to the card for a subsequent update. Therefore, the gateway will need to accommodate this value in its response field.

One of the mandatory EMV tags in the response (Issuer Authentication Data – Tag 91) must include a special Authorization Response Cryptogram (ARPC), which guarantees the integrity of the response message in general.

In some cases the receipt is printed by the POS, and not by the terminal. For the cases when the POS system prints the receipt itself, in order to make the functioning of the POS system more transparent, you need to make the access to the fields printed on the receipt as easy for developers as possible in the face of the future EMV integration, particularly through adding specialized fields to the response message.

Mandatory fields on the receipt

EMV has requirements that certain fields must be printed on the receipt. There are several requirements for approved and for declined transactions, as well as for offline transactions. Commonly, mandatory fields to be printed on receipts are:

  • application name (for example, application preferred name (Tag 9F12) should be printed if possible)
  • application PAN (last four digits of card number; Tag – 5A)
  • card entry mode (such as chip / contact-less / keyed / swipe, including fallback if used)
  • transaction total (for example, the receipt total line must reflect the transaction Amount (Tag 9F02) and identify the currency used to process the transaction)
  • cardholder verification (for example, “Verified by PIN”)
  • authorization mode (for example, “online” vs “offline”)
  • EMV tag data (for example, tag 4F for Application Identifier, 95 – for Terminal Verification Results, 9F10 – for Issuer Application Data, 9B – for Transaction Status Indicator, 8A – for Application Response Code)

Partly, these values are taken from request fields, and partly – from response fields.


EMV-certification is a long road. If you choose to walk it, you’d better be well prepared. Consequently, it is better to think carefully in advance about all the peculiarities of EMV integration implementation and all respective changes of your payment gateway API.

Recommended to you

Previous postThe Benefits of EMV Cards Next postSplit Funding and Adaptive Payments

Copyright© 2024, United Thinkers