Đội ngũ chúng tôi gặp tình huống này khá thường xuyên. Khách đã chuyển khoản xong, nhưng đơn vẫn nằm ở trạng thái chờ thanh toán. Kế toán phải mở app ngân hàng, dò từng dòng biến động rồi nhập tay vào hệ thống. Có lần chúng tôi ngồi cạnh một bạn kế toán làm đúng việc ấy mỗi buổi sáng. Ai đứng cạnh cũng nghĩ cùng một điều: viết một tool đọc tin nhắn biến động số dư chắc vài ngày là xong.
Suy nghĩ đó không hẳn sai, nhưng mới đúng một nửa. Phần đầu thì nhanh gọn. Phần sau mới là chỗ tốn công. Bài này đi qua cả hai hướng, tự xây và dùng dịch vụ sẵn, đồng thời chỉ ra điểm yếu của từng hướng để bạn không phải quyết định theo cảm tính.
Tự xây tool đọc SMS và API ngân hàng cần những gì
Bước đầu tiên là chọn nguồn dữ liệu. Thường có ba cách: đọc SMS từ một chiếc điện thoại nhận thông báo, gọi API trực tiếp nếu ngân hàng cho phép, hoặc nhận webhook từ một bên trung gian. Mỗi cách có độ tin cậy khác nhau. SMS dễ bị trễ hoặc thất lạc khi máy hết pin hay mất sóng. API ổn định hơn nhiều, nhưng cần hợp đồng và thủ tục với ngân hàng. Không phải ngân hàng nào cũng mở cổng này cho doanh nghiệp nhỏ.
Có dữ liệu rồi, bạn còn phải hiểu được nó. Nội dung tin nhắn không hề chuẩn hóa. Mỗi ngân hàng viết một kiểu, và đôi khi còn đổi theo thời gian. Bạn cần tách đúng số tiền, mã đơn nằm trong nội dung chuyển khoản và thời điểm giao dịch. Khớp mã đơn nghe đơn giản, nhưng khách hay gõ sai, thiếu dấu gạch ngang, hoặc chuyển thiếu vài nghìn đồng. Mỗi tình huống như vậy là một nhánh logic riêng, phải viết và kiểm thử từng cái.
Cuối cùng là xử lý trùng lặp và lệch số. Một giao dịch có thể về hai lần. Hai khách có thể chuyển cùng một số tiền trong cùng một phút. Hệ thống phải quyết định ai khớp với ai, và ghi lại lý do để sau này tra cứu. Với một lập trình viên, giai đoạn này thường kéo dài vài tuần. Ngoài ra, bạn nên có thêm ít nhất một người để review và kiểm thử.
Chi phí dev thực tế, không chỉ là tiền server
Nhiều đội chỉ tính tiền server, và đó là phần nhỏ nhất. Phần lớn chi phí nằm ở công xây dựng và kiểm thử. Khi cộng cả thời gian viết code, viết test với các mẫu tin nhắn thật, và chạy thử với dữ liệu của tháng trước, con số thường lớn hơn nhiều so với dự tính ban đầu.
Hạ tầng vẫn phải có. Bạn cần nơi chạy service, nơi lưu log giao dịch và cơ chế sao lưu. Log đặc biệt quan trọng khi kế toán hỏi vì sao một đơn được xác nhận. Sao lưu cũng vậy. Mất dữ liệu đối soát đồng nghĩa với mất khả năng chứng minh dòng tiền.
Một khoản hay bị bỏ sót là chi phí cơ hội. Người viết tool thường cũng là dev chủ chốt của sản phẩm. Khi họ dồn thời gian vào đối soát, các tính năng khác phải chờ. Đội chúng tôi từng thấy một dự án trễ gần hai tháng chỉ vì lý do này. Con số đó không nằm trong bảng chi phí, nhưng hoàn toàn có thật.
Rủi ro bảo mật và tuân thủ khi tự đọc dữ liệu tài chính
Khi tự đọc dữ liệu tài chính, bạn đang giữ thông tin nhạy cảm. Thông tin đăng nhập, khóa API và quyền truy cập tài khoản đều phải được bảo vệ. Lưu khóa thẳng trong mã nguồn là lỗi phổ biến nhất. Cấp quyền rộng cho cả nhóm cũng là lỗi thường gặp. Một người đã rời công ty mà vẫn giữ khóa thì chính là một lỗ hổng.
Rủi ro sai số cũng cần được tính đến. Một tin nhắn đọc sai số tiền có thể khiến đơn được xác nhận khi chưa đủ tiền. Ngược lại, giao dịch thật có thể không được khớp. Đến cuối tháng, bảng đối soát lệch vài triệu mà không ai biết lệch ở đâu. Loại lỗi này khó xử lý nhất, vì phải dò ngược từng giao dịch.
Về mặt quy định, nên hỏi bộ phận pháp chế trước khi triển khai. Điều cần giữ là nhật ký có thể kiểm toán: ai đã thay đổi gì, vào lúc nào, dựa trên giao dịch nào. Thiếu lớp vết này, việc giải trình với kiểm toán sẽ rất vất vả.
Bảo trì dài hạn: phần bị đánh giá thấp nhất
Ngân hàng đổi định dạng SMS hoặc API là chuyện diễn ra thường xuyên. Một hôm, nội dung tin nhắn có thêm một trường mới, phần parse cũ không còn khớp, và đơn hàng ngừng tự cập nhật. Lúc đó đội của bạn phải phát hiện, sửa và triển khai lại. Nếu không có cảnh báo tự động, bạn có thể không biết cho đến khi kế toán lên tiếng.
Ai sẽ xử lý khi có sự cố lúc nửa đêm? Đây là câu hỏi nhiều đội không trả lời trước khi bắt đầu. Nếu chỉ một người hiểu hệ thống, người đó sẽ bị gọi mỗi khi có chuyện. Khi người ấy nghỉ việc, tri thức cũng theo đi. Chi phí duy trì người giữ hệ thống thường bị bỏ sót trong dự toán.
Tool tự xây không phải sản phẩm làm một lần rồi thôi. Nó giống một khoản nợ kỹ thuật cần trả đều đặn. Bạn cần người đủ năng lực, quy trình xử lý sự cố rõ ràng và tài liệu để người sau có thể tiếp quản. Nếu muốn đội chuẩn bị tốt hơn cho việc vận hành, bạn có thể tham khảo các bài viết về vận hành và quy trình số trên blog của chúng tôi.
Khi nào dịch vụ sẵn là lựa chọn hợp lý hơn
Dịch vụ sẵn phù hợp khi quy mô giao dịch từ nhỏ đến vừa và bạn cần đưa vào vận hành nhanh. Không nhiều doanh nghiệp muốn dành hai tháng cho một việc không thuộc lõi kinh doanh. Với nhiều cửa hàng, đây là lựa chọn thực dụng nhất.
Dịch vụ sẵn cũng có điểm yếu. Bạn phụ thuộc vào nhà cung cấp. Nếu họ đổi giá, đổi chính sách hoặc ngừng hỗ trợ một ngân hàng nào đó, bạn không tự quyết được. Mức hỗ trợ các ngân hàng cũng không đồng đều: có ngân hàng kết nối rất mượt, có ngân hàng phải chờ lâu. Hạn mức và chi phí thường tăng theo quy mô, nên khi số đơn nhiều lên, hóa đơn cũng tăng theo.
Một vài cái tên đáng xem là SePay, Casso và PayOS. Mỗi bên mạnh ở những khía cạnh khác nhau. Độ phù hợp vẫn tùy vào số ngân hàng bạn dùng, mức giao dịch và cách tích hợp. Giá và hạn mức nên được kiểm tra trực tiếp trên trang chính thức của từng nhà cung cấp, vì chúng thay đổi theo thời gian.
Nếu bạn đang cân nhắc MONA Pay, bên chúng tôi cũng có gói đối soát. Tính đến tháng 11/2026, gói này miễn phí 500 giao dịch mỗi tháng, không thu phần trăm trên giao dịch và không giữ tiền của bạn. Các gói trả phí có mức 99.000đ, 299.000đ, 799.000đ và 1.990.000đ. Bạn có thể xem bảng giá MONA Pay miễn phí 500 giao dịch mỗi tháng để so sánh với nhu cầu thực tế của mình.
Cách chọn: ba câu hỏi để tự quyết định
Không có đáp án chung cho mọi đội. Quyết định nên dựa trên ba câu hỏi. Thứ nhất, số giao dịch mỗi tháng là bao nhiêu, và mỗi giao dịch quan trọng đến đâu? Vài chục đơn mỗi ngày với giá trị nhỏ khác hẳn vài nghìn giao dịch giá trị lớn.
Thứ hai, đội kỹ thuật có đủ năng lực bảo trì lâu dài không? Không chỉ là viết xong, mà còn phải giữ được hệ thống khi ngân hàng đổi định dạng hay khi người chủ chốt nghỉ việc. Nếu câu trả lời còn mơ hồ, dịch vụ sẵn thường an toàn hơn.
Thứ ba, doanh nghiệp cần kiểm soát dữ liệu đến mức nào? Một số lĩnh vực không cho phép dữ liệu tài chính đi qua bên thứ ba, khi đó tự xây là bắt buộc. Ngược lại, nếu chỉ cần đối chiếu con số cuối ngày, dịch vụ sẵn đáp ứng khá tốt.
Lưu ý khi thử nghiệm và chuyển đổi
Dù chọn hướng nào, đừng chuyển đổi toàn bộ trong một lần. Nên chạy song song hai hệ thống trong khoảng hai đến bốn tuần. Trong thời gian này, mỗi giao dịch đều được ghi nhận bởi cả hai bên, và bạn so sánh kết quả mỗi ngày.
Lập bảng đối chiếu theo ngày là việc nên làm. Mỗi ngày ghi lại số giao dịch, tổng tiền và danh sách mục không khớp. Các sai lệch nhỏ thường xuất hiện ở trường hợp biên như chuyển trùng hoặc gõ sai nội dung. Phát hiện sớm giúp bạn sửa trước khi hệ thống chính thức vận hành.
Cuối cùng là kế hoạch dự phòng. Nếu dịch vụ bên thứ ba gặp sự cố, đơn hàng có thể đứng yên. Hãy chuẩn bị quy trình tạm: kế toán đối chiếu thủ công trong lúc chờ, và có người được phép xác nhận đơn khi cần. Không nên để một sự cố ngoài tầm kiểm soát làm đình trệ cả cửa hàng.
Ví dụ theo quy mô: từ đội nhỏ đến doanh nghiệp lớn
Với cửa hàng vài chục đơn mỗi ngày, bạn thường chỉ cần đối soát đơn giản và nhanh. Một dịch vụ sẵn có thể làm đủ việc chỉ sau vài giờ thiết lập. Viết tool riêng cho quy mô này thường không đáng công sức.
Doanh nghiệp có hàng nghìn giao dịch mỗi ngày thì khác. Bạn cần tính đến hạ tầng, đội bảo trì và khả năng mở rộng. Lúc này tự xây có thể hợp lý, miễn là đã tính đủ chi phí nhân sự và rủi ro. Nhiều đội chọn cách kết hợp: dùng dịch vụ sẵn cho phần nhận tiền, còn phần đối soát nội bộ được giữ lại để kiểm soát logic riêng.
Mọi con số chi phí trong bài này chỉ mang tính tham khảo. Hãy xem bảng giá tại trang chính thức của từng nhà cung cấp trước khi quyết định.
Câu hỏi thường gặp
Tự code đối soát có tiết kiệm hơn dùng dịch vụ sẵn không?
Chỉ tiết kiệm khi quy mô đủ lớn và đội của bạn có sẵn người bảo trì lâu dài. Với quy mô nhỏ, chi phí nhân công xây dựng và bảo trì thường vượt xa phí dịch vụ sẵn trong nhiều năm. Hãy tính cả thời gian dev, thời gian sửa khi ngân hàng đổi định dạng và chi phí cơ hội.
Dịch vụ đối soát bên thứ ba có an toàn với dữ liệu tài chính không?
Điều này phụ thuộc vào nhà cung cấp và cách bạn cấu hình. Hãy hỏi họ về mã hóa, phân quyền truy cập và chính sách lưu trữ, rồi đọc kỹ điều khoản về trách nhiệm khi có sự cố. Nếu dữ liệu thuộc loại nhạy cảm đặc biệt, nên tham khảo ý kiến pháp chế trước khi ký hợp đồng.
Khi ngân hàng đổi định dạng SMS thì ai sửa và mất bao lâu?
Nếu tự xây, đội kỹ thuật của bạn phải sửa, và thời gian có thể từ vài giờ đến vài ngày tùy mức độ thay đổi. Nếu dùng dịch vụ sẵn, nhà cung cấp sẽ sửa, nhưng bạn vẫn phải chờ họ. Dù chọn cách nào, hãy theo dõi tỷ lệ giao dịch không khớp mỗi ngày để phát hiện bất thường sớm.
Có thể vừa dùng dịch vụ sẵn vừa giữ một phần đối soát nội bộ không?
Có, và nhiều đội đang làm như vậy. Dịch vụ sẵn lo việc nhận và ghi nhận tin giao dịch, còn logic khớp đơn và kiểm tra nghiệp vụ nằm trong hệ thống của bạn. Cách này giữ được sự linh hoạt mà không phải gánh toàn bộ việc đọc dữ liệu. Cần đảm bảo hai bên đồng bộ tốt và có bảng đối chiếu để phát hiện lệch.
Bảng giá MONA Pay như thế nào?
Tính đến tháng 11/2026, MONA Pay miễn phí 500 giao dịch mỗi tháng. Các gói trả phí có mức 99.000đ, 299.000đ, 799.000đ và 1.990.000đ. Chúng tôi không thu phần trăm trên giao dịch và không giữ tiền của bạn. Để xem chi tiết, bạn nên kiểm tra lại giá trên trang chính thức trước khi đăng ký.
Comments are closed