The purpose of this section is to provide a quick reference to the different contact and contactless EMV transaction flows. This section does not supersede the specifications maintained by EMVCo or the card brands, and may refer to those documents.
The purpose of EMV is to provide a payment system standard based on smart cards (also known as chip cards), with a number of benefits:
- Global interoperability for smart card based payments.
- Card counterfeiting is significantly more difficult than with magnetic stripe cards
- Devalues transaction data.
- In transaction environments, where allowed, the EMV chip can make offline authorization decisions on behalf of the issuer.
- The card can have embedded risk management features managed by the issuer (such as risk decision, offline PIN, etc.), thus reducing the impact of lost/stolen scenarios.
- The card can be dynamically updated or modified by the issuer during a transaction.
Offline and Online transactions
When it comes to transaction authorization, it is necessary to differentiate offline and online scenarios:
Offline authorization scenario
The terminal requests, in the First Generate AC, a Transaction Certificate (TC). The card approves the transaction based on settings defined by the issuer. The transaction was not sent online for authorization. This scenario is defined as an “offline transaction.”
An offline decline can be a result of either the First Generate AC (before an online authorization request), or Second Generate AC (after an online authorization request).
This scenario can occur in three cases:
- The terminal requests, in either the First or Second Generate AC, an offline approval from the card, but the card chooses to decline.
- The terminal may request an offline approval in the Second Generate AC if the terminal tried to go online for authorization but was unable to do so.
- The terminal requests, in the First Generate AC, an offline decline which is granted by the card. This is used in certain scenarios such as refunds, reversals, etc.
- The terminal requests the card to provide a cryptogram to go online for authorization but the chip rejects the request and declines offline.
- The terminal requests, in either the First or Second Generate AC, an offline approval from the card, but the card chooses to decline.
Online authorization scenario
Online authorization scenarios occur in the situations where the terminal requests the transaction go online to the issuer for approval (standard scenario in North America) or if the terminal requests an offline approval but is asked to go online by the card. Whatever is the trigger for seeking online authorization of the transaction, there are three possible outcomes:
The issuer approves the transaction online.
The issuer declines the transaction. This can happen for many reasons (insufficient funds, card compromised, suspected fraud, etc.).
Online approval declined by the card:
The issuer can grant authorization to the transaction online but the card chooses to decline the transaction. This can happen for many reasons (e.g: information received from the issuer is suspicious or suspected fraud, other risk management parameters, etc.).
The offline approval scenario is different from situations where the merchant chooses to assume an authorization has been approved by the issuer even though the authorization request has not been initiated or completed (e.g.: Stand-In, Store-and-Forward, or Deferred Transaction scenarios).
Full and Partial EMV transaction
This section reviews which step of the EMV transaction applies to full or partial transaction types.
Full EMV transaction:
Standard scenario for a purchase; all the steps of a standard EMV transaction flow are executed.
Partial EMV transaction:
Usually reserved for non-purchase scenarios, where the card is used as an authentication factor for the cardholder rather than a means of payment (e.g.: refund, reversal, etc.).
It is important to note, that regardless of whether the transaction is considered a full or partial EMV transaction, both transaction types result in chip data being sent in the authorization request.
The table below summarizes the steps executed as part of the above two transaction configurations:
|#||Transaction Step||Full EMV||Partial EMV|
|2||Read Application Data||Y||Y|
|3||Offline Data Authentication||Y||O|
|6||Terminal Risk Management||Y||N|
|7||Terminal Action Analysis||Y||Y|
|8||Card Action Analysis||Y||Y|
|9||EMV Online Processing||Y||N|
Step 3 (Partial EMV) - optional; execute to improve security of the transaction
Step 9 (Partial EMV) - The card is requested to provide an AAC in partial EMV, therefore the EMV transaction is complete prior to sending the transaction to the issuer
Contact EMV transaction flow
The EMV processing part of a payment transaction follows 11 specific steps.
Figure 12 EMV transaction steps
The first step of the transaction consists of selecting the application to be used for processing. As EMV uses multi-application capable chip cards, cards can host multiple applications on the same card, such as:
- Debit and Credit application on the same card;
- Multiple debit (or credit) applications with different risk parameters.
Combining debit and credit applications to a single account is highly unusual. Combo card issuance exists in Brazil and therefore may be encountered by NA-based customers when accepting payments from foreign cardholders. But, this type of issuance doesn’t happen outside of Brazil today, and is expressly prohibited for domestic issuance in some markets, like Canada.
Selection of the Application can be done in two different ways:
The terminal explicitly selects the AID (Application Identifier) by issuing multiple commands to the chip. The chip determines which applications supported by the terminal are also supported by the chip. The chip identifies a priority for each supported application, and the terminal chooses the highest mutually supported priority.
Figure 13 Application Selection – Explicit selection
The card provides a list of supported AIDs from the PSE (Payment System Environment), which the terminal uses to select the application used for the transaction. The terminal will select a mutually supported application from the list based on the priorities set by the card for each application supported.
Figure 14 Application Selection – Selection with PSE
Application Selection should be made using the PSE (method 2 above), as it streamlines transaction processing, by avoiding unnecessary selection commands of non-present applications, and is more future-proof.
Elavon recommends cardholder selection based on application name and merchant-preferred selection for the Application Selection.
Once a mutually supported application has been selected on the card, both card and terminal activate the chosen payment application to process the transaction.
Read Application Data
This step finds a mutually agreeable configuration – for both card and terminal – on how to perform the transaction.
The terminal issues a GET PROCESSING OPTIONS command to the card, providing the specific elements required by the application. In return, the card provides its processing capabilities (offline support, CVM supported, etc.) with a list of other elements required by the terminal.
These elements can contain, but are not restricted to:
- PAN Sequence Number
- Application Usage Control
- Application Effective Date
- Application Expiry Date
- Issuer Action Codes
- Issuer Public Key Certificate
Upon receiving this information, the terminal engages in the EMV Risk Management portion of the transaction (steps 3 to 6). The resulting decision determines if the transaction can be conducted offline or online.
Mod-10 verification is not recommended for online authorized transactions. For offline authorized transactions, Elavon recommends merchants to perform mod-10 check on credit products only (debit transactions cannot be performed offline).
Merchants may compare the PAN in tag 5A to the PAN in Track-2 equivalent data if the information is available (not applicable for P2PE implementations).
- 19-digit PAN number must be supported.
- When performing a transaction using a 19-digit PAN, the PAN is padded with an ‘F’ character in the final position. The ‘F’ character must not be printed on the receipt.
- PAN number read from the chip must not be compared to the PAN embossed/printed on the card, as the chip may contain multiple applications.
- Merchant Systems must not alter track-2 equivalent data.
EMV Risk Management
Offline Data Authentication
Offline Data Authentication is performed by the terminal to validate the authenticity of the chip card. This is executed using public key cryptography methods and digital signatures on the card. One of three possible Offline Data Authentication methods can be used: SDA, DDA, or CDA.
- Offline data authentication is an optional step for online-only terminals. However, Elavon strongly recommends performing this step.
- For clients in the United States and Puerto Rico supporting Offline Data Authentication, Elavon recommends supporting SDA, DDA and CDA.
- For Canadian clients supporting Offline Data Authentication, Elavon requires clients to support all three ODA methods (i.e. SDA, DDA and CDA).
- Merchant systems supporting CDA for contact transactions must support CDA in Mode-1.
The terminal kernel checks if there are any restrictions set by the issuer. This includes the expiry and effective date of the application, if the card can be processed domestically or internationally, and which transaction types the card can perform, such as cash or cashback. This step is similar to the Service Code check performed in the magnetic stripe transaction process.
Elavon recommends checking for application effective and expiration date.
The EMV kernel checks if the card application (AID) selected for the transaction is not yet effective or no longer effective (i.e. expired) by checking the Application Effective Date and Application Expiration Date (if present). The results of the corresponding check are saved in the TVR. Whether the transaction is declined or not depends on whether the acquirer has set the corresponding bits in the ‘Terminal Action Code - Denial.’’ The logic is applied to all card brands, but the different values of ‘Terminal Action Code – Denial’ can be defined per AID supported by the terminal.
The kernel identifies a commonly supported Cardholder Verification Method (CVM) based on a list of CVM preferences set by the issuer on the card, and the list supported by the kernel.
Cardholder Verification Methods presently defined in the EMV specification are:
- Offline PIN (encrypted and plaintext)
- Online PIN (encrypted)
- No CVM
Contactless transactions have an additional CVM available, CDCVM (Consumer Device CVM). In CDCVM, the cardholder authenticates themselves directly to the contactless payment instrument. Authentication could be through a PIN or various biometric options (i.e. fingerprint, etc.). Offline PIN is not supported for contactless transactions.
Terminal Risk Management
During this step in the EMV processing, merchant system-specific parameters (such as floor limit, random selection for online, and exception file check) set for the kernel are executed. This step is optional for an online only terminal. Terminal risk management must always be performed by offline-capable terminals.
- Elavon requires merchant systems to send all transactions online for authorization.
- The percentage for random transaction selection must be set at 99%.
- Elavon requires merchant systems not to use “merchants-forced transaction online,” TVR Byte-4 Bit-4, for sending transactions online, as this can make the transaction appear as suspected fraud to the issuer.
Terminal Action Analysis
After execution of the EMV Risk Management process (steps 3 to 6), the terminal can now make a proposition about how the transaction should be conducted, based on:
- The risk assessment conducted in the previous steps (results are stored in the TVR)
- The Terminal Action Codes
- The Issuer Action Codes
The terminal can propose to:
- Decline the transaction offline
- Approve the transaction offline
- Go online to obtain authorization
This proposition is then sent to the card using the First Generate AC command for decision.
We are using the term “proposition” rather than “decision” at this step of the transaction. The decision is always taken in conjunction with the issuer. Either the online (issuer host) or offline (card) instance of the issuer will have the final word on the transaction decision.
Card Action Analysis
Based on issuer-defined rules and limits (also known as the card risk management parameters), the card will respond with a verdict regarding the transaction outcome. Similar to the kernel, when the chip conducts its risk management, it will record the results in the Card Verification Results (CVR) field. The CVR is later passed to the terminal and then to the issuer indicating the chip’s analysis of the current transaction, as well as any previous transaction indications that have not been communicated to the issuer. Unlike the TVR, the CVR format is dependent on the chip’s application specification.
The chip can only respond with the same verdict or a more restrictive verdict.
For example, if the terminal asks the card to decline the transaction offline, the chip must respond with a decline cryptogram. However, if the terminal asks the card to approve the transaction offline, the chip can either agree, decide to go online, or decline the transaction.
Figure 16 Terminal proposition – Card decision
If the transaction is sent online for authorization (standard scenario in North America), the issuer host then performs its own set of verification steps before delivering a decision. The decision is based on the following:
- Whether the card is genuine (verification of the CAM via the cryptogram validation)
- The transaction data provided by the card and the terminal
- The Application Transaction Counter (ATC) value
- A set of financial rules related to the cardholder account (e.g: sufficient balance or credit limit)
At the end of this step, the issuer will send its decision back to the terminal in the form of:
- The ARC (Authorization Response Code), a 2 or 3 digit value defining the authorization disposition
- An Application Response Cryptogram (ARPC), to be sent back to the card
- (Optionally) Issuer Scripts, used to perform management actions on the card (e.g: PIN reset or modification, application block, card risk parameter update, etc.)
Issuer scripting is a mechanism that allows issuers to perform management actions on a smart card. These scripts are updates in the form of data values that are sent along with the issuer response in addition to Issuer Authentication Data (Tag ‘91’).
Examples of issuer scripts are:
- Resetting/changing the PIN
- Blocking a smart card
- Blocking and unblocking an application
- Modifying the number or amount of offline transactions allowed
Issuer scripts are not present in each transaction. The execution of this step is optional in a standard EMV transaction. If the issuer sends issuer scripts to be executed, the terminal must support their execution.
Clients must support issuer script processing if the transaction allows it. If the transaction does not allow it (Quick Chip & M/Chip Fast), the issuer script can be discarded.
Issuer scripts received from the acquiring host will contain a payload and a length. However, in the case of Visa, MasterCard and Discover, the length is calculated in an improper manner today; the length is calculated based on the number of characters in the payload as opposed to the number of bytes.
In order to transmit the correct length to the card, merchants shall ensure that the length calculation is performed as below.
Extract the first 2 ASCII characters to get the TAG (Either ‘71’ or ‘72’)
- Convert to the HEX representation
Extract the fifth character through the end of the string
- Convert to the HEX representation
- Calculate the length of the string in HEX
Build script string
- Add Tag in HEX
- Add calculated Length in HEX
- Add Script in HEX
Send string results
Re-computing the script length is not required for American Express. The issuer script length sent by the host in this case can be used as is.
Sending issuer script results to Elavon in authorization or clearing message is optional.
In this step, the terminal must pass the elements received from the issuer (ARC, cryptogram, etc.) to the card. The card then has the capability to issue a final verdict regarding the transaction execution (approve/decline).
APDU command summary
The following table summarizes the APDU commands used at each step of the EMV transaction.
|2||Read Application Data||GET PROCESSING OPTIONS|
|3||Offline Data Authentication||INTERNAL AUTHENTICATE|
|5||Cardholder Verification||GET CHALLENGE|
|6||Terminal Risk Management||GET DATA|
|7||Terminal Action Analysis||GENERATE AC|
|8||Card Action Analysis||NA|
|10||Issuer Script Processing||APPLICATION BLOCK/UNBLOCK|
Contactless transaction flow
Contactless transactions can be implemented using EMV, but some legacy implementations exist, such as MSD. For the purpose of this guide, we will focus on the contactless EMV implementation.
A contactless EMV transaction shares a number of characteristics with standard EMV contact transactions. In order to increase transaction speed, certain steps are not applicable. Although most of the features are similar, a number of specific risk management techniques are used for contactless.
Contactless terminal limits
Contactless terminal configurations include two limits specifically for contactless transactions:
Floor Limit – Transaction amounts above this limit must go online for authorization
CVM Limit – Transaction amounts above this limit requires a positive CVM (e.g. PIN, signature, etc)
As with contact transactions, offline approval is not supported for North America. The contactless floor limit must be set to 0.
Offline PIN CVM
Offline PIN is not supported by implementations when it comes to contactless. Do the following in order to avoid “double tap” scenarios and a slowdown in transaction processing speed:
- One “tap” to select the application and initiate processing
- Processing interruption and PIN entry on the terminal
- One “tap” to verify the PIN and complete the transaction
Mobile contactless use-cases define a specific CVM:
- ODCVM (On-Device CVM) for MasterCard
- CDCVM (Consumer Device CVM) for Visa.
When using this type of CVM, multiple tap scenarios are possible.
However, these scenarios are distinct from an offline PIN CVM as the CVM (PIN/biometric) value is entered on the Mobile/Consumer device rather than on a certified PIN-entry device.
Generic contactless flow
In this section, we will define the standard contactless transaction steps, as compared to the contact EMV transaction steps.
|#||Transaction Step||Contact EMV||Contactless EMV|
|2||Read Application Data||Y||Y|
|3||Offline Data Authentication||Y||Y|
|6||Terminal Risk Management||Y||Y|
|7||Terminal Action Analysis||Y||Y|
|8||Card Action Analysis||Y||Y|
- Step 1 (Contactless EMV) The execution of this step contains significant differences between contact and contactless
- Step 5 (Contactless EMV) - Generally avoided in favor of speed, unless above the CVM limit
- Step 9 (Contactless EMV) - Although this step is executed, the card is no longer in the field (i.e. communicating with the terminal)
- Step 11 (Contactless EMV) - Depends on brand implementation
Figure 17 Contactless transaction overview
Main differences from contact transaction flow
A number of checks are performed by the terminal in the pre-processing phase. As the limits are managed differently from a contact transaction (see Contactless terminal limits), the ‘Amount, Authorized’ must be known before the pre-conditions step as the transaction may exceed the contactless CVM transaction limit.
The unpredictable number must also be known before the pre-conditions step.
‘Amount, Authorized’ and ‘Unpredictable Number’ must be known before the Pre-Conditions Processing step.
The other configuration data elements processed during the Pre-Condition processing step must be retried in the terminal configuration per supported application (supported AID):
- Terminal Floor Limit
- Terminal Contactless Floor Limit
- Terminal CVM Required Limit
- Status Check Support Flag
- Zero Amount Allowed Flag
- Terminal Transaction Qualifiers (Visa only, see Card Transaction Qualifiers)
Once the configuration data elements have been retrieved, the terminal must then execute the following checks for each application supported:
- Are the limits exceeded?
- Is contactless allowed?
As a result of pre-processing, the terminal can then activate the contactless protocol and match its supported applications against the one supported by the card.
In this step, the terminal will:
- Activate the contactless interface
- Request the card to be presented
- Perform anti-collision protocol
The contactless flow is designed for speed (“tap-and-go”) and, for this purpose, is set to limit user interactions. The application selection step is executed differently from the application selection process explained for contact (see Select Application).
In a contactless application selection, the goal is to automatically select the application to be used for the upcoming transaction.
The application selection step is executed as follows:
The terminal sends a SELECT command to the card to retrieve the PPSE (Proximity Payment System Environment). PPSE is a predefined data element (2PAY.SYS.DDF01) present on the card. The PPSE command and format of the data element on the card is standardized and will not vary between brands.
The contactless card provides the PPSE returned in the SELECT response, containing the Application Priority Indicator for any applications supported.
The terminal matches the application list returned against its own list of supported applications.
- If only one application is mutually supported by the card and the terminal, this application is selected for processing without customer confirmation.
- If multiple applications are mutually supported, the terminal automatically selects the application with the highest Application Priority Indicator. This point differs from contact EMV processing.
- If no applications are mutually supported, the transaction is aborted. The message displayed may be different from a declined transaction and may encourage the cardholder to try using an alternate interface (e.g.: contact).
The appropriate kernel is then activated using the selected application identifier and application processing continues.
As opposed to contact transaction, explicit selection is not allowed (see Select Application). The Application Selection step must use PPSE.
If multiple contactless applications are mutually supported by the card and terminal, the terminal must automatically select the application with the highest Application Priority Indicator.
If the contactless transaction fails, the terminal may display a message encouraging to try an alternate interface to execute the transaction.
When the kernel processing has finished, the kernel indicates which additional services are required:
- Decline the transaction
- Require Cardholder Verification (Signature, Online PIN, No CVM)
- Switch to an alternate interface
- Restart the transaction
Brand specific flows
The implementation for Visa contactless, although inspired by EMV, is significantly different from a standard contactless EMV transaction. The number of commands exchanged between the card and the terminal are reduced to increase transaction speed.
In the Visa implementation, it means all elements are exchanged as part of the Read Application Data step.
Figure 18 Visa contactless transaction flow
Terminal Transactions Qualifiers
Terminal Transaction Qualifiers (Tag ‘9F66’) is a terminal data element indicating capabilities and transaction-specific requirements (e.g., online) of the terminal. It is requested by the card in the PDOL and used by the card to determine how to process the transaction.
Card Transaction Qualifiers
The TTQ (Terminal Transaction Qualifiers) is passed to the card as part of the PDOL data. The TTQ indicates which CVM the terminal supports and whether CVM is required. The card then makes a decision based on its own risk processing and informs the terminal which CVM method it should perform. This is done using a proprietary tag called Card Transaction Qualifiers (Tag ‘9F6C’). The CTQ is passed to the terminal in the GET PROCESSING OPTIONS command response.
The card can require that a CVM is executed even if the terminal did not require it.
- The terminal must support the Terminal Transaction Qualifiers (TTQ) and Card Transaction Qualifiers (CTQ) data elements defined by Visa as part of its contactless implementation.
- If the card indicates a Cardholder Verification Method must be used (as part of the CTQ), the terminal must execute the CVM indicated.
Offline Data Authentication
Visa allows for Offline Data Authentication using the proprietary fDDA (fast DDA) implementation.
There are a few significant differences with a standard EMV ODA implementation:
The fDDA signature is generated as part of the GET PROCESSING OPTIONS command and does not use the INTERNAL AUTHENTICATE command.
fDDA uses data from the PDOL in order to generate the signature and does not use a separate DDOL.
The fDDA signature is verified by the terminal and not sent online to the issuer.
In Visa qVSDC (Quick Visa Debit/Credit) implementation – also referred to as Visa EMV – three different Cryptogram Versions can be used: CVN 10,17, or 18. Based on the CVN (Cryptogram Version Number) used for the transaction, the data required in the PDOL will differ. The table below summarizes the minimum data elements required (minimum PDOL) to execute the Card Action Analysis and compute the Application Cryptogram:
|Data Element||CVN 17||CVN 10 or 18|
|Terminal Country Code||X|
MasterCard contactless EMV implementation is referred to as MasterCard Paypass M/Chip. The transaction flow is very similar to a standard transaction execution. However, there is only one Generate AC command executed as part of the transaction. Issuer Scripting is not supported.
Figure 19 MasterCard contactless transaction flow – overview
Offline Data Authentication
Only the CDA method is allowed for MasterCard PayPass M/Chip.
For contactless transactions only CDA must be supported. SDA or DDA are not supported for contactless transactions.
Introduction to Quick Chip and M/Chip Fast
In order to address concerns over transaction times in the U.S., the card brands announced an alternate implementation of EMV that uses a subset of the standard EMV features.
This implementation, known as Quick Chip (for Visa, Discover, and American Express) or M/Chip Fast (for MasterCard), allows the user to insert their card before the final amount of the transaction is known, and remove it earlier in the transaction process. For simplicity this is referred to as Faster EMV.
Standard EMV flow
Standard EMV implementation requires the final amount to be known before the transaction is executed, and the card to remain inserted throughout the transaction.
The steps of EMV execution, including the steps requiring cardholder interaction (application selection, amount confirmation, CVM) can only start once the final amount (tag ‘9f02’ - Amount, Authorized) is known.
The card can only be removed when:
- The authorization request has been completed online
- The TC has been generated
- (Optionally) Issuer scripts have been executed
Faster EMV flow
Faster EMV addresses the two restrictions above and allows the following process:
Figure 21 Quick Chip transaction execution
In this flow, the card can be inserted before the final amount is known, allowing some of the processing steps to be executed while the merchant system executes other actions of the sale transaction (e.g: scanning items)
The card is inserted.
An EMV transaction is initiated using a Placeholder Amount as the Amount, Authorized (Tag ‘9F02’). Note that this amount may not be equal to the final transaction amount. It is only used to execute the EMV transaction (i.e. verify ODA, perform risk management, verify CVM, etc.).
The terminal requests an ARQC in the First Generate AC command (request online authorization) based on the placeholder amount to which the card responds appropriately.
The terminal sends a Second Generate AC command with a response code ‘Z3’ (Unable to go online) and stores the ARQC from the First Generate AC command. It requests an AAC in the Second Generate AC command (i.e. transaction aborted).
The cardholder is prompted to remove their card.
Once the final amount of the transaction is known, the terminal then initiates an online authorization request with:
The ARQC collected from the card, based on the placeholder amount. Both the Application Cryptogram and the Amount, Authorized tag are based on this placeholder amount.
The real transaction amount is sent to the issuer in the financial message amount field (e.g. DE 4 in ISO-8583).
In effect, steps 3-6 are similar to a deferred authorization scenario.
Cashback is possible when using Faster EMV. However, the cashback amount needs to be known before the transaction is initiated (while the real transaction amount may not).
In a cashback scenario the EMV processing is then initiated with:
- The Placeholder Amount in tag ‘9f02.’
- The real cashback amount in tag ‘9f03’ (Amount, Additional).
The authorization transaction will contain (based on an ISO-8583 message scenario):
- DE 4
- Actual amount of the transaction including the cashback amount
- DE 55
- Placeholder Amount in tag ‘9f02’
- Cashback amount in tag ‘9f03’
Key differences with Classic EMV
This implementation allows the cardholder to retrieve the card faster but with certain consequences:
- The cardholder cannot confirm the real transaction amount before the transaction is executed. However, the final amount can be displayed at the end of the transaction.
- The Authorization request will contain two different amounts:
- The placeholder amount in DE 55 – Tag 9f02
- The real transaction amount in DE 4
- Card risk management, including CVM processing, is based on the placeholder amount, which can be different from the actual amount (e.g. placeholder amount can be under the CVM limit, while actual amount will be above).
- Card risk management based on the issuer data (ARPC validation, second Card Action Analysis) cannot be executed.
- Issuer scripting cannot be executed.
Placeholder amount is at discretion of the Merchant. However, it is highly recommended to use the average high ticket value for the placeholder amount.
POS solutions that implement both Classic EMV and Faster EMV should make the switch between two modes configurable.
- POS Implementations using both standard EMV and Faster EMV transaction flows must execute two distinct certifications.
- Implementations using both standard EMV and Faster EMV transaction flows must be certified as follows:
- If the client is already certified for full EMV, supporting Faster EMV is achieved through a shorter certification process restricted to specific Faster EMV test cases subset (regressions).
- If the client is already certified for Faster EMV and wants to support Full EMV, a full certification process must be executed.
- If the client wants to support both Full EMV and Faster EMV, two distinct certification processes are executed; one for Full EMV and one for Faster EMV.
- An online authorization must be performed for all Faster EMV transactions.
- If the final amount is not known, the merchant system must use a placeholder amount greater than 0.
- All CVM must be supported in Faster EMV.
- If PIN is selected for CVM processing, and if the terminal is using a placeholder amount, the terminal must not display the placeholder amount to the cardholder.
- If the card returns an AAC on the First Generate AC, the transaction must be declined.
- Once the EMV processing is completed, the terminal must prompt the user to remove their card.
- Once the final amount is known, it must be populated in the transaction amount field of the authorization request (e.g. DE 4 in ISO-8583).
- The terminal must use the Authorization Response Code in the online response to determine the outcome of the transaction.
- For Faster EMV implementations, the terminal must discard the Issuer Authentication Data and Issuer Scripts included in the issuer response message.
- The terminal must use the EMV data from the First Generate AC in the clearing data.