Card Acceptance Requirements at Cardholder-Activated Terminals

Card Acceptance Requirements at Cardholder-Activated Terminals


Cardholder-activated terminals (CATs) are typically unattended terminals that accept bank cards for payment. These terminals are frequently installed at rail ticketing stations, gas stations, toll roads, parking garages, and other merchant locations.


CATs are required to comply with regulations appropriate to the type of transaction they facilitate. When dispensing cash, for example, they have to adhere to the ATM operating regulations. When dispensing goods or services, in contrast, they should comply with regulations for unattended purchases. Although unattended terminals may dispense goods and services as well as cash, transactions involving cash-back are not allowed. In other words, an unattended terminal may dispense either cash or goods and services in a single transaction but not both.


Today I will review the types of cardholder-activated terminals, the correct usage of their indicators and then I will offer some specifics on the most common types of CATs.

Types of Cardholder-Activated Terminals


At present, there are seven types of cardholder-activated terminals:

  • CAT Level 1: Automated Dispensing Machines (CAT 1).
  • CAT Level 2: Self-Service Terminals (CAT 2).
  • CAT Level 3: Limited Amount Terminals (CAT 3).
  • CAT Level 4: In-flight Commerce (IFC) Terminals (CAT 4).
  • CAT Level 5: Reserved for future use.
  • CAT Level 6: Electronic Commerce Transactions (CAT 6)
  • CAT Level 7: Transponder Transactions (CAT 7)


As CATs are unattended, traditional point-of-sale (POS) card acceptance procedures do not apply, such as the merchant’s examination of the card to verify its validity and the comparison of the cardholder signature to the one on the sales receipt.

How to Use the CAT Level Indicator


Each CAT transaction is identified through the use of the appropriate CAT level indicator in the authorization and clearing messages. The table below shows what these messages are and where they are located.


The CAT level indicator for…

Terminal Type

Authorization message (DE 61, subfield 10) is…

Clearing message (PDS 0023) is…

CAT Level 1

1

CT1

CAT Level 2

2

CT2

CAT Level 3

3

CT3

CAT Level 4

4

CT4

CAT Level 6

6

CT6

CAT Level 7

7

CT7


General Requirements


CAT requirements specify the maximum dollar amount of transactions permitted as well as authorization, clearing and?áchargeback requirements and related transaction liability for each CAT type.


Merchants operating CATs need to ensure that payment processing procedures at their unattended terminals comply with the following general acceptance requirements:

  1. Characteristic.
    • All CAT transactions are non-face-to-face transactions.
    • All CAT transactions have no merchant present at the time of the transaction.
    • All CAT transactions are initiated by the cardholder.
    • All CAT transactions have the card number captured as a result of reading the EMV chip or magnetic stripe on the card or by using an electronic device (such as transponders, PCs and mobile phones).
    • Messages used at the CAT must communicate to the cardholder, at a minimum, the following information:
      • Invalid transaction.
      • Unable to route.
      • Invalid PIN-re-enter (Level 1 only).
      • Capture card (subject to the terminal’s ability to retain cards).
  2. Authorization.
    • The Authorization Request / 0100 message must include a valid merchant category code (MCC), POS country code, POS postal code and CAT level indicator.
    • Depending on the CAT level indicator, other specific data is required for authorization.
  3. Sales receipt. The acquirer is responsible for providing requested sales receipts.
  4. Clearing.
    • The merchant identification number and CAT level indicator must be present in the First Presentment / 1240, First Chargeback / 1442, Second Presentment / 1240 and Arbitration Chargeback / 1442 messages.
    • The First Presentment / 1240 message of a CAT transaction must contain one of the following values in DE 22 (Point of Service Data Code), subfield 7 (Card Data: Input Mode):
      • B — (Magnetic stripe reader input; track data captured and passed unaltered.) This value does not apply to transactions at CAT 3 devices.
      • C — (Online Chip).
      • F — (Offline Chip).
      • 2 — (Magnetic stripe reader input) This value applies only to transactions at CAT 3 devices.
    • Depending on the CAT level indicator, other specific data is required for clearing.
  5. Scrip. No CAT may accept a card for the purchase of scrip (defined as a two-part paper receipt redeemable for goods, services or cash.).
  6. EMV Chip. A CAT device may be an EMV hybrid device.


Now let’s get into some details.

Automated Dispensing Machines (ADMs)


ADMs should comply with the following requirements:

1. ADMs must accept a personal identification number (PIN) for authentication purposes, not a signature, as long as it is adopted as a standard within a country as well as by the issuers providing the required PIN. The following requirements should also be met:

  • The PIN authorization must be made via a secured transmission.
  • ADM terminals must be able to support numeric, alpha and alphanumeric PINs with a minimum length of four digits and a maximum length of six digits.


2. The acquirer may decline a transaction after four unsuccessful log-in attempts or “invalid transaction” responses from the network. However, the acquirer is allowed to accept more than four consecutive PIN entries.


3. All transactions, regardless of the amount, must be authorized on a zero floor limit basis with full, unaltered card read data transmitted.


4. Card retention at an ADM is not required, however, if the terminal capability is available, the merchant may do so only at the issuer’s specific direction.


5. “No Cardholder Authorization” (Visa Reason Code 72 or MasterCard Reason Code 4837) chargeback rights for this reason code are not available to issuers for transactions processed at ADMs where a PIN and full, unaltered card read data is transmitted because the PIN is a valid proxy for the cardholder’s signature.


6. An ADM that is also a hybrid terminal may perform fallback procedures unless it is prohibited by local regulations. Fallback procedures are used when a smart (chip-based) card is used at a hybrid terminal and the merchant processes the transaction by using the magnetic stripe or by manually entering the account number, because the merchant cannot process the transaction using the chip technology.

Self-Service Terminals (SSTs)


SSTs should comply with the following requirements:


1. Self-Service Terminals do not process PIN authentication. They include (but are not limited to) automated fuel dispensers (AFDs).


2. All SST devices must comply with the following requirements:

  • Zero floor limit for all transactions.
  • Acquirer must read and transmit full, unaltered card read data.


3. The authorization system will send all transactions identified as Self-Service Terminals in the Authorization Request / 0100 message (see above) to the issuer, regardless of Limit 1 parameters.


4. The maximum transaction amount is $100 or its equivalent.


5. “No Cardholder Authorization” chargebacks (Visa Reason Code 72 or MasterCard Reason Code 4837) for SST transactions will be allowed only if the issuer certifies that the account number used in the transaction is fraudulent, as documented in a letter written by its cardholder.


Additionally, the issuer must block the account number until the card’s expiration on or before the processing date of chargeback Reason Code 4837 / 72. The issuer also must list the account number on the “capture card” list until the card’s expiration.


Counterfeit transactions occurring at SSTs for which the acquirer has transmitted the full magnetic stripe data in the authorization request message, and for which an authorization approval was obtained, are ineligible for chargeback Reason Code 4837 / 72.


6. In the U.S., merchants processing automated fuel dispenser transactions at SSTs are allowed to request authorization for $1, as long as they are properly identified by MCC 5542 (automated fuel dispenser) and CAT level indicator 2. If authorization approval is obtained, the merchant is protected from authorization-related chargebacks “requested / required authorization not obtained” (MasterCard Reason Code 4808 or Visa Reason Code 71) or “exceeds floor limit — not authorized and fraudulent transaction” (MasterCard Reason Code 4847 or, once again, Visa Reason Code 71) for transactions less than or equal to $75. The merchant’s protection is limited to $75 for transactions that exceed $75 and issuers may charge back only the difference between the transaction amount and the $75 limit.


7. An SST that also is a hybrid terminal may perform fallback procedures from chip to magnetic stripe, unless prohibited by local regulations.

Limited Amount Terminals


1. A Limited Amount Terminal must check the account number against the Electronic Warning Bulletin file if the terminal, if it is enabled.


2. The maximum transaction amount is $40 or its equivalent.


3. Chargeback rights for “No Cardholder Authorization” chargebacks (Reason Code 4837 / 72) are not available to issuers for properly identified CAT / Level 3 transactions. Chargeback rights for “requested / required authorization not obtained” (Reason Code 4808 / 71), or “exceeds floor limit — not authorized and fraudulent transaction” (Reason Code 4847 / 71) are available if the maximum transaction amount of $40 or its equivalent has been exceeded.


4. A Limited Amount Terminal that also is a hybrid terminal is prohibited from performing fallback procedures from chip to magnetic stripe.

In-flight Commerce (IFC) Terminals


1. Requirements for acquirers and service providers and transaction identification specifications:

  • Acquirers must ensure timely delivery and installation of the IFC Blocked Gaming File to gaming service providers. IFC Blocked Gaming File access is required before every gaming transaction.
  • The acquirer must identify in-flight commerce services or merchandise with the applicable merchant category code (MCC) in the authorization message and merchant business code (MCC) in First Presentment / 1240 messages. If an airline also acts as the service provider, the acquirer may not use an airline MCC but must assign the proper MCC for each type of IFC transaction. The following list of IFC transaction types must be identified with the designated MCC:


    IFC Transaction Type

    MCC

    Catalog card acceptor

    5964

    Duty-free store

    5309

    Gaming

    7995

    Miscellaneous services

    7299

    Video game

    7994


  • Transactions must be consolidated by MCC, per flight, for each cardholder account.
  • The acquirer must identify the transaction with the most appropriate transaction category code (TCC) in the authorization request message, as indicated in the table below:


    IF the IFC transaction is for… THEN the acquirer must use TCC…
    Gaming U for Unique Transaction
    Anything other than gaming R for Retail Purchase


  • The merchant name / location must include the service provider’s name and flight identification. The flight identification must be a recognizable identification of the airline (not necessarily the airline alphabetic International Air Transport Association [IATA] indicator).
  • The city field description should contain the following:


    For… The city field description…
    Mailed purchases and gaming transactions Must include the service provider’s customer service telephone number. It is not required to be a toll-free number.
    All IFC transactions other than mailed purchases and gaming Optionally may be a customer service telephone number.


  • For all IFC transactions except IFC mailed purchase transactions, the transaction date is defined as the date on which the flight departs from the originating city. The transaction date for mailed purchases is the shipment date, unless otherwise disclosed to the cardholder.
  • The acquirer must ensure that the service provider provides full disclosure to the cardholder via the video monitor screen prior to the initiation of any IFC transactions, as detailed below. The screen must prompt the cardholder to acknowledge these terms before initiating a transaction. Disclosure must include the following:
    • Full identification of the service provider and provision for recourse in terms of cardholder complaints or questions.
    • Notification that transactions will be billed upon the issuer’s approval of the authorization request.
    • For mailed purchases only, any additional shipping or handling charges.
    • Policy on refunds or returns.
    • Provision for a paper receipt.

    • For IFC gaming transactions, service providers must additionally disclose the following:

    • Maximum winnings ($3,500) and maximum losses ($350).
    • Notification that the total net transaction amount (whether a net win or loss) will be applied to the cardholder’s account.
    • Notification that the cardholder must be at least 18 years of age to play.
    • Notification that some card issuers may not allow gaming.
  • The acquirer must ensure that the service provider is capable of providing an itemized receipt to the cardholder for all IFC transactions. At the cardholder’s option, the service provider can effect this offer in one of three ways:
    • Printing a receipt at the passenger’s seat.
    • Printing a receipt from a centralized printer on the plane.
    • Mailing a receipt to the cardholder.

    • The mailed receipt offer is to be made available via the video monitor and must require the cardholder to input her name and address. For IFC gaming transactions, the service provider must provide a receipt to the cardholder by methods (1) or (2), described above. The receipt must contain the following elements:

    • Identification of the passenger’s flight, seat number and date of departure.
    • Itemized transaction detail.
    • Gaming transaction specified as a net win or net loss.
    • The cardholder’s account number truncated on the receipt. Acquirers must ensure that transaction receipts provided to cardholders reflect a minimum of four and a maximum of 12 digits of the cardholder account number. The remaining digits are to be truncated. In all cases, at least four digits must be truncated, but it’s recommended that the receipt reflect only the last four digits of the primary account number and that all preceding digits are truncated. The truncated digits should be replaced with fill characters such as “X”, “*” or “#” and not with blank spaces or numeric characters.
  • For IFC terminals, data should be encrypted during transmission of authorization and clearing purposes between the on-board client server and the acquirer.


2. Transaction requirements:

  • No maximum transaction amount applies to any IFC transaction, with the exception of IFC gaming transactions.
  • An IFC terminal that is also a hybrid terminal is prohibited from performing fallback procedures from chip to magnetic stripe.


3. Additional requirements for IFC gaming transactions:

  • Net gaming losses cannot exceed $350 per flight per cardholder account and the respective limit for net payouts is $3,500. This must be monitored throughout the flight by the service provider to ensure compliance.
  • A gaming win transaction will result in posting of net winnings (credit) to the cardholder’s account. Under no circumstance may winnings be paid in cash or other form of payment.
  • Before participating in IFC gaming activity, the acquirer must ensure that such ctivity will be effected in full compliance with all applicable laws and regulations.


4. Cardholder account number verification — in-flight verification:

  • The service provider should conduct a Mod 10 check to verify card authenticity.
  • The service provider should confirm that the card account number is within a valid BIN range.
  • For IFC gaming transactions, the acquirer must ensure that the cardholder’s account number is checked against the IFC Blocked Gaming File — those listed should be prohibited from participating in gaming transactions.


5. Authorization requirements for all IFC transactions:

  • The Authorization Request message must include the cardholder-activated terminal level 4 indicator (see above).
  • The acquirer must read and transmit full, unaltered card read data. An IFC authorization request may not contain a key-entered account number or expiration date.
  • Transactions are either authorized air-to-ground during the transaction or authorized in a delayed batch. All are authorized on a zero floor limit basis.
  • The acquirer must convert all “refer to card issuer” and “capture card” messages received from issuers to “declines”.


6. Additional authorization requirements for IFC gaming transactions. All IFC gaming losses authorized post-flight must be submitted for authorization for the net amount. All gaming transactions authorized during the flight will be for the full wager amount ($350 or a lower amount predetermined by the airline and gaming service provider). No gaming wins will be submitted for authorization.


7. Clearing requirements for all IFC transactions:

  • An acquirer is not allowed to submit declined transactions into clearing.
  • No surcharges or service fees may be assessed on any IFC transaction, including IFC gaming transactions.


8. Additional clearing requirements for IFC gaming transactions:

  • IFC gaming transactions submitted for clearing must be for the net amount that is won or lost.
  • IFC gaming win transactions will be submitted as a credit transaction and interchange will be paid to issuers by acquirers on them.
  • An acquirer may resubmit a gaming transaction for a different amount within the specified transaction limits if it was previously rejected for exceeding the specified transaction limits — $3,500 for wins and $350 for losses.


9. Effective date of the IFC blocked gaming file — updates to the IFC Blocked Gaming File will be effective on the first and the 15th day of each month.


Image credit: Toledoblade.com.

Add a Comment

Your email address will not be published. Required fields are marked *