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.
My works have been cited across media and payment blogs. I do my best to help businesses make the most efficient financial decisions that can positively and significantly improve their business growth.
Whether you are a seasoned investor or just starting out in the world of payments, my writing is designed to be accessible to everyone and help people navigate the complex world of payments. So if you want to stay up-to-date on the latest trends and insights in the payment industry, be sure to check out Paylosophy and my published works.
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. On a regular basis, I work with a team of knowledgeable technical people in the space, and I am passionate about finding creative solutions to the challenges presented by the Payments Industry.
I would be happy to help with any questions you might have regarding credit card payment processing, merchant services, EMV certifications, the various ways of becoming a payment facilitator or a payment platform, as well as any other Payment Industry related issues you might be struggling with. Feel free to follow me on Quora, and don’t hesitate to send me links to the specific Quora questions you would like me to answer.
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.
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.
Recommended to you
