Thẻ 2 — Vòng đời giao dịch thẻ: Authorization → Clearing → Settlement

Tổng quan: ba giai đoạn của một giao dịch thẻ

Với người dùng, "quẹt thẻ" chỉ là một thao tác vài giây: đưa thẻ vào máy POS, nhập PIN hoặc chạm, rồi nhận biên lai. Nhưng phía sau, mỗi giao dịch đi qua ba giai đoạn kỹ thuật riêng biệt, tách nhau về thời gian, về loại bản tin trao đổi và về việc tiền thực sự đã di chuyển hay chưa:

1. Authorization (cấp phép) — kiểm tra tức thời rằng chủ thẻ hợp lệ và còn khả năng chi trả. Chưa có tiền nào rời tài khoản; chỉ tạo một khoản giữ (hold).
2. Clearing (đối chiếu/trình bày) — acquirer gửi chi tiết giao dịch (presentment) qua tổ chức thẻ (scheme) tới issuer để hai bên thống nhất số tiền, phí và ghi nợ/ghi có chính thức. Thường chạy theo lô cuối ngày.
3. Settlement (quyết toán) — dòng tiền ròng thực sự được chuyển giữa các ngân hàng, thông qua ngân hàng thanh toán (settlement bank) của scheme.

Điểm mấu chốt mà nhiều người nhầm: được authorize không có nghĩa là tiền đã chuyển, và tiền đã chuyển không có nghĩa là giao dịch không thể bị đảo (chargeback). Ba giai đoạn này là ba mốc độc lập.

Các tổ chức thẻ (Visa, Mastercard, JCB, các mạng nội địa như NAPAS) đóng vai trò "trung gian định tuyến và bù trừ". Bài này dùng ISO 8583 làm chuẩn bản tin minh hoạ vì đây là chuẩn phổ biến nhất cho bản tin thẻ; các trường cụ thể được nêu ở mức ví dụ minh hoạ, không phải đặc tả ràng buộc của từng scheme.

---

1. Authorization — cấp phép giao dịch

1.1. Mục tiêu và các bước kiểm tra

Authorization trả lời câu hỏi: "Giao dịch này có nên được cho phép ngay bây giờ không?" Issuer (ngân hàng phát hành thẻ) là bên ra quyết định cuối cùng. Các kiểm tra điển hình:

• Thẻ hợp lệ: đúng số PAN, còn hạn (expiry), không bị khoá/báo mất, đúng CVV/CVV2 nếu áp dụng.
• Xác thực chủ thẻ: PIN (giao dịch có tiếp xúc/chip), chữ ký, hoặc 3-D Secure với giao dịch online.
• Hạn mức và số dư: với thẻ ghi nợ là số dư khả dụng; với thẻ tín dụng là hạn mức tín dụng còn lại.
• Kiểm soát rủi ro/gian lận: điểm rủi ro theo địa điểm, số tiền, tần suất, MCC (mã ngành nghề merchant), velocity.

Nếu chấp thuận, issuer trả về mã chấp thuận (approval / auth code) và đặt một khoản giữ trên tài khoản chủ thẻ.

1.2. Hold, số dư khả dụng và số dư sổ

Đây là phân biệt quan trọng:

• Số dư sổ (ledger / posted balance): số tiền đã ghi nợ/ghi có chính thức vào sổ cái.
• Số dư khả dụng (available balance): số dư sổ trừ đi các khoản hold đang treo do authorization.

Khi giao dịch được authorize, tiền chưa bị trừ khỏi sổ; chỉ có số dư khả dụng giảm đi bằng một hold. Tiền chỉ thực sự rời sổ khi giao dịch được clear (posting). Đây là lý do bạn "thấy tiền bị giữ" ngay sau khi quẹt nhưng "chưa trừ hẳn" trong vài ngày, và cũng là lý do số tiền hold có thể khác số tiền cuối cùng (xăng, khách sạn — xem phần pre-auth).

1.3. Online auth vs offline auth

• Online authorization: POS/thiết bị gửi yêu cầu real-time qua acquirer → scheme → issuer, chờ phản hồi. Đây là mặc định cho phần lớn giao dịch hiện nay.
• Offline authorization: thiết bị (đặc biệt là thẻ chip EMV) tự quyết định chấp thuận dựa trên rule lưu trên chip/terminal mà không gọi issuer ngay — dùng khi mất kết nối hoặc với giao dịch giá trị nhỏ (contactless dưới ngưỡng CVM limit). Giao dịch offline được gom lại và gửi lên sau. Offline auth có rủi ro cao hơn vì issuer chưa kiểm tra số dư tại thời điểm quẹt.

1.4. Stand-in processing (STIP / stand-in)

Khi issuer không phản hồi (hệ thống down, timeout, mất kết nối), scheme có thể thay mặt issuer trả lời yêu cầu authorization theo bộ quy tắc do issuer cấu hình trước (giới hạn số tiền, loại giao dịch, danh sách thẻ chặn). Cơ chế này gọi là stand-in processing (STIP) hoặc stand-in. Nó giữ cho hệ thống thanh toán không bị gián đoạn khi một issuer tạm thời không sẵn sàng, đổi lại issuer chịu rủi ro với các quyết định được ra thay. Sau khi issuer online trở lại, các bản tin advice được gửi để đồng bộ.

---

2. ISO 8583 — chuẩn bản tin trao đổi

ISO 8583 là chuẩn quốc tế cho bản tin giao dịch thẻ do định chế tài chính khởi tạo. Gần như toàn bộ luồng auth/clearing giữa terminal, acquirer, scheme và issuer được đóng gói dưới dạng bản tin ISO 8583 (hoặc biến thể riêng của từng scheme dựa trên nó).

2.1. MTI — Message Type Indicator

Mỗi bản tin bắt đầu bằng MTI, một mã 4 chữ số cho biết loại bản tin. Cấu trúc 4 vị trí: phiên bản, lớp (class), chức năng (function), thành phần khởi tạo (origin). Một số MTI hay gặp (ví dụ minh hoạ):

MTI	Ý nghĩa
0100	Authorization request (yêu cầu cấp phép)
0110	Authorization response (phản hồi cấp phép)
0200	Financial transaction request (yêu cầu giao dịch tài chính)
0210	Financial transaction response
0400	Reversal request (yêu cầu đảo)
0410	Reversal response
0420	Reversal advice
0800	Network management request (echo/keep-alive, key exchange)

Quy ước dễ nhớ: cùng cặp, số cuối 0 = request, 0 (kết thúc bằng 10) = response. Ví dụ 0100 (request) ↔ 0110 (response).

2.2. Data Element (DE) — các trường dữ liệu

Sau MTI là bitmap cho biết trường nào có mặt, rồi đến các data element (DE) được đánh số. Một vài DE cốt lõi (ví dụ minh hoạ, giá trị/độ dài tuỳ triển khai):

DE	Tên gọi thường dùng	Nội dung
DE2	Primary Account Number (PAN)	Số thẻ
DE3	Processing Code	Loại giao dịch (mua hàng, rút tiền, hoàn...)
DE4	Amount, Transaction	Số tiền giao dịch
DE7	Transmission Date & Time	Ngày giờ gửi bản tin
DE11	System Trace Audit Number (STAN)	Số truy vết để đối chiếu request/response
DE12/DE13	Local Time / Date	Thời gian tại điểm giao dịch
DE18	Merchant Category Code (MCC)	Mã ngành nghề merchant
DE37	Retrieval Reference Number (RRN)	Số tham chiếu tra soát, dùng trong tra soát/chargeback
DE38	Authorization ID Response	Mã chấp thuận (auth code)
DE39	Response Code	Mã kết quả (approved / declined và lý do)
DE41	Card Acceptor Terminal ID	ID thiết bị chấp nhận thẻ
DE49	Currency Code, Transaction	Mã tiền tệ

Cặp STAN (DE11) + RRN (DE37) đặc biệt quan trọng vì chúng là "chìa khoá" để ghép một response với đúng request, và để truy ngược một giao dịch qua tất cả các giai đoạn (auth, reversal, clearing, chargeback).

Lưu ý: bảng trên là minh hoạ khái niệm. Tên trường, độ dài và định dạng chính xác phụ thuộc vào phiên bản ISO 8583 (1987/1993/2003) và biến thể riêng của từng scheme. Khi triển khai thực tế phải đọc đặc tả kỹ thuật của scheme/switch tương ứng.

---

3. Các biến thể của authorization

3.1. Reversal và void

• Reversal (đảo): huỷ một authorization đã gửi, thường do timeout, lỗi kỹ thuật, hoặc khách huỷ ngay. Bản tin reversal (MTI 04xx) tham chiếu giao dịch gốc qua STAN/RRN để issuer nhả khoản hold. Reversal quan trọng để tránh "hold treo" khi giao dịch không hoàn tất nhưng issuer vẫn giữ tiền.
• Void: huỷ một giao dịch trước khi nó được clear/settle (trong cùng batch). Vì tiền chưa thực sự chuyển, void không cần dòng tiền ngược — chỉ đơn giản không đưa giao dịch vào presentment.

3.2. Partial authorization

Khi số dư/hạn mức không đủ cho toàn bộ số tiền, issuer có thể chấp thuận một phần (ví dụ khách muốn thanh toán 500.000đ nhưng chỉ còn 300.000đ khả dụng). Terminal nhận biết và yêu cầu khách trả phần còn lại bằng phương tiện khác (split tender). Cần terminal hỗ trợ partial auth.

3.3. Pre-authorization và capture (khách sạn, xăng)

Nhiều ngành cần "giữ trước" một số tiền ước lượng rồi mới chốt số thực tế:

• Khách sạn: khi check-in giữ trước (pre-auth) một khoản ước tính cho tiền phòng + phụ phí. Khi check-out, số tiền thực tế được capture (có thể lớn hơn hoặc nhỏ hơn pre-auth).
• Trạm xăng: giữ trước một khoản cố định (ví dụ một số tiền mặc định) trước khi biết khách bơm bao nhiêu, sau đó capture theo số lít thực.

Quy trình gồm hai bước tách biệt: pre-auth (giữ) rồi capture/completion (chốt). Chênh lệch giữa hai con số là lý do người dùng thấy số tiền hold ban đầu khác số bị trừ cuối cùng, và khoản hold dư có thể mất vài ngày để được nhả.

3.4. Refund (hoàn tiền)

Refund là một giao dịch ghi có riêng biệt (không phải đảo giao dịch cũ). Merchant khởi tạo một transaction hoàn tiền, đi qua clearing/settlement như một giao dịch bình thường nhưng theo chiều ngược (tiền từ merchant/acquirer về chủ thẻ). Vì thế refund thường mất vài ngày để về tài khoản chủ thẻ — nó phải chờ chu kỳ clearing/settlement, khác với việc "nhả hold" tức thời của reversal/void.

---

4. Sơ đồ luồng authorization

---

5. Clearing — trình bày và đối chiếu

5.1. Presentment

Sau khi bán hàng, merchant/acquirer chưa lấy được tiền. Acquirer gom các giao dịch đã bán trong ngày và gửi presentment (bản tin clearing chứa chi tiết đầy đủ: số tiền cuối, phí, MCC, RRN...) qua scheme tới issuer. Đây là bước hai bên chính thức thống nhất giao dịch:

• Issuer đối chiếu presentment với authorization đã cấp trước đó (khớp qua RRN/auth code).
• Số tiền được ghi nợ chính thức vào sổ của chủ thẻ (posting) — hold chuyển thành posted.
• Các loại phí interchange được tính vào giai đoạn này.

Clearing thường chạy theo lô cuối ngày (batch) chứ không real-time. Đây là lý do giao dịch "pending" (mới auth) chuyển sang "posted" sau 1–3 ngày.

5.2. Các loại bản tin clearing

Clearing không chỉ có presentment thuận:

• First presentment: acquirer trình bày giao dịch lần đầu.
• Chargeback (representment ngược): issuer đẩy ngược giao dịch nếu chủ thẻ khiếu nại hoặc phát hiện lỗi/gian lận.
• Second presentment / re-presentment: acquirer phản biện chargeback với bằng chứng.

Các vòng này có thể diễn ra sau khi tiền đã settle, tạo ra dòng tiền ngược ở các chu kỳ settlement sau.

---

6. Settlement — quyết toán dòng tiền

6.1. Net settlement

Settlement là lúc tiền thật di chuyển giữa các ngân hàng. Scheme không chuyển từng giao dịch riêng lẻ; thay vào đó nó tính vị thế ròng (net position) của mỗi thành viên trong một chu kỳ:

Net = tổng tiền phải nhận − tổng tiền phải trả, sau khi trừ phí interchange và phí scheme.

Ví dụ trong ngày, acquirer A có tổng doanh số bán 10 tỷ, đồng thời có refund/chargeback 0,5 tỷ và phí 0,2 tỷ → nó nhận về khoản ròng tương ứng. Việc bù trừ ròng giúp giảm số lần chuyển tiền thực tế xuống rất nhiều.

6.2. Ngân hàng thanh toán

Dòng tiền ròng được thực hiện qua ngân hàng thanh toán (settlement bank) do scheme chỉ định: issuer nạp tiền vào tài khoản settlement, acquirer nhận tiền ra từ đó. Chủ thẻ và merchant không tham gia trực tiếp bước này. Sau khi acquirer nhận tiền ròng, nó ghi có cho merchant (sau khi trừ merchant discount rate / MDR — phí acquirer thu của merchant, bao gồm interchange + phí scheme + margin).

---

7. Sơ đồ clearing và settlement

---

8. Bảng so sánh ba giai đoạn

Tiêu chí	Authorization	Clearing	Settlement
Khi nào	Tức thời, tại thời điểm quẹt	Theo lô, thường cuối ngày (T+0/T+1)	Theo chu kỳ scheme (thường T+1/T+2)
Ai quyết định	Issuer (hoặc STIP thay)	Acquirer trình bày, issuer đối chiếu	Scheme tính ròng, settlement bank chuyển
Bản tin điển hình	0100/0110, 0200/0210	Presentment (clearing file)	File/lệnh chuyển tiền ròng
Tác động số dư	Giảm số dư khả dụng (hold)	Ghi nợ chính thức vào sổ (posting)	— (đã posting; đây là dòng tiền liên ngân hàng)
Tiền đã di chuyển chưa	Chưa — chỉ giữ hold	Chưa giữa các ngân hàng (chỉ ghi sổ)	Rồi — tiền ròng thực chuyển

---

9. Timeline thực tế và rủi ro

9.1. Timeline

• Authorization: mili-giây đến vài giây, đồng bộ real-time.
• Clearing: gom lô, thường trong ngày hoặc ngày kế tiếp (T+0/T+1).
• Settlement: theo lịch của scheme, tiền ròng về acquirer thường T+1/T+2 (tuỳ scheme, thị trường, hợp đồng).

Vì thế người dùng thấy trạng thái "pending → posted" thay đổi sau vài ngày, và merchant nhận tiền không tức thời dù khách đã "trả xong".

9.2. Rủi ro chính

• Settlement risk: khoảng thời gian giữa auth và settlement tạo rủi ro một thành viên (acquirer/issuer) mất khả năng thanh toán trước khi hoàn tất net settlement. Scheme quản trị bằng ký quỹ, giới hạn hạn mức thành viên, và lịch settlement chặt.
• Chargeback phát sinh sau: chủ thẻ có thể khiếu nại sau khi tiền đã settle (hàng lỗi, giao dịch gian lận, không nhận hàng). Chargeback tạo dòng tiền ngược ở chu kỳ sau, và merchant có thể đã giao hàng — đây là rủi ro thương mại thực sự cho merchant.
• Auth-clearing mismatch: số tiền clear khác số đã auth (tip, xăng, khách sạn), hoặc clearing đến mà không có auth khớp — cần đối soát để phát hiện.

---

10. Đối soát (reconciliation) và các loại chênh

Đối soát là việc khớp ba nguồn: dữ liệu authorization, dữ liệu clearing (presentment), và dữ liệu settlement (tiền thực nhận), giữa các bên (merchant ↔ acquirer ↔ scheme ↔ issuer). Các loại chênh (discrepancy) thường gặp:

• Auth không có clearing: đã giữ hold nhưng merchant không capture (hold sẽ tự hết hạn và nhả) — cần theo dõi hold treo.
• Clearing không có auth: giao dịch được trình bày nhưng không tìm thấy auth khớp (force post) — rủi ro cao, cần điều tra.
• Chênh số tiền: số clear ≠ số auth (tip, phụ phí, tỷ giá với giao dịch ngoại tệ).
• Chênh phí: interchange/scheme fee tính khác kỳ vọng.
• Chênh settlement: tiền ròng thực nhận ≠ tổng clearing kỳ vọng do refund, chargeback, phí điều chỉnh.

Đối soát tốt phải dựa vào các khoá bất biến qua toàn vòng đời — chủ yếu là RRN/STAN/auth code — để ghép đúng một giao dịch qua auth, clearing, settlement và cả chargeback.

---

11. Ví dụ dòng sự kiện: một giao dịch quẹt thẻ tại POS

Giả sử khách mua hàng 500.000đ tại một cửa hàng, thẻ ghi nợ:

1. T0 (11:00:00) — Khách quẹt thẻ, nhập PIN. POS của merchant tạo yêu cầu auth và gửi tới acquirer (bản tin kiểu 0100/0200, DE4 = 500.000, DE11 STAN gán số truy vết).
2. T0 + ~1s — Acquirer định tuyến qua scheme tới issuer. Issuer kiểm tra: thẻ hợp lệ, còn hạn, số dư khả dụng ≥ 500.000, điểm gian lận thấp → approved, cấp auth code (DE38), đặt hold 500.000đ. Số dư khả dụng của khách giảm 500.000đ; số dư sổ chưa đổi.
3. T0 + ~2s — Response (0110/0210) quay về acquirer → merchant. POS in biên lai, giao hàng. Với khách, giao dịch "xong".
4. Cuối ngày (T0) — Acquirer gom batch, gửi presentment (clearing) 500.000đ qua scheme tới issuer.
5. T+1 (clearing) — Issuer đối chiếu presentment với auth (khớp RRN/auth code), posting: ghi nợ chính thức 500.000đ vào sổ chủ thẻ; hold chuyển thành khoản đã trừ. Interchange được tính.
6. T+1/T+2 (settlement) — Scheme tính vị thế ròng; settlement bank chuyển tiền ròng. Acquirer nhận tiền, ghi có cho merchant sau khi trừ MDR (ví dụ merchant nhận 500.000đ − phí).
7. (Nếu có) T+n — Khách khiếu nại hàng lỗi → issuer khởi tạo chargeback, tạo dòng tiền ngược ở chu kỳ sau; acquirer có thể re-present kèm bằng chứng.

Chuỗi này minh hoạ rõ ba mốc độc lập: auth (bước 2, chỉ hold) → clearing/posting (bước 5, ghi nợ sổ) → settlement (bước 6, tiền ròng chuyển thật).

---

Tóm tắt

• Một giao dịch thẻ đi qua ba giai đoạn tách biệt: authorization (kiểm tra + hold, tức thời), clearing (presentment + posting, theo lô), settlement (chuyển tiền ròng liên ngân hàng, theo chu kỳ scheme).
• Được auth ≠ tiền đã trừ: auth chỉ giảm số dư khả dụng qua hold; tiền chỉ rời sổ khi clearing; tiền chỉ chuyển giữa ngân hàng khi settlement.
• ISO 8583 là chuẩn bản tin, nhận diện qua MTI và các data element (PAN, số tiền, STAN, RRN, response code...); RRN/STAN là khoá để truy vết và đối soát.
• Các biến thể: reversal/void (nhả hold/huỷ trước clearing), partial auth, pre-auth + capture (khách sạn/xăng), refund (giao dịch ghi có riêng, đi qua clearing/settlement).
• Rủi ro chính: settlement risk (khoảng trễ giữa auth và settle) và chargeback phát sinh sau khi tiền đã settle.

Tự kiểm tra

1. Vì sao "được authorize" không đồng nghĩa với "tiền đã bị trừ khỏi tài khoản"? Số dư khả dụng và số dư sổ thay đổi ở giai đoạn nào?
2. STIP (stand-in processing) hoạt động khi nào, và ai chịu rủi ro cho quyết định được ra thay issuer?
3. MTI 0100 và 0110 khác nhau ra sao? RRN/STAN dùng để làm gì xuyên suốt vòng đời giao dịch?
4. Giải thích khác biệt giữa reversal, void và refund về mặt dòng tiền và thời điểm.
5. Vì sao trạm xăng và khách sạn cần pre-auth + capture, và điều đó gây trải nghiệm gì cho người dùng?
6. Kể ba loại chênh trong đối soát và ý nghĩa của mỗi loại.

Đọc tiếp

Thẻ 3 — Phát hành & vòng đời thẻ