POS Transaction types explained

The most common POS transaction — used for the normal purchase of goods or services at a merchant. The terminal sends an Authorization Request (0100) to the cardholder's issuing bank, which responds with an approval or decline (0110).

• Supports CHIP (contact EMV), NFC/contactless, and magnetic stripe entry modes (Field 22)
• Works with both credit and debit cards; debit typically requires PIN verification
• Field 3 Processing Code:00 00 00(purchase, account type, account type)
• On approval: Field 39 Response Code =00(Approved)
• Funds are authorized and held; final settlement occurs at end-of-day batch

Used when a customer returns goods to a merchant and funds should be credited back to the cardholder's account. The POS sends a Financial Advice Request — unlike a purchase, this is typically processed as an advice (no real-time authorization needed from the issuer).

• Field 3 Processing Code:20 00 00(credit / return)
• Sent as an advice (0220); issuer responds with0230
• No cardholder PIN required in most schemes for a refund
• Some schemes require the original transaction reference (Field 37) to be included
• Merchant must have refund privileges enabled in their terminal profile

Allows a cardholder to withdraw cash at a merchant POS, similar to an ATM withdrawal. The amount is debited from the card account and dispensed as cash by the cashier.

• Field 3 Processing Code:01 00 00(cash disbursement)
• Authorization Request (0100) sent to issuer; PIN is typically mandatory
• Subject to daily cash withdrawal limits defined by the issuer
• Many issuers charge a cash advance fee — reflected in Field 28 (transaction fee)
• Not available on all card products; some debit-only cards restrict it

Sent to undo the most recent transaction — for example when a receipt printer fails mid-transaction or the terminal loses connectivity after the authorization was approved. Only the last transaction can be reversed this way.

• Reversal Request:0400→ Reversal Response:0410
• Reversal Advice (when terminal cannot confirm response):0420→0430
• Field 90 carries the original data elements from the reversed transaction
• Must be sent before end-of-day batch close to be effective
• Distinct from a refund: reversals release the authorization hold immediately

Checks that a cardholder has sufficient funds and places a hold on a specific amount — without finalizing the charge. Classic use case: fuel dispensers (petrol stations) and hotels, where the final amount is not known at the start of the transaction.

• Sends an Authorization Request (0100) with a pre-auth indicator in Field 61
• Issuer places the pre-auth amount on-hold; cardholder's available balance decreases
• Pre-auth hold typically expires after 24–72 hours if no completion is received
• Hotels commonly pre-auth for estimated stay cost + incidentals buffer
• Must be followed by a Completion or Adjustment to settle the actual amount

Finalizes a previous pre-authorization with the actual transaction amount. The terminal sends a Financial Advice referencing the original pre-auth. The Adjustment variant also allows the amount to differ from the original pre-auth (e.g., actual fuel dispensed vs. the initial hold).

• Financial Advice Request:0220→ Response:0230
• Field 25 (POS condition code) differentiates completion from a new transaction
• The original approval code (Field 38) must be echoed back from the pre-auth response
• If final amount < pre-auth amount, the excess hold is automatically released
• If final amount > pre-auth amount, the issuer may decline (depends on policy)

Allows a cardholder to check their account balance at a POS terminal, in the same way they might at an ATM. No funds are moved; the issuer returns the balance in the response message.

• Field 3 Processing Code:31 00 00(balance inquiry)
• Issuer returns available and ledger balance in Field 54 (Additional Amounts)
• PIN entry is typically required to authenticate the cardholder
• Some card schemes allow balance display on the POS receipt (configurable)
• Not supported by all card products — credit cards often omit this feature at POS

Checks whether a card is valid and accepted at the terminal or merchant — without placing any hold or moving funds. Typically used when signing up a customer for a recurring payment, or validating a card before allowing a high-value transaction.

• Field 3 Processing Code:36 00 00(account verification)
• Transaction amount in Field 4 is set to zero (000000000000)
• Issuer validates card status, expiry, and merchant eligibility
• Response Code85("No Reason to Decline") = card is valid
• Does not generate interchange or affect cardholder's available balance

Used when a cardholder places an order via telephone or email and the operator manually keys in the card details at the POS. The card is not physically present, which makes this a Card Not Present (CNP) transaction with a different risk and liability profile.

• POS Entry Mode (Field 22):01(manual key entry, card not present)
• CVV2/CVC2 is used instead of PIN for cardholder verification
• Liability shifts to the merchant in most schemes for CNP fraud
• Subject to additional fraud screening; 3DS may apply to online MOTO flows
• Requires specific merchant category and terminal capability flags to be enabled

Establishes a session between the POS terminal and the Terminal Host (Acquirer). Performed at the start of each business day, after a restart, or following a network interruption. The host validates the terminal, synchronizes state, and confirms the terminal is authorised to operate.

• Network Management Request:0800, Field 70 =001(Sign-On)
• Host validates Terminal ID (Field 41) and Merchant ID (Field 42)
• Session keys may be exchanged or confirmed during logon
• POS Operator ID can also be authenticated at this stage
• Successful response:0810, Field 39 =00

Terminates the active session between the POS terminal and the host. Sent when an operator shift ends, when a terminal is being taken offline for maintenance, or to close a failed session cleanly before re-logging on.

• Network Management Request:0800, Field 70 =002(Sign-Off)
• Cleans up session state on the host side
• Recommended before initiating a new logon or key exchange
• Should be sent when changing POS operator (different cashier shift)

Signals the end of a processing period — a day, shift, or accumulation batch. Triggers reconciliation between the POS terminal's local counters and the host's records. Authorized transactions are captured and sent for clearing and settlement.

• Batch Upload Request:0500→ Batch Upload Response:0510
• Or via Network Management:0800, Field 70 =201(Reconcile)
• Terminal counters (amounts and counts by transaction type) are verified against host
• Discrepancies trigger a "out-of-balance" condition that must be resolved
• Can close day, shift, or a specific merchant batch depending on configuration

Requests a running totals report from the host without closing the batch. Used by operators to check accumulated transaction counts and amounts mid-shift, helping to catch discrepancies early.

• Network Management Request:0800, Field 70 =301(Cutover)
• Host responds with totals in Field 63 (Additional Private Data) or Field 60
• Subtotals can be requested per transaction type (purchase, refund, cash, etc.)
• Does not close or reset the current batch period

Generates and distributes a new encryption key between the POS terminal and the host, following a defined key exchange protocol (typically DUKPT or Master/Session). Performed regularly to maintain PCI DSS compliance and protect PIN and transaction data in transit.

• Key Exchange Request:0800, Field 70 =161(Master Key Download)
• Session Key Exchange uses Field 70 =163
• New keys are delivered encrypted under the existing KEK (Key Encrypting Key)
• DUKPT (Derived Unique Key Per Transaction) is the most common scheme at POS
• Must succeed before the terminal can process PIN-based transactions