Peculiarities of host EMV integrations

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)

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

Conclusion

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.