├── Payment_Gateway_System_Design.jpg └── README.md /Payment_Gateway_System_Design.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lkduy2602/Payment-Gateway-System-Design/HEAD/Payment_Gateway_System_Design.jpg -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # THIẾT KẾ HỆ THỐNG CỔNG THANH TOÁN TRUNG GIAN 2 | 3 | Chào mọi người! Hôm nay mình muốn chia sẻ về một thiết kế hệ thống cổng thanh toán trung gian với ngân hàng. 4 | 5 | ![Sơ đồ thiết kế hệ thống](Payment_Gateway_System_Design.jpg) 6 | 7 | Khi lướt GitHub, mình tình cờ tìm thấy một dự án chia sẻ cách lấy API ngân hàng: [MBBank API](https://github.com/CookieGMVN/MBBank). Từ đó, mình nảy ra ý tưởng thiết kế một cổng thanh toán trung gian tương tự như PayOS, SePay, MoMo và các nền tảng thanh toán khác. 8 | 9 | Dưới đây là bản thiết kế sơ bộ về core của hệ thống. Trên thực tế, khi triển khai, hệ thống có thể cần bổ sung thêm nhiều service khác để đảm bảo hiệu suất và tính mở rộng. 10 | 11 | ## CÁC THÀNH PHẦN CHÍNH CỦA HỆ THỐNG 12 | 13 | ### 1. Auth Service 14 | 15 | - Cung cấp và xác thực token cho user khi đăng nhập. 16 | 17 | ### 2. User Service 18 | 19 | - Quản lý thông tin tài khoản người dùng trong hệ thống. 20 | 21 | ### 3. Transaction Service 22 | 23 | - Tạo và quản lý giao dịch (transaction). 24 | 25 | ### 4. App Management Service 26 | 27 | - Cho phép người dùng tạo nhiều dự án khác nhau để quản lý riêng biệt các transaction và tài khoản ngân hàng theo từng dự án. 28 | 29 | ### 5. Bank Link Service 30 | 31 | - Quản lý kết nối tài khoản ngân hàng và token của từng user. 32 | 33 | ### 6. Scheduler Service 34 | 35 | - Quản lý tất cả các cron job của hệ thống, đảm bảo rằng chỉ một instance chạy duy nhất để tránh lỗi khi triển khai multi-instance. 36 | 37 | ### 7. Reconciliation Service 38 | 39 | - Đối soát giao dịch: so sánh kết quả transaction với lịch sử giao dịch nhận được từ ngân hàng. 40 | 41 | ### 8. Bank Connector Service 42 | 43 | - Quản lý kết nối với API ngân hàng, thực hiện các tác vụ liên quan đến truy vấn lịch sử giao dịch. 44 | 45 | ### 9. Notification Service 46 | 47 | - Hiện tại chủ yếu được sử dụng để gửi webhook đến bên thứ ba. 48 | - Nếu hệ thống phát triển và cần nhiều loại thông báo hơn (FCM, Email, SMS...), nên chuyển sang mô hình fanout, trong đó Notification Service chỉ đóng vai trò message queue để phân phối đến các service gửi thông báo. 49 | 50 | ## LUỒNG XỬ LÝ CHÍNH 51 | 52 | ### 1. Tạo Giao Dịch (Transaction) 53 | 54 | - **Bước 1**: Client gọi API để tạo một transaction. 55 | - **Bước 2**: Transaction Service xác thực tính hợp lệ của client thông qua App Management Service. Nếu hợp lệ, hệ thống sẽ tạo transaction thuộc về project đó với trạng thái _chờ xác nhận_. 56 | 57 | ### 2. Quy Trình Xác Nhận Giao Dịch 58 | 59 | - **Bước 1**: Scheduler Service kích hoạt cron job gọi đến Reconciliation Service để bắt đầu quá trình xác nhận giao dịch. 60 | - **Bước 2**: Reconciliation Service truy vấn Transaction Service để lấy danh sách các transaction cần xử lý, được nhóm theo project. 61 | - Nếu số lượng giao dịch lớn, Reconciliation Service phát sự kiện lên message queue để các instance khác cùng xử lý song song, tăng tốc độ xác nhận. 62 | - Để tránh xử lý trùng lặp, Transaction Service sử dụng distributed lock trên các transaction đang được xử lý. 63 | - **Bước 3**: Reconciliation Service gọi Bank Connector Service để truy vấn lịch sử giao dịch của từng tài khoản ngân hàng. 64 | - **Bước 4**: Bank Connector Service gọi Bank Link Service để lấy token của các tài khoản ngân hàng cần kiểm tra. 65 | - **Bước 5**: Bank Connector Service sử dụng API ngân hàng để lấy lịch sử giao dịch và gửi kết quả về Reconciliation Service. 66 | - **Bước 6**: Reconciliation Service đối chiếu dữ liệu nhận được từ ngân hàng với danh sách transaction và xác định giao dịch nào thành công. Các giao dịch thành công sẽ được gửi sự kiện đến Transaction Service để đánh dấu là _hoàn thành_. 67 | - **Bước 7**: Sau khi transaction được đánh dấu hoàn thành, Transaction Service gửi sự kiện đến Notification Service để webhook thông báo kết quả về ứng dụng của khách hàng. 68 | 69 | ## TỔNG KẾT 70 | 71 | Hệ thống trên chỉ là thiết kế sơ bộ và có thể mở rộng thêm nhiều service tùy theo nhu cầu thực tế. Điểm quan trọng nhất là đảm bảo tính nhất quán dữ liệu, khả năng mở rộng và hiệu suất xử lý giao dịch khi hệ thống phát triển. 72 | 73 | Mình rất mong nhận được góp ý và thảo luận từ mọi người để hoàn thiện mô hình này hơn nữa! 74 | --------------------------------------------------------------------------------