Implementation Considerations

Your implementation must address the following business criteria specific to the acceptance of EMV cards:

• An EMV-certified PIN pad terminal capable of accepting EMV chip-enabled cards.
• A payment application that integrates with the PIN pad EMV certified kernel and Fusebox. These will be Level 3 EMV certified. Neither the payment application nor Fusebox can be EMV certified to a TPP alone.
• Ability to update EMV keys and EMV parameters once the PIN pad terminal is on site.
• Ability to update the PIN pad terminal’s applications once on site. Ex.: new EMV kernel, new terminal libraries or OS updates, new payment application.

Implementation Considerations include:

EMV Use Cases

While EMVCoopen_in_newLink opens new window has defined standards for processing EMV transactions, there are slight differences between the card brands, contact vs contactless EMV, and industry considerations. These differences must be supported in the payment application and are tested in the brand Level 3 EMV certification process.

Additionally, “contactless” can refer to either an RFID-enabled EMV ICC chip card or a mobile wallet application. These use cases address some of these differences.

TIP in the EMV Flow

One of the basic changes to the EMV vs the magnetic stripe flow is that the total amount of the transaction must be known early in the process.

Discussion with the TPP regarding where TIP may occur in the transaction life cycle is recommended before completion of the payment application design. It is important to note that only supporting a “No PIN” CVM may move the Lost / Stolen liability to the merchant based on brand requirements.

Cashback in the EMV Transaction Flow

With EMV, cashback is no longer solely a debit or gift card option since an issuer may add that feature to a credit card.

No Debit / Credit Prompting and Application Choice Prompting

An EMV ICC chip may support more than one payment application. If the ‘Application Selection’ process returns multiple supported applications, the payment application can either display the list of applications for cardholder selection or perform candidate list manipulation to allow merchant-driven choice.

United States EMV Debit Network Options

Check with your TPP for information about which debit networks they support for EMV at the time of your integration project.

There is agreement on a Common U.S. Debit Application Identifier (AID) and both Visa and MasterCard have AIDs to support those networks. A chip can be set up to support more than one AID.

The Visa and MasterCard debit AIDs are as follows:

• Visa (e.g., Visa Credit or Visa Debit): A000000003 1010
• Visa Electron: A000000003 2010
• Visa Interlink: A000000003 3010
• PLUS: A000000003 8010
• Visa and MasterCard US Common Debit: A000000098 0840
• Maestro (for MasterCard PIN Debit): A000000004 2203

United States Debit EMV Cardholder Verification Methods

Check with your TPP prior to designing your payment application to ensure which of the following elements are supported for U.S. debit.

• Offline PIN - Not supported for debit in the U.S. The cardholder-entered PIN is sent either in plain text or encrypted to be verified by the ICC chip (Offline Issuer).
• Online PIN - The primary customer verification method (CVM) used in single message debit transactions. The cardholder-entered PIN is encrypted and sent online to be verified by the issuer.
• Signature - Some brands/schemes may support signature as the CVM for transactions under $50. Check with your TPP to ensure they support this method during your design phase.
• No CVM Required - An option for low-value transactions. Check with your TPP to ensure they support this method during your design phase.
• Fail CVM Processing - A catch-all option to ensure CVM processing is deemed to have failed.

EMV Parameter Selectable Kernel Configuration Alternatives

Every EMV ICC chip contains a list of approved CVM methods the issuer wants to support. The EMV certified PIN pad terminal also has a list of CVM methods the TPP wishes to support. In most implementations, the EMV certified PIN pad terminals support all CVMs, so they can support all EMV cards.

Use Case Examples

Use Case - No PIN CVM List Option Example

For restaurants that want the server to present the check to the cardholder, the cardholder may enter the tip amount and provide their card. This is possible if the PIN is not an allowable CVM. Once the server picks up the check with the tip and card, they can run the transaction at the POS in another location and bring the receipt back to obtain the cardholder signature. This is the recommended approach for this particular environment.

The payment application designers should discuss their EMV Kernel configuration options and the EMV certification impacts with their TPP prior to choosing to support this option.

Use Case - No CVM Option Example

This option should only be considered for those merchants with low value transactions such as a quick serve restaurant. The payment application should discuss this configuration option and the EMV certification impacts with their TPP prior to designing a solution to support it.

End of Transaction Flow Considerations

There are two options available for a payment application after it has received either the TC cryptogram from the 2nd Generate command or the response from Fusebox on the reversal for an AAC cryptogram.

• Option 1:

  1. Send the completed response transaction to the POS.
  2. Send the command(s) to the PIN pad to display the transaction status message and prompt the cardholder to retrieve their card from the chip reader.

• Option 2:

  1. Send the command(s) to the PIN pad to display the transaction status message and prompt the cardholder to retrieve their card from the chip reader.
  2. Send the completed response transaction to the POS for receipt printing.

  This option can be even more secure by not sending the response to the POS for receipt printing until the PIN pad detects the card has been removed.

ICC Chip Decline of an Online Approved Transaction

We strongly recommend the payment application perform a reversal prior to returning the response message to the POS and printing the receipts. If using Simplify, it will perform this function. If the payment application sends the decline back to the POS and relies on the POS to perform the reversal, the POS is now in scope to be included as a component of the Level 3 EMV certification. Therefore, any changes to the POS system could require a recertification effort.

Card Removed Early

The contact EMV protocol requires the card remain in the card reader slot until the transaction is completed. If the card is removed before the payment application prompt, the payment application must reverse the transaction and start again.

Communication Failure / Time-Out Processing

All debit transactions are required to go online or be declined. There are two methods to continue a transaction if a communication failure with the issuing host occurs: EMV Offline Authorization and Merchant Stand-In.

EMV Offline Authorization

The following details how to support EMV Offline Authorizations for those TPPs and card brands that support it.

EMV Parameter Settings:

• For each card brand, the EMV Floor Limit must be set to a value above zero and less than or equal to the card brand’s EMV Floor Limit.

• EMV Random Selection values must be set to randomly go online. These are the recommended values, but check with your TPP EMV parameters as they may differ:

• Target Percentage to be used for Random Selection - 99%.

• Maximum Target Percentage to be used for Biased Random Selection – 99%.

• Threshold Value for Biased Random Selection = 0.

EMV Offline Transaction steps

1. Attempt to send the transaction online.
2. If a timeout or communication failure to the issuer response is returned, perform the 2^nd Generate AC and request a TC cryptogram.
3. Set the Authorization Response Code, Tag 8A, to ‘Y1’, if the chip approves it. The card’s final decision is reflected in the Cryptogram Information Data and not in the Authorization Response Code.
4. The POS sends the transaction to Fusebox prior to settlement as it would a Voice Authorized transaction.

The payment application should check if the TPP supports any form of EMV Offline Authorization.

Merchant Stand-In
If Merchant Stand-in is supported by the TPP and the merchant is requesting it, check the rules of the merchant’s TPP.

Fallback
When the payment application receives an error code from the EMV kernel, the payment application may “fallback” to normal magstripe processing rules. A fallback allows the transaction to continue in a less secure manner, bypassing the security features of EMV, but not shifting liability to the merchant as long as it is done properly.

Lodging Flow Considerations

Lodging transactions generally follow the flow below:

1. An initial authorization with the reservation (card not present).
2. An authorization at check-in (card present).
3. An incremental authorization if the cardholder extends their stay (card not present).
4. A prior authorization when the cardholder has checked out (card not present).
5. Settlement.

The Card Account field (0003) should contain either a manually entered PAN or the Fusebox token for card not present transactions.

• previousEMV
• nextCertification