EMV is a payment method primarily designed to prevent counterfeit cards and card skimming through use of dynamic data and cryptography. The cryptogram that is generated provides the dynamic data used to validate that the transaction is unchanged and that it originated from a genuine card.
This section provides an introduction to EMV and its impact on applications directly integrated with the Elavon Fusebox transaction processing gateway.
The transaction types below are for card-present transactions.
|Authorization Only (Type 01)||Credit, full EMV. The transaction qualifier (API Field 0115) must equal 010. EMV supports the Forced/Voice Auth Only feature of this transaction type as a partial EMV.|
|Sale (Type 02)||Credit/Debit, full EMV. Recommended authorization transaction type for both credit and debit.|
|Prior Authorization (Type 07)||Credit-only. Changes an existing Auth Only (Type 01) to a Prior-Auth (Type 07) for settlement. Prior authorizations can also be performed on Forced / Voice Auth Only (Type 01) transactions. This is considered a partial EMV transaction type if the cardholder is present, otherwise use the token from the preceding Auth Only.|
|Return (Type 09)||Credit/Debit, partial EMV for credit, full EMV for debit. Debit transactions should follow the standard online PIN process.|
|Void Sale (Type 11)||Credit/Debit, partial EMV when the cardholder is present. Changes an existing Sale (Type 02) or Prior-Auth (Type 07) to a voided transaction. Usually it is not settled, but it may be included in a batch.|
|Void Return (Type 17)||Credit/Debit, partial EMV when the cardholder is present. It nullifies an existing Return (Type 09) transaction and changes the status of the return transaction to a voided transaction.|
|Full Reversals (Type 61)||Credit/Debit, partial EMV. Reverses the Authorization (Type 01) or Sale (Type 02) for the full amount. Attempted automatically with a Void Sale (11).|
Benefits of EMV
Transport Layer Security
In compliance with industry standards, all applications are required to support TLS 1.2 protocol as well as SHA-2 certificates in all transmissions to our host.
Counterfeit and Skimmed Cards
EMV provides offline and online mechanisms to protect against counterfeit and skimmed cards.
Offline - EMV uses either Static Data Authentication (SDA) or Dynamic Data Authentication (DDA).
DDA allows the EMV Kernel to authenticate that the chip is genuine. It uses unique data for every transaction, therefore, even if it is copied, it cannot be used offline.
SDA allows the EMV Kernel to authenticate that the chip is genuine. It can only be used to conduct an offline transaction, which is not allowed in the U.S.
Online - EMV provides authentication of the chip and the issuer.
The chip is authenticated with the Application Request Cryptogram (ARQC). This provides a dynamic online digital signature allowing the issuer to authenticate both the chip and the transaction data.
The Authorization Response Cryptogram (ARPC) provides a dynamic online digital signature that allows the chip to authenticate the response code returned by the issuer.
A man-in-the-middle attack intercepts the transaction data between the chip and the EMV kernel (offline), or between the various components in the transaction process (online).
Offline - Protection via Combined Data Authentication and Generate AC (CDA) process. This adds to the security of DDA with a cryptogram generated to secure the transaction data integrity between the chip and acceptance.
Online - Man-in-the-middle protection is provided by the combined ARQC/ARPC request and response cryptograms, protecting the integrity of both the response and request data.
Lost and Stolen Cards
EMV provides lost and stolen card protection via offline and online PIN for both credit and debit cards, based on the issuer card setup. Since the chip is the issuer’s representative in the card, it knows the PIN and can authenticate it offline. In the U.S., all debit cards require an online PIN as the cardholder verification method (CVM).
The chip conducts offline risk management by limiting the offline risk to an accumulated amount for a number of transactions. Once the threshold is met, the next transaction is forced to go online.