Guide to EMV Processing for Industry-Specific Transaction Types

Version 1.0
17 November 2005

This document is posted for a comment period of 60 days ending end of February 2006
DRAFT – FOR REVIEW PURPOSES ONLY

8 CVM Required by Device 4 4 4 4 5 5 5 6 6 6 7 7 7 7 8 8 8 8 9 9 9 9 9 9 9 10 10 10 10 10 10 10 11 11 11 11 12 12 12 12 12 13 13 13 13 Page 2 DRAFT For Review Purposes only .6 Transaction Amount Requested in the PDOL 5.3 Cancellation 5.2 ATM Balance Inquiry 3.2.1.2.4.9 PIN Change/Unblock 4.1 ATM Cash Withdrawal 3. 2.1 Reservation 3.1.7 Account Type Requested in the PDOL 5.5.5.4 ATM Funds Transfer 3.3 POS Cash Advance 3.2 Gratuities 5.4 Sale Completion 3.4 Express Check-Out 3.2 Pre-Authorisation 3. Other Processing Considerations 5.5.4.5 Card present Check-Out 3.1 Refund 4.2 Check-In 3.5.2 Referrals 5.5.3 Status Check 3.1.5 Sale Completion with Incremental Authorisation 3.5 Acquirer truncation (Alternate host Authorisation. Introduction General Considerations for Chip 2.2 Tip Adjust 3.4 Reversal 5.4. EMV Transactions in Specific Industries 3.4 Automated Teller Machines 3.1 General Retail Considerations 3.8 Application Unblock 3.3 ATM Deposit /Cash Deposit 3.2 Non-Core Transactions 3.4.3 Additional/Delayed Charges 3.5.5.5 Other Special Environments 3.7 Bill Payment 3. Acquirer Stand-In) 5.1 Dynamic Currency Conversion 5.2.5.1.2.5.1.4 Quasi-Cash 3.1.3 Fuel/Petrol Dispense 3.1 Core Transactions 2.5 POS Balance Inquiry 3.2. Special Transactions in Industries-independent Environments 4.1 Purchase 3.6 POS Deposit 3.2 Lodging and Vehicle Rental Transactions 3.1 Top-up 3.

1 Core Transactions A.2 ATMs Annex .1 Dual/Single Messaging and Host/Terminal Capture 6.2 Non-Core Transactions Index of Commonly Used Transaction Names 13 13 14 14 14 14 15 16 16 17 18 Page 3 DRAFT For Review Purposes only .11 Merchant Forced Transaction Online 5.10 Declined Transactions 5.Goods and Services 5.AUC and CVM Conditions A.9 Processing Restrictions / Application Usage Control (AUC) .5. Notes 6.12 Card Removal 6.

where possible and where known. 2. Introduction This bulletin describes a recommended approach to handling certain types of EMV-enabled transactions and environments. The only exception may occur when the Acquirer does not support full chip data. card-present vs. services. either by errors or by merchant cancellation. The EMV specifications address Core Transactions. is completed using a card with a chip. and refund processing. referral processing. whether for goods. This discussion is intended solely as a guideline.1 Core Transactions Core Transactions directly result in the purchase of goods or services and/or in the disbursement of cash. Financial transactions terminated in mid-processing. The main areas covered are general retail. hotel environments. If a Card Not Present transaction. As a general best practice. Chip does not change the fundamental characteristics of a transaction. with new cardholder and merchant interfaces. 2.2 Non-Core Transactions Non-core Transactions refer to transactions commonly employed to support the retail or cash disbursement environment. existing transaction types should flow in a familiar way. but these exceptions are few. and a card personalized to require ARPC validation may produce an AAC on the second Generate AC. etc. and the transaction is still considered Card Not Present. should be displayed to the Cardholder for confirmation. Approved Core Transactions should result in generation of a Transactions Certificate (TC). but card data is extracted from the chip (such as PAN and expiry date) and used to complete the transaction. In some cases. card-not-present. unattended. should be closed with a Generate AC for an AAC. or cash disbursement. cash disbursements. 2. unattended petrol environments. General Considerations for Chip The introduction of chip should disrupt the cardholder and merchant experience as little as possible. Core Transactions will execute all mandatory functions defined in EMV and may execute optional EMV functions. the chip functionality is irrelevant to the transaction. such as Hotel Guarantee. but do not directly result in the purchase of a good or service nor in the disbursement of cash. payment scheme rules still apply to attended vs. the transaction should be treated as manually entered. Note also that Single-message and host-draft-capture systems will pass the Authorisation Request Cryptogram (ARQC) and not the TC in the clearing file. If EMV processing is not followed. such as the display of a Cardholder Application Selection menu (which only applies to a multi-application chip transaction). It is intended to enable vendors to implement “best practice” implementations in the areas described below.1. individual markets may implement alternate approaches and may mandate particular processing in that market. change is unavoidable. Page 4 DRAFT For Review Purposes only . Only those areas impacting chip technology are described. the final amount. While chip may enable new services.

Risk management is intended to maximize offline Authorisation capability for core transactions. the device can use Application Selection. Note that Single Message and host-capture transactions will contain the Authorisation Request Cryptogram (ARQC) in the settlement/financial message. Please see “Dual/Single Messaging and Host/Terminal Capture” for further discussion. 1 2 3 PIN Change/Unblock may generate a TC. EMV functions can be used for the following purposes: Information: In order to obtain information. Therefore.1. Purchase with Cashback allows the cardholder to withdraw cash against the associated account as part of the Purchase process. and Read Application Data. In a single message environment.EMV functions that extract information or request identification or authentication can be readily used to complete these transactions. functions that would affect future risk management decisions should not be executed. Card Management: Issuer Script Processing may be used to update PINs. This will ensure card risk management processes are not affected. and is not a “decline”. Initiate Application Processing. or may allow the Issuer to validate the payment application using Card Authentication Method as part of online processing.1 3. See “AUC and CVM Conditions” to determine appropriate CVM Conditions and Processing Restrictions for common non-core transaction types. while Dual Message transactions will contain the Transaction Certificate (TC). 3. EMV Transactions in Specific Industries 3. Authentication: In order to check the authenticity of the payment application. Note that an AAC generated for a non-core transaction simply indicates completion. - Non-core transactions should always be completed with an AAC1. while controlling risk. Transactions using EMV functions must follow all relevant EMV requirements. unblock applications. Identification: In order to identify the Cardholder. Where supported by the Merchant and the card. See “AUC and CVM Conditions” Page 5 DRAFT For Review Purposes only . except by core transactions. the device can use Offline Data Authentication as part of offline processing. the online Authorisation request and the clearing record are one financial message. A Purchase is a combination of an Authorisation request (whether sent online or handled through interaction with the chip) and a clearing submission2. Purchase with Cashback may invoke a different CVM condition than a Purchase-only transaction3.1 General Retail Considerations Purchase A Purchase (or Sale) is the act between a cardholder and a merchant where goods and/or services are exchanged for monetary value. the device can use Cardholder Verification methods as defined in the CVM list (Cardholder Verification). etc.

Purchase with Cashback Relevant Transaction Types4: Retail Purchase. Alternate Name: Card Verify 3. Page 6 DRAFT For Review Purposes only .1. Top-up Authorisation Relevant Transaction Types: Hotel – Check-In (Card Present). An online Status Check may also be used by airlines at Check-In to ensure the card used to purchase the transaction is valid. Hotel – Check-Out (Card Present). Alternate Names: Authorisation .The exchange of goods and/or services for monetary value can also be completed using a Pre-Authorisation and a Sale Completion as discussed below. The Pre-Authorisation process will perform all the EMV functions and the request message should contain all the appropriate chip data elements. as in car rental and hotel environments. a subsequent Incremental Authorisation may be issued for the additional amount. Sale with Cashback. Restaurant – Payment and Tip.1. See also the related Industry sections. Vehicle Rental or Automobile Rental (Card Present).Only.1. Retail Purchase with Cash Back. The appropriate chip data elements from both the Pre-Authorisation request and response should be retained for the Sale Completion transaction (including the TC or ARQC). implicitly allowing up to a set amount (as defined in the market regulations) to be used in the Sale Completion. Alternate Names: Authorisation (Single Message and Host-Capture systems).4 Sale Completion A Sale Completion is the financial settlement of a previously Authorised transaction. Sale. Where the transaction amount changes from the pre-Authorised amount. The retained chip data elements from the 4 5 This list is indicative. Merchants can store the card’s PAN and expiry date in order to perform any incremental Authorisations required5.2 Pre-Authorisation Pre-Authorisation occurs when a request is made for pre-approval of the transaction amount before the transaction is completed. without requiring those customers to make a purchase or withdrawal in order to get an online Authorisation. rather than exhaustive. The card and device interact in an identical fashion to the Purchase process. Fuel or Petrol Purchase (when actual or maximum amount is Authorised) 3. Vehicle Collection. Alternatively. Only PAN and expiry date should be stored. never full track 2 data. Cashback. Restaurant – Pre-Tip 3. usually within some range set by the market. Incremental Authorisations are usually Card Not Present and do not contain chip data.3 Status Check In some markets. Status Checks may also be used to reset cumulative offline counters for those customers that have exceeded their offline limits. often where the cardholder and card are no longer present. Status Checks are used as online Pre-Authorisations for fuel dispensing. Status Checks are not appropriate in a chip environment for this type of Pre-Authorisation. the original Pre-Authorisation may be reversed and either a new Pre-Authorisation issued or the transaction is completed with a Purchase. Vehicle Collection Check-In or Automobile Rental (Card Present). The final transaction amount may differ from the previously Authorised amount.

it is recommended that the merchant either reverse the Pre-Authorisation and complete the transaction with a Purchase or. Hotel – Express Check-Out. including all fields needed to validate the cryptogram. Authorisation 3. Post Authorisation. Vehicle . Alternate Names: Post. Charges for guaranteed reservations (“no-shows”) should not be processed as chip transactions unless an EMV transaction has been performed.1. Acquirers / merchants will determine an appropriate estimated amount to be authorised. This will ensure the cardholder’s open-to-buy accurately reflects transaction activity.. and the Pre-Authorisation was obtained as Card Not Present. Incremental Authorisations may be used where the final amount exceeds the market-allowed variance from the authorised amount. in which case there are no chip considerations for the Incremental Authorisation. Cryptogram Date. Authorisation Completion. Page 7 DRAFT For Review Purposes only .2. Vehicle Return or Automobile Rental Return (where final amount exceeds market limits of previously Authorised amounts) 3. If the cardholder is present at completion of the transaction.2 3. including the TC (or ARQC).Delayed or Late Charges. Vehicle – Top-up/Additional Expenses. Vehicle – Express Vehicle Return. Force Post. Alternate Names: Post. based on market requirements. guarantee funds before the final transaction amount is known. Pre-Authorisation Completion Relevant Transaction Types: Hotel – Check-Out (where final amount is within market limits of previously Authorised amounts). should be populated into the settlement transaction.2. Pre-Authorisations with Sale Completions are sometimes also used where the cardholder purchases a number of items that may be shipped at different times.Delayed or Late Charges. Hotel – Top-up/Additional Expenses. the merchant should reverse the Pre-Authorisation and complete the transaction with a Purchase.1 Lodging and Vehicle Rental Transactions Reservation The reservation process will not normally involve the card being present or the chip being read.5 Sale Completion with Incremental Authorisation As previously mentioned (See “Incremental Authorisations”).e.2 Check-In/Rental A normal EMV-based Pre-Authorisation is completed at Check-In to check that the card and cardholder are genuine and. Incremental Authorisation are normally done as Card Not Present. Hotel Check-Out). Incremental Authorisation (This term may apply when the final amount is greater than the pre-Authorised amount). Partial Reversal (When the final amount is less than the pre-Authorised amount (not truly a “Reversal)). Express Check-Out 3. Hotel . Force Post. Vehicle Return or Automobile Rental Return (where final amount is within market limits of previously Authorised amounts). should be populated into the Sale Completion.associated Pre-Authorisation transaction. Post Authorisation. according to the appropriate scheme rules. and Cryptogram Amount. and the Pre-Authorisation was Card Present. Supplemental Authorisation Relevant Transaction Types: Hotel – Check-Out (where final amount exceeds market limits of previously Authorised amounts). This can result in one Pre-Authorisation with a number of Sale Completions whose total adds up to the amount of the Pre-Authorisation. use Incremental Authorisations to ensure the Authorisation amount matches the Sale Completion amount. The retained chip data elements from the original Pre-Authorisation transaction. Restaurant – Post-Tip. If the cardholder is present at completion of the transaction (i. if available.

there are two options at the time of PIN entry: • • Display the estimated amount to the cardholder Display no amount. presenting the data from this transaction in the clearing. In either case. 3.5 Card Present Check-Out/Return Either of the following two methods for card present Check-Out are recommended: • • A Sales Completion is generated for the final billing amount and. or the transaction can be completed with a Purchase.2. If online Authorisation is required. it is also the amount sent online. In both cases the estimated transaction amount is the amount presented to the chip card. card not present. A Sales Completion is generated for the final billing amount and. Page 8 DRAFT For Review Purposes only .2. Alternatively. Any additional charges identified after Check-Out should be processed as separate. If PIN entry is required. if possible. The value confirmed by the cardholder should be the same as the amount presented to the chip card and sent online for Authorisation (if Authorisation is required by the EMV transaction). it is best practice to display amount before the PIN is entered.4 Express Check-Out/Return It is not necessary to perform a full EMV card-read transaction once the final transaction amount is known. The merchant can optionally let the cardholder choose a lower maximum amount for their specific transaction. and a message which simply reads “Please enter your PIN”. The maximum offline amount is the appropriate floor limit as defined by the payment schemes. and a message that reads “Please enter your PIN”. The maximum transaction amount should be presented to the chip card and sent online for authorisation (if authorisation is required by the EMV transaction). the original Pre-Authorisation may be reversed and either a new Pre-Authorisation issued. 3. It is best practice to display the maximum transaction amount to the cardholder before the transaction is authorised (via chip or online). 3. An alternative is to display no amount.For PIN based transactions. transactions. The practice of requesting an Authorisation for a token amount (for example a single currency unit) is not recommended for chip transactions. the chip data from the original Pre-Authorisation should be included. if possible. the chip data from the original Pre-Authorisation should be included (this is similar to express Check-Out) The merchant reverses the original Pre-Authorisation and any Incremental Authorisations and does a full EMV transaction (Purchase) for the final billing amount.3 Fuel/Petrol Dispense For chip transactions in an unattended petrol environment it is recommended that a full EMV transaction be completed for the maximum offline transaction amount before fuel is dispensed. where supported. Sales Completion 3.2. The chip data from the Pre-Authorisation should not be submitted in this clearing record.3 Additional/Delayed Charges Additional Charges over the original Pre-Authorized amount can be authorised using Incremental Authorisations. the final total amount should be displayed to the cardholder.

3. 3. the transaction is considered Card Not Present. As always-online devices supporting online PIN. Note: The settlement/financial message will contain the ARQC for most ATM transactions. the ATM must still request a TC to complete the transaction. Unattended Cash ATM Non-Core Transactions The following transactions can be performed using Application Selection. Cash Disbursement (debit). sometimes followed by an advice to the service operator indicating additional service has been purchased. 3.5. They should be completed with an AAC. If the transaction is completed through extracting data from the chip (but not following EMV payment transaction flow). a clearing record should be submitted containing the chip data from the Pre-Authorisation.1 Automated Teller Machines ATM Cash Withdrawal ATM Cash Withdrawal allows a cardholder to receive cash against the open-to-buy or source of funds.4 3. (Please see “Dual/Single Messaging and Host/Terminal Capture” for further discussion. An “ATM” could support Offline Data Authentication for the dispensing of goods and services.2 ATM Balance Inquiry ATM Balance Inquiry allows a cardholder to determine the available balance for the account(s) associated with the card. care should be taken to ensure this does not create the potential for cardholder confusion.4. 3. and Issuer Script Processing. See “CVM Required by Device”. It is expected that these transactions will be performed at a device under direct control of an issuer. Application Selection should be performed before PIN entry to ensure the appropriate CVM is used for domestic or proprietary programs. Single message environments may require an adjustment to the pre-authorised amount. Unless specifically requested by the service operator. Online Processing using Card Authentication Method. Alternate Names: Cash Advance (credit).) However. 3. Cardholder Verification.4.1 Other Special Environments Top-up Top-ups consist of a standard purchase transaction. Read Application Data. ATMs should not support Offline Data Authentication for Cash Disbursement6. Initiate Application Processing.4.4 ATM Funds Transfer ATM Funds Transfer allows a cardholder to move funds from one account associated with the card to another. If a top-up transaction is completed with card-on-file data7. the format of the advice message should be unaffected by use of a chip card to complete the purchase. Although it is EMV compliant to use the PIN screen to confirm that the appropriate application has been selected.5 3. fuel dispensing is complete) and the final transaction amount is known. Page 9 DRAFT For Review Purposes only . the transaction is considered manually entered. Payment schemes may require that Online PIN is always requested for ATM Cash Withdrawals regardless of the CVM list on the card. 6 As noted earlier. Purchase and Pre-Authorisation transactions have their own rules.When the transaction is completed (that is.4.3 ATM Deposit /Cash Deposit ATM Deposit allows a cardholder to put funds into an account associated with the card. An example would be the purchase of additional minutes for a mobile phone at an unattended acceptance device. and not the TC.

. Online Processing using Card Authentication Method. Initiate Application Processing.6 POS Deposit POS Deposit allows a cardholder to put funds into an account associated with the card.5. 8 Different CVM conditions and Application Usage Controls apply as shown in the section: “ Page 10 DRAFT For Review Purposes only .5. through an ATM or POS device.3 POS Cash Advance POS Cash Advance allows a cardholder to receive cash against the open-to-buy or source of funds. Alternate Names: Balance Return 3.8 Application Unblock Issuer Scripting can be used to unblock an application. Quasi-cash does have its own processing restrictions. using an account associated with the card. No authorisation or advice is issued. POS Non-Core Transactions The following transactions can be performed using Application Selection. Manual Cash Advance. (Some markets may ask for tip amount before proceeding with the authorisation. typically a prepaid account. The processing is the same as a Purchase.7 Bill Payment Bill Payment allows a cardholder to pay invoices. and Issuer Script Processing. Read Application Data. or money orders) that are directly convertible to cash. The process flow will be the same as a Purchase.5.Alternate Names: Mobile Top-up 3.5 POS Balance Inquiry POS Balance Inquiry allows a cardholder to determine the available balance for the account associated with the card. 3.5.8 Manual Cash Advance may also be performed at financial institutions. Alternate Names: Manual Cash. commonly utility bills. where a teller disburses cash. Where allowed for merchants. Attended Cash 3. The Adjust transactions should not have any chip considerations. opening deposits. however the transaction must be online authorised.2 Tip Adjust Tip Adjust allows addition of a tip to a restaurant charge.4 Quasi-Cash Quasi-Cash is the purchase of items (such as gaming chips. never full track 2 data. 7 Only PAN and expiry date should be stored. it is most often restricted to certain T&E merchants. Cardholder Verification.5. They should be completed with an AAC. so there will be no need for a special transaction). 3. such as Cruise Ships and Lodging. 3.These transactions take place at an agent (such as a post office) empowered to accept deposits on behalf of the financial institution.5. not the cryptogram final amount used to generate the TC. other than to ensure that only the transaction amount is updated. 3.5.

Full or partial refunds of the original transaction are both possible. The cardholder returns goods to a merchant and is credited with their value. it is an exception process for Purchase. Generation of an AAC does not mean this transaction is declined. so that the normal referral procedure can take place. In some online-only host-capture environments. These transactions should be performed at a device under direct control of the issuer (normally an ATM) or at a device in a network in which the issuer participates and for which the appropriate operational procedures and liabilities have been defined. After the application has been selected and the terminal has completed the ‘read application data’ stage. However.1 Refund A refund is opposite to a purchase transaction. the merchant should fall back to magnetic-stripe processing for the completion of the refund. If a Generate AC is performed. When a referral Authorisation response is received from the card issuer. the same application should be used for the refund as in the original purchase transaction. the terminal should then request an AAC from the card. Application selection will proceed in the same manner as a purchase transaction.9 PIN Change/Unblock PIN Change/Unblock allows a cardholder to change or unblock a PIN associated with an application on the card. it is recommended that the device send a zero transaction amount to the card. it is the only non-EMV transaction that may result in the generation of a TC. If the merchant system supports it. the acquiring host will not forward the message. it completes the EMV transaction flow. The card will then produce an AAC enabling the EMV transaction flow to complete. the terminal should request an AAC from the card at the second GENERATE AC request. 4.2 Referrals Referrals are intended as a fraud control tool for Issuers to use when more information is needed to verify the identity of the cardholder prior to approving a transaction. Because the PIN Change/Unblock transaction may be used to also reset offline cumulative counters. the ARQC may be included with the clearing record generated by the manual referral process. without going online to the Issuer. Credit 4. it is sent as an advice. or if the Processing Data Object List (PDOL) indicates that the transaction amount has to be included in the Get Processing Options command. A Referral is not a “transaction”.3. 9 Page 11 DRAFT For Review Purposes only . Alternate Names: Return. Special Transactions in Industries-independent Environments 4. the Refund transaction may be sent online. In the event of the chip becoming unreadable in the course of the transaction. The Refund transaction will be initiated as a normal EMV transaction. The Refund transaction with a chip card can be completed by the normal process using the “Track 2 Equivalent Data” field from the chip.5. CVM processing should not be invoked. The local markets where this is implemented will define the requirements. A Refund consists of a Settlement message only9.

then an AAC should be requested to avoid unnecessary requests for online Authorisations on subsequent transactions. Call-Me. Voice Referral. Failure of a card to validate an ARPC may also require a Cancellation if the card’s Application Default Action is set to decline. The transaction currency code and amount are part of the generated cryptogram and must be included in authorisation/clearing (along with all cryptogram fields). Alternate Names: Void 5. In some markets. Call Center 5. should result in cessation of the processing and clearing of any data elements. If the device has received a TC or AAC from the card. 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). usually when an error is made. If an ARQC has been received from the card. Note that the device may also have to apply the currency conversion factor to the floor limit. Other Processing Considerations 5. The device should also convert the floor limit amount into the transaction currency for proper risk management. Termination of a transaction in process.3 Cancellation A Cancellation occurs when a previously completed Purchase or Sale Completion transaction is marked to cancel authorisation and/or clearing of that transaction.Alternate Names: Call for Authorisation. the transaction is completed and can now be cancelled (removed from the batch or marked as void). The most common cause of Cancellation is an error in the amount. such as by the merchant pressing a Cancel button. 5.4 Reversal A Reversal is sent to the Acquirer and on to the Issuer to notify them that the previous Authorisation response was not delivered to the Acceptance Device (“System Reversal”) or has been annulled by the Acceptance Device. and Reversals are not supported. Some markets require that Cancellation processing also generate a Reversal. If the transaction with the card has not reached the point where an ARQC has been requested. while some are satisfied to simply remove the cancelled transaction from the clearing batch. A Cancellation may also occur if a Merchant does not approve the cardholder’s signature. 5. the card can simply be powered off. This merchant termination of an in-process transaction may also be referred to as “Cancellation”. The EMV process should use the converted currency and amount and these should be displayed to the cardholder. 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.1 Dynamic Currency Conversion The dynamic currency conversion should always take place before EMV processing commences. Page 12 DRAFT For Review Purposes only . the device will need to produce a receipt for the cardholder showing that the original transaction has been cancelled.2 Gratuities It is recommended that any gratuity is added to the transaction amount before the EMV transaction starts.

the cashier should be informed on their display that the transaction has been declined. the same is true for international goods and international services. In this case. Online PIN was not in the card’s CVM list). the cryptogram amount in the settlement message (in a dual-message system) should contain the requested cash amount.7 Account Type Requested in the PDOL As of October 2005. 5. a transaction for domestic goods or services is allowed if either the valid flag for domestic goods or domestic services (or both) is set. Unattended devices can either obtain the Transaction amount.“ATM Partial Reversal” (not to be confused with POS Partial Reversal) are usually supported by unattended cash dispensing devices (ATMs) to ensure that accounts are properly debited when partial dispenses of cash occur. etc.10 Declined Transactions Where the Authorisation response received by the device indicates a decline. while the Partial Reversal will contain the adjusted amount (and no chip data). rather than in the device. if Online PIN is not in the CVM List. the card will flag an ARPC failure.6 Transaction Amount Requested in the PDOL If the PDOL indicates that the Transaction Amount has to be included in the GET PROCESSING OPTIONS command.5 Acquirer truncation (Alternate host Authorisation. In some cases.8 CVM Required by Device Certain CVMs may be required in certain situations. Acquirer Stand-In) In some markets. the term ‘NOT AUTHORISED’ may be preferred.Goods and Services The Application Usage Controls “If Goods” and “If Services” can be treated as equivalent. obtaining the Transaction Amount must precede Initiate Application Processing for attended devices. Although a card should validate the Issuer before resetting offline counters. an ATM may always require an online PIN for Cash Withdrawals. the original transaction will contain the requested amount and the chip data (including ARQC). 5. This can force the next transaction for the card online or can even result in a decline by the card. and an ARQC had been requested. EMV will allow cards to request that the account10 selected be passed in the PDOL (which would require that account selection precede Application Initiation). For display to the cardholder. In this case. detects the connection to the Acquirer Host has been lost. for example. In a single-message system. If the card expects a valid Authorisation Response Cryptogram (ARPC). or has timed-out because no Authorisation response has been received. 10 Check-Ing. 5. Acquirers may choose to truncate under-floor-limit transactions in their host. 5. 5. Page 13 DRAFT For Review Purposes only . it is possible that it will reset counters without validation. while the transaction amount should reflect the dispensed cash amount. agreements are in place to allow such truncation to take place with the Issuer assuming liability. That is. It is optional for devices to support this feature. in other markets. When the device performs a CVM that was not determined by CVM list processing (in this example. PIN Entry Required will be set to 0. then an AAC should be requested of the card to avoid unnecessary requests for online Authorisations on subsequent transactions. 5. savings. or put zeros in that field. the device shall not set the TVR bits related to this CVM.9 Processing Restrictions / Application Usage Control (AUC) . the Acquirer has chosen to take the liability of some over-floor-limit transactions rather than to incur the costs of Authorisation. If the Acceptance Device generates a reversal.

If a card is removed after the second cryptogram generation. refers to device-to-Acquirer settlement. If an online Authorisation has taken place. the card should remain in the card reader until the last EMV transaction step. and informational advices are not being considered. In a few markets. a reversal message should be sent (If a decline response has been received. Audit. These clearing messages are usually gathered into a batch for POS devices. is completed. A merchant cannot force a transaction online in an attempt to gain an approval if the transaction has been declined offline. However. and there will be no change in the transaction disposition. and the transaction is “settled”11 later using another message. and issuer script processing. To reinforce the new behavior. If the clearing message is automatically generated from the Authorisation request and response.Authorisation responses indicating a decline may contain a script to be acted on by the card. If the clearing message is changed in some way. it is not necessary to send a reversal). since Single Messages do not require any further clearing. the TC or AAC has been received from the card). 6. from a Point-of-Transaction perspective. the transaction processing should always be terminated. 5. A “Single Message” transaction occurs in a single message format that allows Purchase or transactions to be completely settled from an Authorisation request. The cardholder and merchant experience a difference compared to a transaction with a magnetic stripe card. From a processing perspective. Premature Card Removal If the card is removed before the transaction is complete (i. The batch is then “settled” with the Acquiring host as part of end-of-day (or end-of-cycle) processing. once the EMV transaction has ended and is approved. the Authorisation and clearing message together are considered one transaction (for example. where the card is swiped and returned to the cardholder. 5. prior to end-of-day (or end-of-cycle). a “Purchase”). based on their transaction logs. “Messages” here refers to the components of the transaction needed for authorisation and clearing. then the messages are considered a separate “Authorisation” and “Sale Completion”. they are simply deleted from the clearing batch in most markets.11 Merchant Forced Transaction Online A function to allow the merchant to force a transaction online can be enabled. these must be processed. Notes 6.1 Dual/Single Messaging and Host/Terminal Capture In “Dual Message” processing. the display should indicate that the card be removed. for auditing purposes. 12 11 Page 14 DRAFT For Review Purposes only .12 Terminal-capture systems combine data from the “Settlement”. Terminal-capture and host-capture systems usually exist in the context of Dual Message processing. These “Financial” transactions are approved online by the cardholder’s financial institution. balancing records. the transaction shall be considered complete. but before issuer script processing.e.12 Card Removal When performing an EMV transaction. the Acquirer will transform these messages into “clearing” transactions. the device will set the “Merchant Forced Online” bit in the TVR and request an ARQC from the card in the first GENERATE AC. the Authorisation occurs at the time of the Purchase or Cash Advance transaction using one message. declined transactions are delivered along with the clearing batch to the acquiring host. Non-batched systems may simply submit a series of clearing advices. In this case.

For most ATM transactions. Cash dispensing transactions fall under the appropriate payment scheme Operating Regulations for ATMs. To Card Acceptance Devices using Host Capture. but this is only for informational or error-recovery purposes. Single Message and host-capture transactions will contain the ARQC in the settlement/financial message. Each of the transaction types described can be implemented on Single. A terminal attached to a host-capture system may have a “shadow” (copy) of the settlement batch. 6. it should do so as described in “ATM Cash Withdrawal”. and on Terminal.and Host-Capture systems. Many ATMs operate in a Single Message environment as described above. If it dispenses goods or services. generating a TC ensures cards will not request unnecessary online approvals on subsequent transactions. an “ATM” is a device that dispenses cash. terminal capture transactions will contain the TC in the settlement message. the host retains a copy of the Authorisation request coming from the terminal before passing the request on to be Authorised. Devices operating in a Single Message or Host Capture environment should ensure a TC is generated for approved transactions. In a host-capture system. the settlement/financial message will contain the ARQC. in which case they effectively function as Host Capture. to create the settlement message. along with the Authorisation response data. the acquiring host captures the Authorisation response from the Issuer to create the clearing message and does not have access to the final TC (much like Host-Capture POS). the dispensing of those goods and services is considered a purchase at an unattended device. Some operate in a Dual Message environment. whether Single or Dual Message. it should do so as described in “Purchase” or “Pre-Authorisation” and “Sale Completion”. transactions appear to be Single Message. Page 15 DRAFT For Review Purposes only .and Dual-Message systems. and not the TC. If a device also dispenses goods or services. In most Dual Message ATM implementations. If a device dispenses cash. Although not needed for clearing. since the acquirer host is responsible for generating the clearing message. The host uses the data.2 ATMs As used in this document.Authorisation response with the data from the Authorisation request to create the settlement message.

This is to be used by the device application to determine which controls are in place and which CVM conditions apply.Annex . ATM ATM Cash withdrawal POS Cash Advance PreAuthorisation Purchase Purchase with Cashback Quasi-cash Sale Completion Status Check Yes No No No16 No No No No Application Usage Control Not Cash CashPurchase ATM14 back No Yes No No Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No Yes No No No No Yes Yes Yes Yes Yes Yes Unattended Cash Yes No No No No No No No CVM Condition13 Manual Cashback Cash No No Yes No No No No No No No No No Yes No No No Not Cash15 No No Yes Yes No Yes Yes Yes This chart uses the new CVM Conditions. Page 16 DRAFT For Review Purposes only . it is considered an unattended POS device while dispensing goods or services.AUC and CVM Conditions A.1 Core Transactions The following table illustrates which Application Usage Controls (AUC) and which CVM Conditions are relevant to each core transaction type. The old CVM condition “If cash or cashback” maps to the new condition “If Unattended Cash” 14 15 16 13 “Valid at terminal other than ATMs” Not Unattended Cash and Not Manual Cash and Not Cashback If an ATM also supports purchases of goods or services.

In practice. the CVM invoked for one of these transactions may either result from processing the CVM list on the card or may be a predetermined method selected by the market (just as an ATM might always invoke online PIN). Unattended Cash Yes Yes No Yes Yes No No No N/A CVM Condition Manual Cashback Cash No No No No No No No No No N/A No No No No No No No N/A Not Cash No No Yes No No Yes Yes Yes N/A ATM Balance Inquiry ATM Bill Payment ATM Deposit ATM Funds Transfer ATM PIN Change/ Unblock POS Balance Inquiry POS Bill Payment POS Funds Deposit Refund Page 17 DRAFT For Review Purposes only . Application Usage Controls should not be evaluated for non-core transactions.2 Non-Core Transactions The following table illustrates which CVM Conditions are recommended for device applications to apply to common non-core transaction types.A. Actual requirements will be determined by market requirement.

.............................. 8 Restaurant........................................................................................................................ 6..................................Only...................................... 6 Authorisation Completion ..... 7 Post ...... 8 Vehicle – Return. 7 Vehicle– Additional/Delayed Charges ............. 6 Pre-Authorisation Completion . 7 Vehicle – Express Vehicle Return . 7 Fuel Purchase ..... 11 Reservation ................................................................................ 7 Retail Purchase ................... 9 ATM Deposit . 7 Post Authorisation ... See POS Cash Advance or ATM Cash Withdrawal Cash Deposit..... 7 Hotel – Express Check-Out.................... 6 Vehicle ..................... 11 POS Cash Advance ............................................ 7 Automobile .. 7 Credit... 12 Cancellation ... 7 Incremental Authorisation......................... 12 Deposit at ATM ............................... 6 Sale Completion ....... 11 Cash Disbursement............................. 11 Dining ........................ 10 ATM Partial Reversal .................. 6 Status Check......................... 6 Restaurant – Payment and Tip.... 11 POS Balance Inquiry .................. 10 Hotel – Additional/Delayed Charges.................... See ATM Balance Inquiry or POS Balance Inquiry Balance Return ... See Hotel Manual Cash ........ 7 Force Post................................... See Restaurant Express Check-Out .................... 6 Supplemental Authorisation .......................... 6 Authorisation .. 10 Authorisation ......................................... 10 ATM Funds Transfer .................. 10 Mobile Top-up ............ 6 Hotel ......... 11 ATM Balance Inquiry ................................................................................................................................................ 8 Hotel – Check-In ............................................................. 7 Tip Adjust ... 7 Authorisation............... 13 Attended Cash ..................... 6 Check-In................................... 12 Call-Me..................... 13 Card Verify ......................................................................................................................................................................................................................................................... Incremental........... 11 Call for authorisation .................. 6 Quasi-Cash ....................................................................................... 10 Manual Cash Advance .................... 13 Petrol Purchase......................Index of Commonly Used Transaction Names Application Unblock................................ 7 Sale with Cashback... 10 Top-up....................... 5 Purchase with Cashback................................................... 10 Deposit at POS ............................................................. See Vehicle Balance Inquiry ... 6 Restaurant – Post-Tip ...................... 7........................ 9 Funds Transfer at ATM .......................................................Delayed or Late Charges ....... 8 Hotel – Check-Out................ 7 Pre-Authorisation ....................... 8 Check-Out ................................. 10 Partial Reversal ........... 6 Retail Purchase with Cash Back .............Delayed or Late Charges .................................................... 8 Hotel – Top-up/Additional Expenses ......... 6.... 8 Page 18 DRAFT For Review Purposes only .............................. 6 Return .............................................. 13 Sale .................................................. 7 Lodging ...................................... 11 Bill Payment ...................................... 6 Fuel/Petrol Dispense ...... 10......... 7 Vehicle – Reservation ............. 9 Cashback ............................. 7 Hotel – Check-Out (Card Present) ................... 11 POS Partial Reversal ......... 10 ATM Cash Withdrawal..................... 7 Sale Completion with Incremental Authorisation............................................................................................... 8 Hotel – Reservation......... 6 PIN Change/Unblock................... 12 Reversal . 8 Vehicle – Top-up/Additional Expenses.................................. 7......... 7 Cash Advance..................................... 7 Purchase ...................... 8 Hotel – Card Present Check-Out......... 10 POS Deposit ............... 10 Top-up Authorisation ................ 10 Referrals........................................... 12 Refund.......

........ 8 Vehicle Rental (Card Present)................................................ 7 Voice Referral .................. 12 Void ......Vehicle Collection................................................................... 6 Vehicle– Rental ..... 6 Vehicle Collection Check-In ................................. 6 Vehicle Return.............. 13 Page 19 DRAFT For Review Purposes only ............................