The testing of the EMV payment application differs significantly from regular POS application. In which, there are many additional scenarios including for offline/online transactions and security that need to be covered.

The Girmiti team has strong expertise in using the certification tools to evaluate the applications. Also ensure your card management system and fraud/risk management systems have been successfully updated to support chip card transactions.

Transaction Processing Comparison – Magstripe Vs EMV

Magstripe Transaction Flow

To understand the difference in the flow for testing Magstripe vs EMV, the following are some points to consider:

• Magstripe is easily cloned
• Terminal performs little or no risk assessment
• Authorization/Capture Message
• Track data is often in the clear
• The authentication data is static
• Authorization/Authentication
• Risk assessment performed at the host
• Host cannot recognize cloned cards

Transaction flow would be as follows:

• Transaction initiated from Terminal to Acquirer system
• Acquirer forwards it to card association
• Card association forwards it to Issuer
• Issuer responds back with the Auth Code and transaction flows back in the same fashion up to the Terminal

Our Team helps and works closely with related companies, to understand the existing scope, current business scenarios, flows of the existing systems, to provide the consulting solutions to Build, Architect, Enhance Features, Design, Develop, Test, Support, Maintain existing system and UAT.

EMV Transaction Flow

EMV Transaction flow will be as follows:

• EMV transactions begin with a data exchange between the card and the terminal.
• When a customer uses a chip card at the terminal, the terminal communicates with the card to obtain all the information needed to determine if the transaction can be processed offline or must be processed as an online transaction
• Kernel processes the offline data authentication – SDA, DDA, CDA, fDDA
• Kernel performs the CVM based on Terminal and Card Capabilities – PIN, Signature, CDCVM
• If the terminal determines the transaction must be processed online, the terminal sends a Read Record Command to the card to retrieve the Card Data Objects List (CDOL1). The CDOL contains a list of EMV tags and value lengths that the card needs from the terminal
• The terminal uses information from the CDOL to compile a list of ‘values only’ that is sent to the card in an authorization request cryptogram (ARQC) Generate AC command
• The card validates the information from the terminal and, if the data is formatted correctly, sends a response to the terminal containing the ARQC, Application Transaction Counter, and Issuer Application Data.

• The terminal uses the information from the card, as well as the tags and values that the terminal sent to the card previously and sends a request to the Acquirer.
• The Acquirer maps the message from the terminal into the message format required by the Issuer or designated Gateway.
• The Gateway/Interchange/Switch must send the tags and values from the terminal to the Issuer unchanged. If the values are modified in any way, the Issuer will not be able
• to validate the ARQC. The Issuer receives the message and generates a response using the following process
• When the Issuer receives the message, the Issuer generates its own ARQC by reconstructing the block of data used when the card generated the ARQC. The Issuer then validates that its Issuer-generated ARQC matches the card’s ARQC (sent in the message).
• About the 9F10 tag in the request message: The 9F10 tag is used to identify what key file index should be used (that is, it identifies the keys on that card), and contains the cryptogram version number (CVN). The Issuer uses the CVN to determine the type of algorithm to use when generating a session key and the cryptogram’s block of data.
• The Issuer uses the request message’s ARQC, as well as the Authorization Response Code (ARC) when generating the authorization response cryptogram (ARPC).
• The Issuer sends the ARPC and any Issuer scripting back to the card in the response.
• Again, it’s imperative that the information sent back to the terminal and card for the cryptogram goes through the Gateway/Interchange/Switch and the Acquirer unchanged. If anything is modified or changed during the transfer process, the card cannot validate the ARPC.
• When the terminal gets the response, it sends the card to the ARPC in an external Authentication command.
• The terminal can now send the card any applicable Issuer script commands (that is, Application Protocol Data Unit (APDU) commands such as PIN change, application block, or card block) to be processed, or to be used in the completion message. If the card approves the ARPC and an APDU command has been sent to the card, even though an Issuer script may not be relevant to the current transaction, the command will be executed. The card then responds to the device with a status command that indicates whether the command was executed successfully. (This example addresses only Issuer Script APDU commands. There are other APDU commands as well, but those commands occur offline between the Card and the terminal—that is, those commands are not sent by the Issuer.)

Test Considerations for Various Entities

This section covers the Testing considerations that encompass Issuer, Acquirer, Switch and so forth in the EMV transaction flow. The entities taken into consideration are:

• Acquirer
• Switch/Gateway/Interchange
• Issuer

Acquirer EMV Processing Considerations

As an Acquirer, Merchant, Merchant Acquirer, or Terminal Driver, the implementation of EMV can affect several aspects of transaction processing. Organizations will likely need to develop tests the address needs such as:

• Testing ATM and POS configurations for compatibility with both chip cards and magnetic stripe cards
• Testing EMV message processing capabilities, including
• Testing ability to recognize and correctly process properly (and improperly) formatted EMV messages
• Testing ability to recognize and correctly process valid (and invalid) EMV message contents
• Testing fee processing
• Testing any required information handling for card or account management
• Testing ability to properly map the EMV tags or tokens in received messages to the correct tags and tokens required in the EMV messages one send to others

Switch/Gateway/Interchange EMV processing considerations

As a Switch network, Gateway, or Interchange, the primary challenge is EMV message mapping and validation. Organization will likely need to develop tests the address needs such as:

• Testing validation of the EMV message
• Testing ability to recognize valid (and invalid) data in the EMV message contents
• Testing your ability to recognize properly (and improperly) formatted EMV messages
• Testing ability to correctly map the EMV tags or EMV tokens before you forward the transaction
• Ensuring one examines the correct EMV tags or EMV tokens when you receive a response message
• Testing fee processing
• Testing any required information handling for card or account management
• Testing switch availability, and testing to ensure ability to process a higher volume of online transactions

Issuer EMV processing considerations

Issuers face more challenges than the other entities in the EMV transaction processing flow. Not only do Issuers face the difficulty of simulating their various endpoints during testing, they must also ensure their EMV messages are properly formatted and contain the correct content, including managing the cryptogram. In addition, current card management systems and risk management systems must be evaluated and updated to accommodate the new chip cards and associated EMV processing.

Your organization will likely need to develop tests the address needs such as:

• Ensuring host correctly processes transactions regardless of the terminal’s capability to accept chip cards
• Ensuring EMV message is properly formatted and that its contents are valid
• Testing validation of the cryptogram sent in the request message, and ensuring Host Security Module (HSM) generates the correct cryptogram for the response
• Testing the management of the keys on the card and on the host
• Testing your ability to process Issuer scripts (that can potentially damage your test cards)