Merchant Approved Transactions

Introduction
Offline PIN payments, also known as Merchant Approved Transactions (MAT), are a payment mechanism where a debit card transaction is accepted without real-time communication with the bank or acquirer. This mechanism is mainly used in situations where network connectivity is unavailable or unreliable, such as on airplanes, in remote areas, or during temporary outages.

Although the use of offline PIN payments has declined in recent years due to improved connectivity, it remains an important fallback mechanism within the payments ecosystem.

Basic principle
In a standard PIN transaction (online authorization), the following happens:

• Card is read (chip/contactless)
• Terminal sends an authorization request via the acquirer to the issuing bank
• Bank checks balance, limits, and fraud parameters
• Approval or decline is returned immediately

With offline PIN payments, steps 2 and 3 do not occur at the time of payment. Instead:

• The terminal and/or card performs local checks
• The merchant accepts the transaction based on predefined rules
• The transaction is stored in the terminal
• Later, when connectivity is available, the transaction is submitted for clearing and settlement

Technical operation

1. EMV card and offline capabilities
Offline PIN is based on the EMV standard (Europay, Mastercard, Visa). EMV cards contain:

• Offline limits (floor limit)
• Risk management parameters
• Cryptographic keys

The card can independently make decisions using:

• Offline Data Authentication (ODA)
• SDA (Static Data Authentication)
• DDA (Dynamic Data Authentication)
• CDA (Combined DDA with Application Cryptogram)
• Card Risk Management
• Terminal Risk Management

2. Decision logic
An offline transaction is approved based on a combination of:

Terminal-side checks:

• Floor limit (maximum amount for offline acceptance)
• Random transaction selection (e.g., x% must still go online)
• Velocity checks (number of transactions in a short time)

Card-side checks:

• Offline spending limit
• Application Transaction Counter (ATC)
• PIN verification (offline PIN possible)

If both the card and terminal approve, the transaction is accepted offline.

3. Cryptography and storage
For an offline-approved transaction, the card generates a:

• Transaction Certificate (TC) → proof of approval

The terminal stores:

• Transaction amount
• Card data (hashed/tokenized)
• Cryptogram (TC)
• Timestamp

This data is later sent in batch to the payment processor.

4. Deferred authorization
Once the terminal is back online:

• All offline transactions are uploaded one by one to the system
• They are forwarded to the acquirer
• The issuing bank validates afterward:
  • Authenticity (cryptogram check)
  • Available balance (not guaranteed)

Important: the bank can still decline the transaction afterward.

Risks and liability
The biggest difference from online transactions is the distribution of risk.

With offline PIN payments, the risk lies with the merchant:

• Insufficient funds → customer had no balance
• Stolen card → no real-time block check
• Fraud → limited detection
• Incorrect PIN → no detection

Therefore, restrictions are often applied:

• Low maximum amounts
• Limited number of offline transactions per card
• Use only in controlled environments

Use cases
Offline PIN is used in:

• Aviation (in-flight payments)
• Public transport
• Hospitality (events)
• Unattended terminals (parking meters)
• Retail fallback during outages
• Remote areas without stable internet

Difference from contactless payments
Although contactless payments may seem “instant,” they are usually still authorized online. Only for small amounts can a form of offline approval occur, depending on:

• CVM limits (Cardholder Verification Method)
• Offline counters on the card

If you choose to accept offline payments with NFC instead of a chip read (e.g., via a SoftPOS device), you do not have the ability to read the PIN from the chip. If the cardholder enters an incorrect PIN during an NFC payment, or if internet becomes available and the payment is sent to the bank and requires PIN verification at that moment, the payment will be declined. A trade-off must be made between speed and certainty.

A payment that is below the limit but temporarily requires PIN validation will be retried at a later time. A payment with an incorrect PIN cannot be retried and should be considered lost.

Retry logic
You should restore internet connectivity to the terminal as quickly as possible so transactions can be uploaded. There are up to three retry attempts, depending on the status of the initial payment:

• The next business day
• The third business day after the payment
• 7 days after the original transaction

If the payment is not successful on the final attempt, the merchant loses the ability to collect the payment via the original card transaction. An alternative solution must then be found, or the merchant absorbs the loss.