Recommendations for EMV

Processing for
Industry-Specific Transaction
Types

Version 1.0
June 12th 2006

This document contains proprietary information of EMVCo LLC. Copyright 2006. All rights reserved.
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

Copyright
The information contained in this manual is proprietary and
confidential to EMVCo. LLC.
This material may not be duplicated, published, or disclosed, in
whole or in part, without the prior written permission of EMVCo. LLC.

Trademarks
EMV™ is a trademark owned by EMVCo. LLC.
All third-party product and service names are trademarks or
registered trademarks of their respective owners.

Media
This document is available on the EMVCo Web site at
www.emvco.com

This document contains proprietary information of EMVCo LLC. Copyright 2006. All rights reserved.
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

Table of Contents
1 Introduction 1
2 General Considerations for Chip 1
2.1 EMV Transactions 1
2.2 Non-EMV Transactions using EMV functionality 2
3 Basic Transaction Processes 2
3.1 Purchase 2
3.1.1 Card present - (“Purchase – Card Present”) 3
3.1.2 Card Not Present - (“Purchase – Card Not Present”) 3
3.2 Authorisation 3
3.2.1 Pre-Authorisation(“Pre-Authorisation”) 3
3.2.2 Incremental Authorisation - (“Incremental Authorisation”) 4
3.2.3 Status Check (“Status Check”) 4
3.3 Sale Completion 5
3.3.1 Card present - (“Sale Completion – Card Present”) 5
3.3.2 Card Not Present - (“Sale Completion – Card Not Present”) 5
3.4 Reversal - (“Reversal”) 5
3.5 Refund - (“Refund”) 6
3.6 Cancellation - (“Cancellation”) 6
3.7 Referral - (“Referral”) 7
4 EMV Transactions in Specific Industries 7
4.1 Hotels 7
4.1.1 Reservation 7
4.1.2 No-Shows 7
4.1.3 Check-In 7
4.1.4 Extended Stay or Higher than Estimated Spending 8
4.1.5 Check Out 8
4.1.6 Additional Charge after check-out 8
4.2 Fuel/Petrol Dispense 9
4.2.1 Pre-Authorisation 9
4.2.2 Sale Completion 9
4.3 Mobile Top Up 9
5 Non-EMV Transactions using EMV functionality 10
5.1 ATM Balance Inquiry 10
5.2 ATM Deposit /Cash Deposit 10
5.3 ATM Funds Transfer 10
5.4 POS Balance Inquiry 10
5.5 POS Deposit 10
5.6 Dynamic Currency Conversion 10
5.7 Bill Payment 10
6 Other Processing Considerations 11
6.1 Acquirer truncation (Alternate host Authorisation, Acquirer Stand-In) 11
6.2 Card Removal 11
6.2.1 Premature Card Removal 11
6.3 Dual/Single Messaging and Host/Terminal Capture 11
6.4 Gratuities 12
6.5 PIN Management 12
Annex – AUC and CVM Conditions 13
A.1 EMV Transactions 13
A.2 Non-EMV Transactions using EMV functionality 14
Index of Commonly Used Transaction Names 15

________________________________________________________________________________
Page iii June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

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 describes
“best practice” implementations in certain environments and for certain types of transactions.
Only those areas impacted by chip technology are described.

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.

This discussion is intended solely as a guideline and should be used in conjunction with the
current EMV books 1 to 4. Individual markets may implement alternate approaches and may
mandate particular processing in that market.

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 use of Offline PIN.

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

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-draft-capture systems will
pass the Authorisation Request Cryptogram (ARQC) and not the TC in the clearing file. 1

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

1
Generally, the TC will be discarded. Please see “Dual/Single Messaging and Host/Terminal Capture”

________________________________________________________________________________
Page 1 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

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 can be readily used to complete these 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 for card management such as to
update PINs etc.

Non EMV transactions should be completed by an AAC. 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 is not a “decline”.

Transactions using EMV functions must follow all relevant EMV requirements. EMV functions
should be executed in the same order as for EMV transactions, that is, non-EMV transactions using
EMV functionaliy should follow the EMV transaction flow.

See “AUC and CVM Conditions” in Annex 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. It is a combination of an Authorisation (whether sent online or
handled through interaction with the chip) and a clearing submission 2 . 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 to
that of a pre-authorisation (discussed later) as the final transaction amount is always known prior to
a purchase authorisation.

2
In the single message environment, the online authorisation request and the clearing record may be one financial message.

________________________________________________________________________________
Page 2 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

3.1.1 Card present - (“Purchase – 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-only transaction 3 .

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]:
Authorisation (Single Message and Host-Capture systems), Sale, Sale with Cashback,
Cashback, Purchase with Cashback, Financial Presentment

3.1.2 Card Not Present - (“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. It should
be noted that if account data is stored from a previous card-present transaction in order to
create a card not present transaction, this storage must be conducted in line with the Payment
Card Industry Data Security Standards (PCI DSS) and card scheme rules.

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 on the chip.

3.2.1 Pre-Authorisation(“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 scheme rules but normally will be EMV
transactions. 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 message (if required). Note that in unattended
environments, this “estimated amount” is likely to be the maximum dispensable value of
goods or services.

The Pre-Authorisation process will perform all the EMV functions and the 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 Pre-Authorisation request and response
should be retained for the Sale Completion transaction. These elements include the TC or
ARQC. The full track 2 data should not be retained (in line with Payment Card Industry
Data Security Standard (PCI DSS)) but the PAN and expiry date will be required. If a
pre-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
See “AUC and CVM Conditions” in Annex.

________________________________________________________________________________
Page 3 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

3.2.2 Incremental Authorisation - (“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. Market practice or scheme rules may allow
variances above the actual pre-authorised amount which are still covered by the approval. The
Incremental Authorisation will be for the difference between the original pre-authorisation and the
actual or estimated final amount. A merchant may process as many incremental authorisations as
are necessary to ensure the authorised amount is greater than the final transaction amount.

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, as allowed by the Payment Card Industry Data
Security Standard (PCI DSS) and card scheme rules.

If the card is present, the incremental authorisation can be chip-read, and should be conducted
as per “pre-authorisation” above.

[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, Top-up Authorisation

3.2.3 Status Check (“Status Check”)

A Status Check is an authorisation for a single currency unit.

In some markets, Status Checks are used as online Pre-Authorisations for fuel dispensing,
implicitly allowing up to a set amount (as defined by the market / scheme regulations) to be
used in the Sale Completion, while a nominal amount is used in the online authorisation request.
Offline Status Checks of this type are not appropriate in a chip environment as the nominal
amount cannot be related to the true pre-approved amount.

Status Check 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 that the card used to make a reservation,
or to pay for services in advance of delivery, is authentic. In a card present environment, EMV
functions such as Offline Data Authentication (SDA/DDA) should be sufficient for such uses – that
is, a non-EMV transaction should be used and a status check is no longer necessary.

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

________________________________________________________________________________
Page 4 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

3.3 Sale Completion

A Sale Completion is the financial settlement 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. It is recommended that the authorisation approval code from the
original pre-authorisation response message (as opposed to those obtained from incremental
authorisations) be used in this message as this code will generally be for the highest value.

[Alternate Names]:
Post, Post Authorisation, Force Post, Authorisation Completion, Pre-Authorisation Completion

3.3.1 Card present - (“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 market 4 ) and complete the transaction with a chip-read Purchase.

3.3.2 Card Not Present - (“Sale Completion – Card Not Present”)

Sale Completions are sometimes also 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 - (“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) 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.

4
In some markets reversals must be submitted within certain time frames.

________________________________________________________________________________
Page 5 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

3.5 Refund - (“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 only 5 .

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 is to be included in the Get Processing Options command, it is recommended
that the terminal sends 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 card to produce 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 - (“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 pressing a cancel button on the device.
Cancellations also occur when a merchant does not approve the cardholder’s signature or if the
device fails to validate an ARPC (and the card’s Application Default Action is set to decline).

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 on-line, 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).

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.

________________________________________________________________________________
Page 6 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

It is recommended that the device produce a receipt for the cardholder showing that the original
transaction has been cancelled.

[Alternate names]:
Void

3.7 Referral - (“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 prior to approving a transaction. A Referral is not a
“transaction”; it is an exception process for Purchase.

Card present 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 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
Please refer to the [Alternative Name] section for Vehicle Rental and other Travel and
Entertainment Industry.

4.1.1 Reservation
Recommended Process: Status check

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

For PIN-based transactions, it is recommended to display no amount to the cardholder and a

message that reads “Please enter your PIN”.

The estimated transaction amount is the amount presented to the chip card. If online
________________________________________________________________________________
Page 7 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

Authorisation is required, it is also the amount sent online.

[Alternative Name]:
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 then incremental authorisation should be performed.

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 possible, the chip
data from the original Pre-Authorisation should be included.

[Alternative Name]:
Vehicle return, Automobile return

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

If the chip data from the Pre-Authorisation cannot be retreived and if the market supports
reversals the recommended method is:

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

[Alternative Name]:
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.

________________________________________________________________________________
Page 8 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

[Alternate Name]:
Top up/Additional Expense, Signature on file

4.2 Fuel/Petrol Dispense

The practice of requesting an Authorisation for a token amount (for example a single currency unit)
is not recommended for chip transactions.

4.2.1 Pre-Authorisation
Recommended Process: Pre-Authorisation – Card Present

For chip transactions in an unattended petrol environment it is recommended that a

Pre-Authorisation transaction be completed for the maximum offline transaction amount before fuel
is dispensed.

If PIN entry is required, it is best practice to display the maximum 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 on-line 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 online authorisation is required by the EMV transaction).

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 should be submitted containing the chip data
from the Pre-Authorisation. Single message environments may require an adjustment to the
pre-authorised amount.

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 data 6 , 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 Names]:
Top-up

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

________________________________________________________________________________
Page 9 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

5 Non-EMV Transactions using EMV functionality

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.

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.

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 Names]:
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) should always take place before full EMV processing
commences. DCC devices should perform an information-only non-EMV transaction using EMV
functions to obtain the Primary Account Number, since most currency conversion systems use the
IIN/BIN or account range to identify whether the card is eligible for DCC.

After completing a non-EMV transaction to obtain the BIN/IIN or account range, the selected
application should be retained. Once the transaction currency has been determined a new full EMV
transaction should be initiated with the previously selected application.

Note that the device may also have to apply the currency conversion factor to the floor limit used to
determine when online authorisation will be required by the device. 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).

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.

________________________________________________________________________________
Page 10 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

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.

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

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

6.3 Dual/Single Messaging and Host/Terminal Capture

In “Dual Message” processing, the Authorisation occurs at the time of the Purchase or Cash
Advance transaction using one message, and the transaction is “settled” 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 Messages 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,

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.

________________________________________________________________________________
Page 11 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

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.

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

________________________________________________________________________________
Page 12 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

Annex – AUC and CVM Conditions

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 Condition 9

ATM Not Cash Cash-ba Purchase Unattended Manual Cashback Not
ATM 10 ck Cash Cash Cash 11
ATM Cash Yes No Yes No No Yes No No No
withdrawal
POS Cash No Yes Yes No No No Yes No No
Advance
Pre-Authorisat No Yes No No Yes No No No Yes
ion
Purchase No 12 Yes No No Yes No No No Yes
Purchase with No Yes No Yes Yes No No Yes No
Cashback
Quasi-cash No Yes No No Yes No No No Yes
Sale No Yes No No Yes No No No Yes
Completion
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.

________________________________________________________________________________
Page 13 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

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 on 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 Manual Cashback Not Cash
Cash 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/ Yes No No No
Unblock
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

________________________________________________________________________________
Page 14 June 2006
 Recommendations for EMV Processing
for Industry-Specific Transaction Types
__________________________________________________________________________________________________________

Index of Commonly Used Transaction Names

ATM Balance Inquiry....................13, 19 Partial Reversal .................................... 7, 9
ATM Deposit ..................................14, 19 PIN Change/Unblock .......................... 16
ATM Funds Transfer.....................14, 19 POS Balance Inquiry .................... 14, 19
ATM Partial Reversal .......................... 9 POS Cash Advance ............................. 18
Authorisation4, 5, 6, 7, 8, 9, 10, 11, 12, POS Deposit ........................................ 14
13, 15, 16 POS Partial Reversal ............................. 7, 9
Authorisation - Only................................. 6 Post ..................................................... 7, 8
Authorisation Completion ......................... 8 Post Authorisation................................. 7, 8
Balance Return .......................................14 Pre-Authorisation5, 6, 7, 8, 11, 12, 13,
Bill Payment..................................14, 19 18
Call for authorisation ...............................10 Pre-Authorisation Completion.................... 8
Call-Me..................................................10 Purchase.......... 5, 6, 8, 10, 12, 13, 15, 18
Cancellation.........................................10 Purchase with Cashback ............ 5, 6, 18
Card Verify............................................ 8 Refund ............................................. 9, 19
Cash Advance ......................................15 Reservation ......................................... 11
Cash Deposit........................................14 Return ............................................. 10, 14
Cashback ...................................6, 18, 19 Reversal................................. 7, 9, 10, 12
Check-In ..............................................11 Sale .... 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 18
Check-Out............................................12 Sale Completion5, 6, 7, 8, 9, 10, 11, 12,
Credit ...................................................10 13, 15, 18
Express Check-Out.............................11 Sale with Cashback ................................... 6
Force Post ..........................................7, 8 Status Check ................................... 7, 18
Fuel/Petrol Dispense ...........................12 Supplemental Authorisation ................ 7
Hotel.....................................................11 Top-up.............................................. 7, 13
Incremental Authorisation..........7, 8, 12 Top-up Authorisation................................. 7
Manual Cash .......................................18 Voice Referral ........................................ 10
Mobile Top-up ......................................13

________________________________________________________________________________
Page 15 June 2006