Tự viết tool đối soát hay dùng dịch vụ sẵn: chi phí, rủi ro, bảo trì

Khi đơn tăng, đối soát tiền về bắt đầu thành nỗi đau

Bạn đã bao giờ mở app ngân hàng và thấy cả chục khoản chuyển khoản, nhưng không chắc khoản nào trả cho đơn nào chưa? Đội ngũ bên mình gặp cảnh này khá thường xuyên khi một shop bắt đầu tăng khách đều. Lúc vài chục đơn mỗi ngày, nhân viên còn đối chiếu bằng tay được. Khi lên vài trăm đơn, việc đó thành cái hố đen ăn hết buổi chiều.

Chúng tôi đã đi qua giai đoạn này cùng nhiều đội nhỏ. Sai sót hiếm khi đến từ sự cẩu thả. Thường gặp hơn là nội dung chuyển khoản gõ lệch, khách quên ghi mã đơn, hoặc hai đơn cùng số tiền về trong một buổi. Đối soát thủ công không chịu nổi kiểu lộn xộn ấy.

Có hai hướng đi rõ ràng. Hướng thứ nhất là tự viết tool đọc SMS biến động số dư hoặc gọi API ngân hàng, rồi tự khớp giao dịch với đơn. Hướng thứ hai là dùng dịch vụ sẵn, nơi nhà cung cấp lo phần nhận dữ liệu và khớp giao dịch. Bài này đặt hai hướng cạnh nhau theo chi phí, rủi ro và bảo trì, để bạn tự cân nhắc theo hoàn cảnh của mình.

Bài dành cho dev freelance, đội kỹ thuật nhỏ và người phụ trách vận hành đang gánh việc đối soát. Nếu bạn đang phân vân nên làm hay nên mua, đọc hết bài sẽ giúp bạn có câu trả lời rõ hơn. Với giai đoạn đầu kinh doanh, bạn cũng có thể xem danh sách phần mềm quản lý miễn phí đáng dùng cho doanh nghiệp mới bắt đầu mà chúng tôi đã tổng hợp trước đó.

Một tool đối soát thực chất gồm những phần nào

Nhiều người nghĩ tool đối soát chỉ là vài dòng code đọc tin nhắn rồi so số tiền. Thực tế nó gồm ba phần. Phần đầu là lấy dữ liệu giao dịch về hệ thống. Phần thứ hai là khớp nội dung chuyển khoản với mã đơn. Phần cuối là cập nhật trạng thái đơn và báo cho người liên quan.

Nguồn dữ liệu thường gặp có ba loại. SMS biến động số dư là cách rẻ và dễ bắt đầu, nhưng phụ thuộc hoàn toàn vào định dạng tin nhắn của từng ngân hàng, và định dạng có thể đổi mà không báo trước. API ngân hàng ổn định hơn nhiều, song không phải ngân hàng nào cũng mở cho doanh nghiệp nhỏ, và thủ tục đăng ký thường kéo dài. Email thông báo là lựa chọn phụ, thường chỉ dùng khi không còn đường nào khác.

Có vài việc người mới hay đánh giá thấp. Việc đầu tiên là xử lý tin nhắn bị lặp, vì một giao dịch có thể về hai lần. Việc thứ hai là khoản tiền về lệch vài nghìn do phí chuyển, khiến việc khớp số tiền tuyệt đối thất bại. Việc thứ ba là khách gõ nội dung chuyển khoản rất tuỳ hứng: viết hoa, thiếu dấu, thêm chữ, bớt số. Tìm đúng mã đơn trong chuỗi như thế khó hơn bạn tưởng.

Chi phí dev: tính đủ những khoản nào

Khi bàn về chi phí, đa số người chỉ nghĩ đến số giờ viết code. Đó là phần dễ thấy nhất, nhưng không phải phần duy nhất. Với một luồng khớp giao dịch cơ bản, thời gian viết và kiểm thử ban đầu thường nằm trong khoảng vài ngày đến vài tuần, tùy bạn có tự làm luôn giao diện đối soát hay không.

Ngoài code còn có chi phí hạ tầng. Bạn cần một địa chỉ đủ ổn định để nhận webhook, nơi lưu log, và một màn hình để nhân viên xem các giao dịch chưa khớp. Giao diện này hay bị bỏ quên khi lập dự toán. Thiếu nó, nhân viên vẫn phải mở file log và đọc từng dòng để tra cứu, và chính điều đó làm chậm cả quy trình.

Để có điểm so sánh cụ thể, hãy nhìn vào một gói dịch vụ sẵn. Theo thông tin tại thời điểm chúng tôi viết bài, MONA Pay miễn phí 500 giao dịch mỗi tháng, các gói trả phí là 99.000, 299.000, 799.000 và 1.990.000 đồng, và không thu theo phần trăm giá trị giao dịch. Với shop lượng nhỏ, con số này cho thấy tự làm chưa chắc đã rẻ hơn, nhất là khi tính cả thời gian dev. Bạn nên xem bảng giá MONA Pay tại trang chính thức để đối chiếu với lượng giao dịch thực tế của mình, vì giá có thể thay đổi theo thời gian.

Rủi ro bảo mật và dữ liệu cá nhân

Tool đối soát chạm vào dữ liệu tiền bạc, nên bảo mật không thể coi là phần phụ. Khóa API, mật khẩu truy cập và token cần được lưu tách khỏi mã nguồn, và chỉ những người thực sự cần mới có quyền đọc. Đội ngũ bên mình từng gặp trường hợp một nhóm nhỏ để khóa thẳng trong file cấu hình rồi đẩy lên kho mã dùng chung. Đó là lỗ hổng lớn, và thường chỉ lộ ra khi đã muộn.

Rủi ro thứ hai là khớp sai. Nếu tool gán nhầm một khoản tiền cho đơn khác, bạn có thể giao hàng khi chưa nhận đủ tiền, hoặc giữ hàng của người đã trả đủ. Thiệt hại không chỉ nằm ở tiền mà còn ở niềm tin của khách. Nên đặt ngưỡng rõ ràng: khoản khớp không chắc chắn thì chuyển cho người xử lý, đừng để tool tự động cập nhật.

Rủi ro thứ ba liên quan đến dữ liệu cá nhân. Nội dung chuyển khoản đôi khi có tên hoặc số điện thoại của khách. Bạn cần quyết định dữ liệu đó được lưu bao lâu, ai được xem và xoá khi nào. Điều này đặc biệt quan trọng nếu doanh nghiệp có nghĩa vụ bảo vệ thông tin khách hàng theo quy định hiện hành.

Bảo trì dài hạn: phần không ai nhìn thấy lúc viết xong

Lúc viết xong, tool chạy đúng và ai cũng hài lòng. Vấn đề thường bắt đầu sau vài tháng. Ngân hàng đổi định dạng SMS, hoặc API nâng phiên bản, và tool ngừng khớp mà không báo lỗi rõ ràng. Nhân viên chỉ thấy đơn không tự cập nhật, và phải mất vài ngày mới tìm ra nguyên nhân.

Chi phí người trực cũng cần được tính vào. Ai nhận thông báo khi tool gặp sự cố vào tối cuối tuần? Ai cập nhật thư viện khi có bản vá bảo mật? Đây là những việc tốn thời gian đều đặn, và thường rơi vào người đã viết tool, người có thể đã chuyển sang dự án khác từ lâu.

Khi tool khớp sai, ai chịu trách nhiệm? Câu hỏi này nên có đáp án trước khi tool chạy thật. Nếu không, mỗi sự cố sẽ thành việc đẩy qua lại giữa các bộ phận, và khách là người phải chờ lâu nhất.

Ba câu hỏi nên trả lời trước khi chọn

Trước khi quyết định, bạn nên tự trả lời ba câu hỏi. Thứ nhất, số giao dịch hiện tại và dự kiến trong 12 tháng tới là bao nhiêu? Nếu lượng tăng nhanh, cách tự làm có thể phải nâng cấp sớm hơn bạn nghĩ, và mỗi lần nâng cấp đều tốn thêm công sức.

Thứ hai, đội ngũ có bao nhiêu thời gian rảnh để bảo trì? Một dev làm toàn thời gian và một dev freelance theo dự án có khả năng rất khác nhau. Đừng đánh giá cao khả năng bảo trì khi đội đang bận nhiều việc khác.

Thứ ba, bạn thực sự cần kiểm soát dữ liệu đến mức nào? Có doanh nghiệp bắt buộc dữ liệu nằm trong hạ tầng riêng, nhưng cũng có nơi chỉ cần kết quả khớp là đủ. Tuỳ yêu cầu, bạn sẽ nghiêng về một trong hai hướng.

Điểm chưa tốt của dịch vụ sẵn

Dịch vụ sẵn không phải lựa chọn hoàn hảo. Điểm yếu lớn nhất là sự phụ thuộc vào nhà cung cấp. Nếu bạn cần một logic khớp rất đặc thù, ví dụ quy tắc gộp nhiều chuyển khoản cho một đơn lớn, bạn có thể bị giới hạn bởi những gì họ hỗ trợ sẵn.

Thị trường hiện có nhiều đối thủ đáng cân nhắc như SePay, Casso và PayOS. Mỗi bên có cách tính phí, tính năng và mức hỗ trợ khác nhau. Đừng tin bất kỳ con số nào mà không tự kiểm tra, vì giá và hạn mức thay đổi theo thời gian. Hãy đối chiếu trực tiếp trên trang chính thức của từng bên trước khi quyết định.

Một điểm nên hỏi kỹ là điều kiện chuyển gói và khả năng xuất dữ liệu khi rời đi. Hỏi trước xem lịch sử giao dịch có xuất ra được không, và ở định dạng nào. Đây là chỗ hay gây phiền khi bạn muốn đổi nhà cung cấp về sau.

Sai lầm thường gặp khi tự làm và cách tránh

Sai lầm đầu tiên là không kiểm thử với giao dịch thật. Dữ liệu mẫu thường sạch sẽ, trong khi chuyển khoản thực tế đủ kiểu viết sai. Hãy lấy một tuần giao dịch thật làm bộ kiểm thử, ghi lại mọi trường hợp tool không khớp được, rồi xử lý từng nhóm một.

Sai lầm thứ hai là bỏ qua cơ chế chống trùng lặp. Một giao dịch có thể đến hai lần do mạng chập chờn hoặc webhook gửi lại. Nếu tool không nhận ra, đơn sẽ bị cập nhật hai lần. Bạn cũng cần quy tắc cho giao dịch đến muộn, khi đơn đã bị hủy từ trước.

Sai lầm thứ ba là không có nhật ký để truy vết. Khi có tranh chấp với khách, bạn cần biết giao dịch nào đã khớp với đơn nào, vào lúc nào và dựa trên dữ liệu gì. Không có log, gần như không thể chứng minh điều gì.

Lộ trình thực tế để không kẹt giữa chừng

Cách an toàn nhất là chạy thử với lượng đơn nhỏ, song song với quy trình đối soát cũ. Trong giai đoạn này, người phụ trách vẫn kiểm tra tay, còn tool chỉ đề xuất kết quả. Khi tỷ lệ khớp đúng ổn định trong vài tuần, bạn mới cho tool tự cập nhật đơn.

Hãy đặt sẵn mốc để quyết định đổi hướng. Nếu sau vài tháng, thời gian bảo trì vượt quá phần việc kinh doanh chính, hoặc lượng giao dịch tăng mạnh, đó là tín hiệu nên cân nhắc dịch vụ sẵn. Ngược lại, nếu yêu cầu đặc thù và đội ngũ đủ năng lực, tự làm vẫn có lý do để tồn tại.

Đội ngũ bên mình khuyên bạn bắt đầu từ việc nhỏ và đo lường rõ ràng. Quyết định tốt nhất thường đến từ con số thật của chính shop bạn, không phải từ cảm tính về việc tự làm cho chủ động. Nếu bạn đang tìm thêm góc nhìn về chọn dịch vụ công nghệ cho doanh nghiệp, hướng dẫn lựa chọn dịch vụ công nghệ cho doanh nghiệp mới cũng là bài đọc nối tiếp hợp lý.

Câu hỏi thường gặp

Shop nhỏ có nên tự viết tool đối soát không?

Với shop lượng đơn còn ít, thường không nên. Chi phí thời gian để viết, kiểm thử và bảo trì thường lớn hơn lợi ích thu về. Nếu đã có dev sẵn và nhu cầu đặc thù, khi đó việc tự làm mới đáng xem xét nghiêm túc.

Dùng dịch vụ sẵn có an toàn với dữ liệu giao dịch không?

Mức an toàn phụ thuộc vào chính sách bảo mật và cách nhà cung cấp lưu trữ dữ liệu. Hãy đọc kỹ tài liệu của từng bên và hỏi về quyền truy cập, thời gian lưu và quy trình xử lý sự cố trước khi đăng ký.

Chi phí bảo trì thường chiếm bao nhiêu sau khi tool chạy ổn định?

Không có con số chung cho mọi đội. Điều chắc chắn là phần bảo trì không biến mất sau khi tool chạy ổn. Nó xuất hiện đều đặn dưới dạng cập nhật, xử lý sự cố và theo dõi, nên cần tính vào dự toán ngay từ đầu.

Làm sao biết tool tự viết đang khớp sai?

Hãy so kết quả của tool với đối soát thủ công định kỳ, ví dụ mỗi tuần kiểm tra ngẫu nhiên vài chục giao dịch. Theo dõi số đơn phải khớp lại bằng tay và số giao dịch chưa khớp cũng giúp phát hiện sớm vấn đề.

Có thể chuyển từ tool tự viết sang dịch vụ sẵn mà không gián đoạn không?

Có thể, nếu chạy song song một thời gian trước khi tắt hẳn tool cũ. Cần chuẩn bị sẵn việc xuất lịch sử giao dịch và đối chiếu đầy đủ, để không mất dữ liệu hay bỏ sót đơn đang chờ tiền.