Một lớp thanh toán, nhiều cổng thanh toán: WeChat Pay và Alipay tại Odoo POS
Nếu vận hành bán lẻ tại Trung Quốc, doanh nghiệp gần như không cần hỏi khách sẽ thanh toán bằng gì. Tại quầy, khách mở app và trả bằng WeChat Pay hoặc Alipay. Vấn đề đáng bàn nằm ở phía sau thao tác quét mã đó: lớp tích hợp với Odoo có đủ bền khi bạn mở đến cửa hàng thứ ba, thêm nhà cung cấp thanh toán thứ hai, hoặc nâng cấp Odoo trong đợt tiếp theo hay không.
Phần lớn các bản tích hợp đầu tiên không đi được xa đến vậy. Lý do nằm ở cách thiết kế. Và một phiên bản có thể vận hành lâu dài cần được xây dựng khác ngay từ đầu.
Bản làm nhanh không thể mở rộng
Cách làm phổ biến ban đầu là dựng một workflow low-code để ký request rồi gọi cổng thanh toán. Khi demo, mọi thứ trông ổn. Nhưng sau đó hệ thống bắt đầu xuống cấp, không phải vì nghiệp vụ thanh toán quá khó, mà vì thiếu kỷ luật kỹ thuật. Secret dùng để ký giao dịch của merchant bị đặt trực tiếp trong workflow. Runtime tự cập nhật mà không ghim phiên bản, nên một thay đổi ngoài ý muốn cũng có thể làm production lỗi. Tình huống khách vẫn đang nhập PIN bị xử lý bằng một mớ nhánh rẽ, nhưng lại không có bản ghi bền vững để biết chính xác chuyện gì đã xảy ra. Retry và đối soát khó được mô tả một cách đáng tin cậy. Mỗi khách hàng mới lại kéo theo một lần dựng lại toàn bộ luồng bằng tay, không có unit test và cũng không có trạng thái có thể tái sử dụng.
Đó không phải là bài toán thanh toán. Đó là bài toán biến một prototype thành sản phẩm vận hành thật. Và đây chính là cái bẫy Majorbird muốn loại bỏ.
Một chuẩn giao tiếp, nhiều cổng thanh toán
Nguyên tắc thiết kế rất rõ ràng: Odoo POS chỉ nên nói một ngôn ngữ trung lập, bất kể phía sau là nhà cung cấp nào. Vì vậy, phía POS giao tiếp với một HTTP contract duy nhất, dùng một bộ lệnh nhỏ và cố định: thanh toán với mã đơn hàng, số tiền, mã khách đưa để quét và cổng thanh toán cần dùng; truy vấn hoặc poll trạng thái; hoàn tiền; hủy giao dịch; cùng một raw proxy để xử lý các tình huống đặc biệt.
Trạng thái thanh toán được chuẩn hóa về một bộ trạng thái chung để mọi cổng thanh toán cùng ánh xạ vào: đã tạo, đang thanh toán, đã thanh toán, thất bại hoặc đã hủy, sau đó là đang hoàn tiền, đã hoàn tiền hoặc hoàn tiền một phần. Những phần phức tạp theo từng nhà cung cấp như thuật toán ký, tên trường dữ liệu, định dạng số tiền, endpoint cần gọi, đều được đóng gói trong module riêng của từng cổng và quản lý sau một registry.
Nhờ vậy, “một addon, nhiều cổng thanh toán” không chỉ là khẩu hiệu. Phương thức thanh toán trong Odoo chỉ cần lưu endpoint và cổng thanh toán cần dùng. Muốn thêm nhà cung cấp mới, chỉ cần thêm một module mới và một dòng trong registry. POS addon không phải chỉnh sửa. Không phải làm lại module, không tạo bản sao tách nhánh, không có bản build riêng cho từng khách hàng.
Vì sao thanh toán POS tại Trung Quốc là một bài toán riêng
Cần nói thẳng rằng bài toán này khó hơn nhiều so với việc nối một cổng thẻ phổ biến ở thị trường phương Tây. Và lý do thường khiến nhiều người bất ngờ.
Luồng thanh toán bị đảo chiều. Thay vì khách quét QR của cửa hàng, thu ngân sẽ quét mã hiển thị trong app của khách. Đây là luồng customer-presented barcode, còn gọi là micropay.
Kết quả thanh toán không phải lúc nào cũng có ngay. Có giao dịch hoàn tất tức thì, nhưng cũng có giao dịch phải chờ khách nhập PIN và được trả về dưới dạng trạng thái kiểu “user paying”. Không có câu trả lời đồng bộ đơn giản là thành công hay thất bại. Hệ thống phải poll cho đến khi giao dịch có kết quả cuối cùng. Quan trọng hơn, các phản hồi mơ hồ như “system busy” hoặc “user still paying” tuyệt đối không được xem là thất bại. Nếu retry một giao dịch thực ra đã thành công, khách có thể bị trừ tiền hai lần. Một giao dịch bị kẹt ở trạng thái “paying” quá thời gian cho phép cần được đảo tự động để không có khoản tiền nào bị treo.
Đối soát cũng cần một ledger riêng. Các cổng thanh toán chỉ trả lời theo từng giao dịch, không có sẵn chức năng “liệt kê doanh số hôm nay” để hệ thống dựa vào. Vì vậy, hệ thống phải tự lưu bản ghi bền vững và đối soát dựa trên đó. Đằng sau cùng một contract, hai nhà cung cấp lại vận hành rất khác nhau: WeChat Pay v2 dùng XML với chữ ký MD5 và chứng chỉ TLS phía client cho hoàn tiền, trong khi Alipay dùng JSON với RSA2. Mục tiêu của contract trung lập là để thu ngân và Odoo POS không cần biết bất kỳ chi tiết nào trong số đó.
Từ giải pháp chắp vá thành dịch vụ vận hành được
Để biến thiết kế này thành một hệ thống có thể phục vụ nhiều merchant, điều quan trọng là áp dụng đúng các nguyên tắc phần mềm cơ bản. Gateway chạy như một service có quản lý phiên bản, dùng image tag bất biến, nghĩa là bản đã test cũng chính là bản được triển khai. Cấu hình được tách khỏi code: credential và thông tin cổng thanh toán lấy từ môi trường, không hardcode dữ liệu nhạy cảm, secret được kéo từ vault khi khởi động thay vì đóng gói sẵn trong artifact. Logic ký giao dịch có unit test. Hệ thống có ledger bền vững, cơ chế đối soát chạy nền để xử lý giao dịch bị kẹt, dashboard vận hành và backup có khả năng tự kiểm chứng. Khi có khách hàng mới, đội triển khai làm theo checklist thay vì xây lại từ đầu.
Điều này tạo ra khác biệt gì tại quầy
Với nhà bán lẻ, kết quả tốt nhất là mọi thứ diễn ra rất “êm”, đúng như mục tiêu ban đầu. Doanh nghiệp nhận WeChat Pay và Alipay trực tiếp tại Odoo POS, có xác nhận và hoàn tiền theo thời gian thực. Giao dịch được đối soát tự động vào Odoo, thay vì cuối ngày phải có người ngồi so tổng tiền trên app thanh toán với doanh số bán hàng. Thêm nhà cung cấp mới không đồng nghĩa với một dự án custom lại từ đầu. Việc triển khai nhiều cửa hàng và nhiều khách hàng nhanh hơn, chi phí bảo trì thấp hơn, còn log thanh toán có thể audit xuyên suốt từ đầu đến cuối.
Hiện tại, POS addon được thiết kế cho Odoo 18 Enterprise POS, trong khi gateway service hoạt động độc lập với phiên bản Odoo. Bản chuyển sang Odoo 19 đã nằm trong kế hoạch.
Góc nhìn của chúng tôi
Hạ tầng thanh toán tại Trung Quốc không phải phần khó nhất. Gần như đội nào cũng có thể làm cho một giao dịch chạy thành công một lần. Phần khó là làm cho mọi cửa hàng, mọi nhà cung cấp và mọi lần nâng cấp cùng vận hành theo một cách nhất quán, không phải xây lại mỗi lần và không để rủi ro trừ tiền hai lần chờ xảy ra. Đó là khác biệt giữa một tích hợp chạy tốt trong demo và một tích hợp đủ vững cho production. Đây cũng là cùng một kỷ luật “chẩn đoán trước khi xây” mà Majorbird áp dụng cho các dự án Odoo khác.
Nếu bạn đang cân nhắc triển khai WeChat Pay và Alipay tại Odoo POS, hoặc đang phải duy trì một bản tích hợp làm riêng bắt đầu phát sinh chi phí, tốt nhất nên trao đổi trước khi sự cố xảy ra vào thời điểm tệ nhất. Hãy trao đổi với đội ngũ Majorbird tại odoo@majorbird.com hoặc www.majorbird.com.