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



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



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




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




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




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




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





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




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.





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




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




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




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




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




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




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




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




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




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




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




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




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

recommendations for emv processing for industry-specific transaction types v2 20110801075511607

Documents