Giờ cao điểm, nhân viên thu ngân khó vừa pha đồ uống, vừa mở điện thoại kiểm tra từng khoản chuyển. Tích hợp đối soát ngân hàng vào phần mềm POS của quán cafe giải quyết được bước xác nhận này nếu khoản tiền được nối đúng bill. Nhưng chỉ một quy tắc ghép theo số tiền cũng đủ gây nhầm: hai bàn cùng mua đồ uống 85.000 đồng, một khách trả thiếu hoặc cả nhóm chia nhau thanh toán.
Luồng cần xây là bill tạo yêu cầu thu, kết quả hợp lệ quay về POS, rồi thu ngân nhìn thấy trạng thái đủ để xử lý. Muốn luồng đó hoạt động trong ca bận rộn, quán phải thống nhất cách nhận diện bill, xử lý thanh toán hỗn hợp và phục hồi khi mạng mất. Kết nối nhanh là bước đầu; phần khó hơn là giữ trạng thái nhất quán.
Kiểm tra POS có thể nhận và cập nhật những dữ liệu nào
Trước buổi triển khai, hỏi đơn vị POS về API hoặc điểm tích hợp chính thức. Hệ thống có tạo mã bill ổn định, lấy số còn phải thu và cập nhật kết quả thanh toán không? Có lưu lịch sử và chống một yêu cầu bị áp dụng hai lần không? Câu trả lời cần gắn với phiên bản đang dùng tại quán, không chỉ tên thương hiệu phần mềm.
Nếu POS chỉ cho xuất báo cáo cuối ca, phạm vi có thể mới dừng ở đối chiếu sau bán. Muốn thu ngân thấy xác nhận ngay trên bill cần một luồng khác, thường phải phát triển hoặc cấu hình với đơn vị phần mềm. Đừng coi việc dịch vụ thanh toán có webhook là bằng chứng POS bất kỳ đã nhận được webhook đó.
Trên hoadontudong.com.vn, hướng dẫn tích hợp QR với phần mềm bán hàng có thể dùng để chuẩn bị câu hỏi cho các bên. Nên thống nhất ai xây lớp kết nối, ai giữ khóa, ai hỗ trợ lúc ca bán đang chạy và cách xử lý nếu POS cập nhật phiên bản sau khi bàn giao.
Bill, ca và khoản thanh toán cần định danh riêng
Mã bill xác định nghĩa vụ của khách; mã ca xác định phạm vi báo cáo; mã giao dịch nhận diện khoản tiền. Một bill có thể có nhiều khoản thanh toán, còn một giao dịch gửi lại không tạo thêm tiền. Nếu dùng chung một mã cho cả ba, việc điều tra đơn trả gộp hoặc bàn giao ca sẽ trở nên khó khăn.
Lưu số phải thu theo phiên bản bill tại lúc tạo yêu cầu. Khi khách gọi thêm món, giảm giá hoặc bỏ món, POS cần biết yêu cầu thu cũ còn hiệu lực thế nào. Không lấy số tiền đã gửi trước đó so với bill hiện tại rồi tự xem là trả thiếu, nếu nhân viên vừa thay đổi bill mà hệ thống chưa lưu lịch sử.
Mã bàn hỗ trợ phục vụ nhưng không đủ làm khóa thanh toán. Cùng một bàn có nhiều lượt khách trong ngày; khách có thể đổi bàn hoặc tách bill. Mã ca cũng không nên phụ thuộc tên người đang đăng nhập. Khi thay thu ngân giữa ca, các bill còn mở cần được bàn giao mà không đổi định danh gốc.
Thiết kế luồng QR theo bill và xác nhận tại máy chủ
Với bill đã xác định số cần thu, POS hoặc lớp kết nối tạo yêu cầu thanh toán rồi hiển thị QR phù hợp. Tài liệu Collection Link Pay2S mô tả việc tạo liên kết thanh toán. Phần liên kết yêu cầu đó với bill và ca thuộc thiết kế của ứng dụng quán, cần được thử trực tiếp trên phần mềm đang sử dụng.
Khách chuyển xong, kết quả phải được xác thực ở máy chủ trước khi cập nhật. Đặc tả IPN Pay2S yêu cầu kiểm tra thông báo và xử lý chống trùng trước khi phản hồi nhận thành công. Màn hình thu ngân đọc trạng thái đã lưu từ backend; ảnh chuyển khoản hoặc việc khách quay về trang kết quả chỉ hỗ trợ tra cứu.
Trạng thái nên đủ rõ cho thao tác quầy: chờ thanh toán, đã nhận một phần, đã đủ, cần kiểm tra và đã hủy. Không để tất cả cùng hiển thị một vòng quay đang xử lý. Khi khách hỏi, nhân viên cần biết tiền chưa được xác nhận hay đã nhận nhưng chưa khớp bill để chọn đúng hướng xử lý.
Một hợp đồng dữ liệu nội bộ ngắn, dễ kiểm tra
Ví dụ sau là cấu trúc đề xuất giữa lớp kết nối và POS, không phải payload API Pay2S. Nó tách bill, ca, yêu cầu và số đã phân bổ để các bên thống nhất trước khi lập trình.
{
"billId": "BILL_DEMO_001",
"shiftId": "SHIFT_DEMO_001",
"paymentRequestId": "PAYMENT_DEMO_001",
"amountDue": 85000,
"amountAllocated": 50000,
"paymentStatus": "partially_paid"
}Hai bên cần bổ sung quy tắc phiên bản bill, kiểu tiền và các trạng thái thực tế theo khả năng POS. Thống nhất phần này sớm giúp tránh lỗi một bên hiểu đã nhận tiền là đóng bill, trong khi bên kia vẫn còn phần thanh toán bằng tiền mặt.
Chia thanh toán và đổi bill mà không làm lệch tiền
Một bill 150.000 đồng có thể được trả 100.000 đồng bằng chuyển khoản và 50.000 đồng tiền mặt. POS cần cộng các khoản đã xác nhận theo phương thức, rồi tính phần còn phải thu. Không đánh dấu bill chưa thanh toán chỉ vì giao dịch chuyển khoản không bằng toàn bộ bill; cũng không đóng bill khi mới nhận phần đầu.
Với nhóm khách mỗi người chuyển một phần, lưu từng giao dịch độc lập và tổng phân bổ vào bill. Nếu người cuối chuyển dư, khoản vượt cần được nhận diện và xử lý theo quy trình của quán. Không tự bù sang một bàn khác chỉ vì bàn đó còn nợ đúng số tiền. Thu ngân phải nhìn được từng khoản đã gắn, nhất là lúc có nhiều người trả cùng lúc.
Tách hoặc gộp bill sau khi đã nhận tiền cần bước chuyển phân bổ có lịch sử. Trước khi cho phép sửa, kiểm tra bill đã đóng hoặc đã có tác vụ chứng từ chưa. Quyền sửa nên theo vai trò của quán; người sửa lưu lý do để quản lý ca và kế toán không phải dựng lại câu chuyện từ các tin nhắn riêng.
Tình huống giả định: hai bàn cùng trả 85.000 đồng
Bill A và B cùng trị giá 85.000 đồng. Khách ở bàn A chuyển theo yêu cầu của A, còn bàn B chưa trả. Nếu ứng dụng tìm bill gần nhất có cùng tiền rồi chọn B, A vẫn báo chờ và B lại được đóng. Tổng tiền trong ngày có thể vẫn đúng, nhưng trạng thái phục vụ và trách nhiệm ca đã sai.
Khóa nhận diện phải nối giao dịch với yêu cầu đã tạo cho A. Khi tham chiếu bị thiếu, phần mềm nên gợi ý để thu ngân kiểm tra thay vì tự chọn. Trong trường hợp chưa đủ bằng chứng, giữ giao dịch ở danh sách cần xác minh, hỏi khách thông tin cần thiết và tránh yêu cầu họ chuyển lại khi đã có khoản ghi có.
Vấn đề này thường lộ ra khi thử hai bill song song. Một buổi demo chỉ thanh toán lần lượt từng bill dễ bỏ qua. Hãy đưa cả tình huống nhân viên mở lại bill, khách trả thêm món và hai khoản đến gần nhau vào bộ thử; kiểm tra kết quả trên màn hình quầy lẫn dữ liệu cuối ca.
Mất mạng, thông báo muộn và thao tác gửi lại
Quầy có thể mất mạng trong khi khách vẫn chuyển tiền thành công từ điện thoại. Nhân viên cần có quy trình tra cứu qua kênh được phép và ghi lại bill đang chờ. Khi mạng trở lại, POS phải đọc trạng thái hiện tại từ máy chủ thay vì tạo yêu cầu mới cho cùng một khoản hoặc đánh dấu lại toàn bộ theo thao tác tay.
Ở phía backend, thông báo đến lại phải được nhận mà không cộng tiền lần nữa. Nếu tác vụ cập nhật POS bị lỗi sau khi khoản thu đã được lưu, cần thử lại đúng tác vụ đó. Không chạy lại từ đầu như thể nhận một giao dịch mới. Tham khảo nguyên tắc lưu giao dịch và chống lặp để thống nhất với đội kỹ thuật.
Nếu lớp thanh toán và POS dùng hai cơ sở dữ liệu, một thao tác lưu ở bên này không bảo đảm bên kia đã cập nhật. Có thể thiết kế hàng đợi tác vụ và lưu yêu cầu đồng bộ cùng khoản thu, rồi theo dõi đến khi POS xác nhận. Đây là đề xuất kiến trúc, cần điều chỉnh theo API thực tế. Nhân viên quầy nên nhìn thấy trạng thái đã nhận tiền, đang cập nhật thay vì một nhãn thất bại khiến họ yêu cầu khách trả lại.
Đổi món hoặc hoàn sau khi bill đóng cũng cần luồng riêng. Lưu bill gốc, giá trị điều chỉnh, người duyệt và kết quả hoàn, tránh xóa giao dịch đã nhận. Nếu khách dùng cả tiền mặt lẫn chuyển khoản, thống nhất cách hoàn theo quy trình của quán và kiểm tra số đã hoàn để không chi hai lần. Báo cáo ca cần thể hiện phần điều chỉnh này cho người bàn giao.
Khoản tiền đến sau khi bill hủy cần được kiểm tra riêng. Hủy trên POS không khiến khoản chuyển thật biến mất. Quán cần người quyết định khôi phục theo điều kiện hiện tại, lập bill mới có liên kết hoặc xử lý hoàn phù hợp. Cấu hình phải tránh một thông báo cũ tự mở lại bill đã được quản lý kết thúc.
Chốt ca bằng tiền nhận và bill còn chờ
Báo cáo ca nên có tổng từng phương thức, khoản chưa phân bổ, bill thiếu tiền, khoản dư và điều chỉnh. Tiền mặt kiểm theo quy trình quầy; chuyển khoản đối chiếu nguồn nhận; bill kiểm tra số đã phân bổ. Ba góc nhìn này giúp xác định chênh đến từ thiếu tiền, sai phân bổ hay dữ liệu đồng bộ, thay vì quy mọi lỗi cho thu ngân.
Khi tiền đến sau giờ giao ca, giữ ca của bill cùng thời gian giao dịch và thời gian nhận dữ liệu. Cần quy tắc cập nhật vào bản chốt và người được duyệt. Nếu triển khai hóa đơn, dùng trạng thái riêng để kiểm tra bill đã nhận đủ nhưng hóa đơn còn chờ. Bài chuẩn hóa dữ liệu hóa đơn cho website và POS giúp chuẩn bị bước tiếp theo này.
Nghiệm thu nên bắt đầu ở một quầy, qua đủ một ca bận, với người sẽ vận hành thực tế. Ghi lại những lần thu ngân phải hỏi quản lý hoặc mở ứng dụng khác; đó là các điểm cần sửa trong luồng. Khi muốn đánh giá phạm vi kết nối, có thể mang bộ bill mẫu và tài liệu POS tới đội triển khai Pay2S. Điều kiện mở rộng là ca sau xử lý được các ngoại lệ mà không cần người lập trình đứng cạnh.
