Week 4 · Day 5

Acquiring &
POS Flow

When a merchant accepts a card payment, an entire network of systems works behind the scenes in under 2 seconds. Today you learn exactly who does what — and where things can break.

POS to Switch Flow Acquiring Bank Issuing Bank Card Network Settlement

01 The Simple Idea First

Real-life Analogy

Think of a card payment like a phone call between two banks.

The merchant's bank (acquirer) dials the call. The card network (Visa / 1LINK) is the telephone exchange that connects the call. The customer's bank (issuer) picks up and says yes or no.

The POS machine is the phone the merchant uses to start that call. The whole conversation happens in under 2 seconds. As L2, you trace what was said at each step when something goes wrong.

02 The 4 Key Players in Every POS Transaction

🏪

Player 1

Merchant & POS Terminal

The shop and its card machine. The POS reads the card chip/tap and sends the payment request. It is the starting point of every acquiring transaction.

🏦

Player 2

Acquiring Bank

The merchant's bank — the bank that gave the merchant their POS machine and processes their card receipts. It receives the request from the POS and sends it into the card network.

🔀

Player 3

Card Network / Switch

The routing layer — Visa, Mastercard, or 1LINK (domestic). It receives from the acquirer, identifies which bank issued the card, and routes the authorization request to that bank.

💳

Player 4

Issuing Bank & CMS

The customer's bank — the bank that issued the card being used. Its CMS receives the authorization request, checks balance and limits, and sends back approved or declined.

💡 Simple way to remember: Acquirer = merchant's bank. Issuer = customer's bank. The card network is the highway connecting them. As L2, your company could be sitting on either side — as the acquirer, the issuer, or both.

Issuing vs Acquiring — What's the Difference?

Issuing is what we covered in CMS (Day 2) — your bank issued a card to a customer. When that customer uses their card anywhere, your CMS is the issuer that approves or declines.

Acquiring is the other side — your bank has merchants who use your POS machines. When those merchants accept card payments, your system is the acquirer that processes the incoming transactions and settles funds into the merchant's account.

Many banks do both — they issue cards to customers AND provide POS machines to merchants. As L2, you need to know which side a ticket is coming from before you start investigating.

03 POS to Switch Flow — Full Step by Step

💳 POS Transaction Flow — From Tap to Approval

🏪

Step 1 — POS Terminal

Customer taps or inserts card at POS

POS reads card data from chip, tap (NFC), or swipe. It creates an authorization request with: card number, amount, merchant ID, terminal ID, and transaction time. This is sent to the acquiring bank's switch.

POS → Authorization Request → Acquirer Switch

🏦

Step 2 — Acquiring Bank Switch

Acquirer validates and logs the request

The acquirer's switch receives the request, validates the format, checks merchant status (is the merchant active, not blacklisted), logs the transaction, and forwards it to the card network.

Merchant active check → Log TXN → Forward to Network

🔀

Step 3 — Card Network (Visa / 1LINK)

Network routes to the issuing bank

The card network reads the card BIN (first 6 digits) to identify which bank issued the card, and routes the authorization request to that bank's CMS. For domestic cards in Pakistan, 1LINK handles this routing.

BIN lookup → Identify Issuer → Route to Issuer CMS

💳

Step 4 — Issuing Bank CMS

Issuer checks card, balance, and limits

The issuer's CMS receives the request and runs all checks — Is the card active? Is it not blocked? Does the account have enough balance? Is the amount within daily limits? Is this merchant category allowed?

All checks pass → APPROVED (00) | Any fail → DECLINED (code)

🔀

Step 5 — Response travels back

Authorization response routed back to POS

The approval or decline response travels back the same path — Issuer → Network → Acquirer Switch → POS Terminal. The entire round trip takes under 2 seconds.

Issuer → 1LINK → Acquirer Switch → POS → Shows APPROVED or DECLINED

💰

Step 6 — Settlement

End of day settlement — funds move to merchant

At end of day, all approved authorizations are batched and settled. The issuing bank moves funds through the network to the acquiring bank, which then credits the merchant's account minus any fees.

Batch settlement → Issuer debits → Network clears → Acquirer credits merchant

Authorization vs Settlement — Two Different Things

Authorization is the real-time check and reservation of funds. It happens in 2 seconds. Money is not moved yet — it is just reserved (a hold is placed on the account).

Settlement is when the money actually moves. It typically happens at end of day in a batch. The hold is converted to a real debit and funds transfer from the issuer to the acquirer to the merchant.

Why this matters for L2: A merchant saying "card was approved but I didn't receive funds" is a settlement issue — not an authorization issue. These are investigated completely differently.

❌ POS Decline Codes — Common Ones You Will See

Code	Meaning	Issuer or Acquirer?	L2 Action
00	Approved — transaction successful	—	All good — no action needed
51	Insufficient funds	Issuer	Client side — customer's account balance too low
54	Expired card	Issuer	Card has expired — reissue via CMS
55	Incorrect PIN	Issuer	Customer entered wrong PIN — verify attempt count
57	Transaction not permitted to cardholder	Issuer	Card not enabled for this transaction type — update CMS settings
61	Exceeds withdrawal limit	Issuer	Daily limit hit — advise customer or update limit
62	Restricted card	Issuer	Card blocked — check who blocked it and why in CMS
91	Issuer unavailable	Issuer	P1 check — issuer CMS unreachable. All transactions for that bank failing.
96	System malfunction	Acquirer / Switch	Escalate — internal system error. Check switch logs immediately.
41	Lost card	Issuer	Card flagged as lost. Transaction correctly declined. Inform merchant.
43	Stolen card	Issuer	Card flagged as stolen. Correct security behavior. Log and inform.

🔴 Acquiring Breakpoints — Where POS Transactions Fail

Breakpoint	Where it happens	How to spot it
POS not connecting	POS → Acquirer	POS shows "connection error" or "host unavailable" — check acquirer switch service
Merchant not active	Acquirer validation	Response code 58 — merchant blocked or suspended in acquirer system
Switch routing failure	Acquirer → Network	Transactions timing out before reaching issuer — check switch logs
Issuer CMS down	Network → Issuer	Code 91 across all cards of one bank — only that bank's cards declining
Settlement mismatch	End of day batch	Merchant reports funds not received despite approvals — check settlement batch

04 Hands-on Lab — Trace a POS Transaction

🔬 Lab: Investigate a POS Transaction Failure

Acquirer Investigation

Merchant says: "Card was declined at my POS — don't know why"

Start at the acquirer switch log — find the transaction and check the response code.

SQL — Acquirer switch log

SELECT TXN_ID, CARD_NUMBER, AMOUNT,
MERCHANT_ID, TERMINAL_ID,
RESPONSE_CODE, TXN_TIME
FROM POS_TRANSACTIONS
WHERE TERMINAL_ID = 'TERM-8801'
ORDER BY TXN_TIME DESC
LIMIT 10;

→ RESPONSE_CODE = 62 means card is restricted. RESPONSE_CODE = 91 means issuer CMS is down.

Check if the merchant is active in the acquirer system

If the merchant was suspended or has a configuration issue, all their POS transactions will fail.

SQL — Merchant check

SELECT MERCHANT_ID, MERCHANT_NAME,
STATUS, MCC_CODE, SETTLEMENT_ACCOUNT
FROM MERCHANT_MASTER
WHERE MERCHANT_ID = 'MRCH-4421';

→ STATUS = SUSPENDED means all POS transactions for this merchant are being declined by the acquirer before they even reach the network.

Check the full transaction trace — every hop

Trace the transaction through each layer — acquirer sent it, network received it, issuer responded.

SQL — full transaction trace

SELECT TXN_ID, HOP, FROM_NODE,
TO_NODE, STATUS, RESPONSE_CODE, HOP_TIME
FROM TXN_TRACE_LOG
WHERE TXN_ID = 'TXN-POS-9901'
ORDER BY HOP ASC;

→ Shows exactly where the transaction stopped — POS→Acquirer (OK), Acquirer→Network (OK), Network→Issuer (TIMEOUT = issuer unreachable)

Merchant says: "Payments were approved but funds not in my account"

This is a settlement issue — check the end-of-day settlement batch for this merchant.

SQL — settlement check

SELECT BATCH_ID, MERCHANT_ID,
TXN_COUNT, TOTAL_AMOUNT,
SETTLED_AMOUNT, STATUS, SETTLEMENT_DATE
FROM SETTLEMENT_BATCH
WHERE MERCHANT_ID = 'MRCH-4421'
AND SETTLEMENT_DATE = '2024-03-15';

→ STATUS = PENDING means settlement batch ran but funds not yet transferred. Check if batch processing job completed.

Find all declines in the last hour — scope the issue

Quickly check if declines are isolated to one merchant or system-wide.

SQL

SELECT RESPONSE_CODE, COUNT(*) AS TOTAL
FROM POS_TRANSACTIONS
WHERE STATUS = 'DECLINED'
AND TXN_TIME > NOW() - INTERVAL '1 hour'
GROUP BY RESPONSE_CODE
ORDER BY TOTAL DESC;

→ Mostly code 91 = issuer CMS down (P1). Mixed codes = normal decline activity. All code 96 = acquirer switch issue (P1).

05 Real L2 Scenarios

Merchant calls: "Every single card is being declined at my POS since 30 minutes." You run the decline count query — 100% code 91 in last 30 minutes. The issuer bank's CMS is down. This is a P1 — open bridge. Every transaction for that bank's cards is failing across all merchants.

Merchant says: "A customer's card was declined but they have money in their account." You check POS_TRANSACTIONS — response code 57 (transaction not permitted). Card is not enabled for POS transactions — only ATM. Customer needs to enable POS usage in their bank app or CMS settings.

Merchant says: "Yesterday's sales are approved but money not in account." You check SETTLEMENT_BATCH — STATUS = FAILED. The settlement job crashed last night. This is not an authorization issue — the transactions are all approved. The settlement processing failed. Escalate to the batch processing team to rerun the settlement.

New merchant onboarded but their POS is declining all transactions with code 58. You check MERCHANT_MASTER — STATUS = PENDING_ACTIVATION. Merchant setup is incomplete. The acquiring team needs to activate the merchant account before the POS can process transactions.

✅ Week 4 · Day 5 Outcomes

Explain the 4 key players in every POS transaction — merchant, acquirer, card network, issuer
Describe the full POS to switch flow — tap → acquirer → network → issuer → response → POS
Explain the difference between the acquiring side and the issuing side of a transaction
Explain the difference between authorization (real-time hold) and settlement (actual fund movement)
Map POS decline codes to their root cause and the correct L2 action
Identify acquirer breakpoints — POS connectivity, merchant status, switch routing, settlement
Trace a POS transaction through POS_TRANSACTIONS, MERCHANT_MASTER, TXN_TRACE_LOG, and SETTLEMENT_BATCH
Distinguish between a card issue (issuer side) and a merchant/system issue (acquirer side)

Acquiring &POS Flow