PCI Watch

Tracking changes across the Payment Card Industry

Recommendations for EMV® Processing for Industry-Specific Transaction Types

v3.0
Contact

EMV® Best Practices Document Recommendations for EMV Processing for Industry-Specific Transaction Types Version 3 Auguest 2016

countries.

Legal Notice

The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications.

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 Table of Contents Revision Summary 5 1 Introduction 6 2 General Considerations for Chip 6 2.1 EMV Transactions 6 2.2 Non-Payment Transactions using EMV functionality 7 2.3 Dual/Single-Messaging and Host/Terminal-Capture 8 3 Basic Transaction Processes 9 3.1 Purchase 9 3.1.1 Authorisation 9 3.2 Pre-Authorisation 9 3.3 Status Check 9 3.4 Account Verification 10 3.5 Incremental Authorisation 10 3.6 Sale Completion 10 3.7 Reversals 11 3.7.1 Partial Reversals 11 3.8 Refund Transactions 11 3.9 Cancellations 12 3.10 Referrals 12 4 EMV Transactions in Specific Industries 13 4.1 Gratuities 13 4.2 Hotels and Vehicle Rental 13 4.2.1 Reservation 13 4.2.2 No-Shows 13 4.2.3 Check-In 13 4.2.4 Higher than Estimated Spending 14 4.2.5 Check Out 14 4.2.6 Additional Charge after Check-Out 14 4.3 Fuel/Petrol Dispense 15 4.3.1 Fuel Dispensing Initiation 15 4.3.2 Fuel Dispensing Complete 15 5 Other Processing Considerations 15

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types 5.1 Acquirer Truncation (Alternate Host Authorisation, Acquirer Stand-In) 5.2 Deferred Authorisation 5.3 Premature Card Removal 5.4 Purchase with Cashback 5.4.1 Offered and accepted before dip/tap 5.4.2 Offered and accepted during/after dip/tap 5.5 POS Cash Advance 5.6 Offline PIN Management 5.7 Online PIN Retries 5.8 Categories of Transactions that Require Authorisation 5.9 Dynamic Currency Conversion 5.9.1 Offer During Transaction 5.9.2 After Last Command 6 Payment Tokenisation 6.1 Type of Transactions 6.2 Token Domain Restriction Controls 6.3 Merchant-Initiated Transactions 6.3.1 Standing Instruction 6.3.2 Re-Authorisation 6.3.3 Re-Submission 6.4 Payment Token Transactions Annex A – AUC and CVM Conditions A.1 EMV Payment Transactions A.2 Non-Payment Transactions using EMV Functionality

/ 24 15 16 16 16 17 17 18 18 18 18 18 19 19 20 20 20 20 21 21 21 21 23 23 24

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types Revision Summary

/ 24 This new version is produced from a thorough review on the previous version Recommendations for EMV Processing for Industry-Specific Transaction Types V2.0 to ensure every process meets today’s practice in different markets. This section is an outline of major functional and structural changes.  Removed independent Card Not Present related sections including Purchase – Card Not Present and Sale Completion – Card Not Present. Corresponding processes were added into transaction descriptions where necessary.  Removed original Section ‘Non-EMV Transactions using EMV functions’ and renamed Non-EMV transactions to Non-Payment transactions.  Removed original Section ‘Mobile Top-up’.  Added Section ‘Account Verification’ in Section 3 ‘Basic Transaction Process’  Added Subsection ‘Partial Reversals’ in Section 3.8 ‘Reversal’  Added Section ‘POS Cash Advance’ in Section 5 ‘Other Processing Considerations’  Added Section 6 ‘Payment Tokenisation’  Updated ‘Gratuities’ with current practical solutions and moved it from Section 5 ‘Other Processing Considerations’ to Section 3 ‘Basic Transaction Processes’  Updated ‘Dynamic Currency Conversion’ with current practical solutions and moved it from Section 5 ‘Non-EMV transactions’(which has been deleted in this version) to the new Section 5 ‘Other Processing Considerations’  Updated ‘Purchase with Cashback’ with current practical solutions and moved it from Section 3 ‘Basic Transaction Processes’ to Section 5 ‘Other Processing Considerations’  Updated ‘Dual/Single-Messaging and Host/Terminal-Capture’ and moved it from Section 5 ‘Other Processing Considerations’ to Section 2.3  Recommendations for Contactless transactions added where necessary.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 1

Introduction

This document describes a recommended approach to handling certain types of EMV-enabled transactions and environments including integrated POS and stand alone terminals. It is intended solely as a guideline and should be used in conjunction with the current EMV Books 1 to 4 and EMV Contactless Books A to D. The document describes “best practice” implementations in certain environments and for certain types of transactions. Only those areas impacted by chip technology are described. Individual markets may implement alternative approaches and may mandate particular processing in that market. The intended audience is vendors and financial institutions. The implementations described are intended to be applicable both in markets where an existing EMV infrastructure is already in place, as well as markets that are planning an EMV migration. 2 General Considerations for Chip While chip may enable new services with new cardholder and merchant interfaces, existing transaction types should flow in a familiar way. However, in some cases, change is unavoidable such as the display of a Cardholder Application Selection menu (which only applies to a multi-application chip transaction) or introduction of a new Cardholder Verification Method such as Offline PIN. If a Card Not Present transaction, such as Hotel Guarantee, is completed using a card with a chip, the chip functionality is irrelevant to the transaction, and the transaction is still considered Card Not Present. Transactions where either the card or the terminal has not completed EMV processing (by generating an Application Cryptogram (AC)) are not considered as EMV transactions. This would include any transaction where data such as a PAN and expiry date are extracted from the chip and used to complete the transaction but the full transaction flow was not completed. These transactions are covered below (see Non-Payment Transactions using EMV functionality). The transaction types listed throughout this document are typical of those found in many markets. Other transaction types may exist in particular markets and similar functions may be known by other names. The principles described in this document can be used to modify those market-specific practices to best leverage EMV support.

2.1 EMV Transactions EMV transactions directly result in the purchase of goods or services and/or in the disbursement of cash. EMV transactions will execute all mandatory functions defined in the EMV specifications and may execute optional EMV functions. Approved EMV Transactions should result in generation of a Transaction Certificate (TC) or the generation of an Authorisation Request Cryptogram (ARQC) and issuer authorisation approval. Note that single-message and host-capture systems will pass the Authorisation Request Cryptogram (ARQC) rather than the TC in the clearing file.1 1 Generally, the TC will be discarded. Please see “Dual/Single Messaging and Host/Terminal Capture”

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 As a general best practice, where possible and where known, the final amount, whether for goods, services, or cash disbursement, should be displayed to the Cardholder for confirmation prior to or as part of the cardholder verification process. For contact transactions, these displays should correspond to the EMV specifications Book 4 Section 6.5.1 “Amount Entry and Management” and Book 4 Section 11.2 “Standard Messages.”. For contactless transactions, these displays should correspond to the EMV Contactless Book A Section 9 “User Interface Recommendations”.

2.2 Non-Payment Transactions using EMV functionality Non-Payment transactions using EMV functionality refer to transactions commonly employed to support the retail or cash disbursement environment but do not directly result in the purchase of goods or services nor in the disbursement of cash. EMV functions that extract information or request identification or authentication may be used to complete these Non-Payment transactions. EMV functions can be used for the following purposes:  Information: In order to obtain information, a device can use Application Selection, Initiate Application Processing, and Read Application Data.  Verification: In order to verify the identity of the Cardholder, the device can use Cardholder Verification methods as defined in the CVM List, or other data objects used by some contactless implementations (Cardholder Verification).  Authentication: In order to check the authenticity of the payment application, the device can use Offline Data Authentication as part of offline processing, and/or may allow the Issuer to validate the payment application using Card Authentication as part of online processing.  Card Management: Issuer Script Processing may be used for contact card management such as to update offline PINs etc. Some contactless kernels also support issuer scripts, as defined in the respective EMV Contactless Books C-x. In contact transactions, if a second cryptogram is required, Non-Payment transactions should be completed using an AAC where this is needed. The only exceptions to this are PIN change and PIN unblock transactions which may result in a TC, depending on payment system requirements. Note that an AAC generated for a Non-Payment transaction simply indicates completion and does not indicate transaction decline. EMV functions should be executed in the same order as for EMV transactions, that is, Non-Payment transactions using EMV functionality should follow the EMV transaction flow. See “AUC and CVM Conditions” in Annex A to determine appropriate CVM conditions and processing restrictions for common Non-Payment transactions using EMV functionality.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 2.3 Dual/Single-Messaging and Host/Terminal-Capture In “Dual-Message” processing, the authorisation occurs at the time of the Purchase or Cash Advance transaction using one message, and the transaction is “settled”2 later using another message. These clearing messages are usually gathered into a batch for POS devices. The batch is then “settled” with the Acquiring host as part of end-of-day (or end-of-cycle) processing. Non-batched systems may simply submit a series of clearing advices, based on their transaction logs, prior to end-of-day (or end-of-cycle). If the clearing message is automatically generated from the authorisation request and response, the authorisation and clearing message together are considered one transaction (for example, a “Purchase”). If the clearing message is changed in some way, then the messages are considered a separate “Authorisation” and “Sale Completion”. A “Single-Message” transaction occurs in a single message format that allows Purchase transactions to be completely settled from an authorisation request. Terminal-capture and host-capture systems usually exist in the context of dual-message processing, since single message transactions do not require any further clearing. 3 Terminal-capture systems combine data from the authorisation response with the data from the authorisation request to create the clearing message. In a host-capture system, the host retains a copy of the authorisation request coming from the terminal. The host uses the data, along with the authorisation response data, to create the clearing message. To Acceptance Devices using host-capture, transactions appear to be single- message, since the Acquirer host is responsible for generating the clearing message. Single-message and host-capture transactions will contain an ARQC in the clearing/financial message for online approved transactions, as will any online-approved contactless transactions. Single-message and host capture systems will need a means for the terminal to upload TCs to the host for offline approved transactions. For contact chip or offline contactless transactions terminal-capture transactions will contain a TC in the final message. For most ATM transactions, whether single or dual-message, the clearing/financial message will contain the ARQC, and not the TC. In most dual-message ATM implementations, the acquiring host captures the authorisation response from the Issuer or its agent to create the clearing message and does not have access to the final TC (much like host-capture POS). Devices operating in a single-message or host-capture environment should ensure a TC is generated for approved contact transactions. Although not needed for clearing, generating a TC ensures cards will not request unnecessary online approvals on subsequent transactions. Generally the TC will be discarded in single-message or host-capture environments. However, some markets may require retention of the TC and will define the appropriate advice messages needed for transmission of the TC. In single-message and host-capture systems it is important that transactions declined by the card after an authorisation approval have been received are advised to the host system. All of the transaction types described in this document can be implemented on single- and dual-message systems, and on terminal- and host-capture systems. 2 “Settlement”, from a Point-of-Transaction perspective, refers to device-to-Acquirer settlement. From a processing perspective, the Acquirer will transform these messages into “clearing” transactions. 3 “Messages” here refers to the components of the transaction needed for authorisation and clearing. Audit, balancing records, and informational advices are not being considered.

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 3 Basic Transaction Processes This section covers basic transaction processes applicable to a number of industry sectors.

3.1 Purchase A Purchase (or Sale) is the act between a cardholder and a merchant where goods and/or services are exchanged for monetary value. [Alternate Names]: Sale 3.1.1 Authorisation This documentation targets online Authorisation processing which is a process where an Issuer or its agent approves a transaction with a final transaction amount. Authorisations take place via an online and realtime connection to either the Issuer or its agent. The terminal / card will have completed the contact or contactless transaction flow to the point where an Application Cryptogram(AC) has been received, and the online request message (if generated) should contain all the appropriate chip data elements to enable online authentication.

3.2 Pre-Authorisation When the amount is not known, then a Pre-authorisation is performed for an estimated amount. The ‘estimated amount’ depends on the rules of payment systems and merchant type. Pre-authorisation will take place via online connection to the Issuer or its agent. The terminal / card will have completed the contact or contactless transaction flow to the point where an authorisation cryptogram has been received, and the online request message should contain all the appropriate chip data elements to enable online authentication. The transaction amount of the Sale Completion will reflect the final transaction amount. Incremental Authorisation may be submitted if the original amount exceeds the ‘estimated amount’. [Alternate Names]: Authorisation, Authorisation – Only 3.3 Status Check A Status Check is used to validate the authenticity of the card used to make a reservation or in advance of delivery of goods or services, or pre-authorisation. A Status Check is an online authorisation for a nominal amount, usually a single major unit of currency. All EMV functions have to be performed. If a Status Check is performed, the amount of any clearing message reflects the actual amount of purchase. [Alternate Name]: Card Verify

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 3.4 Account Verification An Account Verification is an online transaction used to ensure that a card used to pay for services in advance of delivery or to make a reservation is genuine and that the account is in good order. Account Verifications do not provide authorisation protection. [Alternate Name]: Account Number Verification 3.5 Incremental Authorisation An Incremental Authorisation is an additional authorisation when the amount exceeds the original authorisation amount. Where the final amount may exceed the amount of the pre-authorisation, a further Incremental Authorisation may be obtained. The Incremental Authorisation will be for the difference between the original pre-authorisation and the actual or estimated final amount. A merchant may process as many incremental authorisations as are necessary Note: Market practice or payment system rules may allow variances above the pre-authorised amount for specific transaction scenarios. Incremental Authorisations are usually ”Manual” or “Key Entered” and are not EMV transactions. The original chip data obtained during authorisation should not be resubmitted during incremental authorisations. No chip data (except the PAN and expiry date) nor the full track 2 data should be stored or used for this purpose. Merchants can store the card’s PAN and expiry date in order to perform incremental authorisations. [Alternate Names]: Supplemental Authorisation, Top-up Authorisation 3.6 Sale Completion A Sale Completion is the communication of the final amount of a transaction in case the original amount is changed. For example, it is often used after a pre-authorised transaction, where the cardholder and card are no longer present. The final transaction amount may differ from the pre-authorised amount, usually within a range defined by the market. The sales completion is presented as a clearing submission or advice. Where any significant amount of time passes between the pre-authorisation, and submission of the clearing, an online, real-time reversal or correction to the pre-authorised amount will likely be required. The retained chip data elements from the associated Pre-Authorisation transaction including all fields needed to validate the cryptogram, should be populated into the clearing message, if used, where it is possible. [Alternate Names]: Post, Post Authorisation, Authorisation Completion, Pre-Authorisation Completion, Clearing Transaction, Settlement Transaction

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 3.7 Reversals A Reversal is sent to the Acquirer and on to the Issuer to notify the Issuer that the previous authorisation response was not delivered to the Acceptance Device (“System Reversal”) or has been annulled by the Acceptance Device. Reversals are a function of the transaction network or of the device application and do not require interaction with the card for generation of the Reversal message itself. Reversals typically do not contain chip data, with the possible exception of a decline arising from an Issuer Authentication failure. Individual payment systems may request additional data as a means to assist the Issuer in resolving these failures. If the Acceptance Device generates a reversal (e.g. because it detects the connection to the Acquirer Host has been lost or has timed-out because no authorisation response has been received) and an ARQC had been requested, then the terminal completes the transaction according to the EMV specification.

3.7.1 Partial Reversals A Partial Reversal is usually supported by unattended cash dispensing devices (ATMs) to ensure that accounts are properly debited when partial dispenses (“misdispenses”) of cash occur. Partial Reversals may also be used to adjust the unused portion of a POS authorisation, typically when the original authorisation was an estimate or the entire amount of the approved purchase could not be delivered or dispensed (i.e. fuel dispensing). Partial Reversals need not contain chip data. The original transaction will contain the requested amount and the chip data (including ARQC), while the Partial Reversal will contain the adjusted amount (and no chip data).

3.8 Refund Transactions A Refund is where the cardholder returns goods to a merchant and is credited with their value. Full or partial refunds of the original transaction are both possible. A Refund consists of a clearing message only4. The recommended method for performing a chip refund is to start a chip transaction and follow the normal EMV transaction flow in order to obtain the “Track 2 Equivalent Data” field from the chip. If this field is not present on the chip then the terminal should obtain the contents of the “PAN” and “Expiry Date” fields instead. Once the required data (either track 2 data or PAN and expiry date) is obtained, the terminal should then stop the contact chip transaction flow by asking the chip for an AAC (decline cryptogram) at the 1st GENERATE AC stage of the transaction. Once the terminal has read the track 2 information (or PAN and expiry date) from the chip, the subsequent decision of the chip to approve or decline the transaction is not relevant. Therefore, although the recommendation is for the terminal to request an AAC for a contact transaction, merchant systems should be able to process the refund irrespective of the type of 4 In single-message and online-only host-capture environments, the Refund transaction may be sent online to the acquirer.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 cryptogram produced by the card. The decision to approve or decline the refund should be made by the Acquirer or merchant regardless of the type of cryptogram generated. If an attempted chip refund fails,(for example if the chip cannot be read or chip technology fails at some point in the transaction) the merchant should re-initiate the refund transaction either by using the magnetic stripe or by using PAN Key Entry. [Alternate Names]: Return, Credit 3.9 Cancellations A Cancellation occurs when a Purchase or Sale Completion is aborted either during processing, or after processing. In a dual-message environment Cancellation can only occur before the transaction is “cleared” to the Acquirer. There are a number of reasons why cancellation may occur, such as an error in the amount entered by the merchant which the merchant may seek to correct by pressing a cancel button on the device. In all cases, initiation of a Cancellation should result in the cessation of processing and deletion of any data elements. If the transaction has not reached the point where an ARQC has been requested, the card can simply be powered off. If an ARQC has been requested and the transaction has been routed online, then cancellation processing should also generate an authorisation Reversal for the full amount. The transaction should simply be removed from the clearing batch or marked ‘void’. If the device has received a TC or AAC from the card, the transaction is completed and can now be cancelled (removed from the batch or marked as void). It is recommended that the device produce a receipt for the cardholder showing that the original transaction has been cancelled. [Alternate Name]: Void 3.10 Referrals A Referral is intended as a fraud control tool for Issuers to use when more information is needed to verify the identity of the cardholder or the validity of the card prior to approving a transaction. A Referral is not a “transaction”; it is an exception process for Purchase. In contact transactions, when a referral authorisation response is received from the card issuer, the terminal should request an AAC from the card at the second GENERATE AC request. Generation of an AAC merely completes the EMV transaction flow so that the referral procedure can take place. The type of cryptogram produced by the card should be disregarded by the terminal as any subsequent approval of the transaction is dependent on the outcome of the referral process. Depending on the market’s implementation, the referral process will most likely result in a completely new transaction taking place, once the Issuer has lifted the authorisation block. [Alternate Names]: Call for Authorisation, Voice Authorisation, Call-Me, Call Center

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types 4 EMV Transactions in Specific Industries

/ 24 4.1 Gratuities Market requirements will determine whether gratuities are included in the authorisation amount. In some markets, it is assumed that the gratuity will only be added to the clearing amount, and may occur outside of EMV processing. The data last presented to the card must be submitted as the chip data in the clearing record. In other markets, any gratuity may be added to the authorisation amount before the EMV transaction starts. This will ensure that the final billing amount is both presented to the card during the transaction and displayed to the cardholder at the time of PIN entry (if required).

4.2 Hotels and Vehicle Rental 4.2.1 Reservation The reservation process may require card details to be captured to guarantee a reservation. This process will not normally involve the card being present or the chip being read. A Card Not Present transaction should be performed. If the card is present, then a pre-authorisation is performed.

4.2.2 No-Shows Charges for guaranteed reservations (“no-shows”) should not be processed as chip transactions unless an EMV transaction has been performed at the time of reservation.

4.2.3 Check-In Recommended Process: Pre-Authorisation Pre-Authorisation is completed at Check-In to check that the card and cardholder are genuine and, according to the appropriate payment system rules, guarantee funds before the final transaction amount is known. Acquirers/merchants will determine an appropriate estimated amount to be authorised, based on market requirements. Because Check-In may use estimated amounts that may be considerably larger than final Check-Out amounts, it is recommended that the estimated amount should be displayed before cardholder verification is performed to avoid cardholder confusion. The estimated transaction amount is the amount presented to the chip card. If online authorisation is required, it is also the amount sent online for authorisation.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 4.2.4 Higher than Estimated Spending Recommended Process: Incremental Authorisation If the estimated amount used for pre-authorisation is no longer adequate to cover the estimated final bill, an incremental authorisation should be performed. The card does not need to be present, and the authorisations should not include chip data.

4.2.5 Check Out 4.2.5.1 Express Check-Out Recommended Process: Sale Completion Transactions It is not necessary to perform a full EMV transaction once the final transaction amount is known. A Sale Completion is generated for the final billing amount and, if chip data is required for clearing, then the chip data from the original Pre-Authorisation should be included.

4.2.5.2 Card Present - Check-Out Recommended Process: Sale Completion Recommended Process: Reversals & Purchase Either of the following two methods for card present Check-Out are acceptable:  A Sales Completion is generated for the final billing amount and, if possible, the chip data from the original Pre-Authorisation should be included (this is the same as Express Check-Out)  If the market supports reversals and chip data is required in clearing, but the chip data from the Pre-Authorisation cannot be retrieved, the recommended method is:

  • The merchant reverses the original Pre-Authorisation and any Incremental Authorisations
  • The merchant performs a full EMV transaction (Purchase) for the final billing amount, presenting the data from this transaction in the clearing message. In either case, the final total amount should be displayed to the cardholder.

4.2.6 Additional Charge after Check-Out Any additional charges identified after Check-Out should be processed as separate card not present transactions. The chip data from the Pre-Authorisation should not be submitted in this clearing record. [Alternate Names]: Top up/Additional Expense, Signature on file

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 4.3 Fuel/Petrol Dispense For chip transactions in an unattended petrol environment, it is recommended that either a Status Check transaction, or a Pre-Authorisation transaction for the maximum transaction amount, be performed before fuel is dispensed.

4.3.1 Fuel Dispensing Initiation Recommended Process: Pre-Authorisation If a merchant is not using Status Check, then it is best practice to display the maximum amount that may be dispensed. If a cardholder verification is required, then the amount should be displayed in advance. The merchant may optionally let the cardholder choose a lower maximum amount for their specific transaction. The value confirmed by the cardholder should be the same as the amount presented to the chip card and sent online for authorisation. An alternative is to display no amount. The maximum transaction amount should be presented to the chip card and sent online for authorisation.

4.3.2 Fuel Dispensing Complete Recommended Process: Sale Completion When the transaction is completed (that is, fuel dispensing is complete), the final transaction amount is known. If the final amount is less than the Pre-Authorised amount, then depending on market allowance, a partial reversal of the difference may be sent online to ensure the cardholder’s available balance is correctly balanced. A clearing record for the final amount should be submitted containing the chip data (where required) from the Pre-Authorisation. In single message systems, where a status check was performed before the dispense, a completion advice message will be required. 5 Other Processing Considerations 5.1 Acquirer Truncation (Alternate Host Authorisation, Acquirer Stand-In) In some markets Acquirers may choose to stand-in for or “truncate” authorisations in their host system. Where Acquirer truncation takes place, if the EMV process has resulted in an online authorisation request containing an ARQC, then the Acquirer host should respond “Unable to go online” to the authorisation request. Note that in contact transactions the card should perform the second risk management stage and may decline the transaction, based on the parameters set by the Issuer on the card.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 5.2 Deferred Authorisation In some environments where online authorisations are not normally available (such as aircrafts and ferries), an attended terminal may have functionality to allow the transaction to proceed after the card returns an ARQC as the first cryptogram type, for contact transactions, the card determines to decline the transaction due to the terminal being unable to go online. If the merchant wishes to proceed with the purchase, once the communication links are re-established, they can obtain an online authorisation and approval from the Issuer before submitting an item for clearing. In this case the ARQC may be used in the online authorisation (for example, after the plane lands or the ferry docks), and the approval code along with the ARQC may be put into the subsequent clearing message. To reduce the risk of fraudulent transactions, merchants may want acceptance only if Cardholder Verification and Offline Data Authentication have not failed. However, not all cards support offline processing. Individual payment systems may have their own requirements for processing EMV transactions at on-board terminals. In addition, payment systems may allow deferred authorisations in online-capable environments to provide service during temporary communication outages.

5.3 Premature Card Removal When performing an EMV transaction, the card should remain in the card reader for contact or in communication area for contactless until the last EMV transaction step. To reinforce this behaviour, after the EMV contact transaction has ended or after the EMV contactless cardholder device has been read, the display should indicate that the card can be removed. For contact chip if the card is removed before the transaction is complete (i.e. the TC or AAC has not been received from the card), the transaction processing should always be terminated. If an online authorisation has taken place, a reversal message should be sent. (If a decline response has been received, it is not necessary to send a reversal). If a card is removed after the second cryptogram generation, but before issuer script processing, the transaction shall be considered complete, and there will be no change in the transaction disposition.

5.4 Purchase with Cashback A purchase with cashback enables a sum of cash to be added to the amount of a purchase transaction. The purchase with cashback offer can be made to the cardholder and accepted either before or during/after the card dip/tap. If the terminal supports Purchase with Cashback, the recommended processing for each scenario is as follows.

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 5.4.1 Offered and accepted before dip/tap The transaction is initiated using the Amount, Authorized (tag ‘9F02’) set to the purchase amount plus the cashback amount, the Transaction Type (tag ‘9C’) set to the indicate Purchase with Cashback, and the Amount, Other (tag ‘9F03’) set to the cashback amount. For contact transactions the cardholder dips the card which may support domestic and/or international purchase with cashback, and the Application Usage Control on the card is consulted during Terminal Risk Management:  If purchase with cashback is supported by the card then the terminal proceeds with all parameters already set for the purchase with cashback.  If the card does not support purchase with cashback, then the terminal should dynamically revert all parameters to the purchase-only transaction. If any of the Amount, Authorized; Amount, Other or Transaction Type have already been communicated to the card in the GET PROCESSING OPTIONS command, then a new transaction without cashback should be initiated. The new transaction may automatically select the same application that was used for the original transaction. For contactless transactions the contactless CVM Required Limit is set to zero. The cardholder taps the card5, and the transaction follows the normal transaction flow.

5.4.2 Offered and accepted during/after dip/tap The transaction is initiated using the Amount, Authorized (tag ‘9F02’) set to the purchase amount, the Transaction Type (tag ‘9C’) set to indicate purchase (00), and the Amount, Other (tag 9F03) set to zero. For contact transactions, the cardholder dips the card, and the Application Usage Control on the card is consulted. If purchase with cashback is supported by the card, then the offer is made to the cardholder. If the cardholder accepts the offer, the cashback amount is chosen and the terminal should dynamically update the Amount, Authorized (tag ‘9F02’) to the purchase amount plus cashback amount, the Transaction Type (tag ‘9C’) to indicate Purchase with Cashback, and the Amount, Other (tag ‘9F03’) to the cashback amount. If any of the Amount, Authorized; Amount, Other or Transaction Type have already been communicated to the card in the GET PROCESSING OPTIONS command, a new transaction with cashback should be initiated. The new transaction may automatically select the same application that was used for the original transaction. If the card does not support purchase with cashback, then the card proceeds with all parameters already set for purchase. For contactless transactions, the transaction is completed and the terminal may then determine eligibility for purchase with cashback. If the offer is made and accepted, then the original transaction is discarded and the transaction is reinitiated following the recommendation for “Offer and accepted before dip/tap”. [Alternate Names]: Sale with Cashback, Cashback 5 In a contactless transaction, a card can be a plastic card other form of cardholder device such as a smartphone.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 5.5 POS Cash Advance POS Cash Advance allows a cardholder to withdraw cash from an account with the card at a POS. There are no specific recommended settings on for POS devices that support bothwith cash disbursement capability and they can be used forand purchasePurchase, too Please refer to Annex A.2 for applicable AUC and CVM Condition codes. [Alternate Names]: Cashout 5.6 Offline PIN Management PIN Change/Unblock allows a cardholder to change or unblock a PIN associated with an application on the card. The local markets where this is implemented will define the requirements.

5.7 Online PIN Retries When supported and required by the card (contact or contactless), certain transactions (e.g. ATM cash withdrawals or ATM balance inquiries) may involve online PIN retries by the cardholder, following an incorrect PIN attempt. Acquirers send the authorisation request again with the retried PIN and the same chip data as was sent during the first attempt, or they may restart the chip transaction for each PIN retry. Issuers should be prepared to expect either of these scenarios and hence the ATC and other chip data may be repeated in subsequent attempts if the online PIN received in an authorisation request was incorrect. If a new chip transaction is started, the terminal will select the same AID as the original transaction.

5.8 Categories of Transactions that Require Authorisation A category of transactions may need to be authorised online due to market or payment system requirements. An example would be where the market requires that particular types of transactions (e.g. Purchase with Cashback) be authorised online. The terminal should only set TVR bits as required in the EMV Specifications. Setting of the ‘Merchant Forced Online’ TVR bit should only be used when there are suspicious circumstances, and is not recommended for other transactions.

5.9 Dynamic Currency Conversion Dynamic Currency Conversion (DCC) is an optional service offered at Point-of-Sale terminals and ATMs in which cardholders may elect to have a transaction amount converted to their card billing currency instead of using the local currency. DCC processing itself is outside the scope of EMV processing requirements or recommendations, and EMVCo does not make any recommendations regarding the nature of DCC processing. These guidelines are intended to allow co-existence of DCC and EMV processing without interference with each other.

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 The opportunity to offer DCC may be identified in one of two ways:  The DCC opportunity may be identified and offer made to the cardholder during the transaction, once the required data (PAN) has been read from the card but before the first GENERATE AC command for contact transactions.  DCC may be performed after the first GENERATE AC command for contact transactions and after interaction with the card is complete during contactless transactions but before authorisation. This approach is most suitable for contactless transactions 5.9.1 Offer During Transaction For contact transactions, the opportunity to offer DCC may be identified during the transaction after the READ RECORD stage is complete. Once the DCC offer is made and accepted or rejected the EMV transaction should continue using either the converted transaction amount in the converted currency (if DCC processing determined that a converted transaction amount is to be used and the cardholder accepted the DCC offer) or the original transaction amount in the original currency (if DCC processing determined that the original currency is to be used or the cardholder declined the DCC offer). If DCC is accepted and if the Amount, Authorized or Transaction Currency Code have already been communicated to the card a new EMV transaction should be initiated. The original application can be selected directly without performing cardholder selection. If DCC is performed floor limit processing and weighted random transaction selection may need to accommodate this change; either by applying the currency conversion factor to the floor limit and transaction limit or by retaining a copy of the original transaction amount.

5.9.2 After Last Command DCC may be performed after the last command but before authorisation. This approach is most suitable for contactless transactions. Once the DCC offer is made and accepted or rejected the transaction amount and transaction currency code used in the authorisation message are updated to the DCC amount. Care should be taken to ensure that original amount and application currency code are included in the cryptogram data which will be different to the amount and application currency code of the authorisation,and card risk management is based on the original amount and application currency code as well, such as CVM to be proposed.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 6 Payment Tokenisation 6.1 Type of Transactions All transactions are the result of a consumer and Merchant interaction where an acceptance agreement is entered into by the parties. This agreement results in two different types of transaction initiation. The first and most common type is the Consumer-Initiated Transaction. This is where the consumer presents their payment credential directly to the Merchant to initiate the financial transaction. Consumer-Initiated Transactions use various card authentication features such as chip, contactless chip or 3DS. The interaction may result in a single transaction or begin a chain of two or more transactions. The second type is the Merchant-Initiated Transaction. This is the result of a previous consumer interaction where the consumer has expressly provided permission for additional charges to occur. Merchant-Initiated Transactions are always considered card not present, since the technology used to initiate the transaction relies upon the PAN and PAN Expiry Date having previously been provided to the Merchant. Card authentication features like an EMV cryptogram should not typically be reused for these subsequent transactions. There are implications to Merchant-Initiated Transactions when using Payment Tokenisation. Merchants who intend to initiate transactions derived from Consumer-Initiated Transactions should provide an indicator to the Card Issuer that subsequent transactions will be initiated by the Merchant. A Consumer-Initiated Transaction response may include an identifier which may be used to refer to subsequent Merchant-Initiated Transactions.

6.2 Token Domain Restriction Controls Payment Tokenisation relies on a concept known as Token Domain Restriction Controls. This means that each transaction presented must match the established controls set at the time of Token Issuance. EMV technology is widely used as the method of establishing the defined set of Token Domain Restriction Controls for card present transactions. Given the types of transactions described in this document, it is necessary to establish different criteria for the handling of Merchant-Initiated Transactions where Payment Tokens are used.

6.3 Merchant-Initiated Transactions When a Payment Token is used by the consumer to initiate a transaction, the card authentication data is validated as part of the Token Domain Restriction Controls associated with the Payment Token. Merchant-Initiated Transactions that result from cardholder-initated transactions using a Payment Token will not contain the necessary Card authentication data to successfully navigate the established Token Domain Restriction Controls. These transactions will only have access to the Payment Token and the Token Expiry Date. To successful navigate the established Token Domain Restriction Controls associated with a Payment Token, a Merchant-Initiated Transaction should refer to the original Consumer

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 Initated Transaction and include the linking transaction identification indicator and the specific type of Merchant-Initiated Transaction presented (refer to the table below). This will enable the applicable Token Domain Restriction Controls to be applied to the Merchant-Initiated Transactions.

6.3.1 Standing Instruction Any cardholder agreement where the consumer has entered into a previous agreement with the merchant to be charged a fixed or variable amount on a defined frequency. Each standing instruction is a new purchase, and does not have cardholder authentication or validation performed. Types of standing instructions include  Recurring payments (fixed or variable amount with a defined interval)  Subscription services (fixed amount, fixed interval – renewal process)  Instalments (fixed amount and fixed number of payments)  Account top ups (variable interval, variable amount) Each type of standing instructions may have unique conditions as to length, renewal process etc.

6.3.2 Re-Authorisation A reauthorisation is a purchase made after the original purchase and can reflect a number of specific conditions. Common scenarios include delayed/split shipments and extended stays/rentals, back orders or pre-orders.

6.3.3 Re-Submission This is an event that occurs when the original purchase occurred but the merchant was not able to get a positive authorisation at the time the goods or services were provided.

6.4 Payment Token Transactions The following table reflects the transaction types used in Payment Tokenisation. Consumer-Initiated Transactions Merchant-Initiated Transactions Purchase Incremental Authorisation Authorisation Re-Authorisation Preauthorisation No Show Status check Additional Charge after check-out Account Verification Re-Submission Purchase with Cashback Standing Instruction Deferred Authorisation Refund

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types Reservation

/ 24 Payment Tokens can also be used for the following system-generated messages  Completions  Reversals  Partial Reversals  Cancellations

countries.

EMV® Recommendations for EMV Processing for Industry-Specific Transaction Types

/ 24 Annex A – AUC and CVM Conditions This annex describes Application Usage Controls (AUC) and Cardholder Verification Method (CVM) conditions that are relevant to EMV Payment and Non-Payment transaction types. A.1 EMV Payment Transactions The following table illustrates which Application Usage Controls (AUC) and which CVM Conditions are relevant to each EMV transaction type. This is to be used by the device application to determine which controls are in place and which CVM conditions apply. ATM ATM Cash Yes withdrawal POS Cash No Advance Pre-Authorisation No Purchase No9 Application Usage Control CVM Condition6 Not ATM7 No Cash Yes Cashback No Purchase Unattended Cash No Yes Manual Cash No Cashback No Yes Yes No No No Yes No Yes No No Yes No No No Yes No No Yes No No No Not Cash8 No No Yes Yes Purchase with No Yes No Yes Yes No Cashback Quasi-cash No10 Yes No No Yes No No Yes No No No Yes Sale Completion No Yes No No Yes No No No Yes Status Check No Yes No No Yes No No No Yes Refund No Yes No No Yes No No No Yes 6 This chart uses the new CVM Conditions. The old CVM condition “If cash or cashback” maps to the new condition “If Unattended Cash” 7 “Valid at terminal other than ATMs” 8 Not Unattended Cash and Not Manual Cash and Not Cashback 9 If an ATM also supports purchases of goods or services, it is considered an unattended POS device while dispensing goods or services. 10 If an ATM also supports Quasi-cash, it is considered an unattended POS device.

countries.

EMV® Recommendations for EMV Processing For Industry-Specific Transaction Types

/ 24 A.2 Non-Payment Transactions using EMV Functionality The following table illustrates which CVM Conditions are recommended for device applications to apply to common Non-Payment Transactions using EMV functionality. Actual requirements will be determined by market requirement. In practice, the CVM invoked for one of these transactions may either result from processing the CVM List from the card or may be a predetermined method selected by the market. Application Usage Controls should not be evaluated for Non-Payment Transactions using EMV functionality. ATM Balance Inquiry ATM Bill Payment ATM Deposit ATM Funds Transfer ATM PIN Change/ Unblock POS Balance Inquiry POS Bill Payment POS Funds Deposit Unattended Cash Yes Yes No Yes Yes No No No CVM Condition Manual Cash Cashback No No No No No No No No No No No No No No No No Not Cash No No Yes No No Yes Yes Yes - End of Document -

countries.