Thực chiến ngân hàng: cấp phép, quyết toán & tranh chấp giao dịch thẻ tín dụng

1. Bối cảnh doanh nghiệp & phạm vi

Bạn là QA Lead mảng thẻ tín dụng tại SGB Card — công ty phát hành thẻ liên kết với 4 ngân hàng đối tác, quản lý khoảng 1,2 triệu thẻ đang lưu hành với tổng giá trị giao dịch (TPV) khoảng 3.200 tỷ đồng mỗi tháng. Hệ thống xử lý trung bình 400.000 giao dịch cấp phép mỗi ngày, trong đó khoảng 2% phát sinh tranh chấp (dispute) cần điều tra. Quý này, đội kỹ thuật nâng cấp luồng cấp phép để hỗ trợ capture một phần (partial capture) cho ngành hàng khách sạn và thuê xe — nơi số tiền cuối cùng thường khác số tiền giữ chỗ ban đầu.

Ràng buộc từ tổ chức thẻ quốc tế (Visa/Mastercard) rất khắt khe: mọi giao dịch capture phải xảy ra trong vòng 7 ngày kể từ khi cấp phép, nếu không hold phải tự động hết hạn (auth expiry). Đối soát với tổ chức thẻ diễn ra mỗi ngày qua file settlement, và bất kỳ giao dịch nào không khớp phải được xử lý trong vòng 24 giờ theo quy định vận hành nội bộ. Một lỗi phổ biến và tốn kém nhất trong domain này là 'double capture' — khi hệ thống capture cùng một giao dịch hai lần do lỗi retry, khiến khách hàng bị trừ tiền hai lần và ngân hàng phải hoàn trả kèm phí phạt từ tổ chức thẻ.

Phạm vi tự động hoá của tài liệu này

• Luồng cấp phép (authorization/hold): kiểm tra hạn mức, giữ tiền tạm thời, chưa thực trừ.
• Luồng quyết toán (settlement/capture): capture toàn phần và một phần, void phần hold còn dư.
• Hoàn tiền & tranh chấp (refund/chargeback): mở case tranh chấp, hoàn tiền tạm ứng, đóng case sau điều tra.
• Đối soát với tổ chức thẻ: so khớp file settlement hàng ngày với sổ nội bộ, xử lý lệch dữ liệu.
• Tích hợp AI Agent hỗ trợ phân loại case tranh chấp và gợi ý ca kiểm thử biên cho luồng capture một phần.

2. Kiến trúc & luồng nghiệp vụ

Luồng nghiệp vụ thẻ tín dụng có một đặc điểm khiến nhiều QA mới vào nghề nhầm lẫn: hành động 'quẹt thẻ' không đồng nghĩa với 'trừ tiền ngay'. Hiểu đúng ranh giới giữa cấp phép và quyết toán là nền tảng để thiết kế test đúng oracle.

Khi khách quẹt thẻ, Card Gateway định tuyến yêu cầu tới tổ chức thẻ (Visa/Mastercard) dựa trên BIN (Bank Identification Number) của thẻ, tổ chức thẻ chuyển tiếp tới Issuer Core để kiểm tra hạn mức khả dụng và tạo một HOLD — khoản tiền bị 'giữ chỗ' nhưng chưa thực sự rời khỏi tài khoản khách hàng. Phản hồi cấp phép (approve/decline) phải trả về trong vòng 3 giây theo yêu cầu của tổ chức thẻ, nếu không giao dịch tự động bị coi là timeout và merchant phải thử lại.

Quyết toán (settlement/capture) diễn ra sau đó, thường khi merchant giao hàng hoặc hoàn tất dịch vụ — có thể vài phút sau (cửa hàng bán lẻ) hoặc vài ngày sau (khách sạn, thuê xe). Capture là bước THỰC SỰ trừ tiền khách hàng, và số tiền capture có thể nhỏ hơn hoặc bằng số tiền đã hold (partial capture), nhưng KHÔNG BAO GIỜ được lớn hơn. Phần hold còn dư sau capture phải được giải phóng (void) để trả lại hạn mức khả dụng cho khách hàng.

3. Mô hình dữ liệu & bất biến nghiệp vụ

Mô hình dữ liệu trung tâm gồm CardTransaction (giao dịch, có transactionId duy nhất, holdAmount, capturedAmount, trạng thái), LedgerEntry (bút toán ghi kép cho mỗi bước hold/capture/void/refund), và DisputeCase (case tranh chấp gắn với transactionId gốc, có trạng thái điều tra riêng). Ba thực thể này liên kết chặt chẽ, và một test tốt phải kiểm tra được tính nhất quán xuyên suốt cả ba khi có bất kỳ thao tác nào xảy ra.

Bốn bất biến phải đúng ở MỌI thời điểm

• hold ≤ hạn mức khả dụng của thẻ tại thời điểm cấp phép — không được tạo hold vượt quá số dư khả dụng.
• capture ≤ hold ban đầu — không bao giờ được capture nhiều hơn số tiền đã giữ chỗ, kể cả cộng dồn nhiều lần capture một phần.
• Double-entry: tổng Nợ = tổng Có ở mọi bước (hold, capture, void, refund) — tiền không tự sinh hay biến mất khỏi hệ thống.
• Idempotency theo transactionId: gửi lại cùng một yêu cầu capture/void/refund không được tạo bút toán thứ hai.