Khi mình vừa rời dự án E-Commerce để bước sang một dự án Retail, mình từng nghĩ phần Payment Flow sẽ đơn giản — chỉ là thanh toán thôi mà. Dù là online hay tại cửa hàng, người dùng cũng “trả tiền để mua hàng”, về bản chất vẫn giống nhau. Nhưng chỉ sau vài buổi làm việc với team POS và kế toán, mình nhận ra: Payment trong Retail là một thế giới hoàn toàn khác, phức tạp và giàu logic hơn rất nhiều.
Điều thú vị là, E-Commerce không hỗ trợ partial payment, còn Retail thì ngược lại — có thể split, partial, thậm chí hoàn trả tiền thừa (change) ngay tại POS. Tại sao lại có sự khác biệt này, trong khi mục tiêu cuối cùng vẫn là “hoàn tất giao dịch”? Hãy cùng mình phân tích luồng thanh toán giữa hai domain để thấy rõ điều đó.
Payment flow trong e-commerce được thiết kế như thế nào?
Trong E-Commerce, thanh toán thường được thực hiện sau khi người dùng xác nhận đơn hàng (checkout). Các bước phổ biến gồm:
- Chọn phương thức thanh toán (COD, Credit Card, E-Wallet, Internet Banking).
- Hệ thống tạo đơn hàng tạm (Pending Order).
- Gửi request sang Payment Gateway (như MoMo, ZaloPay, VNPay…).
- Gateway redirect người dùng sang trang thanh toán.
- Sau khi thanh toán thành công, gateway callback về hệ thống E-Commerce.
- Đơn hàng chuyển trạng thái “Paid” và được chuyển cho OMS xử lý.
Đặc trưng lớn nhất là mỗi đơn hàng chỉ có một phương thức thanh toán duy nhất. Nếu khách muốn “chia đôi” thanh toán (ví dụ: 50% bằng thẻ, 50% bằng ví điện tử) — hệ thống không cho phép. Để làm vậy, họ phải chia đơn hàng thành 2 order riêng biệt.
Tại sao lại như vậy?
Bởi vì E-Commerce Payment Flow gắn chặt với Payment Gateway API, mà hầu hết các cổng thanh toán chỉ nhận một transaction ID tương ứng với một tổng giá trị đơn hàng. Gateway đóng vai trò trung gian bảo đảm giao dịch (authorization & capture), nên nếu có nhiều phương thức thanh toán cùng lúc, việc reconcile và refund sẽ cực kỳ phức tạp.
Ngoài ra, hệ thống E-Commerce luôn hướng đến automated flow, nơi mọi thứ phải diễn ra liền mạch, không có sự can thiệp của con người. Chính vì thế, luồng thanh toán được thiết kế đơn giản, “1 order – 1 payment method – 1 transaction”.
Retail Payment Flow – “Một giao dịch, nhiều phương thức”
Trong khi đó, ở Retail, luồng thanh toán lại mang đặc trưng offline và linh hoạt theo con người. Khi khách hàng đến cửa hàng, họ có thể:
- Trả bằng tiền mặt 100%.
- Trả 70% tiền mặt + 30% bằng thẻ.
- Dùng voucher, loyalty point, rồi trả phần còn lại bằng ví điện tử.
- Hoặc đơn giản là đưa tờ 500.000 cho đơn hàng 90.000 và nhận lại tiền thừa.
Đây là điều mà hệ thống POS (Point of Sale) phải hỗ trợ: Multi-Tender Transaction – nghĩa là một giao dịch có thể có nhiều hình thức thanh toán song song.
Lý do Retail cần điều này là vì trải nghiệm tại cửa hàng khác hoàn toàn online:
- Khách hàng tương tác trực tiếp với nhân viên thu ngân.
- Hệ thống không thể giới hạn họ chỉ dùng một phương thức duy nhất.
- Việc nhận tiền, trả tiền, hoặc trừ điểm diễn ra tức thời, và POS cần phản ứng trong mili-giây.
Ví dụ:
Một khách hàng mua đơn hàng 1.200.000đ tại cửa hàng. Họ có:
- 500.000đ tiền mặt.
- 200.000đ trong ví Momo.
- 500 điểm loyalty (tương đương 500.000đ).
Thu ngân chỉ cần nhập lần lượt các phương thức:
- Cash: 500.000đ
- Loyalty Point: 500.000đ
- Momo: 200.000đ
POS ghi nhận 3 dòng payment trong cùng 1 receipt, và transaction vẫn “balanced” vì tổng các payment bằng tổng giá trị đơn hàng.
Đây chính là partial/multi payment – thứ mà E-Commerce gần như không thể làm được do hạn chế trong cơ chế gateway và luồng online automation.
Khác biệt kỹ thuật giữa POS Integration vs Payment Gateway API
Trong E-Commerce, thanh toán được thực hiện thông qua Payment Gateway API, nên hệ thống chỉ cần gửi request, nhận callback, rồi lưu trạng thái “Paid”/“Failed”. Giao dịch online phụ thuộc hoàn toàn vào phía gateway, không cần POS.
Trong Retail, hệ thống POS tích hợp trực tiếp với nhiều thiết bị thanh toán tại quầy như:
- Máy POS card (Napas, Visa, MasterCard).
- Mã QR code e-wallet.
- Hệ thống voucher, loyalty engine.
- Và cả ngăn kéo tiền mặt (cash drawer).
Mỗi phương thức thanh toán được POS ghi nhận như một tender type, và tất cả được tổng hợp vào transaction summary trước khi “đóng ca” (shift close).
Điểm mấu chốt là POS xử lý tất cả payment tại local level, không cần redirect sang cổng thanh toán bên ngoài như web.
Nói cách khác, Retail có quyền “split” transaction ngay tại thiết bị bán hàng, trong khi E-Commerce thì không — vì toàn bộ logic nằm ở payment gateway của bên thứ ba.
Case Study: Multi-Tender Transaction trong Retail
Hãy hình dung một case thực tế:
Tại cửa hàng thời trang, một khách hàng mua đơn hàng trị giá 890.000đ.
Họ muốn thanh toán:
- 400.000đ bằng tiền mặt,
- 200.000đ bằng voucher khuyến mãi,
- 290.000đ còn lại bằng thẻ Visa.
Nhân viên thu ngân thao tác như sau:
- Chọn Payment Method #1: Cash → nhập 400.000đ.
- Chọn Payment Method #2: Voucher → nhập mã, POS xác thực giá trị 200.000đ.
- Chọn Payment Method #3: Visa → máy POS cà thẻ, xác nhận 290.000đ.
- POS kiểm tra tổng payment = 890.000đ → balanced → cho phép in hóa đơn.
Tại backend, hệ thống ghi nhận 3 record trong bảng Payment, mỗi record gắn với PaymentType, Amount, ReferenceID, nhưng chỉ có 1 TransactionID đại diện cho đơn hàng.
Trong báo cáo cuối ngày, kế toán cửa hàng có thể xem:
- Tổng tiền mặt thu trong ca.
- Tổng giá trị voucher đã sử dụng.
- Tổng tiền thẻ đã cà qua máy Napas.
Đây là cách Retail system reconcile dữ liệu — hoàn toàn khác với E-Commerce vốn chỉ cần đối soát với 1 gateway API.
Change management – bài toán không tồn tại ở E-Commerce
Một yếu tố thú vị khác là tiền thừa (change).
Trong Retail, nếu khách hàng thanh toán bằng tiền mặt lớn hơn giá trị đơn hàng, POS phải tự động tính và hiển thị số tiền thừa cần trả lại.
Ví dụ:
Order = 92.000đ
Customer pays = 100.000đ
Change = 8.000đ
Tuy chỉ là một phép trừ đơn giản, nhưng từ góc nhìn hệ thống, đây là một transaction ghi âm (negative payment) mà POS phải xử lý, để đảm bảo tổng transaction luôn cân bằng về mặt kế toán.
Trong E-Commerce, điều này không bao giờ xảy ra vì toàn bộ payment được xác nhận chính xác qua gateway, không có chuyện “trả thừa – thối lại”.
Những thách thức khi thiết kế Payment Flow cho Retail
Đối với BA hoặc PM trong dự án Retail, Payment Flow là một trong những module phức tạp nhất, vì liên quan đến:
- Đa phương thức thanh toán (Cash, Card, Wallet, Voucher, Loyalty…)
- Multi-Tender logic (partial, split, change)
- Integration với thiết bị ngoại vi (POS terminal, scanner, cash drawer)
- Reconciliation và shift closing
- Refund và return flow (hàng đổi trả, hoàn tiền loyalty…)
Một thiết kế sai trong Payment Flow có thể khiến cả hệ thống POS “đơ” tại quầy, hoặc dữ liệu reconciliation bị sai lệch — dẫn đến sai số tài chính khi đối soát với ngân hàng.
Payment không chỉ là trả tiền, mà là kiểm soát dòng giá trị
Sự khác biệt giữa E-Commerce và Retail trong Payment Flow không chỉ nằm ở công nghệ mà còn ở triết lý vận hành.
- E-Commerce hướng tới automation & simplicity – mỗi đơn hàng chỉ cần một transaction rõ ràng, đồng nhất với cổng thanh toán.
- Retail hướng tới flexibility & control – cho phép khách hàng và nhân viên xử lý linh hoạt mọi tình huống tại quầy, đồng thời vẫn đảm bảo cân bằng tài chính.
Đó là lý do vì sao khi một Business Analyst từ E-Commerce chuyển sang Retail, module Payment thường là “cú sốc đầu tiên” – vì nó đòi hỏi hiểu sâu về kế toán giao dịch, POS integration, và cả hành vi thanh toán thực tế của con người.
Hiểu được multi-tender transaction, split payment, change management chính là bước đầu tiên để một BA thực sự “đi vào lõi domain Retail” – nơi thanh toán không chỉ là “trả tiền mua hàng”, mà là trái tim kết nối giữa vận hành, kế toán và trải nghiệm khách hàng.
