Skip to content

URD: Thanh toán & Giao dịch

ModuleCORE-08Phiên bảnv0.4
Trạng tháiIn-progressNgày2026-05-30

1. Mục đích

Định nghĩa yêu cầu hướng người dùng cho việc thu thanh toán và ghi nhận tiền kết quả. Module kết nối nhà cung cấp thanh toán của một merchant tới BANA, bộc lộ trạng thái thanh toán live, và ghi sổ mọi thanh toán, mua hàng, và biến động tồn hoàn tất vào một sổ cái tài chính ghi sổ kép để chủ có thể xem số dư và đối chiếu sổ sách.

2. Phạm vi

Bao gồmLoại trừ
Credential nhà cung cấp thanh toán theo từng merchant (VNPAY QR MMS, PhonePOS)Code tích hợp gateway trực tiếp (mối quan tâm lập trình viên)
Trạng thái thanh toán real-time (webhook + WebSocket)UX checkout / tách-thanh-toán (module Đơn hàng)
Subscription webhook outbound theo từng merchantLưu trữ dữ liệu thẻ / token
Tài khoản / ví Tài chính + tài khoản controlQuy đổi đa tiền tệ
Voucher ghi sổ kép (RECEIPT / PAYMENT / TRANSFER / ADJUSTMENT)Phát hành hóa đơn thuế (module Thuế & Hóa đơn)
Tự-post từ event bán, mua, và khoHoàn tiền nhà cung cấp có cấu trúc (Dự kiến)
Phân cấp nhóm (seed + tùy chỉnh)Đối chiếu tiền mặt theo từng ca (Dự kiến)

3. Định nghĩa

Thuật ngữĐịnh nghĩa
Nhà cung cấp thanh toán (Payment provider)Một service ngoài (ví dụ VNPAY) xử lý thanh toán của một khách hàng
WebhookMột thông báo outbound BANA gửi tới subscriber khi một thanh toán đổi trạng thái
Tài khoản / Ví (Account / Wallet)Một nơi tiền nằm: cash, bank, thu QR, POS di động, hoặc một tài khoản control nội bộ
VoucherMột mục ghi sổ cân bằng của một loại (RECEIPT, PAYMENT, TRANSFER, ADJUSTMENT)
Giao dịch (dòng sổ cái)Một dòng DEBIT hoặc CREDIT trong một voucher, ảnh hưởng số dư của một tài khoản
Nhóm (Category)Một nhãn thu hoặc chi phân loại tiền đến từ đâu hoặc đi đâu
Tự-post (Auto-posting)Một voucher được tạo tự động bởi hệ thống phản ứng với một event nghiệp vụ

4. Mô hình Khái niệm

Chỉ là khái niệm — schema đầy đủ nằm trong mô hình miền lập trình viên paymentfinance.

5. Yêu cầu Chức năng

Mỗi bảng cho một lĩnh vực chức năng. Mã <AREA> khớp với ID test-case. Mức ưu tiên = MoSCoW (Must / Should / Could / Won't).

5.1 Vòng đời Thanh toán (PAY)

IDPYêu cầu
URD-PAY-001MHệ thống nhận kết quả thanh toán từ nhà cung cấp và cập nhật trạng thái của thanh toán
URD-PAY-002MKhi thanh toán thành công, hệ thống thông báo cho subscriber (ví dụ sale settle đơn)
URD-PAY-003MTrạng thái thanh toán được broadcast live tới thu ngân (pending → paid / failed / expired)
URD-PAY-004MCùng kết quả thanh toán chỉ được áp một lần, dù gửi nhiều lần (idempotent)
URD-PAY-005SChủ có thể subscribe endpoint webhook theo loại event, với retry khi gửi thất bại
URD-PAY-006WHoàn tiền có cấu trúc qua nhà cung cấp gốc (Dự kiến — xem §7)

5.2 Credential Nhà cung cấp (PRV)

IDPYêu cầu
URD-PRV-001MChủ có thể kết nối một nhà cung cấp thanh toán (VNPAY QR MMS, PhonePOS) theo từng merchant
URD-PRV-002MCredential nhà cung cấp được lưu mã hóa và không bao giờ hiện đầy đủ
URD-PRV-003SCredential được giới hạn theo từng merchant nên một merchant không thể dùng của merchant khác

5.3 Tài khoản & Ví (WAL)

IDPYêu cầu
URD-WAL-001MChủ có thể tạo tài khoản loại CASH, BANK, mã QR, hoặc POS di động
URD-WAL-002MHệ thống duy trì tài khoản control nội bộ (ví dụ inventory, COGS) tự động
URD-WAL-003MMỗi tài khoản theo dõi một số dư mở và một số dư hiện tại chạy
URD-WAL-004MMột tài khoản mặc định mỗi merchant nhận thu bán tự-post
URD-WAL-005SVai trò phi-chủ chỉ thấy tài khoản của merchant họ được cấp truy cập

5.4 Voucher & Sổ cái (VCH)

IDPYêu cầu
URD-VCH-001MMọi voucher cân bằng: tổng DEBIT bằng tổng CREDIT
URD-VCH-002MLoại voucher là RECEIPT, PAYMENT, TRANSFER, ADJUSTMENT
URD-VCH-003MMột thanh toán bán hoàn tất tự-post một voucher RECEIPT vào tài khoản mặc định
URD-VCH-004MNhận một đơn mua hàng tự-post một voucher PAYMENT
URD-VCH-005MMột lần xuất/điều chỉnh tồn tự-post voucher sổ cái khớp
URD-VCH-006MMỗi voucher ghi source event của nó nên cùng event chỉ post một lần (idempotent)
URD-VCH-007MVoucher được đánh số theo từng merchant và loại (ví dụ PT / PC / PCK / PKT)
URD-VCH-008SChủ có thể tạo một voucher thủ công (draft → issue)
URD-VCH-009SChủ có thể void một voucher qua một đảo ngược cân bằng (không xóa cứng)
URD-VCH-010CChuyển giữa hai tài khoản được ghi như một voucher tổng-không

5.5 Nhóm (CAT)

IDPYêu cầu
URD-CAT-001M14 nhóm hệ thống được seed và không thể gỡ
URD-CAT-002MNhóm có kiểu INCOME hoặc EXPENSE
URD-CAT-003SChủ có thể thêm nhóm tùy chỉnh theo từng merchant, gồm một phân cấp cha

6. Tiêu chí Chấp nhận

AC-PAY-01: Cập nhật trạng thái thanh toán
Cho trướcKhiThì
Một thanh toán pendingNhà cung cấp báo thành côngTrạng thái thành paid, subscriber được thông báo, thu ngân thấy cập nhật live
Một thanh toán pendingNhà cung cấp báo thất bại / hết hạnTrạng thái thành failed / expired; đơn vẫn mở
Một kết quả đã ápCùng kết quả gửi lạiBị bỏ qua; không hiệu ứng trùng
AC-VCH-01: Tự-post từ event
Cho trướcKhiThì
Một thanh toán bán thành côngEvent được xử lýMột voucher RECEIPT cân bằng post vào tài khoản mặc định
Một đơn mua hàng đã nhậnEvent được xử lýMột voucher PAYMENT cân bằng post
Cùng source eventNó được gửi lạiKhông voucher thứ hai được tạo (idempotent)
AC-VCH-02: Voucher thủ công và void
Cho trướcKhiThì
Một chủTạo và issue một voucher thủ côngMột voucher cân bằng xuất hiện trong sổ cái với một số thứ tự
Một voucher đã issueChủ void nóMột voucher đảo ngược cân bằng được post; bản gốc được giữ
AC-WAL-01: Tài khoản và số dư
Cho trướcKhiThì
Một chủTạo một tài khoản với một số dư mởTài khoản hiện số dư mở đó là hiện tại
Một voucher đã postNó debit/credit một tài khoảnSố dư chạy của tài khoản cập nhật tương ứng

7. Ràng buộc & Không-mục-tiêu

Ràng buộc

IDRàng buộc
C-01Mọi voucher phải cân bằng (tổng DEBIT = tổng CREDIT)
C-0214 nhóm seed không thể gỡ
C-03Credential nhà cung cấp mã hóa at-rest và masked trong response
C-04Mỗi event nghiệp vụ post tối đa một voucher (idempotent qua source event id)
C-05Bản ghi dùng soft-delete / đảo ngược — không xóa cứng lịch sử tài chính
C-06Một tài khoản mặc định mỗi merchant cho thu bán tự-post

Không-mục-tiêu

  • Flow SoftPOS / NFC tap-to-pay
  • Nhà cung cấp e-wallet bổ sung (Momo, ZaloPay)
  • Hoàn / đảo charge nhà cung cấp ngoài có cấu trúc
  • Quy đổi đa tiền tệ và đối chiếu cross-currency
  • Dashboard đối chiếu tiền mặt theo từng ca

8. Lịch sử Phiên bản

NgàyTác giảMô tảVer
2026-02-26P. Do — Product OwnerUser story ban đầuv0.1
2026-04-16P. Do — Product OwnerVí tài chính, giao dịch, nhómv0.3
2026-05-30Di chuyểnTái cấu trúc theo quy ước module; căn các lĩnh vực (PAY/PRV/WAL/VCH/CAT) theo thực tế hai-package; hoàn tiền + đối chiếu đánh dấu Dự kiếnv0.4

Proprietary and Confidential. Unauthorized copying, distribution, or use of this software is strictly prohibited.