App có thanh toán: điều phải quyết định trước tại Việt Nam

Khi tiền bắt đầu chảy qua ứng dụng, điều gì thay đổi

Ngay khi gắn tính năng thanh toán, ứng dụng không còn chỉ là phần mềm mà trở thành một chặng trong dòng tiền. Tiền vào tài khoản của ai, ai chịu trách nhiệm hoàn tiền, hồ sơ lưu ở đâu và trong bao lâu: tất cả xuất hiện cùng lúc. Tại Việt Nam còn thêm yếu tố tiền tệ, thói quen thanh toán và điều kiện của chủ thể kinh doanh. Quyết định về cấu trúc phải đi trước lựa chọn công nghệ.

Nếu chỉ nhìn vào danh sách tính năng, thanh toán trông giống việc thêm một màn hình. Sau giỏ hàng là màn chọn phương thức, rồi màn báo thành công, thế là xong. Thứ tăng lên thực ra không phải màn hình mà là trách nhiệm. Khi giao dịch thất bại nhưng tiền đã trừ, khi cùng một yêu cầu đến hai lần và bị tính phí hai lần, khi người dùng bấm hủy nhưng người bán đã giao hàng, hệ thống phải tự phán đoán và tự khôi phục. Quy tắc phán đoán đó phải được thống nhất từ phía kinh doanh trước khi viết mã code.

Điểm phân hóa rõ nhất tại thị trường Việt Nam là bề rộng của phương thức thanh toán. Chuyển khoản ngân hàng, mã QR, ví điện tử, thẻ, và trả tiền mặt khi nhận hàng cùng tồn tại trong một dịch vụ. Mỗi phương thức có thời điểm xác nhận và thời điểm hủy khác nhau, cách báo lỗi cũng khác nhau. Có phương thức xác nhận trong vài giây, có phương thức cần người kiểm tra mới chốt được. Muốn giấu toàn bộ khác biệt đó sau một màn hình duy nhất thì phần quản lý trạng thái phía sau phải chặt chẽ hơn hẳn. Đây là đoạn điển hình mà giao diện trông đơn giản nhưng máy chủ thì không.

Chi phí quay đầu cũng khác. Tính năng thông thường làm sai thì bản phát hành sau sửa lại. Bản ghi về dòng tiền thì không viết đè được. Muốn thu hồi một khoản đã đối soát và chi ra, phải thương lượng giữa người với người, và niềm tin bị bào mòn trước tiên. Đó là lý do dự án có thanh toán cần mật độ câu hỏi ở giai đoạn khởi động cao hơn các dự án khác.

Các câu hỏi cần có lời đáp trước khi bắt đầu thường quy về bốn nhóm. Chủ thể thực sự nhận tiền là ai. Từ lúc vào đến lúc tới tay người nhận cuối, khoản tiền đổi tay mấy lần. Khi có sự cố, tên nào đứng ra chịu trách nhiệm với người dùng. Nếu sau này phải chứng minh dòng tiền, hồ sơ nào cần còn lại. Khi bốn câu này có lời đáp, việc tích hợp cổng thanh toán trở thành công việc bình thường. Nếu chưa có mà đã bắt đầu code, tích hợp xong nhưng dịch vụ vẫn không mở được.

Cần nói thêm một điểm. Ứng dụng có thanh toán thì gánh nặng vận hành cũng tăng theo. Đối soát, trả lời thắc mắc, xử lý hoàn tiền, chốt sổ hàng tháng lặp lại hằng ngày hoặc hằng tuần. Phần này ít khi nằm trong báo giá phát triển nhưng lại tiêu tốn nhân lực thật. Với một đội nhóm nhỏ, thay vì mở rộng phạm vi thanh toán ngay từ đầu, nên mở đúng mức mà vận hành gánh được rồi tăng dần. Đây cũng là điều chúng tôi liên tục xác nhận khi tự vận hành sản phẩm của mình. Việc lặp lại mỗi ngày sau khi ra mắt mới là thứ định đoạt sức bền của tổ chức, chứ không phải việc xây dựng ban đầu.

Vì sao phải xác định chủ thể thu tiền và chủ thể đối soát trước tiên

Chủ thể thu tiền là pháp nhân hoặc cá nhân mà tiền của người dùng chảy vào đầu tiên. Chủ thể đối soát là bên chia và chuyển khoản tiền đó tới người nhận cuối. Hai bên có thể trùng nhau, cũng có thể tách rời. Lựa chọn này quyết định câu chữ hợp đồng, chứng từ, trách nhiệm hoàn tiền, cách hạch toán và cả điều kiện kinh doanh cần có.

Hiểu lầm phổ biến nhất là coi đây như một tham số kỹ thuật. Tài liệu tích hợp có ô đăng ký tài khoản người bán, nên nhiều người nghĩ chỉ cần chọn điền gì vào ô đó. Trên thực tế, cái tên điền vào ô đó chính là bên ký kết với người dùng. Khi người dùng đòi hoàn tiền, khi cơ quan thuế hỏi căn cứ giao dịch, khi tranh chấp đi theo thủ tục bảo vệ người tiêu dùng, cái tên đứng ra là tên pháp lý của chủ thể đứng tên nhận tiền. Nếu thương hiệu hiển thị trên màn hình khác với chủ thể thu tiền thực tế, khoảng cách ấy sớm muộn cũng quay lại thành vấn đề.

Với dịch vụ có nhiều bên tham gia, đường đi tách thành hai nhánh. Nhánh thứ nhất là nền tảng gom tiền một lần rồi đối soát và chuyển đi. Nhánh thứ hai là tiền vào thẳng người bán hoặc người cung cấp, còn nền tảng thu phí riêng. Nhánh thứ nhất cho trải nghiệm liền mạch và xử lý tranh chấp tập trung một nơi. Đổi lại, nó phát sinh tính chất giữ hộ và chuyển hộ tiền của người khác. Tính chất đó được phép tới đâu, có cần giấy phép hay thủ tục đăng ký riêng hay không, phụ thuộc vào hình thức kinh doanh và quy định hiện hành, nên bắt buộc phải xác nhận với tư vấn tại chỗ. Nhánh thứ hai giảm được gánh nặng đó nhưng tài khoản và kỳ đối soát bị phân tán theo từng người bán, còn hoàn tiền và tranh chấp thì rời khỏi tay nền tảng.

Khi có yếu tố xuyên biên giới sẽ xuất hiện thêm một phần nữa. Cấu hình đội phát triển ở Hàn Quốc còn dịch vụ chạy ở Việt Nam là chuyện thường gặp. Trong cấu hình này, không có lý do nào bắt bên làm phần mềm phải trùng với bên nhận tiền. Ngược lại, tách rời thường mới là cấu trúc bình thường. Khi rà soát cấu trúc cho nhiều dịch vụ, chúng tôi gặp lại một nhận định nhiều lần: với dịch vụ mà tính minh bạch của đối soát là giá trị cốt lõi, bên nhận tiền và chia tiền phải có hiện diện thật tại Việt Nam. Đây không phải vấn đề có thể lách bằng cách viết phần mềm khéo hơn. Cố đi vòng thì hệ thống chạy được về mặt kỹ thuật nhưng dịch vụ không mở được về mặt kinh doanh.

Vì thế nên giữ đúng thứ tự. Dựng cấu trúc pháp nhân và hợp đồng trước, chọn phương thức thanh toán và luồng đối soát phù hợp với cấu trúc đó, rồi mới viết mã. Đi ngược lại thì phải vứt bỏ thứ đã làm. Tích hợp thanh toán thấm sâu vào mô hình dữ liệu, máy trạng thái và hệ thống phân quyền, nên khi chủ thể thu tiền thay đổi, thứ phải sửa không phải vài màn hình mà là bộ khung máy chủ.

Trong quá trình quyết định, có một thứ nên ghi thành văn bản. Với mỗi chặng tiền di chuyển: tên bên gửi và bên nhận, hợp đồng làm căn cứ cho chặng đó, phí và nghĩa vụ thuế phát sinh tại chặng đó, và cách đảo ngược khi có sự cố. Chỉ cần một bảng như vậy là đội phát triển, kế toán và bên tư vấn có thể nói chuyện trên cùng một bức tranh. Không có bảng đó, mỗi bên giữ một bức tranh khác nhau trong đầu và ngộ nhận rằng đã thống nhất.

Ngã rẽ giữa thanh toán trong ứng dụng và thanh toán bên ngoài

Với ứng dụng di động, câu hỏi phải dùng thanh toán trong ứng dụng của kho ứng dụng hay được gắn cổng thanh toán riêng xuất hiện rất sớm. Nhìn chung, hàng hóa số và gói đăng ký tiêu thụ bên trong ứng dụng thường thuộc diện thanh toán qua kho, còn hàng hóa vật lý và dịch vụ cung cấp bên ngoài ứng dụng thì có dư địa dùng thanh toán bên ngoài. Tuy vậy, tiêu chí và ngoại lệ vẫn thay đổi liên tục.

Ngã rẽ này quan trọng không chỉ vì mức phí. Dùng thanh toán trong ứng dụng thì bên nhận tiền là kho ứng dụng, còn kỳ đối soát, quy đổi tiền tệ và phán quyết hoàn tiền đi theo quy tắc của kho. Doanh nghiệp đứng ở vị trí nhận đối soát từ kho. Dùng thanh toán bên ngoài thì tiền vào thẳng phía doanh nghiệp, và doanh nghiệp tự thiết kế, tự chịu trách nhiệm về đối soát, chứng từ và hoàn tiền. Cùng một mức doanh thu nhưng hình dạng ghi nhận trong sổ sách và tốc độ vòng quay tiền là khác nhau.

Mức phí cụ thể, ngoại lệ dành cho doanh nghiệp quy mô nhỏ, và phạm vi được phép hướng dẫn hay đặt liên kết ra ngoài đều nằm trong tài liệu chính sách của từng kho, và thay đổi theo thời điểm cũng như theo khu vực. Đó là lý do bài viết này không khẳng định các con số và điều kiện đó. Trước khi nộp thẩm định, hãy đọc trực tiếp tài liệu chính sách mới nhất của từng kho, và với phần nằm sát ranh giới thì hỏi bộ phận thẩm định để xác nhận trước. Cách từng qua được năm ngoái không bảo đảm sẽ qua được năm nay.

Có một chỗ đặc biệt dễ nhầm với dịch vụ tại Việt Nam: thanh toán diễn ra trong ứng dụng nhưng việc cung cấp thực tế lại do cửa hàng ngoài đời hoặc do một người thực hiện. Đặt chỗ, ghép lớp học, dịch vụ tận nơi đều nằm ở đây. Bề ngoài là thanh toán trong ứng dụng, nhưng thực thể cung cấp lại ở ngoài ứng dụng nên cách phân loại có thể khác nhau. Trong số sản phẩm của chúng tôi cũng có dịch vụ dạng ghép nối người học và người dạy. Với cấu trúc như vậy, nên làm rõ ngay từ khâu thiết kế rằng ứng dụng là nơi kết nối, còn việc cung cấp và quan hệ đối giá nằm giữa những người tham gia. Nếu ranh giới này mờ, câu hỏi sẽ đến cùng lúc từ cả phía thẩm định kho ứng dụng lẫn phía yêu cầu tại chỗ.

Khuyến nghị về thiết kế thì đơn giản. Đừng đóng đinh hệ thống vào một phương thức thanh toán duy nhất. Nếu tách lớp nghiệp vụ xử lý đơn hàng, sản phẩm, giá và hoàn tiền khỏi phần phương thức thanh toán, thì sau này khi chạy song song cả hai kiểu hoặc chuyển hẳn sang một bên, phạm vi phải sửa sẽ nhỏ đi nhiều. Những thủ tục chỉ tồn tại ở kho ứng dụng như xác thực biên nhận, đồng bộ trạng thái gói đăng ký, nhận thông báo hoàn tiền nên được nhốt bên trong lớp trung gian.

Nếu chọn vận hành song song cả hai, cần tính trước rằng công việc đối soát sẽ nhân đôi. Bảng kê đối soát của kho ứng dụng và lịch sử giao dịch của cổng thanh toán riêng khác nhau về ký hiệu tiền tệ, thời điểm ghi nhận và cách phản ánh hoàn tiền. Phần lớn nguyên nhân khiến con số cuối tháng không khớp nằm ở đây. Nếu ngay từ đầu chuẩn hóa cả hai nguồn ghi chép về cùng một định dạng sổ cái, thời gian mà con người phải ngồi khớp tay sau này sẽ giảm đáng kể.

Cấu trúc cho dịch vụ cần minh bạch đối soát

Với dịch vụ mà một lần thanh toán được chia cho từ hai người nhận trở lên, đối soát không phải tính năng phụ mà chính là thân của sản phẩm. Sàn giao dịch, nền tảng vận hành cửa hàng, dịch vụ ghép nối, điều phối xe và giao hàng đều thuộc nhóm này. Điều người tham gia kiểm tra đầu tiên không phải giao diện đẹp tới đâu, mà là phần của tôi đã về đúng hay chưa.

Phải bắt đầu từ cách ghi chép. Sổ cái giao dịch nên là cấu trúc chỉ thêm vào chứ không viết đè. Nếu lưu trạng thái vào một cột rồi cập nhật liên tục, ta biết giá trị hiện tại nhưng mất dấu con đường đã đi tới đó. Ghi mỗi sự kiện thành một dòng riêng cho xác nhận thanh toán, hủy, hoàn tiền một phần, trừ phí, giải phóng khoản tạm giữ, rồi tính số dư hiện tại bằng tổng các dòng đó, thì khi có tranh chấp dịch vụ mới giải thích được. Giải thích được chính là niềm tin.

Vấn đề trùng lặp và sai thứ tự cũng phải chặn từ đầu. Yêu cầu thanh toán có thể đến hai lần vì đường truyền, thông báo từ bên cung cấp dịch vụ thanh toán có thể đảo thứ tự hoặc lặp lại nhiều lần. Cần thiết kế khóa định danh sao cho xử lý cùng một giao dịch bao nhiêu lần cũng cho kết quả giống như xử lý một lần. Phần nhận thông báo nên được xây với giả định sẽ có gửi lại, và nên có bước chủ động truy vấn lại trạng thái ở phía bên cung cấp thanh toán thay vì chỉ tin vào thông báo. Thiếu ba thứ này thì tới khâu đối soát, con người phải ngồi vá bằng tay mỗi ngày.

Xử lý tiền tệ cũng cần quy tắc định trước. Tiền tệ của Việt Nam trên thực tế không dùng phần thập phân. Nhân với tỷ lệ phí thì chắc chắn phát sinh phần dư, và nếu không quy định ai nhận phần dư đó, làm tròn theo hướng nào, thì chênh lệch nhỏ ở từng giao dịch sẽ tích lại theo tháng thành con số không khớp. Quy tắc làm tròn nên được ghi vào tài liệu và gom về một chỗ duy nhất trong mã nguồn.

Kỳ đối soát và quy tắc tạm giữ là quyết định kinh doanh. Khi nào chốt, khi nào chi, và giữ lại bao lâu với các giao dịch có khả năng tranh chấp đều ảnh hưởng trực tiếp tới dòng tiền của người tham gia. Quan trọng hơn việc đặt ra quy tắc là làm cho người tham gia biết trước quy tắc đó. Nếu trên màn hình bảng kê họ tự xem được kỳ này gồm những gì, khoản nào bị giữ lại và vì lý do gì, thì số lượt hỏi giảm hẳn. Ngược lại, chỉ hiện tổng số thì mọi thắc mắc đều dồn về con người.

Nhận định đã nêu ở mục trước quay lại ở đây. Dịch vụ càng lấy minh bạch đối soát làm cốt lõi thì câu hỏi bên nào thực sự giữ tiền và chia tiền càng phải đi trước phần thiết kế kỹ thuật. Sổ sách có tinh vi tới đâu, nếu thực thể thu và chi không phù hợp với yêu cầu tại chỗ thì đó chỉ là bản ghi của một dịch vụ không mở được. Vì vậy, với loại dịch vụ này, thiết kế kỹ thuật và thiết kế chủ thể nên được bàn trong cùng một cuộc họp.

Cuối cùng là dấu vết kiểm tra. Ai đã đổi quy tắc đối soát vào lúc nào, tỷ lệ phí áp dụng từ thời điểm nào, khoản điều chỉnh thủ công được xử lý dưới phê duyệt của ai: tất cả phải còn lại. Trong đối soát, chuyện con người can thiệp bằng tay chắc chắn sẽ xảy ra. Bản thân việc can thiệp không phải vấn đề, không có bản ghi về lần can thiệp đó mới là vấn đề.

Những điều cần xác nhận và những câu phải hỏi chuyên gia

Phần trên là chuyện dựng cấu trúc. Dưới đây là các hạng mục mà bài viết này không trả lời được, vì chúng thay đổi theo hình thức kinh doanh và theo thời điểm, nên phải xác nhận trực tiếp với chuyên gia tại chỗ. Quy định tại Việt Nam có sửa đổi và cách áp dụng cũng khác nhau tùy vụ việc. Bắt đầu phát triển dựa trên giả định chưa được xác nhận thì chi phí quay đầu rất lớn.

Trước hết là nhóm điều kiện kinh doanh. Ngành nghề đã đăng ký có bao gồm hoạt động đang định làm hay không. Nếu hoạt động thuộc thương mại điện tử hoặc trung gian trực tuyến thì có cần đăng ký hay thông báo riêng hay không. Pháp nhân có vốn đầu tư nước ngoài thực hiện hoạt động đó có điều kiện bổ sung nào không. Và việc giữ tiền tạm thời rồi chuyển cho bên thứ ba được xếp vào phạm trù nào. Hạng mục cuối gần như luôn xuất hiện với dịch vụ dạng sàn, nên phải hỏi trước khi chốt cấu trúc.

Tiếp theo là thuế và chứng từ. Ở mỗi bước giao dịch phải xuất chứng từ gì, phí nền tảng và tiền hàng được tách ra thế nào, khi chi trả cho cá nhân tham gia thì có nghĩa vụ khấu trừ tại nguồn hay không, và khoản tiền cùng phí dịch vụ đi qua biên giới thì kèm theo thủ tục nào. Bài viết này không bàn về thuế suất và kỳ kê khai. Cách chính xác là vẽ cấu trúc kinh doanh thành sơ đồ, đưa cho bên tư vấn kế toán và nhận câu trả lời theo từng chặng.

Nhóm dữ liệu và bảo vệ người tiêu dùng cũng nên nằm trong danh sách xác nhận. Dữ liệu cá nhân liên quan tới thanh toán phải lưu ở đâu, thời hạn lưu trữ và mức kiểm soát truy cập yêu cầu tới đâu, và cấu hình không tự xử lý thông tin thẻ mà chuyển cho bên cung cấp dịch vụ thanh toán giúp giảm bớt yêu cầu tới mức nào. Kèm theo đó là chính sách hoàn tiền và hủy phải được thông báo cho người dùng theo cách nào. Khâu thẩm định kho ứng dụng đôi khi hỏi đúng những mục này, nên chuẩn bị một lần cho cả hai phía sẽ đỡ mất công.

Về phương thức thanh toán, hỏi thẳng bộ phận tiếp nhận của bên cung cấp là nhanh nhất. Cần hồ sơ gì, ngành nghề nào được hỗ trợ và ngành nghề nào bị loại trừ, kỳ đối soát và chính sách tạm giữ ra sao, khi có tranh chấp thì doanh nghiệp phải làm gì. Bài viết không giới thiệu một bên cung cấp cụ thể nào, vì khả năng đáp ứng thay đổi theo hình thức kinh doanh. Gửi cùng một bộ câu hỏi tới hai ba nơi rồi đặt các câu trả lời cạnh nhau để so sánh sẽ hợp lý hơn.

Chính sách kho ứng dụng là hạng mục phải kiểm tra lại ngay trước khi nộp thẩm định. Loại sản phẩm đang xây có thuộc diện thanh toán trong ứng dụng hay không, được phép hướng dẫn thanh toán bên ngoài tới đâu, ứng dụng phải xử lý việc hủy gói và hoàn tiền như thế nào. Tài liệu thay đổi, và tài liệu đã thay đổi mới là tiêu chí thẩm định. Không nên mang nguyên nội dung đọc được ở thời điểm bắt đầu dự án để đi nộp.

Đối tượng để hỏi chia làm ba. Hình thức pháp nhân, phạm vi hoạt động và tính chất của việc xử lý tiền: hỏi tư vấn pháp lý tại chỗ. Chứng từ và xử lý thuế: hỏi tư vấn kế toán tại chỗ. Điều kiện đối soát và khả năng được tiếp nhận: hỏi bên cung cấp dịch vụ thanh toán. Đội phát triển đóng vai trò nhận câu trả lời từ ba nơi đó và chuyển thành cấu trúc hệ thống. Việc chúng tôi làm ở giai đoạn đầu dự án cũng chủ yếu là như vậy. Không phải trả lời thay, mà lập danh sách những điều cần hỏi rồi điều chỉnh thiết kế theo từng câu trả lời nhận về.

Tóm lại, thứ tự nên là: xác định chủ thể thu tiền và chủ thể đối soát, xác nhận với bên tư vấn về điều kiện và thủ tục mà chủ thể đó cần, chọn phương thức thanh toán và đối chiếu chính sách kho ứng dụng trong phạm vi đã xác nhận, rồi mới dựng sổ cái và quy trình đối soát. Giữ đúng thứ tự này thì việc phát triển trở thành công việc dự đoán được. Bỏ qua thứ tự thì phần mềm làm tốt vẫn nằm đó mà không mở ra được.