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

1. 2.

Introduction General Considerations for Chip 2.1 Core Transactions 2.2 Non-Core Transactions 3. EMV Transactions in Specific Industries 3.1 General Retail Considerations 3.1.1 Purchase 3.1.2 Pre-Authorisation 3.1.3 Status Check 3.1.4 Sale Completion 3.1.5 Sale Completion with Incremental Authorisation 3.2 Lodging and Vehicle Rental Transactions 3.2.1 Reservation 3.2.2 Check-In 3.2.3 Additional/Delayed Charges 3.2.4 Express Check-Out 3.2.5 Card present Check-Out 3.3 Fuel/Petrol Dispense 3.4 Automated Teller Machines 3.4.1 ATM Cash Withdrawal 3.4.2 ATM Balance Inquiry 3.4.3 ATM Deposit /Cash Deposit 3.4.4 ATM Funds Transfer 3.5 Other Special Environments 3.5.1 Top-up 3.5.2 Tip Adjust 3.5.3 POS Cash Advance 3.5.4 Quasi-Cash 3.5.5 POS Balance Inquiry 3.5.6 POS Deposit 3.5.7 Bill Payment 3.5.8 Application Unblock 3.5.9 PIN Change/Unblock 4. Special Transactions in Industries-independent Environments 4.1 Refund 4.2 Referrals 5. Other Processing Considerations 5.1 Dynamic Currency Conversion 5.2 Gratuities 5.3 Cancellation 5.4 Reversal 5.5 Acquirer truncation (Alternate host Authorisation, Acquirer Stand-In) 5.6 Transaction Amount Requested in the PDOL 5.7 Account Type Requested in the PDOL 5.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

5.9 Processing Restrictions / Application Usage Control (AUC) - Goods and Services 5.10 Declined Transactions 5.11 Merchant Forced Transaction Online 5.12 Card Removal 6. Notes 6.1 Dual/Single Messaging and Host/Terminal Capture 6.2 ATMs Annex - AUC and CVM Conditions A.1 Core Transactions A.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

1. Introduction
This bulletin describes a recommended approach to handling certain types of EMV-enabled transactions and environments. It is intended to enable vendors to implement best practice implementations in the areas described below. The main areas covered are general retail, hotel environments, unattended petrol environments, referral processing, and refund processing. Only those areas impacting chip technology are described. This discussion is intended solely as a guideline; individual markets may implement alternate approaches and may mandate particular processing in that market.

2. General Considerations for Chip

The introduction of chip should disrupt the cardholder and merchant experience as little as possible. While chip may enable new services, with new cardholder and merchant interfaces, existing transaction types should flow in a familiar way. 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), but these exceptions are few. Chip does not change the fundamental characteristics of a transaction; payment scheme rules still apply to attended vs. unattended, card-present vs. card-not-present, cash disbursements, etc. 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. If EMV processing is not followed, but card data is extracted from the chip (such as PAN and expiry date) and used to complete the transaction, the transaction should be treated as manually entered.

2.1

Core Transactions
Core Transactions directly result in the purchase of goods or services and/or in the disbursement of cash. The EMV specifications address Core Transactions. Core Transactions will execute all mandatory functions defined in EMV and may execute optional EMV functions. Approved Core Transactions should result in generation of a Transactions Certificate (TC). The only exception may occur when the Acquirer does not support full chip data, and a card personalized to require ARPC validation may produce an AAC on the second Generate AC. 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. Financial transactions terminated in mid-processing, either by errors or by merchant cancellation, should be closed with a Generate AC for an AAC. 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.

2.2

Non-Core Transactions
Non-core Transactions refer to transactions commonly employed to support the retail or cash disbursement environment, but do not directly result in the purchase of a good or service nor in the disbursement of cash.

Page 4 DRAFT For Review Purposes only

EMV functions that extract information or request identification or authentication can be readily used to complete these transactions. Risk management is intended to maximize offline Authorisation capability for core transactions, while controlling risk. Therefore, functions that would affect future risk management decisions should not be executed, except by core transactions. EMV functions can be used for the following purposes: Information: In order to obtain information, the device can use Application Selection, Initiate Application Processing, and Read Application Data. Identification: In order to identify the Cardholder, the device can use Cardholder Verification methods as defined in the CVM list (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, or may allow the Issuer to validate the payment application using Card Authentication Method as part of online processing. Card Management: Issuer Script Processing may be used to update PINs, unblock applications, etc.

Non-core transactions should always be completed with an AAC1. This will ensure card risk management processes are not affected. Note that an AAC generated for a non-core transaction simply indicates completion, and is not a decline. Transactions using EMV functions must follow all relevant EMV requirements. See AUC and CVM Conditions to determine appropriate CVM Conditions and Processing Restrictions for common non-core transaction types.

3. EMV Transactions in Specific Industries

3.1
3.1.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. A Purchase is a combination of an Authorisation request (whether sent online or handled through interaction with the chip) and a clearing submission2. Where supported by the Merchant and the card, Purchase with Cashback allows the cardholder to withdraw cash against the associated account as part of the Purchase process. Purchase with Cashback may invoke a different CVM condition than a Purchase-only transaction3. Note that Single Message and host-capture transactions will contain the Authorisation Request Cryptogram (ARQC) in the settlement/financial message, while Dual Message transactions will contain the Transaction Certificate (TC). Please see Dual/Single Messaging and Host/Terminal Capture for further discussion.
1 2 3

PIN Change/Unblock may generate a TC. In a single message environment, the online Authorisation request and the clearing record are one financial message.

See AUC and CVM Conditions

Page 5 DRAFT For Review Purposes only

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. Alternate Names: Authorisation (Single Message and Host-Capture systems), Sale, Sale with Cashback, Cashback, Purchase with Cashback Relevant Transaction Types4: Retail Purchase, Retail Purchase with Cash Back, Hotel Check-Out (Card Present); Vehicle Collection, Vehicle Rental or Automobile Rental (Card Present); Restaurant Payment and Tip, Fuel or Petrol Purchase (when actual or maximum amount is Authorised) 3.1.2 Pre-Authorisation Pre-Authorisation occurs when a request is made for pre-approval of the transaction amount before the transaction is completed. Where the transaction amount changes from the pre-Authorised amount, as in car rental and hotel environments, a subsequent Incremental Authorisation may be issued for the additional amount. Incremental Authorisations are usually Card Not Present and do not contain chip data. Merchants can store the cards PAN and expiry date in order to perform any incremental Authorisations required5. Alternatively, the original Pre-Authorisation may be reversed and either a new Pre-Authorisation issued or the transaction is completed with a Purchase. The Pre-Authorisation process will perform all the EMV functions and the request message should contain all the appropriate chip data elements. The card and device interact in an identical fashion to the Purchase process. 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). Alternate Names: Authorisation - Only, Top-up Authorisation Relevant Transaction Types: Hotel Check-In (Card Present); Vehicle Collection Check-In or Automobile Rental (Card Present); Restaurant Pre-Tip 3.1.3 Status Check In some markets, Status Checks are used as online Pre-Authorisations for fuel dispensing, implicitly allowing up to a set amount (as defined in the market regulations) to be used in the Sale Completion. Status Checks are not appropriate in a chip environment for this type of Pre-Authorisation. Status Checks may also be used to reset cumulative offline counters for those customers that have exceeded their offline limits, without requiring those customers to make a purchase or withdrawal in order to get an online Authorisation. An online Status Check may also be used by airlines at Check-In to ensure the card used to purchase the transaction is valid. Alternate Name: Card Verify 3.1.4 Sale Completion A Sale Completion is the financial settlement of a previously Authorised transaction, often where the cardholder and card are no longer present. The final transaction amount may differ from the previously Authorised amount, usually within some range set by the market. The retained chip data elements from the
4 5

This list is indicative, rather than exhaustive. See also the related Industry sections. Only PAN and expiry date should be stored, never full track 2 data.

Page 6 DRAFT For Review Purposes only

associated Pre-Authorisation transaction, including all fields needed to validate the cryptogram, should be populated into the settlement transaction. If the cardholder is present at completion of the transaction (i.e. Hotel Check-Out), and the Pre-Authorisation was obtained as Card Not Present, the merchant should reverse the Pre-Authorisation and complete the transaction with a Purchase. If the cardholder is present at completion of the transaction, and the Pre-Authorisation was Card Present, it is recommended that the merchant either reverse the Pre-Authorisation and complete the transaction with a Purchase or, if available, use Incremental Authorisations to ensure the Authorisation amount matches the Sale Completion amount. This will ensure the cardholders open-to-buy accurately reflects transaction activity. Pre-Authorisations with Sale Completions are sometimes also used where the cardholder purchases a number of items that may be shipped at different times. This can result in one Pre-Authorisation with a number of Sale Completions whose total adds up to the amount of the Pre-Authorisation. Alternate Names: Post, Post Authorisation, Force Post, Authorisation Completion, Pre-Authorisation Completion Relevant Transaction Types: Hotel Check-Out (where final amount is within market limits of previously Authorised amounts), Hotel Top-up/Additional Expenses, Hotel Express Check-Out, Hotel - Delayed or Late Charges; Vehicle Return or Automobile Rental Return (where final amount is within market limits of previously Authorised amounts); Vehicle Top-up/Additional Expenses, Vehicle Express Vehicle Return, Vehicle - Delayed or Late Charges; Restaurant Post-Tip, Express Check-Out 3.1.5 Sale Completion with Incremental Authorisation As previously mentioned (See Incremental Authorisations), Incremental Authorisations may be used where the final amount exceeds the market-allowed variance from the authorised amount. Incremental Authorisation are normally done as Card Not Present, in which case there are no chip considerations for the Incremental Authorisation. The retained chip data elements from the original Pre-Authorisation transaction, including the TC (or ARQC), Cryptogram Date, and Cryptogram Amount, should be populated into the Sale Completion.. Alternate Names: Post, Post Authorisation, Force Post, Partial Reversal (When the final amount is less than the pre-Authorised amount (not truly a Reversal)), Incremental Authorisation (This term may apply when the final amount is greater than the pre-Authorised amount), Supplemental Authorisation Relevant Transaction Types: Hotel Check-Out (where final amount exceeds market limits of previously Authorised amounts); Vehicle Return or Automobile Rental Return (where final amount exceeds market limits of previously Authorised amounts)

3.2
3.2.1

Lodging and Vehicle Rental Transactions

Reservation The reservation process will not normally involve the card being present or the chip being read. Charges for guaranteed reservations (no-shows) should not be processed as chip transactions unless an EMV transaction has been performed.

Authorisation

3.2.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, according to the appropriate scheme 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.

Page 7 DRAFT For Review Purposes only

For PIN based transactions, there are two options at the time of PIN entry: Display the estimated amount to the cardholder Display no amount, and a message that reads Please enter your PIN.

In both cases the estimated transaction amount is the amount presented to the chip card. If online Authorisation is required, it is also the amount sent online. 3.2.3 Additional/Delayed Charges Additional Charges over the original Pre-Authorized amount can be authorised using Incremental Authorisations, where supported. Alternatively, the original Pre-Authorisation may be reversed and either a new Pre-Authorisation issued, or the transaction can be completed with a Purchase. 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. Sales Completion 3.2.4 Express Check-Out/Return It is not necessary to perform a full EMV card-read transaction once the final transaction amount is known. A Sales Completion is generated for the final billing amount and, if possible, the chip data from the original Pre-Authorisation should be included. 3.2.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, 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, presenting the data from this transaction in the clearing.

In either case, the final total amount should be displayed to the cardholder.

3.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. The maximum offline amount is the appropriate floor limit as defined by the payment schemes. The practice of requesting an Authorisation for a token amount (for example a single currency unit) is not recommended for chip transactions. It is best practice to display the maximum transaction amount to the cardholder before the transaction is authorised (via chip or online). If PIN entry is required, it is best practice to display amount before the PIN is entered. The merchant can 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 (if Authorisation is required by the EMV transaction). An alternative is to display no amount, and a message which simply 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).

Page 8 DRAFT For Review Purposes only

When the transaction is completed (that is, fuel dispensing is complete) and the final transaction amount is known, a clearing record should be submitted containing the chip data from the Pre-Authorisation. Single message environments may require an adjustment to the pre-authorised amount.

3.4
3.4.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. As always-online devices supporting online PIN, ATMs should not support Offline Data Authentication for Cash Disbursement6. Application Selection should be performed before PIN entry to ensure the appropriate CVM is used for domestic or proprietary programs. Although it is EMV compliant to use the PIN screen to confirm that the appropriate application has been selected, care should be taken to ensure this does not create the potential for cardholder confusion. Payment schemes may require that Online PIN is always requested for ATM Cash Withdrawals regardless of the CVM list on the card. See CVM Required by Device. Note: The settlement/financial message will contain the ARQC for most ATM transactions, and not the TC. (Please see Dual/Single Messaging and Host/Terminal Capture for further discussion.) However, the ATM must still request a TC to complete the transaction. Alternate Names: Cash Advance (credit), Cash Disbursement (debit), Unattended Cash

ATM Non-Core Transactions The following transactions can be performed using Application Selection, Initiate Application Processing, Read Application Data, Cardholder Verification, Online Processing using Card Authentication Method, and Issuer Script Processing. They should be completed with an AAC. 3.4.2 ATM Balance Inquiry ATM Balance Inquiry allows a cardholder to determine the available balance for the account(s) associated with the card. 3.4.3 ATM Deposit /Cash Deposit ATM Deposit allows a cardholder to put funds into an account associated with the card. It is expected that these transactions will be performed at a device under direct control of an issuer. 3.4.4 ATM Funds Transfer ATM Funds Transfer allows a cardholder to move funds from one account associated with the card to another.

3.5
3.5.1

Other Special Environments

Top-up Top-ups consist of a standard purchase transaction, sometimes followed by an advice to the service operator indicating additional service has been purchased. An example would be the purchase of additional minutes for a mobile phone at an unattended acceptance device. Unless specifically requested by the service operator, the format of the advice message should be unaffected by use of a chip card to complete the purchase. If a top-up transaction is completed with card-on-file data7, the transaction is considered Card Not Present. If the transaction is completed through extracting data from the chip (but not following EMV payment transaction flow), the transaction is considered manually entered.
6

As noted earlier, Purchase and Pre-Authorisation transactions have their own rules. An ATM could support Offline Data Authentication for the dispensing of goods and services.

Page 9 DRAFT For Review Purposes only

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

Only PAN and expiry date should be stored, never full track 2 data.

8 Different CVM conditions and Application Usage Controls apply as shown in the section:

Page 10 DRAFT For Review Purposes only

3.5.9

PIN Change/Unblock 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. Because the PIN Change/Unblock transaction may be used to also reset offline cumulative counters, it is the only non-EMV transaction that may result in the generation of a TC. 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.

4. Special Transactions in Industries-independent Environments

4.1 Refund
A refund is opposite to a purchase transaction. 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 Settlement message only9. The Refund transaction with a chip card can be completed by the normal process using the Track 2 Equivalent Data field from the chip. The Refund transaction will be initiated as a normal EMV transaction. If a Generate AC is performed, or if the Processing Data Object List (PDOL) indicates that the transaction amount has to be included in the Get Processing Options command, it is recommended that the device send a zero transaction amount to the card. CVM processing should not be invoked. Application selection will proceed in the same manner as a purchase transaction; the same application should be used for the refund as in the original purchase transaction. After the application has been selected and the terminal has completed the read application data stage, the terminal should then request an AAC from the card. The card will then produce an AAC enabling the EMV transaction flow to complete. In the event of the chip becoming unreadable in the course of the transaction, the merchant should fall back to magnetic-stripe processing for the completion of the refund, without going online to the Issuer. Alternate Names: Return, Credit

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. A Referral is not a transaction; it is an exception process for Purchase. 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 does not mean this transaction is declined; it completes the EMV transaction flow, so that the normal referral procedure can take place. If the merchant system supports it, the ARQC may be included with the clearing record generated by the manual referral process.

In some online-only host-capture environments, the Refund transaction may be sent online. However, it is sent as an advice; the acquiring host will not forward the message.

Page 11 DRAFT For Review Purposes only

Alternate Names: Call for Authorisation, Voice Referral, Call-Me, Call Center

5. Other Processing Considerations

5.1 Dynamic Currency Conversion
The dynamic currency conversion should always take place before EMV processing commences. Note that the device may also have to apply the currency conversion factor to the floor limit. The EMV process should use the converted currency and amount and these should be displayed to the cardholder. The transaction currency code and amount are part of the generated cryptogram and must be included in authorisation/clearing (along with all cryptogram fields). The device should also convert the floor limit amount into the transaction currency for proper risk management.

5.2

Gratuities
It is recommended that any gratuity is added to the transaction 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).

5.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; usually when an error is made. The most common cause of Cancellation is an error in the amount. A Cancellation may also occur if a Merchant does not approve the cardholders signature. Failure of a card to validate an ARPC may also require a Cancellation if the cards Application Default Action is set to decline, and Reversals are not supported. Termination of a transaction in process, such as by the merchant pressing a Cancel button, should result in cessation of the processing and clearing of any data elements. This merchant termination of an in-process transaction may also be referred to as Cancellation. Some markets require that Cancellation processing also generate a Reversal, while some are satisfied to simply remove the cancelled transaction from the clearing batch. If the transaction with the card has not reached the point where an ARQC has been requested, the card can simply be powered off. If an ARQC has been received from the card, then an AAC should be requested to avoid unnecessary requests for online Authorisations on subsequent transactions. 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). In some markets, the device will need to produce a receipt for the cardholder showing that the original transaction has been cancelled. Alternate Names: Void

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. 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.

Page 12 DRAFT For Review Purposes only

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. In this case, the cryptogram amount in the settlement message (in a dual-message system) should contain the requested cash amount, while the transaction amount should reflect the dispensed cash amount. In a single-message system, 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). If the Acceptance Device generates a reversal, 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 an AAC should be requested of the card to avoid unnecessary requests for online Authorisations on subsequent transactions.

5.5

Acquirer truncation (Alternate host Authorisation, Acquirer Stand-In)

In some markets, Acquirers may choose to truncate under-floor-limit transactions in their host, rather than in the device. In some cases, the Acquirer has chosen to take the liability of some over-floor-limit transactions rather than to incur the costs of Authorisation; in other markets, agreements are in place to allow such truncation to take place with the Issuer assuming liability. If the card expects a valid Authorisation Response Cryptogram (ARPC), the card will flag an ARPC failure. This can force the next transaction for the card online or can even result in a decline by the card. Although a card should validate the Issuer before resetting offline counters, it is possible that it will reset counters without validation.

5.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, obtaining the Transaction Amount must precede Initiate Application Processing for attended devices. Unattended devices can either obtain the Transaction amount, or put zeros in that field.

5.7

Account Type Requested in the PDOL

As of October 2005, EMV will allow cards to request that the account10 selected be passed in the PDOL (which would require that account selection precede Application Initiation). It is optional for devices to support this feature.

5.8

CVM Required by Device

Certain CVMs may be required in certain situations, for example, an ATM may always require an online PIN for Cash Withdrawals. When the device performs a CVM that was not determined by CVM list processing (in this example, Online PIN was not in the cards CVM list), the device shall not set the TVR bits related to this CVM. In this case, if Online PIN is not in the CVM List, PIN Entry Required will be set to 0.

5.9

Processing Restrictions / Application Usage Control (AUC) - Goods and Services

The Application Usage Controls If Goods and If Services can be treated as equivalent. That is, a transaction for domestic goods or services is allowed if either the valid flag for domestic goods or domestic services (or both) is set; the same is true for international goods and international services.

5.10

Declined Transactions
Where the Authorisation response received by the device indicates a decline, the cashier should be informed on their display that the transaction has been declined. For display to the cardholder, the term NOT AUTHORISED may be preferred.

10

Check-Ing, savings, etc.

Page 13 DRAFT For Review Purposes only

Authorisation responses indicating a decline may contain a script to be acted on by the card; these must be processed. In a few markets, for auditing purposes, declined transactions are delivered along with the clearing batch to the acquiring host. However, they are simply deleted from the clearing batch in most markets.

5.11

Merchant Forced Transaction Online

A function to allow the merchant to force a transaction online can be enabled. In this case, the device will set the Merchant Forced Online bit in the TVR and request an ARQC from the card in the first GENERATE AC. A merchant cannot force a transaction online in an attempt to gain an approval if the transaction has been declined offline.

5.12

Card Removal
When performing an EMV transaction, the card should remain in the card reader until the last EMV transaction step, and issuer script processing, is completed. The cardholder and merchant experience a difference compared to a transaction with a magnetic stripe card, where the card is swiped and returned to the cardholder. To reinforce the new behavior, once the EMV transaction has ended and is approved, the display should indicate that the card be removed. Premature Card Removal If the card is removed before the transaction is complete (i.e. the TC or AAC has 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.

6. Notes
6.1 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 settled11 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 or transactions to be completely settled from an Authorisation request. These Financial transactions are approved online by the cardholders financial institution. Terminal-capture and host-capture systems usually exist in the context of Dual Message processing, since Single Messages do not require any further clearing.12 Terminal-capture systems combine data from the
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. Messages here refers to the components of the transaction needed for authorisation and clearing. Audit, balancing records, and informational advices are not being considered.
12 11

Page 14 DRAFT For Review Purposes only

Authorisation response with the data from the Authorisation request to create the settlement message. In a host-capture system, the host retains a copy of the Authorisation request coming from the terminal before passing the request on to be Authorised. The host uses the data, along with the Authorisation response data, to create the settlement message. A terminal attached to a host-capture system may have a shadow (copy) of the settlement batch, but this is only for informational or error-recovery purposes. To Card 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 the ARQC in the settlement/financial message; terminal capture transactions will contain the TC in the settlement message. For most ATM transactions, whether Single or Dual Message, the settlement/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 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 transactions. Although not needed for clearing, generating a TC ensures cards will not request unnecessary online approvals on subsequent transactions. Each of the transaction types described can be implemented on Single- and Dual-Message systems, and on Terminal- and Host-Capture systems.

6.2

ATMs
As used in this document, an ATM is a device that dispenses cash. Cash dispensing transactions fall under the appropriate payment scheme Operating Regulations for ATMs. If a device also dispenses goods or services, the dispensing of those goods and services is considered a purchase at an unattended device. If a device dispenses cash, it should do so as described in ATM Cash Withdrawal. If it dispenses goods or services, it should do so as described in Purchase or Pre-Authorisation and Sale Completion. Many ATMs operate in a Single Message environment as described above. Some operate in a Dual Message environment, in which case they effectively function as Host Capture.

Page 15 DRAFT For Review Purposes only

Annex - 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. This is to be used by the device application to determine which controls are in place and which CVM conditions apply. 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. 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, it is considered an unattended POS device while dispensing goods or services.

Page 16 DRAFT For Review Purposes only

A.2 Non-Core Transactions

The following table illustrates which CVM Conditions are recommended for device applications to apply to common non-core transaction types. 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 on the card or may be a predetermined method selected by the market (just as an ATM might always invoke online PIN). Application Usage Controls should not be evaluated for non-core transactions. 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

Index of Commonly Used Transaction Names

Application Unblock............................ 11 ATM Balance Inquiry .......................... 10 ATM Cash Withdrawal.......................... 9 ATM Deposit ...................................... 10 ATM Funds Transfer .......................... 10 ATM Partial Reversal ......................... 13 Attended Cash ................................... 10 Authorisation ........................................ 6 Authorisation - Only.............................. 6 Authorisation Completion ..................... 7 Authorisation, Incremental.................... 7 Automobile .......................... See Vehicle Balance Inquiry ......... See ATM Balance Inquiry or POS Balance Inquiry Balance Return .................................. 11 Bill Payment ....................................... 11 Call for authorisation .......................... 12 Call-Me............................................... 12 Cancellation ....................................... 13 Card Verify ........................................... 7 Cash Advance. See POS Cash Advance or ATM Cash Withdrawal Cash Deposit................................ 10, 11 Cash Disbursement.............................. 9 Cashback ............................................. 6 Check-In............................................... 8 Check-Out ............................................ 7 Credit.................................................. 12 Deposit at ATM .................................. 10 Deposit at POS .................................. 11 Dining ............................ See Restaurant Express Check-Out .............................. 7 Force Post............................................ 7 Fuel Purchase ...................................... 6 Fuel/Petrol Dispense ............................ 9 Funds Transfer at ATM ...................... 10 Hotel Additional/Delayed Charges..... 8 Hotel Card Present Check-Out.......... 8 Hotel Check-In .............................. 6, 8 Hotel Check-Out................................ 7 Hotel Check-Out (Card Present) ....... 6 Hotel - Delayed or Late Charges .......... 7 Hotel Express Check-Out.............. 7, 8 Hotel Reservation.............................. 8 Hotel Top-up/Additional Expenses .... 7

Incremental Authorisation................. 6, 7 Lodging .................................. See Hotel Manual Cash ...................................... 10 Manual Cash Advance ....................... 10 Mobile Top-up .................................... 10 Partial Reversal .............................. 7, 13 Petrol Purchase.................................... 6 PIN Change/Unblock.......................... 11 POS Balance Inquiry .......................... 11 POS Cash Advance ........................... 10 POS Deposit ...................................... 11 POS Partial Reversal ........................... 7 Post ...................................................... 7 Post Authorisation ................................ 7 Pre-Authorisation ................................. 6 Pre-Authorisation Completion .............. 7 Purchase .............................................. 5 Purchase with Cashback...................... 6 Quasi-Cash ........................................ 10 Referrals............................................. 12 Refund................................................ 11 Reservation .......................................... 8 Restaurant............................................ 6 Restaurant Payment and Tip............. 6 Restaurant Post-Tip .......................... 7 Retail Purchase .................................... 6 Retail Purchase with Cash Back .......... 6 Return ................................................ 12 Reversal ............................................. 13 Sale ...................................................... 6 Sale Completion ................................... 7 Sale Completion with Incremental Authorisation..................................... 7 Sale with Cashback.............................. 6 Status Check........................................ 6 Supplemental Authorisation ................. 7 Tip Adjust ........................................... 10 Top-up................................................ 10 Top-up Authorisation ............................ 6 Vehicle - Delayed or Late Charges ...... 7 Vehicle Express Vehicle Return ........ 7 Vehicle Reservation .......................... 8 Vehicle Return................................... 8 Vehicle Top-up/Additional Expenses. 7 Vehicle Additional/Delayed Charges .. 8

Page 18 DRAFT For Review Purposes only

Vehicle Collection................................. 6 Vehicle Collection Check-In ................. 6 Vehicle Rental .................................... 8 Vehicle Rental (Card Present).............. 6

Vehicle Return...................................... 7 Voice Referral .................................... 12 Void .................................................... 13

Page 19 DRAFT For Review Purposes only