Đối chiếu thực tế: các hệ thanh toán thật giữ tiền khớp thế nào?

TL;DR: Bài này đặt thiết kế thanh toán của bạn cạnh các nguồn công khai: Stripe (2017, 2024 và tài liệu API), Square (2019), Modern Treasury (2024), cùng tài liệu tích hợp của MoMo, VNPAY, ZaloPay. Mỗi case chạm một trục của module: gửi lại lệnh trừ tiền, giữ số dư, chốt và đối soát. Phần lớn khác biệt đến từ ràng buộc cụ thể của từng case: API nhà cung cấp phát lại kết quả cũ hay chỉ chặn mã trùng, và tài khoản có nóng hay không. Stripe và MoMo trả lại kết quả cũ cho cùng khoá; nhà cung cấp trong bảng của bạn chỉ từ chối mã trùng, nên sàn của bạn phải tự tra cứu.

Bảng ràng buộc của bạn: đỉnh 3.000 lượt thanh toán mỗi giây, khoảng 3.600 giao dịch mập mờ mỗi đợt sale, nhà cung cấp từ chối mã trùng, API tra cứu chỉ 10 lượt mỗi giây. Đọc blog kỹ thuật của Stripe xong, câu hỏi tự nhiên là "sao họ không phải khổ thế?". Câu trả lời thường là một ràng buộc mà họ có và bạn không.

1. Analogy: hai bưu điện trả lời khác nhau

Hai bưu điện cùng nhận kiện. Hỏi lại cùng mã vận đơn, bưu điện thứ nhất đọc lại biên nhận cũ, còn bưu điện thứ hai chỉ nói "mã này đã dùng". Người gửi ở bưu điện thứ hai chỉ cầm biên nhận: muốn biết kiện tới chưa phải gọi tổng đài tra mã, hoặc chờ phiếu báo phát.

2. Cách đọc một case: tìm ràng buộc khác bạn

Module có ba trục quyết định. Bài 03 chọn thứ tự bước quanh lệnh trừ tiền và máy trạng thái có trạng thái "chưa rõ". Bài 04 chọn cách ghi sổ. Bài 05 chọn cách chốt giao dịch mập mờ và so sổ với file. Với mỗi case, bạn tách ràng buộc của họ, lựa chọn của họ, trục bị tác động, rồi mới hỏi thiết kế của mình đổi ở đâu.

Tài liệu tích hợp của MoMo, VNPAY, ZaloPay chỉ nói nhà cung cấp hứa gì với sàn, nên bài này không suy đoán kiến trúc nội bộ của họ.

3. Gửi lại cùng mã thì nhận về gì?

Stripe 2017 và tài liệu API: cùng khoá, kết quả cũ

Idempotency key là chuỗi duy nhất client sinh cho một ý định và gửi kèm mọi lần thử, để server biết lần sau là gửi lại chứ không phải lệnh mới. Bài "Designing robust and predictable APIs with idempotency" (Stripe, 22/2/2017) viết rằng khi kết nối đứt, kết quả "is ambiguous from the perspective of the client"; lần thử lại cùng khoá nhận về kết quả đã lưu. Tài liệu xử lý lỗi HTTP của Stripe (tra 19/10/2026) giữ khoá ít nhất 24 giờ. Quá hạn mà vẫn chưa rõ thì tài liệu bảo dừng thử lại, tra đối tượng và dùng webhook để đối soát.

Ràng buộc khác: Stripe chạy lệnh trừ tiền, nên trả lại response cũ chỉ là một lần đọc phía họ. Nhà cung cấp trong bảng của bạn hứa ít hơn: từ chối mã trùng mà không nói lần đầu đã trừ chưa.

MoMo, VNPAY: hai loại mã, hai hành vi

Trang Idempotency của MoMo ghi rằng gửi lại cùng requestId thì "MoMo returns the latest status of the request", và requestId có hiệu lực tối thiểu 31 ngày. Nhưng bảng mã kết quả MoMo có mã 41 "Duplicated orderId.", còn tài liệu VNPAY yêu cầu vnp_TxnRef "Không được trùng lặp trong ngày."

Bảng của bạn bám kiểu orderId và vnp_TxnRef: không trừ lần hai, nhưng cũng không nói lần đầu đã trừ chưa. Vì thế luồng của bạn có thêm trạng thái "chưa rõ" và hàng chờ tra cứu. Hỏi lại 3.600 giao dịch mập mờ, mỗi giao dịch một lượt, ở 10 lượt mỗi giây mất 360 giây, tức 6 phút.

Cả hai phía đều coi lệnh trừ tiền là pivot transaction, bước mà sau nó không còn bù ngược được. Trang Saga pattern của Microsoft Azure (25/2/2025) định nghĩa: "Pivot transactions serve as the point of no return in the saga." Stripe cũng không thoát điểm đó. Họ giữ kết quả của nó ở phía mình.

Thử ngẫmNếu nhà cung cấp của bạn trả lại kết quả cũ cho mã trùng như MoMo với requestId, bạn bỏ được trạng thái "chưa rõ", hay chỉ rút ngắn thời gian nằm trong đó?

4. Số dư nằm ở đâu khi tài khoản bị ghi dồn?

Square Books 2019: bút toán chỉ insert, số dư vẫn cập nhật

Theo bài "Books, an immutable double-entry accounting database service" (Square, 16/10/2019), cách cũ "stopped scaling with our payments business": không tách được một lượt thanh toán thành nhiều lần chi trả. Books bắt mọi bút toán cân về 0 và các bảng bút toán chỉ có insert. Riêng bảng books thì "inherently mutable (current balance is updated on every operation)".

Đặt cạnh ba phương án ở bài 04, Books gần nhất với sổ cái kèm số dư dẫn xuất. Bài viết không nói số dư có cập nhật cùng transaction với lệnh insert không, nên đừng suy ra điều đó. Ràng buộc của họ là bài toán chi trả nhiều lần; hướng đi thì giống bạn: không bao giờ sửa bút toán đã ghi.

Modern Treasury 2024: tài khoản nóng và gom lô

Bài "Behind the scenes: how we built Ledgers for high throughput" (Modern Treasury, 25/1/2024) gọi tên đúng vấn đề của bạn. Tài khoản nóng (hot account) là tài khoản có mặt trong phần lớn giao dịch. Khi tải cao, "contention for the single balance cache row causes Transaction write latency to spike dramatically".

Họ cho client chọn trên từng bút toán. Bút toán cần khoá số dư chạy tuần tự bằng row lock của Postgres; bút toán còn lại vào hàng đợi, một job gom lô rồi mới cập nhật số dư. Mục tiêu là xong trong 60 giây, p90 đo được 1 giây. Cái giá cũng được nêu: lô dài thì trễ, lô ngắn thì lại tranh chấp.

Ràng buộc khác bạn: họ không biết trước tài khoản nào nóng, nên đẩy quyết định xuống từng bút toán. Bạn thì biết đúng ba tài khoản: phải thu nhà cung cấp, phí nhà cung cấp, doanh thu phí sàn, và không bước nào đọc số dư của chúng lúc sale. Số dư người bán thì bị đọc 500 lượt mỗi giây trước khi chi trả và duyệt hoàn tiền. Bạn chọn được theo tài khoản.

Thử ngẫmMột người bán lớn chiếm 40% đơn của đợt sale. Tài khoản phải trả của người đó có thành tài khoản nóng không, và khi đó bạn gom lô nó được không?

5. Vì sao Stripe chịu được bốn ngày mà bạn thì không?

Stripe Ledger 2024: tài khoản trung chuyển phải về 0

Bài "Ledger: Stripe's system for tracking and validating money movement" (Stripe, 16/2/2024) mô tả Ledger là "an immutable log of events" và viết: "Each day, Ledger sees five billion events and 99.99% of our dollar volume is fully ingested and verified within four days." Cơ chế phát hiện lệch là tài khoản trung chuyển (clearing account), nơi tiền chỉ đi qua và ở trạng thái ổn định phải về 0. Luồng nào đứt giữa chừng thì số dư nằm lại, và truy vấn tìm lệch chỉ là tìm tài khoản trung chuyển có số dư khác 0.

Ràng buộc khác bạn: Stripe đo theo tỉ lệ tiền trên năm tỉ sự kiện mỗi ngày; chỉ số đó không đo một khách phải chờ bao lâu mới biết đơn mình ra sao. Bạn gắn giá cho từng giao dịch: treo quá 30 phút thì 30% khách gọi tổng đài, mỗi cuộc 15.000 đ; quá 24 giờ thì khách khiếu nại qua ngân hàng. Bốn ngày là 96 giờ, gấp bốn lần hạn của bạn.

Ý tưởng trung chuyển thì chép được. Tài khoản phải thu nhà cung cấp ghi Nợ 247.250 đ mỗi đơn trung bình rồi được ghi Có khi tiền quyết toán về. So xong file của một ngày, phần phải thu của ngày đó phải về 0.

VNPAY và ZaloPay: sàn tự đi hỏi

VNPAY gọi IPN (Instant Payment Notification, lời báo kết quả server nhà cung cấp gọi vào server bạn) với "Tổng số lần gọi tối đa: 10 lần", cách nhau 5 phút, và ghi về Return URL: "Không cập nhật kết quả giao dịch tại địa chỉ này". ZaloPay ghi "Callback endpoints may receive duplicate events", và 15 phút chưa có callback thì sàn phải tự gọi QueryOrder.

Webhook của Stripe thì gửi lại "for up to three days with an exponential back off in live mode". IPN của VNPAY hết lượt sau khoảng 45 phút (10 lần gọi tổng cộng, cách nhau 5 phút), cùng cỡ với ràng buộc tự đặt khoảng 50 phút của bảng bạn, nên endpoint của bạn chết một tiếng là mất lời báo. Đó là lý do bài 05 ghép IPN, tra cứu định kỳ và file đối soát thay vì chờ một nguồn.

6. Bảng tổng hợp: ràng buộc nào đổi lựa chọn nào

Bốn trong sáu dòng (Stripe idempotency, Square Books, Modern Treasury, Stripe Ledger) là nhà cung cấp hoặc bên bán hạ tầng sổ cái cho người khác. Họ có thứ bạn không có (kết quả của lệnh, quy mô dữ liệu) và thiếu thứ bạn có (biết trước tài khoản nào nóng). Hai dòng tài liệu Việt Nam không phải lựa chọn; chúng là ràng buộc bạn nhận về.

7. Ba cách chép case sai

❌ Nhầm 1: chép "cứ gửi lại cùng khoá" của Stripe sang nhà cung cấp từ chối mã trùng. Nhận lỗi mã trùng, code coi là thất bại rồi tạo mã mới:

-- provider answers "duplicate txn_ref" after a timeout
UPDATE payments SET status = 'failed'
WHERE txn_ref = 'GD1001';
-- then a NEW txn_ref is created and the charge is sent again

✅ Mã trùng chỉ nói lần đầu đã tới nơi. Nếu 720 giao dịch một chạm đã trừ của một đợt đều bị gửi lại bằng mã mới, mỗi lần trừ hai lần tốn khoảng 18.000 đ, cộng lại cỡ 12,96 triệu đồng mỗi đợt. Chuyển sang "chưa rõ" rồi đưa vào hàng tra cứu:

UPDATE payments SET status = 'unknown'
WHERE txn_ref = 'GD1001' AND status = 'pending';
INSERT INTO query_schedule (txn_ref, created_at, attempt, next_check_at)
VALUES ('GD1001', now(), 0, now());

❌ Nhầm 2: chép gom lô cho mọi tài khoản. Số dư người bán chậm tới khoảng 60 giây, trong khi bước duyệt hoàn tiền đọc nó.

✅ Chỉ gom lô ba tài khoản chung. Tài khoản người bán bị ghi rải ra nhiều hàng, nên cập nhật cùng transaction vẫn dưới trần:

BEGIN;
INSERT INTO entries (txn_id, account_id, amount)
VALUES (:txn_id, :seller, -237500);  -- credit leg, negative
UPDATE accounts SET balance = balance - 237500
WHERE id = :seller;
COMMIT;

❌ Nhầm 3: lấy "99,99% trong bốn ngày" làm mục tiêu đối soát. Chỉ số tính theo tiền nên vài giao dịch nhỏ treo lâu không làm nó nhúc nhích. Quy ra số lượt, 0,01% của 1.800.000 lượt một đợt vẫn là cỡ 180 giao dịch được phép trễ.

✅ Đếm theo giao dịch: số giao dịch "chưa rõ" quá 24 giờ phải bằng 0, và phải thu của hôm qua phải về 0 trước 12 giờ trưa.

8. Đào sâu

9. Liên hệ các bài khác

• Bài 03: Thứ tự bước quanh lệnh trừ tiền: pivot và trạng thái "chưa rõ" mà mục 3 đối chiếu.
• Bài 04: Sổ cái chỉ ghi thêm: ba phương án ghi sổ, nền để đọc Square và Modern Treasury.
• Bài 05: Đối soát với nhà cung cấp: ba nguồn chốt kết quả mà VNPAY và ZaloPay buộc bạn ghép.
• Tránh distributed transaction (data-phan-tan): saga, bước bù và outbox.

10. Tóm tắt

• Đọc blog của một công ty thanh toán: hỏi trước ràng buộc nào của họ mà bạn không có, như kết quả của lệnh trừ, quy mô hay độ nóng của tài khoản.
• Nhà cung cấp từ chối mã trùng: coi là "chưa rõ" và đi tra cứu, đừng coi là thất bại.
• Tài khoản có mặt trong mọi lượt: gom lô số dư được, miễn không bước nào cần đọc nó ngay.
• Mỗi giao dịch treo có giá riêng: đặt mục tiêu đối soát theo giao dịch, không theo tỉ lệ tiền.

11. Tự kiểm tra

Bài tiếp theo: Tổng kết module