Recommendations for EMV Processing for Industry-Specific Transaction Types V2 20110801075511607
Transcript of Recommendations for EMV Processing for Industry-Specific Transaction Types V2 20110801075511607
Best Practices Document
Version 2.0 July 2011
Recommendations for EMV Processing for Industry-Specific
Transaction Types
This Best Practices 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 guide and should be
used in conjunction with the current version of EMV Books 1 to 4.
©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
EMV Recommendations for EMV Processing for Industry-Specific Transaction Types
Version 2.0
July 2011
EMV Contents Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 1 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
Contents Best Practices Document 1
Version 2.0 July 2011 1
1 Introduction 3
2 General Considerations for Chip 3
2.1 EMV Transactions 4
2.2 Non-EMV Transactions using EMV functionality 4
3 Basic Transaction Processes 5
3.1 Purchase 5
3.1.1 Purchase - Card Present 5
3.1.2 Purchase with Cashback – Card Present 5
3.1.3 Purchase - Card Not Present 6
3.2 Authorisation 6
3.2.1 Authorisation 6
3.2.2 Pre-Authorisation 6
3.2.3 Incremental Authorisation 6
3.2.4 Status Check 7
3.3 Sale Completion 7
3.3.1 Sale Completion - Card Present 8
3.3.2 Sale Completion - Card Not Present 8
3.4 Reversal 8
3.5 Refund 9
3.6 Cancellation 9
3.7 Referral 10
4 EMV Transactions in Specific Industries 10
4.1 Hotels 10
4.1.1 Reservation 10
4.1.2 No-Shows 11
4.1.3 Check-In 11
4.1.4 Extended Stay or Higher than Estimated Spending 11
4.1.5 Check Out 11
4.1.6 Additional Charge after check-out 12
4.2 Fuel/Petrol Dispense 12
4.2.1 Pre-Authorisation 12
Contents EMV Recommendations for EMV Processing for Industry-Specific Transaction Types
Page 2 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
4.2.2 Sale Completion 13
4.3 Mobile Top-Up 13
5 Non-EMV Transactions using EMV functions 13
5.1 ATM Balance Inquiry 13
5.2 ATM Deposit /Cash Deposit 14
5.3 ATM Funds Transfer 14
5.4 POS Balance Inquiry 14
5.5 POS Deposit 14
5.6 Dynamic Currency Conversion 14
5.7 Bill Payment 15
6 Other Processing Considerations 15
6.1 Acquirer Truncation (Alternate Host Authorisation, Acquirer Stand-In) 15
6.2 Forced Acceptance for On-board Transactions 16
6.3 Card Removal 16
6.3.1 Premature Card Removal 16
6.4 Dual/Single-Messaging and Host/Terminal-Capture 17
6.5 Gratuities 18
6.6 PIN Management 18
6.7 Categories of Transactions that Require Authorisation 18
6.8 Online PIN Retries 18
Annex A – AUC and CVM Conditions 19
A.1 EMV Transactions 19
A.2 Non-EMV Transactions using EMV functionality 20
Index of Commonly Used Transaction Names 21
EMV Introduction Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 3 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
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. The document describes “best
practice” implementations in certain environments and for certain types of
transactions. Individual Payment Systems may require alternative processes or
implementations according to their own rules, and these should of course be
followed where applicable. 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.
Payment systems have established rules for chip transactions which in many cases
are no different from those for magnetic stripe transactions.
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 EMV
transactions. This would include any transaction where data such as a PAN and
expiry date are extracted and used to complete the transaction.
The transaction types listed throughout this document are typical of those found in
many markets. Other transaction types may exist in particular markets. The
principles described in this document can be used to modify those market-specific
practices for EMV support.
Payment Card Industry (PCI) requirements must always be followed whenever card
or transaction data is held in the terminal or Acquirer infrastructure.
General Considerations for Chip EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 4 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
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). Note that single-message and host-capture systems will pass the
Authorisation Request Cryptogram (ARQC) rather than the TC in the clearing file.1
As a general best practice, where possible, 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 (CVM) process. 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.”
2.2 Non-EMV Transactions using EMV functionality
Non-EMV 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 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
(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 for card
management such as to update PINs etc.
Non-EMV transactions should be completed using an AAC (decline cryptogram).
The only exceptions to this are PIN change and PIN unblock transactions which
may result in a TC. Note that an AAC generated for a non-EMV transaction simply
indicates completion and does not indicate transaction decline.
Non-EMV transactions using EMV functions must follow all relevant EMV
requirements. EMV functions should be executed in the same order as for EMV
1 Generally, the TC will be discarded. Please see “Dual/Single Messaging and
Host/Terminal Capture”
EMV Basic Transaction Processes Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 5 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
transactions, that is, non-EMV transactions using EMV functionaliy 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-EMV transactions using
EMV functionality.
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. 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
normally contain the Transaction Certificate (TC). Please see “Dual/Single
Messaging and Host/Terminal-Capture” for further discussion.
[Alternate Names]: Sale
3.1.1 Purchase - Card Present
Purchase – Card Present is a combination of an authorisation (whether sent online
or handled through interaction with the chip) and a clearing submission2. 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 authorisation
element of a purchase transaction differs from that of a pre-authorisation (discussed
later) as the final transaction amount is always known prior to a purchase
authorisation.
3.1.2 Purchase with Cashback – Card Present
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 without cashback3.
[Alternate Names]: Sale with Cashback, Cashback, Purchase with Cashback
2 In the single message environment, the online authorisation request and the clearing
record may be one financial message.
3 See “AUC and CVM Conditions” in Annex A.
Basic Transaction Processes EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 6 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
3.1.3 Purchase - Card Not Present
As there is no possibility of interaction between the card and accepting device in a
card not present transaction, the introduction of chip has no impact on this
transaction type.
[Alternate Names]: Authorisation (Single-Message and Host-Capture systems),
Sale, Financial Presentment
3.2 Authorisation
An Authorisation is a process where an Issuer or its agent approves a transaction.
Authorisations can take place either via online connection to the Issuer or its agent
or offline via the parameters stored in the terminal and on the chip.
The amount presented to the card in the First Generate AC of a pre-authorisation
shall be an estimated amount and shall be the same amount and currency that is
sent to the card Issuer in the authorisation request (if required).
3.2.1 Authorisation
The authorisation process will perform all the appropriate EMV functions for that
transaction, and online request message (if generated) should contain all the
appropriate chip data elements. The card and device interact in an identical
fashion to the Purchase process including CVM processing. The appropriate chip
data elements from both the authorisation request and response should be retained
for the Sale Completion transaction. These elements include the TC or ARQC. If
an authorisation is performed without the card being present, the introduction of
EMV has no impact and existing practices should continue.
[Alternate Names]: Authorisation, Authorisation – Only
3.2.2 Pre-Authorisation
If an authorisation takes place before the final amount is determined, then it is
known as a pre-authorisation. Pre-authorisations are subject to payment system
rules but normally will be EMV transactions. Note that in certain environments,
any “estimated amount” is likely to be the maximum dispensable value of goods or
services.
[Alternate Names]: Authorisation, Authorisation – Only
3.2.3 Incremental Authorisation
Where the final amount will exceed or is likely to 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
EMV Basic Transaction Processes Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 7 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
process as many incremental authorisations as are necessary to ensure the
authorised amount is greater than the final transaction amount.
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 pre-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.
If the card is present, the incremental authorisation can be chip-read, and should be
conducted as per “pre-authorisation” above.
[Alternate Names]: Supplemental Authorisation, Top-up Authorisation
3.2.4 Status Check
A Status Check is an online authorisation for a nominal amount.
In some markets, Status Checks are used as online Pre-Authorisations for
automated fuel dispensing, implicitly allowing up to a set amount (as defined by the
market / payment system regulations) to be used in the Sale Completion, while a
nominal amount (usually a single unit of currency) is used in the online
authorisation request.
Status Checks may 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
Status Checks have traditionally also been used to validate the authenticity of the
card used to make a reservation or in advance of delivery of goods or services. In a
card present environment, EMV functions such as dynamic Offline Data
Authentication (DDA/CDA) should be sufficient to ensure a card is not counterfeit.
If a Status Check is performed without the card being present, the introduction of
EMV has no impact and existing practices should continue.
[Alternate Name]: Card Verify
3.3 Sale Completion
A Sale Completion is the finalisation of a previously pre-authorised transaction,
often 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 retained chip data elements from the
associated Pre-Authorisation transaction including all fields needed to validate the
cryptogram, should be populated into the completion message.
[Alternate Names]: Post, Post Authorisation, Force Post, Authorisation Completion,
Pre-Authorisation Completion
Basic Transaction Processes EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 8 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
3.3.1 Sale Completion - Card Present
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 (and necessary), use Incremental Authorisations to ensure the
authorisation amount matches the Sale Completion amount. This will ensure the
cardholder‟s open-to-buy accurately reflects transaction activity.
If the cardholder is present at completion of the transaction, and the
Pre-Authorisation was obtained as Card Not Present, the merchant should reverse
the Pre-Authorisation (if reversals are available in the market4) and complete the
transaction with a chip-read Purchase.
3.3.2 Sale Completion - Card Not Present
Sale Completions are sometimes used when 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. In this case, the chip data obtained during the
pre-authorisation should be attached to all completion messages.
3.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.
“ATM Partial Reversal” (not to be confused with POS 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. 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 (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 an AAC should
be requested of the card to avoid unnecessary requests for online authorisations on
subsequent transactions.
4 In some markets reversals must be submitted within certain time frames.
EMV Basic Transaction Processes Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 9 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
3.5 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 only5.
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.
If the Processing Options Data Object List (PDOL) indicates that the
transaction amount and transaction type are to be included in the Get
Processing Options (GPO) command, it is recommended that the terminal
send the refunded amount as the transaction amount.
If the card does not contain a PDOL or if the PDOL indicates that the
transaction amount, but not the transaction type, is to be included in the
GPO command,the terminal should send a zero transaction amount to the
card.
Once the required data (either track 2 data or PAN and expiry date) is obtained, the
terminal should then stop the 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, merchant systems should be able to process the refund irrespective of the
cryptogram produced by the card. The decision to approve or decline the refund
should be made by the Acquirer or merchant in the same way as for magnetic stripe.
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.6 Cancellation
A Cancellation occurs when a Purchase or Sale Completion transaction is aborted
either during processing, or after processing. In a dual-message environment
Cancellation should 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
5 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.
EMV Transactions in Specific Industries EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 10 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
pressing a cancel button on the device. Cancellations also occur when a merchant
does not approve the cardholder‟s signature.
In all cases, initiation of a Cancellation should result in the cessation of processing
and clearing 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. 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.7 Referral
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. 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 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 either result in
production of a clearing record linked to the original authorisation (in which the
ARQC and related data of that authorisation should be included), or, more likely, it
will result in a completely new transaction taking place.
[Alternate Names]: Call for Authorisation, Voice Referral, Call-Me, Call Center
4 EMV Transactions in Specific Industries
4.1 Hotels
4.1.1 Reservation
Recommended Process: Status check
EMV EMV Transactions in Specific Industries Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 11 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
The reservation process will not normally involve the card being present or the chip
being read.
4.1.2 No-Shows
Recommended Process: Sale Completion – Card Not Present
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.1.3 Check-In
Recommended Process: Pre-Authorisation – Card Present
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 Hotel Check-In estimated amounts may be considerably larger than final
Check-Out amounts, it is recommended that the estimated amount is not displayed
to the cardholder 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.
[Alternate Names]: Vehicle Check-Out, Automobile Check-Out
4.1.4 Extended Stay or 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, incremental authorisation should be performed. The card
does not need to be present, and the authorisations should not include chip data.
4.1.5 Check Out
4.1.5.1 Express Check-Out
Recommended Process: Sale Completion - Card Not Present
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.
[Alternate Names]: Vehicle return, Automobile return
EMV Transactions in Specific Industries EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 12 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
4.1.5.2 Card Present - Check-Out
Recommended Process: Sale Completion - Card Present
Recommended Process: Reversal – Card Present & Purchase – Card Present
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
similar to Express Check-Out)
If the chip data from the Pre-Authorisation cannot be retreived and if the
market supports reversals, the recommended method is:
o The merchant reverses the original Pre-Authorisation and any
Incremental Authorisations
o 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.
[Alternate Names]: Vehicle return, Automobile return
4.1.6 Additional Charge after check-out
Recommended Process: Purchase – Card Not Present
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
4.2 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 offline transaction amount be performed before fuel is dispensed.
4.2.1 Pre-Authorisation
Recommended Process: Pre-Authorisation – Card Present
If a merchant is not using Status Check, then, if PIN entry is required, it is best
practice to display the maximum amount that may be dispensed before the PIN is
entered. 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.
EMV Non-EMV Transactions using EMV functions Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 13 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
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.
4.2.2 Sale Completion
Recommended Process: Sale Completion – Card Present
When the transaction is completed (that is, fuel dispensing is complete) and the
final transaction amount is known, a clearing record for the final amount should be
submitted containing the chip data from the Pre-Authorisation.
4.3 Mobile Top-Up
Recommended Process: Purchase – Card Present
Recommended Process: Purchase – Card Not Present
Mobile 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 data6, 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.
[Alternate Name]: Top-up
5 Non-EMV Transactions using EMV functions
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.
5.1 ATM Balance Inquiry
ATM Balance Inquiry allows a cardholder to determine the available balance for the
account(s) associated with the card.
6 Only PAN and expiry date should be stored, never full track 2 data.
Non-EMV Transactions using EMV functions EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 14 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
5.2 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.
5.3 ATM Funds Transfer
ATM Funds Transfer allows a cardholder to move funds from one account
associated with the card to another account.
5.4 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 Name]: Balance Return
5.5 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.
5.6 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. This recommendation is intended to allow co-existence of
DCC and EMV processing without interference with each other.
The transaction flow must allow for the candidate DCC transaction to be identified,
the currency conversion to be performed, and the cardholder choice to be exercised
before the first GENERATE AC stage of the EMV transaction. If this cannot be
accomplished within the flow of a full EMV transaction, an information-only
non-EMV transaction using EMV functionality can be performed to obtain the
information needed to initiate the DCC processing. Potential DCC candidates can
be identified by reading the Application Currency Code (EMV Tag „9F42‟) from the
card during the READ APPLICATION DATA stage of the transaction. However,
other methods may be used as appropriate to the market.
After completing an information-only non-EMV transaction to identify a DCC
candidate, the selected application should be retained. At this point, if the
EMV Other Processing Considerations Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 15 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
transaction is eligible for DCC, a new transaction amount will be calculated in the
new transaction currency and offered to the cardholder. The cardholder will have
the choice to accept or decline processing of the transaction in the converted
transaction currency, A new full EMV transaction should now be initiated with the
previously selected application, 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). Since the
original application selection data was retained, the original application can be
selected directly without performing cardholder selection.
If the transaction amount was converted to a currency different from the local
currency, floor limit processing and random transaction selection may need to
accommodate this change, either by applying the currency coversion factor to the
floor limit and transaction limit or by retaining a copy of the original transaction
amount.
The full EMV transaction should use the converted transaction 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 message (along with all cryptogram fields).
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.
6 Other Processing Considerations
6.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. Truncated authorisations may include under floor limit
transactions that would normally be completed offline at the terminal or over floor
limit transactions that would normally be sent online to the issuer for
authorisation. In both cases where Acquirer truncation takes place, if the EMV
process has resulted in an online authorisation request containing an ARQC, then
the Acquirer host must implement a mechanism to ensure that the terminal
completes the transaction in the EMV “Unable to go online”mode. Note that 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.
Other Processing Considerations EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 16 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
6.2 Forced Acceptance for On-board Transactions
In some environments where online authorisations are not normally available, such
as aircrafts and ferries, an attended terminal may have functionality allowing an
attendant to override the decline (AAC) returned by the ICC if the terminal
requests for an approval (TC) during the 2nd Generate AC command. If this occurs,
the merchant may put the AAC into the clearing message to indicate that the
transaction was declined by the chip (most likely due to card's risk management
settings).
In some situations merchants may need to obtain an authorisation before submitting an item for clearing (a deferred authorisation). In this case the ARQC may be used later to request an 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 clearing message subsequently.
To reduce the risk of fraudulent transactions, it is recommended that an attendant
force acceptance only if Cardholder Verification and Offline Data Authentication
are successful. Individual payment systems may have their own requirements for
processing EMV transactions at on-board terminals. In addition, payment systems
may allow forced acceptance in online-capable environments to provide service
during temporary communication outages.
6.3 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 experiences differ from magnetic stripe read transactions
where the card is swiped and immediately returned to the cardholder. To reinforce
the new behavior, after the EMV transaction has ended and is approved, the display
should indicate that the card be removed.
6.3.1 Premature Card Removal
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.
EMV Other Processing Considerations Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 17 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
6.4 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”7
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 cardholder‟s financial
institution.
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.8 Terminal-capture systems combine data from the 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.
7 “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.
8 “Messages” here refers to the components of the transaction needed for authorisation and
clearing. Audit, balancing records, and informational advices are not being considered.
Other Processing Considerations EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 18 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
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.
Each of the transaction types described can be implemented on single- and
dual-message systems, and on terminal- and host-capture systems.
6.5 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).
6.6 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.
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.
6.7 Categories of Transactions that Require Authorisation
A category of transactions may be authorised online due to market or payment
system requirements. The terminal should only set TVR bits as required in the
EMV Specifications. Setting of the „Merchant Forced Online‟ TVR bit is not
recommended as it may be treated as suspicious and result in unecessary declines.
An example would be where the market requires that particular types of
transactions (e.g. Purchase with Cashback) be authorised online.
6.8 Online PIN Retries
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 may accompany the PIN retry with 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 where the online PIN received in an
authorisation request was incorrect. If a new chip transaction is started, the
cardholder should not be asked to intervene.
EMV Annex A – AUC and CVM Conditions Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 19 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
Annex A – AUC and CVM Conditions
This annex describes Application Usage Controls (AUC) and Cardholder
Verification Method (CVM) conditions that are relevant to EMV and non-EMV
transaction types.
A.1 EMV 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.
Application Usage Control CVM Condition9
ATM Not
ATM10
Cash Cash- back
Purchase Unattended Cash
Manual
Cash
Cash- back
Not Cash
11
ATM Cash withdrawal Yes No Yes No No Yes No No No
POS Cash Advance No Yes Yes No No No Yes No No
Pre-Authorisation No Yes No No Yes No No No Yes
Purchase No12
Yes No No Yes No No No Yes
Purchase with Cashback No Yes No Yes Yes No No Yes No
Quasi-cash 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
9 This chart uses the new CVM Conditions. The old CVM condition “If cash or cashback”
maps to the new condition “If Unattended Cash”
10 “Valid at terminal other than ATMs”
11 Not Unattended Cash and Not Manual Cash and Not Cashback
12 If an ATM also supports purchases of goods or services, it is considered an unattended
POS device while dispensing goods or services.
Annex A – AUC and CVM Conditions EMV Recommendations for EMV Processing For Industry-Specific Transaction Types
Page 20 July 2011 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
A.2 Non-EMV Transactions using EMV functionality
The following table illustrates which CVM Conditions are recommended for device
applications to apply to common Non-EMV 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-EMV Transactions
using EMV functionality.
CVM Condition
Unattended
Cash
Manual
Cash
Cashback Not Cash
ATM Balance Inquiry Yes No No No
ATM Bill Payment Yes No No No
ATM Deposit No No No Yes
ATM Funds Transfer Yes No No No
ATM PIN Change/ Unblock Yes No No No
POS Balance Inquiry No No No Yes
POS Bill Payment No No No Yes
POS Funds Deposit No No No Yes
Refund N/A N/A N/A N/A
EMV Index of Commonly Used Transaction Names Recommendations for EMV Processing for Industry-Specific Transaction Types
July 2011 Page 21 ©1994-2011 EMVCo LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Recommendations
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the
user and EMVCo found at http://www.emvco.com/.
Index of Commonly Used Transaction Names
ATM Balance Inquiry ................... 13, 20
ATM Deposit .................................. 14, 20
ATM Funds Transfer ..................... 14, 20
ATM Partial Reversal ........................... 8
Authorisation4, 5, 6, 7, 8, 10, 11, 12, 15,
16, 17
Authorisation Completion .................... 7
Balance Return.................................... 14
Bill Payment .................................. 15, 20
Call for authorisation.......................... 10
Call-Me ................................................. 10
Cancellation ........................................... 9
Card Verify ............................................ 7
Cash Advance ...................................... 17
Cash Deposit ........................................ 14
Cashback .................................... 5, 19, 20
Check-In ................................................ 11
Check-Out ............................................ 12
Credit ..................................................... 9
Express Check-Out ............................. 11
Force Post .............................................. 7
Fuel/Petrol Dispense ........................... 12
Hotel ..................................................... 10
Incremental Authorisation ......... 6, 8, 12
Manual Cash ....................................... 19
Mobile Top-up ...................................... 13
Partial Reversal .................................... 8
PIN Change/Unblock .......................... 18
POS Balance Inquiry .................... 14, 20
POS Cash Advance .............................. 19
POS Deposit......................................... 14
POS Partial Reversal ............................ 8
Post ......................................................... 7
Post Authorisation ................................ 7
Pre-Authorisation5, 6, 7, 8, 11, 12, 13,
19
Pre-Authorisation Completion ............. 7
Purchase ...... 5, 6, 8, 9, 10, 12, 13, 17, 19
Purchase with Cashback ................ 5, 19
Refund .............................................. 9, 20
Reservation .......................................... 10
Return .............................................. 9, 14
Reversal ..................................... 8, 10, 12
Sale ........... 5, 6, 7, 8, 9, 11, 12, 13, 17, 19
Sale Completion5, 6, 7, 8, 9, 11, 12, 13,
17, 19
Sale with Cashback ............................... 5
Status Check ................................... 7, 19
Supplemental Authorisation ................ 7
Top-up .............................................. 7, 13
Top-up Authorisation ............................ 7
Voice Referral ...................................... 10