Professional Documents
Culture Documents
Version 1.0
17 November 2005
This document is posted for a comment period of 60 days ending end of February 2006
DRAFT FOR REVIEW PURPOSES ONLY
1. 2.
Introduction General Considerations for Chip 2.1 Core Transactions 2.2 Non-Core Transactions 3. EMV Transactions in Specific Industries 3.1 General Retail Considerations 3.1.1 Purchase 3.1.2 Pre-Authorisation 3.1.3 Status Check 3.1.4 Sale Completion 3.1.5 Sale Completion with Incremental Authorisation 3.2 Lodging and Vehicle Rental Transactions 3.2.1 Reservation 3.2.2 Check-In 3.2.3 Additional/Delayed Charges 3.2.4 Express Check-Out 3.2.5 Card present Check-Out 3.3 Fuel/Petrol Dispense 3.4 Automated Teller Machines 3.4.1 ATM Cash Withdrawal 3.4.2 ATM Balance Inquiry 3.4.3 ATM Deposit /Cash Deposit 3.4.4 ATM Funds Transfer 3.5 Other Special Environments 3.5.1 Top-up 3.5.2 Tip Adjust 3.5.3 POS Cash Advance 3.5.4 Quasi-Cash 3.5.5 POS Balance Inquiry 3.5.6 POS Deposit 3.5.7 Bill Payment 3.5.8 Application Unblock 3.5.9 PIN Change/Unblock 4. Special Transactions in Industries-independent Environments 4.1 Refund 4.2 Referrals 5. Other Processing Considerations 5.1 Dynamic Currency Conversion 5.2 Gratuities 5.3 Cancellation 5.4 Reversal 5.5 Acquirer truncation (Alternate host Authorisation, Acquirer Stand-In) 5.6 Transaction Amount Requested in the PDOL 5.7 Account Type Requested in the PDOL 5.8 CVM Required by Device
4 4 4 4 5 5 5 6 6 6 7 7 7 7 8 8 8 8 9 9 9 9 9 9 9 10 10 10 10 10 10 10 11 11 11 11 12 12 12 12 12 13 13 13 13
5.9 Processing Restrictions / Application Usage Control (AUC) - Goods and Services 5.10 Declined Transactions 5.11 Merchant Forced Transaction Online 5.12 Card Removal 6. Notes 6.1 Dual/Single Messaging and Host/Terminal Capture 6.2 ATMs Annex - AUC and CVM Conditions A.1 Core Transactions A.2 Non-Core Transactions Index of Commonly Used Transaction Names
13 13 14 14 14 14 15 16 16 17 18
1. Introduction
This bulletin describes a recommended approach to handling certain types of EMV-enabled transactions and environments. It is intended to enable vendors to implement best practice implementations in the areas described below. The main areas covered are general retail, hotel environments, unattended petrol environments, referral processing, and refund processing. Only those areas impacting chip technology are described. This discussion is intended solely as a guideline; individual markets may implement alternate approaches and may mandate particular processing in that market.
2.1
Core Transactions
Core Transactions directly result in the purchase of goods or services and/or in the disbursement of cash. The EMV specifications address Core Transactions. Core Transactions will execute all mandatory functions defined in EMV and may execute optional EMV functions. Approved Core Transactions should result in generation of a Transactions Certificate (TC). The only exception may occur when the Acquirer does not support full chip data, and a card personalized to require ARPC validation may produce an AAC on the second Generate AC. Note also that Single-message and host-draft-capture systems will pass the Authorisation Request Cryptogram (ARQC) and not the TC in the clearing file. Financial transactions terminated in mid-processing, either by errors or by merchant cancellation, should be closed with a Generate AC for an AAC. As a general best practice, where possible and where known, the final amount, whether for goods, services, or cash disbursement, should be displayed to the Cardholder for confirmation.
2.2
Non-Core Transactions
Non-core Transactions refer to transactions commonly employed to support the retail or cash disbursement environment, but do not directly result in the purchase of a good or service nor in the disbursement of cash.
EMV functions that extract information or request identification or authentication can be readily used to complete these transactions. Risk management is intended to maximize offline Authorisation capability for core transactions, while controlling risk. Therefore, functions that would affect future risk management decisions should not be executed, except by core transactions. EMV functions can be used for the following purposes: Information: In order to obtain information, the device can use Application Selection, Initiate Application Processing, and Read Application Data. Identification: In order to identify the Cardholder, the device can use Cardholder Verification methods as defined in the CVM list (Cardholder Verification). Authentication: In order to check the authenticity of the payment application, the device can use Offline Data Authentication as part of offline processing, or may allow the Issuer to validate the payment application using Card Authentication Method as part of online processing. Card Management: Issuer Script Processing may be used to update PINs, unblock applications, etc.
Non-core transactions should always be completed with an AAC1. This will ensure card risk management processes are not affected. Note that an AAC generated for a non-core transaction simply indicates completion, and is not a decline. Transactions using EMV functions must follow all relevant EMV requirements. See AUC and CVM Conditions to determine appropriate CVM Conditions and Processing Restrictions for common non-core transaction types.
PIN Change/Unblock may generate a TC. In a single message environment, the online Authorisation request and the clearing record are one financial message.
The exchange of goods and/or services for monetary value can also be completed using a Pre-Authorisation and a Sale Completion as discussed below. Alternate Names: Authorisation (Single Message and Host-Capture systems), Sale, Sale with Cashback, Cashback, Purchase with Cashback Relevant Transaction Types4: Retail Purchase, Retail Purchase with Cash Back, Hotel Check-Out (Card Present); Vehicle Collection, Vehicle Rental or Automobile Rental (Card Present); Restaurant Payment and Tip, Fuel or Petrol Purchase (when actual or maximum amount is Authorised) 3.1.2 Pre-Authorisation Pre-Authorisation occurs when a request is made for pre-approval of the transaction amount before the transaction is completed. Where the transaction amount changes from the pre-Authorised amount, as in car rental and hotel environments, a subsequent Incremental Authorisation may be issued for the additional amount. Incremental Authorisations are usually Card Not Present and do not contain chip data. Merchants can store the cards PAN and expiry date in order to perform any incremental Authorisations required5. Alternatively, the original Pre-Authorisation may be reversed and either a new Pre-Authorisation issued or the transaction is completed with a Purchase. The Pre-Authorisation process will perform all the EMV functions and the request message should contain all the appropriate chip data elements. The card and device interact in an identical fashion to the Purchase process. The appropriate chip data elements from both the Pre-Authorisation request and response should be retained for the Sale Completion transaction (including the TC or ARQC). Alternate Names: Authorisation - Only, Top-up Authorisation Relevant Transaction Types: Hotel Check-In (Card Present); Vehicle Collection Check-In or Automobile Rental (Card Present); Restaurant Pre-Tip 3.1.3 Status Check In some markets, Status Checks are used as online Pre-Authorisations for fuel dispensing, implicitly allowing up to a set amount (as defined in the market regulations) to be used in the Sale Completion. Status Checks are not appropriate in a chip environment for this type of Pre-Authorisation. Status Checks may also be used to reset cumulative offline counters for those customers that have exceeded their offline limits, without requiring those customers to make a purchase or withdrawal in order to get an online Authorisation. An online Status Check may also be used by airlines at Check-In to ensure the card used to purchase the transaction is valid. Alternate Name: Card Verify 3.1.4 Sale Completion A Sale Completion is the financial settlement of a previously Authorised transaction, often where the cardholder and card are no longer present. The final transaction amount may differ from the previously Authorised amount, usually within some range set by the market. The retained chip data elements from the
4 5
This list is indicative, rather than exhaustive. See also the related Industry sections. Only PAN and expiry date should be stored, never full track 2 data.
associated Pre-Authorisation transaction, including all fields needed to validate the cryptogram, should be populated into the settlement transaction. If the cardholder is present at completion of the transaction (i.e. Hotel Check-Out), and the Pre-Authorisation was obtained as Card Not Present, the merchant should reverse the Pre-Authorisation and complete the transaction with a Purchase. If the cardholder is present at completion of the transaction, and the Pre-Authorisation was Card Present, it is recommended that the merchant either reverse the Pre-Authorisation and complete the transaction with a Purchase or, if available, use Incremental Authorisations to ensure the Authorisation amount matches the Sale Completion amount. This will ensure the cardholders open-to-buy accurately reflects transaction activity. Pre-Authorisations with Sale Completions are sometimes also used where the cardholder purchases a number of items that may be shipped at different times. This can result in one Pre-Authorisation with a number of Sale Completions whose total adds up to the amount of the Pre-Authorisation. Alternate Names: Post, Post Authorisation, Force Post, Authorisation Completion, Pre-Authorisation Completion Relevant Transaction Types: Hotel Check-Out (where final amount is within market limits of previously Authorised amounts), Hotel Top-up/Additional Expenses, Hotel Express Check-Out, Hotel - Delayed or Late Charges; Vehicle Return or Automobile Rental Return (where final amount is within market limits of previously Authorised amounts); Vehicle Top-up/Additional Expenses, Vehicle Express Vehicle Return, Vehicle - Delayed or Late Charges; Restaurant Post-Tip, Express Check-Out 3.1.5 Sale Completion with Incremental Authorisation As previously mentioned (See Incremental Authorisations), Incremental Authorisations may be used where the final amount exceeds the market-allowed variance from the authorised amount. Incremental Authorisation are normally done as Card Not Present, in which case there are no chip considerations for the Incremental Authorisation. The retained chip data elements from the original Pre-Authorisation transaction, including the TC (or ARQC), Cryptogram Date, and Cryptogram Amount, should be populated into the Sale Completion.. Alternate Names: Post, Post Authorisation, Force Post, Partial Reversal (When the final amount is less than the pre-Authorised amount (not truly a Reversal)), Incremental Authorisation (This term may apply when the final amount is greater than the pre-Authorised amount), Supplemental Authorisation Relevant Transaction Types: Hotel Check-Out (where final amount exceeds market limits of previously Authorised amounts); Vehicle Return or Automobile Rental Return (where final amount exceeds market limits of previously Authorised amounts)
3.2
3.2.1
Authorisation
3.2.2
Check-In/Rental A normal EMV-based Pre-Authorisation is completed at Check-In to check that the card and cardholder are genuine and, according to the appropriate scheme rules, guarantee funds before the final transaction amount is known. Acquirers / merchants will determine an appropriate estimated amount to be authorised, based on market requirements.
For PIN based transactions, there are two options at the time of PIN entry: Display the estimated amount to the cardholder Display no amount, and a message that reads Please enter your PIN.
In both cases the estimated transaction amount is the amount presented to the chip card. If online Authorisation is required, it is also the amount sent online. 3.2.3 Additional/Delayed Charges Additional Charges over the original Pre-Authorized amount can be authorised using Incremental Authorisations, where supported. Alternatively, the original Pre-Authorisation may be reversed and either a new Pre-Authorisation issued, or the transaction can be completed with a Purchase. Any additional charges identified after Check-Out should be processed as separate, card not present, transactions. The chip data from the Pre-Authorisation should not be submitted in this clearing record. Sales Completion 3.2.4 Express Check-Out/Return It is not necessary to perform a full EMV card-read transaction once the final transaction amount is known. A Sales Completion is generated for the final billing amount and, if possible, the chip data from the original Pre-Authorisation should be included. 3.2.5 Card Present Check-Out/Return Either of the following two methods for card present Check-Out are recommended: A Sales Completion is generated for the final billing amount and, if possible, the chip data from the original Pre-Authorisation should be included (this is similar to express Check-Out) The merchant reverses the original Pre-Authorisation and any Incremental Authorisations and does a full EMV transaction (Purchase) for the final billing amount, presenting the data from this transaction in the clearing.
In either case, the final total amount should be displayed to the cardholder.
3.3
Fuel/Petrol Dispense
For chip transactions in an unattended petrol environment it is recommended that a full EMV transaction be completed for the maximum offline transaction amount before fuel is dispensed. The maximum offline amount is the appropriate floor limit as defined by the payment schemes. The practice of requesting an Authorisation for a token amount (for example a single currency unit) is not recommended for chip transactions. It is best practice to display the maximum transaction amount to the cardholder before the transaction is authorised (via chip or online). If PIN entry is required, it is best practice to display amount before the PIN is entered. The merchant can optionally let the cardholder choose a lower maximum amount for their specific transaction. The value confirmed by the cardholder should be the same as the amount presented to the chip card and sent online for Authorisation (if Authorisation is required by the EMV transaction). An alternative is to display no amount, and a message which simply reads Please enter your PIN. The maximum transaction amount should be presented to the chip card and sent online for authorisation (if authorisation is required by the EMV transaction).
When the transaction is completed (that is, fuel dispensing is complete) and the final transaction amount is known, a clearing record should be submitted containing the chip data from the Pre-Authorisation. Single message environments may require an adjustment to the pre-authorised amount.
3.4
3.4.1
ATM Non-Core Transactions The following transactions can be performed using Application Selection, Initiate Application Processing, Read Application Data, Cardholder Verification, Online Processing using Card Authentication Method, and Issuer Script Processing. They should be completed with an AAC. 3.4.2 ATM Balance Inquiry ATM Balance Inquiry allows a cardholder to determine the available balance for the account(s) associated with the card. 3.4.3 ATM Deposit /Cash Deposit ATM Deposit allows a cardholder to put funds into an account associated with the card. It is expected that these transactions will be performed at a device under direct control of an issuer. 3.4.4 ATM Funds Transfer ATM Funds Transfer allows a cardholder to move funds from one account associated with the card to another.
3.5
3.5.1
As noted earlier, Purchase and Pre-Authorisation transactions have their own rules. An ATM could support Offline Data Authentication for the dispensing of goods and services.
Alternate Names: Mobile Top-up 3.5.2 Tip Adjust Tip Adjust allows addition of a tip to a restaurant charge. No authorisation or advice is issued. The Adjust transactions should not have any chip considerations, other than to ensure that only the transaction amount is updated, not the cryptogram final amount used to generate the TC. (Some markets may ask for tip amount before proceeding with the authorisation, so there will be no need for a special transaction). 3.5.3 POS Cash Advance POS Cash Advance allows a cardholder to receive cash against the open-to-buy or source of funds. Where allowed for merchants, it is most often restricted to certain T&E merchants, such as Cruise Ships and Lodging. The processing is the same as a Purchase, however the transaction must be online authorised.8 Manual Cash Advance may also be performed at financial institutions, where a teller disburses cash. Alternate Names: Manual Cash, Manual Cash Advance, Attended Cash 3.5.4 Quasi-Cash Quasi-Cash is the purchase of items (such as gaming chips, opening deposits, or money orders) that are directly convertible to cash. The process flow will be the same as a Purchase. Quasi-cash does have its own processing restrictions. POS Non-Core Transactions The following transactions can be performed using Application Selection, Initiate Application Processing, Read Application Data, Cardholder Verification, Online Processing using Card Authentication Method, and Issuer Script Processing. They should be completed with an AAC. 3.5.5 POS Balance Inquiry POS Balance Inquiry allows a cardholder to determine the available balance for the account associated with the card, typically a prepaid account. Alternate Names: Balance Return 3.5.6 POS Deposit POS Deposit allows a cardholder to put funds into an account associated with the card.These transactions take place at an agent (such as a post office) empowered to accept deposits on behalf of the financial institution. 3.5.7 Bill Payment Bill Payment allows a cardholder to pay invoices, commonly utility bills, through an ATM or POS device, using an account associated with the card. 3.5.8 Application Unblock Issuer Scripting can be used to unblock an application..
Only PAN and expiry date should be stored, never full track 2 data.
8 Different CVM conditions and Application Usage Controls apply as shown in the section:
3.5.9
PIN Change/Unblock PIN Change/Unblock allows a cardholder to change or unblock a PIN associated with an application on the card. The local markets where this is implemented will define the requirements. Because the PIN Change/Unblock transaction may be used to also reset offline cumulative counters, it is the only non-EMV transaction that may result in the generation of a TC. These transactions should be performed at a device under direct control of the issuer (normally an ATM) or at a device in a network in which the issuer participates and for which the appropriate operational procedures and liabilities have been defined.
4.2
Referrals
Referrals are intended as a fraud control tool for Issuers to use when more information is needed to verify the identity of the cardholder prior to approving a transaction. A Referral is not a transaction; it is an exception process for Purchase. When a referral Authorisation response is received from the card issuer, the terminal should request an AAC from the card at the second GENERATE AC request. Generation of an AAC does not mean this transaction is declined; it completes the EMV transaction flow, so that the normal referral procedure can take place. If the merchant system supports it, the ARQC may be included with the clearing record generated by the manual referral process.
In some online-only host-capture environments, the Refund transaction may be sent online. However, it is sent as an advice; the acquiring host will not forward the message.
Alternate Names: Call for Authorisation, Voice Referral, Call-Me, Call Center
5.2
Gratuities
It is recommended that any gratuity is added to the transaction amount before the EMV transaction starts. This will ensure that the final billing amount is both presented to the card during the transaction and displayed to the cardholder at the time of PIN entry (if required).
5.3
Cancellation
A Cancellation occurs when a previously completed Purchase or Sale Completion transaction is marked to cancel authorisation and/or clearing of that transaction; usually when an error is made. The most common cause of Cancellation is an error in the amount. A Cancellation may also occur if a Merchant does not approve the cardholders signature. Failure of a card to validate an ARPC may also require a Cancellation if the cards Application Default Action is set to decline, and Reversals are not supported. Termination of a transaction in process, such as by the merchant pressing a Cancel button, should result in cessation of the processing and clearing of any data elements. This merchant termination of an in-process transaction may also be referred to as Cancellation. Some markets require that Cancellation processing also generate a Reversal, while some are satisfied to simply remove the cancelled transaction from the clearing batch. If the transaction with the card has not reached the point where an ARQC has been requested, the card can simply be powered off. If an ARQC has been received from the card, then an AAC should be requested to avoid unnecessary requests for online Authorisations on subsequent transactions. If the device has received a TC or AAC from the card, the transaction is completed and can now be cancelled (removed from the batch or marked as void). In some markets, the device will need to produce a receipt for the cardholder showing that the original transaction has been cancelled. Alternate Names: Void
5.4
Reversal
A Reversal is sent to the Acquirer and on to the Issuer to notify them that the previous Authorisation response was not delivered to the Acceptance Device (System Reversal) or has been annulled by the Acceptance Device. Reversals are a function of the transaction network or of the device application and do not require interaction with the card for generation of the Reversal message itself.
ATM Partial Reversal (not to be confused with POS Partial Reversal) are usually supported by unattended cash dispensing devices (ATMs) to ensure that accounts are properly debited when partial dispenses of cash occur. In this case, the cryptogram amount in the settlement message (in a dual-message system) should contain the requested cash amount, while the transaction amount should reflect the dispensed cash amount. In a single-message system, the original transaction will contain the requested amount and the chip data (including ARQC), while the Partial Reversal will contain the adjusted amount (and no chip data). If the Acceptance Device generates a reversal, detects the connection to the Acquirer Host has been lost, or has timed-out because no Authorisation response has been received, and an ARQC had been requested, then an AAC should be requested of the card to avoid unnecessary requests for online Authorisations on subsequent transactions.
5.5
5.6
5.7
5.8
5.9
5.10
Declined Transactions
Where the Authorisation response received by the device indicates a decline, the cashier should be informed on their display that the transaction has been declined. For display to the cardholder, the term NOT AUTHORISED may be preferred.
10
Authorisation responses indicating a decline may contain a script to be acted on by the card; these must be processed. In a few markets, for auditing purposes, declined transactions are delivered along with the clearing batch to the acquiring host. However, they are simply deleted from the clearing batch in most markets.
5.11
5.12
Card Removal
When performing an EMV transaction, the card should remain in the card reader until the last EMV transaction step, and issuer script processing, is completed. The cardholder and merchant experience a difference compared to a transaction with a magnetic stripe card, where the card is swiped and returned to the cardholder. To reinforce the new behavior, once the EMV transaction has ended and is approved, the display should indicate that the card be removed. Premature Card Removal If the card is removed before the transaction is complete (i.e. the TC or AAC has been received from the card), the transaction processing should always be terminated. If an online Authorisation has taken place, a reversal message should be sent (If a decline response has been received, it is not necessary to send a reversal). If a card is removed after the second cryptogram generation, but before issuer script processing, the transaction shall be considered complete, and there will be no change in the transaction disposition.
6. Notes
6.1 Dual/Single Messaging and Host/Terminal Capture
In Dual Message processing, the Authorisation occurs at the time of the Purchase or Cash Advance transaction using one message, and the transaction is settled11 later using another message. These clearing messages are usually gathered into a batch for POS devices. The batch is then settled with the Acquiring host as part of end-of-day (or end-of-cycle) processing. Non-batched systems may simply submit a series of clearing advices, based on their transaction logs, prior to end-of-day (or end-of-cycle). If the clearing message is automatically generated from the Authorisation request and response, the Authorisation and clearing message together are considered one transaction (for example, a Purchase). If the clearing message is changed in some way, then the messages are considered a separate Authorisation and Sale Completion. A Single Message transaction occurs in a single message format that allows Purchase or transactions to be completely settled from an Authorisation request. These Financial transactions are approved online by the cardholders financial institution. Terminal-capture and host-capture systems usually exist in the context of Dual Message processing, since Single Messages do not require any further clearing.12 Terminal-capture systems combine data from the
Settlement, from a Point-of-Transaction perspective, refers to device-to-Acquirer settlement. From a processing perspective, the Acquirer will transform these messages into clearing transactions. Messages here refers to the components of the transaction needed for authorisation and clearing. Audit, balancing records, and informational advices are not being considered.
12 11
Authorisation response with the data from the Authorisation request to create the settlement message. In a host-capture system, the host retains a copy of the Authorisation request coming from the terminal before passing the request on to be Authorised. The host uses the data, along with the Authorisation response data, to create the settlement message. A terminal attached to a host-capture system may have a shadow (copy) of the settlement batch, but this is only for informational or error-recovery purposes. To Card Acceptance Devices using Host Capture, transactions appear to be Single Message, since the acquirer host is responsible for generating the clearing message. Single Message and host-capture transactions will contain the ARQC in the settlement/financial message; terminal capture transactions will contain the TC in the settlement message. For most ATM transactions, whether Single or Dual Message, the settlement/financial message will contain the ARQC, and not the TC. In most Dual Message ATM implementations, the acquiring host captures the Authorisation response from the Issuer to create the clearing message and does not have access to the final TC (much like Host-Capture POS). Devices operating in a Single Message or Host Capture environment should ensure a TC is generated for approved transactions. Although not needed for clearing, generating a TC ensures cards will not request unnecessary online approvals on subsequent transactions. Each of the transaction types described can be implemented on Single- and Dual-Message systems, and on Terminal- and Host-Capture systems.
6.2
ATMs
As used in this document, an ATM is a device that dispenses cash. Cash dispensing transactions fall under the appropriate payment scheme Operating Regulations for ATMs. If a device also dispenses goods or services, the dispensing of those goods and services is considered a purchase at an unattended device. If a device dispenses cash, it should do so as described in ATM Cash Withdrawal. If it dispenses goods or services, it should do so as described in Purchase or Pre-Authorisation and Sale Completion. Many ATMs operate in a Single Message environment as described above. Some operate in a Dual Message environment, in which case they effectively function as Host Capture.
This chart uses the new CVM Conditions. The old CVM condition If cash or cashback maps to the new condition If Unattended Cash
14 15 16
13
Valid at terminal other than ATMs Not Unattended Cash and Not Manual Cash and Not Cashback If an ATM also supports purchases of goods or services, it is considered an unattended POS device while dispensing goods or services.
ATM Balance Inquiry ATM Bill Payment ATM Deposit ATM Funds Transfer ATM PIN Change/ Unblock POS Balance Inquiry POS Bill Payment POS Funds Deposit Refund
Application Unblock............................ 11 ATM Balance Inquiry .......................... 10 ATM Cash Withdrawal.......................... 9 ATM Deposit ...................................... 10 ATM Funds Transfer .......................... 10 ATM Partial Reversal ......................... 13 Attended Cash ................................... 10 Authorisation ........................................ 6 Authorisation - Only.............................. 6 Authorisation Completion ..................... 7 Authorisation, Incremental.................... 7 Automobile .......................... See Vehicle Balance Inquiry ......... See ATM Balance Inquiry or POS Balance Inquiry Balance Return .................................. 11 Bill Payment ....................................... 11 Call for authorisation .......................... 12 Call-Me............................................... 12 Cancellation ....................................... 13 Card Verify ........................................... 7 Cash Advance. See POS Cash Advance or ATM Cash Withdrawal Cash Deposit................................ 10, 11 Cash Disbursement.............................. 9 Cashback ............................................. 6 Check-In............................................... 8 Check-Out ............................................ 7 Credit.................................................. 12 Deposit at ATM .................................. 10 Deposit at POS .................................. 11 Dining ............................ See Restaurant Express Check-Out .............................. 7 Force Post............................................ 7 Fuel Purchase ...................................... 6 Fuel/Petrol Dispense ............................ 9 Funds Transfer at ATM ...................... 10 Hotel Additional/Delayed Charges..... 8 Hotel Card Present Check-Out.......... 8 Hotel Check-In .............................. 6, 8 Hotel Check-Out................................ 7 Hotel Check-Out (Card Present) ....... 6 Hotel - Delayed or Late Charges .......... 7 Hotel Express Check-Out.............. 7, 8 Hotel Reservation.............................. 8 Hotel Top-up/Additional Expenses .... 7
Incremental Authorisation................. 6, 7 Lodging .................................. See Hotel Manual Cash ...................................... 10 Manual Cash Advance ....................... 10 Mobile Top-up .................................... 10 Partial Reversal .............................. 7, 13 Petrol Purchase.................................... 6 PIN Change/Unblock.......................... 11 POS Balance Inquiry .......................... 11 POS Cash Advance ........................... 10 POS Deposit ...................................... 11 POS Partial Reversal ........................... 7 Post ...................................................... 7 Post Authorisation ................................ 7 Pre-Authorisation ................................. 6 Pre-Authorisation Completion .............. 7 Purchase .............................................. 5 Purchase with Cashback...................... 6 Quasi-Cash ........................................ 10 Referrals............................................. 12 Refund................................................ 11 Reservation .......................................... 8 Restaurant............................................ 6 Restaurant Payment and Tip............. 6 Restaurant Post-Tip .......................... 7 Retail Purchase .................................... 6 Retail Purchase with Cash Back .......... 6 Return ................................................ 12 Reversal ............................................. 13 Sale ...................................................... 6 Sale Completion ................................... 7 Sale Completion with Incremental Authorisation..................................... 7 Sale with Cashback.............................. 6 Status Check........................................ 6 Supplemental Authorisation ................. 7 Tip Adjust ........................................... 10 Top-up................................................ 10 Top-up Authorisation ............................ 6 Vehicle - Delayed or Late Charges ...... 7 Vehicle Express Vehicle Return ........ 7 Vehicle Reservation .......................... 8 Vehicle Return................................... 8 Vehicle Top-up/Additional Expenses. 7 Vehicle Additional/Delayed Charges .. 8
Vehicle Collection................................. 6 Vehicle Collection Check-In ................. 6 Vehicle Rental .................................... 8 Vehicle Rental (Card Present).............. 6