Website đã nhận tiền nhưng kế toán còn phải hỏi thông tin người mua, nhập lại hàng hóa rồi tìm đúng đơn để lập hóa đơn. Khoảng cách giữa hai quy trình này khiến một khoản thu phải được xử lý nhiều lần. Tự động hóa có ích khi dữ liệu được giữ từ đầu và từng trạng thái vẫn có thể kiểm tra.
Bài viết trên hoadontudong.com.vn giải thích cách Pay2S nối luồng thanh toán với hóa đơn điện tử, đồng thời phân biệt yêu cầu lập, bản nháp và kết quả phát hành. Có thể đọc giới thiệu API Pay2S trước khi khảo sát cấu hình phù hợp. Nội dung tập trung thiết kế vận hành; kế toán vẫn xác định chính sách áp dụng cho từng nghiệp vụ.
Pay2S là gì trong luồng thanh toán và HĐĐT?
Theo tổng quan hóa đơn điện tử Pay2S, doanh nghiệp có thể kết nối tài khoản nhà cung cấp, chọn mẫu, tạo nháp và tự động hóa theo điều kiện. Luồng này cần dữ liệu đơn và kết nối sẵn sàng; một khoản tiền vào tài khoản chưa tự mô tả đầy đủ người mua hay hàng hóa.
Với website tự tạo thanh toán, metadata được gửi trong extraData của Collection Link V2. Merchant nên giữ một bản dữ liệu nguồn để đối chiếu sau này. Nếu người mua yêu cầu sửa thông tin, hệ thống cần biết dữ liệu nào đã gửi và hồ sơ đã đến bước nào trước khi cho phép thao tác.
extraData phục vụ vận chuyển metadata theo contract, không phải nơi thay thế mọi dữ liệu đơn. Ứng dụng bán hàng vẫn quản lý nghĩa vụ và lịch sử; Pay2S cùng nhà cung cấp xử lý những bước thuộc cấu hình hóa đơn. Phân rõ vai trò giúp tránh kỳ vọng chỉ cần thêm một trường là toàn bộ công việc kế toán đã được tự động.
Nên tách bảng theo dõi thành tiền, hồ sơ hóa đơn và kết quả phát hành. Khi một phần bị chậm, các phần còn lại vẫn được giữ đúng. Người hỗ trợ có thể trả lời khách đã thanh toán hay chưa, trong khi kế toán biết đang chờ dữ liệu hoặc kết quả từ nhà cung cấp.
Collection Link V2 bổ sung gì?
Collection Link V2 mở rộng dữ liệu người mua, hàng hóa và tùy chọn hóa đơn. Tài liệu quy định signatureVersion=2 cùng metadata Base64, vẫn dùng endpoint create hiện tại. Không nên coi V2 là một URL mới có thể thay vào client V1 mà không sửa cách ký và dữ liệu.
Secret Key dùng ký tại backend. Người mua không trực tiếp lựa chọn bộ khóa, tài khoản kết nối hoặc mẫu hóa đơn thông qua các trường tùy ý. Backend cần mapping đơn với đúng chủ thể, nhất là khi website có nhiều cửa hàng hoặc pháp nhân.
Điểm cần lưu sau create là kết quả thanh toán thực tế, bao gồm orderInfo do response trả về. Dữ liệu request và response có vai trò khác nhau trong V2; lưu cả tham chiếu cần thiết giúp nối đơn với kết quả IPN và hồ sơ hóa đơn mà không dựa vào suy đoán từ nội dung chuyển khoản.
Trước khi chuyển phiên bản, hãy chọn một nhóm đơn đại diện để thử: người mua cá nhân, doanh nghiệp, nhiều dòng hàng và hồ sơ thiếu dữ liệu. Việc một đơn mẫu chạy được chưa chứng minh mapping đáp ứng toàn bộ danh mục đang bán.
Metadata người mua và hàng hóa
Dữ liệu người mua cần có nguồn rõ và được kiểm tra trước khi tạo đơn. Tên người chuyển tiền có thể khác đơn vị mua hàng, nên không dùng nó để ghi đè tên doanh nghiệp hoặc mã số thuế. Với khách doanh nghiệp, bước xác nhận thông tin ở checkout giúp giảm việc sửa hồ sơ sau thanh toán.
Danh sách hàng hóa nên giữ mã nội bộ ổn định, tên dùng trên chứng từ, số lượng, giá và dữ liệu thuế phù hợp. Tên marketing trên website có thể khác tên nghiệp vụ; nếu có quy tắc mapping, cần người phụ trách kiểm tra và có cách phát hiện sản phẩm mới chưa được cấu hình.
Tổng thanh toán phải khớp dữ liệu dòng hàng theo quy tắc áp dụng. Không nên gửi một tổng tiền riêng rồi kỳ vọng hệ thống đoán ra chênh lệch do chiết khấu hoặc thuế. Kế toán cần xác nhận cách biểu diễn những trường hợp này trước khi đội kỹ thuật dựng metadata.
Tình huống giả định: khách mua hai loại dịch vụ nhưng backend chỉ gửi một dòng tổng hợp không đủ mô tả nghiệp vụ. Thanh toán vẫn có thể được ghi nhận, trong khi kế toán chưa có căn cứ kiểm tra hóa đơn. Cần sửa dữ liệu từ đơn nguồn, không chỉ thay một nhãn trên màn hình hóa đơn.
Để bàn giao, lưu bảng mapping và một bộ đơn đã ẩn thông tin cá nhân. Người quản lý có thể xem mỗi trường lấy từ đâu và ai chịu trách nhiệm khi thiếu. Tài liệu này hữu ích hơn việc chỉ giữ một payload đã ký mà không giải thích nguồn dữ liệu.
extraData và chữ ký V2
Theo đặc tả V2, metadata JSON UTF-8 được Base64 đúng một lần, rồi dùng cùng chuỗi trong payload và chữ ký. Base64 không che giấu nội dung; dữ liệu người mua vẫn cần được quản lý theo quyền truy cập phù hợp.
Backend nên tạo metadata một lần từ dữ liệu đã kiểm tra, sau đó mã hóa và ký. Không để lớp gửi HTTP serialize lại metadata hoặc đổi URL sau khi tính chữ ký. Khi có lỗi xác minh, đối chiếu biểu diễn dữ liệu thay vì thử thêm một lần Base64.
Test nên có tiếng Việt, nhiều dòng hàng và các trường tùy chọn rỗng để phát hiện khác biệt encoding. Dùng khóa giả và dữ liệu giả trong fixture. Không lưu thông tin đăng nhập hoặc payload chứa dữ liệu thật vào repository để tiện so sánh.
Khi nào hóa đơn được phát hành?
Yêu cầu hóa đơn và hóa đơn đã phát hành là hai trạng thái khác nhau. Tài liệu tự động hóa hóa đơn phân biệt tự tạo nháp với tự phát hành; đơn còn phải đáp ứng điều kiện kết nối, mẫu và dữ liệu. Nên bắt đầu ở chế độ kiểm tra phù hợp trước khi bật tác động thật.
Thời điểm lập hóa đơn cần được xác định theo nghiệp vụ và quy định áp dụng, không mặc định mọi tiền về đều là điều kiện phát hành ngay. Doanh nghiệp nên thống nhất chính sách theo nhóm đơn với kế toán, rồi chuyển thành quy tắc và quyền thao tác trong hệ thống.
Trong vận hành, hồ sơ chờ phải có lý do và người xử lý. Nếu thiếu dữ liệu người mua, đội bán hàng có thể cần bổ sung; nếu chưa rõ kết quả nhà cung cấp, cần kiểm tra trạng thái trước. Không dùng cùng một nút tạo lại cho mọi lỗi vì có thể làm phát sinh hồ sơ trùng.
Nên kiểm tra đến PDF hoặc kết quả cuối của nhà cung cấp khi nghiệm thu. Tạo được bản nháp mới chứng minh một phần luồng. Việc ký, cấp số và gửi người mua cần được theo dõi theo những trạng thái tương ứng của hệ thống.
Checklist tránh xuất hóa đơn trùng
Chống xuất trùng bắt đầu từ việc giữ một liên hệ rõ giữa đơn nguồn, yêu cầu hóa đơn và kết quả nhận được. Khi IPN gửi lại, ứng dụng không được tạo thêm một yêu cầu mới chỉ vì handler chạy lần nữa. Xem xử lý IPN và vận hành chống trùng cho phần backend.
Không dùng extraData làm khóa duy nhất để quyết định đã phát hành hay chưa. Cần lưu tham chiếu nghiệp vụ và kết quả hóa đơn, đồng thời kiểm soát các tác vụ có thể chạy đồng thời. Nếu vừa bật luồng tự động vừa gọi API hóa đơn độc lập cho cùng đơn, phải có thiết kế tránh hai đường cùng tạo tác động.
Với kết quả chưa xác định, tra cứu hoặc đồng bộ trước khi gửi lại. Tài liệu đối soát hóa đơn phân biệt bước kiểm tra dữ liệu với thao tác lập, phát hành. Một lần kiểm tra lại không nên bị hiểu là một lần tạo hóa đơn mới.
Quyền phát hành thủ công cũng cần được quản lý. Khi nhân viên xử lý hồ sơ ngoài luồng tự động, họ phải nhìn được trạng thái mới nhất và giữ lý do thao tác. Chống trùng không chỉ là bài toán hai worker; nó còn là phối hợp giữa thao tác người dùng và tác vụ nền.
Ví dụ kỹ thuật an toàn cho Pay2S là gì
Đoạn JSON dưới giữ ba khái niệm để giải thích, không phải body create V2 đầy đủ. Trong request thực, invoiceOptions thuộc metadata được mã hóa vào extraData, không gửi như một trường cấp ngoài theo sơ đồ này. Secret Key vẫn nằm tại backend và không bổ sung vào payload.
{
"signatureVersion": "2",
"extraData": "<BASE64_METADATA>",
"invoiceOptions": { "requested": true }
}Khi triển khai, dựng đủ metadata cùng các trường create theo đặc tả, rồi kiểm tra tổng tiền và chữ ký. Dùng mẫu đầy đủ của phiên bản đang áp dụng; không chép sơ đồ rút gọn thành request thật. Bước phân biệt này tránh việc một ví dụ giải thích bị hiểu thành contract thay thế.
Quy trình triển khai Pay2S là gì
Bắt đầu từ cấu hình nhà cung cấp và mẫu, chuẩn bị mapping, rồi tạo một nhóm đơn thử. Kiểm tra HMAC cùng dữ liệu V2 trước khi theo dõi thanh toán và hàng chờ hóa đơn. Sau đó nghiệm thu nháp, phát hành và cách xử lý hồ sơ lỗi.
Khi dữ liệu đã ổn định, mở tự động hóa cho nhóm nghiệp vụ được xác nhận. Theo dõi hồ sơ tồn và kiểm tra lại sau khi thêm sản phẩm, cửa hàng hoặc mẫu mới. Mọi thay đổi có thể ảnh hưởng dữ liệu chứng từ cần đi qua một lượt thử phù hợp.
Câu hỏi thường gặp về Pay2S là gì
Pay2S là phần mềm hóa đơn hay cổng thanh toán?
Pay2S có các công cụ thanh toán và kết nối hóa đơn theo cấu hình. Cần xem sản phẩm và contract cụ thể; không suy từ tên gọi rằng một phần mềm thay toàn bộ quy trình kế toán hoặc nhà cung cấp hóa đơn.
requested=true có nghĩa hóa đơn đã phát hành?
Không. Đây là tùy chọn yêu cầu tham gia luồng hóa đơn. Kết quả cuối còn phụ thuộc điều kiện dữ liệu, kết nối, mẫu và cấu hình tự động hóa.
Có phải gửi extraData dạng JSON không?
Metadata được dựng thành JSON UTF-8 rồi Base64 một lần theo V2. Payload gửi chuỗi đã mã hóa trong extraData, không đưa object thô vào trường này.
Hóa đơn bán hàng lấy từ invoiceType nào?
Loại hóa đơn lấy từ mẫu đã gán. invoiceType của request thể hiện việc tham gia luồng hóa đơn, không dùng giá trị sales để chọn hóa đơn bán hàng theo suy đoán.
Có thể bỏ items khi yêu cầu hóa đơn không?
Với tích hợp V2 có yêu cầu hóa đơn, cần gửi danh sách theo contract. Không dựa vào cấu hình hàng mặc định của luồng khác để bỏ dữ liệu bắt buộc trong request.
Kết luận
Luồng thanh toán và hóa đơn chỉ nối tốt khi dữ liệu người mua, hàng hóa và trạng thái được giữ rõ từ đầu. Hãy nghiệm thu đến kết quả cuối, đồng thời giữ đường kiểm tra cho hồ sơ chưa đủ điều kiện. Tự động hóa nên giảm nhập lại và giúp truy vết, không làm mất quyền kiểm soát của kế toán.
Đọc tiếp theo nhu cầu trong cụm Pay2S
- Pay2S là gì? Tổng quan giải pháp thanh toán trực tuyến tự động
- Pay2S là gì? API Pay2S hoạt động như thế nào trong hệ thống thanh toán
- Pay2S là gì? Pay2S có phải là cổng thanh toán không?
- Pay2S là gì? Luồng thanh toán từ lúc tạo đơn đến khi xác nhận
- Pay2S là gì? Pay2S hỗ trợ thanh toán QR và ngân hàng như thế nào?
