Thanh toán nội địa: chuyển khoản QR, ví điện tử và thẻ

Phương thức thanh toán là thói quen, không phải sở thích

Việc chọn phương thức thanh toán không nên xuất phát từ sự tiện lợi của đội kỹ thuật. Điều cần biết trước là người dùng của dịch vụ đó đã quen thanh toán bằng cách nào. Nếu màn hình chỉ hiển thị cách thanh toán mà họ không quen, khách sẽ dừng lại ngay ở bước cuối, và phần lớn những người dừng lại đó không nhắn tin hỏi, họ chỉ lặng lẽ rời đi.

Ở thị trường trong nước, chuyển khoản ngân hàng và quét mã xảy ra hằng ngày. Người mua mở ứng dụng ngân hàng, quét mã, xem số dư trừ đi rồi quay lại. Với nhiều nhóm khách, việc nhập số thẻ vào một dịch vụ mới gặp lần đầu lại là hành động cần cân nhắc. Thêm vào đso, thói quen trả tiền khi nhận hàng cũng còn phổ biến ở một số ngành, nên việc chuyển sang trả tiên qua ứng dụng trước là một thay đổi về hành vi chứ không chỉ đơn giản là vài nút bấm.

Điều đó không có nghĩa là thẻ không cần thiết. Câu trả lời thay đổi theo đối tượng khách. Nếu bán cho doanh nghiệp thì chuyển khoản từ tài khoản công ty và bộ chứng từ đi kèm mới là trọng tâm. Nếu phục vụ khách nước ngoài đang ở Việt Nam thì phải nhận được thẻ phát hành ở nước ngoài. Nếu là dịch vụ thu phí hằng tháng thì lại thêm những điều kiện khác. Độ tuổi người dùng, thiết bị họ hay dùng, khác biệt giữa thành phố lớn và tỉnh đều ảnh hưởng đến lựa chọn này.

Vì vậy trong buổi làm việc đầu tiên, câu hỏi cần đặt ra trước khi thiết lập danh sách tính năng là: hiện tại doanh nghiệp đang nhận tiền như thế nào. Đây chính là phần mà đã chứa sẵn một nửa câu trả lời. Nếu khách đã quen chuyển khoản cho cửa hàng thì thói quen đó sẽ được đưa lên ứng dụng. Nếu khách quen trả tiền mặt lúc nhận hàng thì việc thu trước trở thành một bài toán thuyết phục riêng, cần thêm chính sách và cách diễn đạt trên màn hình.

Bài viết này không khẳng định mức phí, điều kiện hợp đồng hay yêu cầu xét duyệt của bất kỳ đơn vị nào. Những điều đó khác nhau giữa các ngân hàng và các đơn vị xử lý thanh toán, được thỏa thuận theo ngành nghề và quy mô giao dịch, và thay đổi theo thời gian. Đây là phần doanh nghiệp phải làm việc trực tiếp với đơn vị cung cấp, không phải phần bên phát triển trả lời thay. Điều bên phát triển có thể trao đổi được là mỗi phương thức thực hiện màn như thế nào và máy chủ phải xử lý thêm những trạng thái nào.

Yeowubie Interaction cũng làm theo thứ tự đó khi thiết kế màn hình có thanh toán. Liệt kê các phương thức có thể dùng, vẽ ra mỗi phương thức chiếm bao nhiêu bước trong luồng của người dùng, và khi thất bại thì người dùng quay về đâu. Trên bản vẽ đó doanh nghiệp mới chọn. Nếu chốt phương thức trước rồi mới vẽ màn hình, luồng thường phải dựng lại từ đầu.

Không nên mở tất cả phương thức cùng lúc. Nên mở một phương thức quen thuộc nhất trước, quan sát các câu hỏi thực tế của khách rồi mới thay đổi hoặc trình bày thêm. Mỗi lần thêm một phương thức là thêm một đường hoàn tiền, một quy trình đối chiếu và một bộ câu trả lời cho bộ phận chăm sóc khách hàng. Nhìn trên màn hình chỉ đơn giản là một nút bấm, nhưng phía sau nút bấm đó là cả công việc vận hành hằng ngày.

Thiết kế cho môi trường chuyển khoản và mã QR là chủ lực

Khi chuyển khoản và mã QR là phương thức chính, trọng tâm thiết kế dịch chuyển từ nút thanh toán sang bước xác nhận. Tiền di chuyển bên ngoài màn hình của chúng ta, trong ứng dụng ngân hàng của người dùng. Thứ cần xây không hẳn là chức năng thanh toán, mà là quy trình đối chiếu khoản tiền vào với đơn hàng và ghi lại kết quả đó.

Luồng cơ bản khá đơn giản. Tạo đơn trước, hiển thị số tiền, tài khoản nhận và một mã nhận diện đơn hàng. Người dùng chuyển sang ứng dụng ngân hàng, chuyển khoản rồi quay lại. Trên màn hình, thứ quan trọng không phải là hình ảnh đẹp mà là nút sao chép, số tiền hiển thị rõ ràng và dòng chữ cho biết đơn giao dịch đang ở bước nào. Nhiệm vụ của màn hình này là giúp người dùng không quên mình đang làm gì khi qua lại giữa hai ứng dụng.

Phần khó nhất là nhận diện. Dù có hướng dẫn ghi mã đơn vào nội dung chuyển khoản, người dùng vẫn xóa đi, gõ sai, và mỗi ứng dụng ngân hàng lại giới hạn ký tự khác nhau. Vì vậy cách đối chiếu chỉ dựa vào nội dung chuyển khoản không phải lúc nào cũng khớp. Có nơi dùng cách để số tiền lẻ khác nhau theo từng đơn, nhưng khi đó phần hướng dẫn phải viết kỹ để khách không nghĩ là hệ thống tính sai. Việc có cấp được số tài khoản riêng cho từng đơn hay không phụ thuộc vào dịch vụ mà ngân hàng và đơn vị xử lý cung cấp, và đây là điều cần xác nhận trước khi lập trình.

Mã QR chia thành hai kiểu. Mã in sẵn dán tại quầy thì dễ làm, nhưng không mang theo số tiền và mã đơn nên gánh nặng đối chiếu vẫn còn nguyên. Mã sinh theo từng đơn thì mang được số tiền và thông tin nhận diện, thuận lợi cho việc khớp tự động. Thị trường trong nước có chuẩn mã dùng chung giữa các ngân hàng nên nhiều ứng dụng đọc được, nhưng trường thông tin nào được đưa vào và phát hành qua đường nào thì tùy phạm vi cung cấp và hợp đồng, cần đọc tài liệu chính thức rồi mới chốt thiết kế.

Có nhận được thông báo tiền vào tự động hay không sẽ quyết định kế hoạch nhân sự. Nếu có thông báo, danh sách chờ tự giảm. Nếu không, nhân viên phải mở màn hình ngân hàng kiểm tra từng khoản. Dịch vụ dù vẫn chạy được nhưng phải tính trước rằng có người phải ngồi làm việc đó mỗi ngày. Khi đó trang quản trị bắt buộc phải có danh sách các khoản chưa xác nhận, nút xác nhận thủ công, và lưu vết ai xác nhận vào lúc nào.

Chính sách thời gian cũng cần quyết trước. Chuyển khoản có khi xong trong vài phút, có khi lâu hơn. Nếu dịch vụ giữ chỗ hoặc giữ hàng, phải định rõ chờ bao lâu thì hủy đơn, và nếu tiền vào sau khi đơn đã hủy thì xử lý ra sao. Cho người dùng một nút báo đã chuyển khoản hoặc chỗ tải lên ảnh chứng từ giúp việc hỗ trợ dễ hơn, nhưng hành động đó không phải là căn cứ xác nhận đã thanh toán. Căn cứ nằm ở phần sau.

Tóm lại, cách này nhìn thì dễ ghép nhưng nặng về vận hành. Ngược lại, đi qua đơn vị xử lý thì màn hình hiển thị gọn gàng hơn và bớt việc thủ công, đổi lại có ràng buộc hợp đồng và điều kiện đối soát. Chọn hướng nào thì căn cứ vào số lượng giao dịch dự kiến và việc có người phụ trách kiểm tra hay không. Ghi lại căn cứ của lựa chọn đó trước khi bắt đầu lập trình sẽ giúp tính nhanh thiệt hơn khi sau này muốn đổi cách làm.

Ví điện tử và thẻ có luồng xử lý khác nhau

Với người dùng thì cả hai chỉ là một lần bấm, nhưng phía máy chủ thì công việc khác nhau. Ví điện tử thường là luồng đi sang ứng dụng khác rồi quay về, còn thẻ thì phần nhập liệu và xác thực bổ sung diễn ra ngay trong luồng của chúng ta. Chỗ phát sinh lỗi khác nhau nên màn hình và cách xử lý ngoại lệ cũng phải khác.

Với ví điện tử, việc chuyển ứng dụng là mấu chốt. Trên điện thoại, ứng dụng ví mở lên, người dùng xác nhận rồi quay về ứng dụng hoặc trình duyệt của chúng ta. Trên máy tính, phổ biến hơn là hiển thị mã để quét bằng ứng dụng ví. Đường quay về phải được đăng ký trước, và phải thử trên ứng dụng, trên web và trên trình duyệt di động riêng biệt. Trường hợp người dùng không quay về xảy ra nhiều hơn ta tưởng: họ đóng ứng dụng, việc chuyển màn thất bại, hoặc mất mạng. Vì thế thiết kế chỉ dựa vào lần quay về để chốt trạng thái chắc chắn sẽ thủng.

Với thẻ, nguyên tắc là không đặt biểu mẫu nhập thẻ trên máy chủ của mình. Chuyển sang trang thanh toán hoặc thư viện do đơn vị xử lý cung cấp để số thẻ không đi qua hệ thống của chúng ta. Nhờ vậy phạm vi phải chịu trách nhiệm thu hẹp lại, và nguy cơ dữ liệu nhạy cảm lọt vào nhật ký hệ thống cũng giảm. Khi có thêm bước xác thực từ phía ngân hàng, luồng sẽ dài thêm một màn hình, kèm theo đó là phần thông báo khi xác thực không thành công và đường thử lại.

Thẻ phát hành trong nước và thẻ phát hành ở nước ngoài có thể được xử lý khác nhau. Phạm vi hỗ trợ, cách xử lý loại tiền tệ và việc có nhận thẻ quốc tế hay không tùy từng đơn vị, nên ở đây chỉ đưa vào danh sách cần xác nhận chứ không khẳng định. Đơn vị tiền tệ cũng là chỗ hay sai. Với loại tiền không dùng phần thập phân, nên lưu số tiền dưới dạng số nguyên và gom quy tắc làm tròn về một chỗ. Những sai lệch nhỏ giữa màn hình, máy chủ và bảng đối soát thường bắt đầu từ đây.

Việc lưu thông tin thẻ để thu phí định kỳ là một chủ đề riêng. Phải thiết kế cả phần người dùng đồng ý điều gì, hủy ở đâu, khi thu phí thất bại thì thử lại lúc nào và khi nào dừng dịch vụ. Tùy đơn vị cung cấp mà cách làm này có thể cần thủ tục hoặc bước xem xét riêng, nên hãy hỏi trước về khả năng áp dụng và thời gian cần thiết rồi đưa vào tiến độ.

Thời điểm nhận được môi trường thử nghiệm cũng nên nằm trong kế hoạch. Việc cấp tài khoản thử có thể mất thời gian, và tài liệu đôi khi khác với phản hồi thực tế ở tên trường hoặc ngôn ngữ mô tả. Khi chuyển sang môi trường chính thức lại có thủ tục thay khóa và đăng ký địa chỉ. Đăng ký tài khoản ngay từ lúc còn đang bàn hợp đồng, chứ không phải vào ngày bắt đầu lập trình, sẽ tránh được phần chờ đợi ở cuối dự án.

Càng thêm phương thức thì thứ tăng lên không phải màn hình mà là các nhánh trạng thái. Có phương thức tách riêng bước cho phép và bước thu tiền, có phương thức cho hủy một phần và có phương thức thì không. Vì vậy cần gom các trạng thái rời rạc đó về một mô hình trạng thái duy nhất của hệ thống mình. Công việc đó nối phần này với phần tiếp theo.

Làm sao xác nhận rằng khoản thanh toán đã hoàn tất

Căn cứ để nói một khoản đã thanh toán xong không phải dòng chữ thành công trên màn hình người dùng, mà là thông báo mà máy chủ của chúng ta nhận và ghi lại. Màn hình báo thành công nhưng máy chủ không có bản ghi thì đơn đó chưa xong. Ngược lại, người dùng đã tắt trình duyệt mà thông báo đã tới thì đơn đó xong. Không chốt nguyên tắc này từ đầu thì khi có tranh chấp sẽ không có mốc để đối chiếu.

Thường có hai đường để biết kết quả: người dùng quay về màn hình của chúng ta, và máy chủ bên xử lý gửi thông báo trực tiếp sang máy chủ của chúng ta. Đường thứ nhất phụ thuộc vào đường truyền và thiết bị của người dùng, lại có thể bị can thiệp, nên không dùng làm căn cứ chốt. Đường thứ hai cần kèm bước kiểm tra chữ ký hoặc xác thực nguồn gửi, và phải đối chiếu lại số tiền, loại tiền, mã đơn trong thông báo với đơn hàng của mình. Bỏ qua bước kiểm tra số tiền là lỗi xảy ra nhiều hơn người ta nghĩ.

Thông báo không chỉ đến một lần. Cùng một nội dung có thể tới nhiều lần, thứ tự cũng có thể đảo. Vì vậy phải đảm bảo mỗi giao dịch chỉ được xử lý một lần. Ghi lại đã xử lý hay chưa theo mã giao dịch, và nếu thông báo cũ tới lại thì vẫn trả về thành công nhưng không cần phải báo lại. Nếu trả về lỗi ở tình huống này, phía kia sẽ gửi lại liên tục và tạo ra vấn đề khác.

Cần thêm đường tự truy vấn để phòng khi thông báo bị đứt. Định kỳ hỏi lại trạng thái của những đơn còn treo lâu, và những đơn vẫn chưa rõ thì đưa lên danh sách trong trang quản trị. Phải có nút để người phụ trách chốt lần cuối và phải lưu lại lịch sử thao tác đó. Ai chốt, vào lúc nào, dựa trên căn cứ gì, những thông tin này cần còn lại để sau này còn truy ngược. Dù tự động hóa tốt đến đâu vẫn nên chừa chỗ cho con người can thiệp ở bước cuối.

Không nên chép nguyên mã trạng thái của từng đơn vị xử lý vào trạng thái nghiệp vụ của mình. Mã bên đó khác nhau theo nhà cung cấp và còn thay đổi. Phía mình chỉ giữ những trạng thái mà nghiệp vụ cần biết như chờ, hoàn tất, thất bại, đã hủy, hoàn một phần, rồi quản lý riêng một bảng ánh xạ sang mã của nhà cung cấp. Nhờ vậy thêm phương thức mới cũng không làm ảnh hưởng tới màn hình đơn hàng và bảng đối soát. Với phương thức có bước trung gian giữa cho phép và thu tiền, hãy định trước cách xử lý bước trung gian đó.

Cần nói rõ rằng thứ chúng ta lưu là bản ghi về sự việc, không phải bản thân dòng tiền. Tiền chạy giữa đơn vị xử lý thanh toán, ngân hàng và doanh nghiệp, còn chủ thể nhận tiền và đối soát là doanh nghiệp. Trách nhiệm của bên phát triển là để lại dấu vết có thể kiểm chứng về việc gì đã xảy ra vào lúc nào. Nếu để ranh giới này mờ, khi có sự cố thì việc đầu tiên phải làm sẽ là tranh luận xem ai chịu trách nhiệm.

Với doanh nghiệp có công ty mẹ ở nước ngoài, nên hỏi trước kế toán về định dạng dữ liệu đối soát mà họ cần. Dữ liệu chạy tại chỗ và trường thông tin mà bên kia yêu cầu thường không giống nhau. Xác nhận sớm sẽ giảm việc mỗi cuối tháng lại phải ngồi chỉnh lại bảng biểu bằng tay. Yêu cầu kiểu này mà xuất hiện sau khi dự án đã xong thì sẽ mất thêm nhiều công sức để xử lý.

Vẽ sẵn hoàn tiền và đối soát trước khi bắt đầu

Kế hoạch làm thanh toán trước rồi tính hoàn tiền sau thường là kế hoạch đắt nhất. Không có đường hoàn tiền thì mỗi lần khách khiếu nại lại phải xử lý bằng tay, và việc xử lý đó không nằm ở đâu ngoài lịch sử tài khoản ngân hàng và cửa sổ tin nhắn. Vài tháng sau, chính doanh nghiệp cũng không biết đã trả lại những gì.

Đường hoàn tiền khác nhau theo phương thức. Thẻ xử lý theo khái niệm hủy giao dịch và hủy một phần. Chuyển khoản thì thực chất là chúng ta chuyển ngược lại, nghĩa là phải thu thập thông tin tài khoản của khách, và thông tin đó là dữ liệu cá nhân cần được bảo vệ. Ví thì theo quy định của nhà cung cấp. Có giới hạn thời gian hay không, có hoàn một phần được hay không cũng tùy nhà cung cấp và hợp đồng, nên để trong danh mục cần xác nhận. Làm nút hoàn tiền trước khi xác nhận thì sẽ có một nút bấm vào không chạy.

Vì thế chính sách phải có trước. Hoàn tiền được trong thời hạn nào, có cho hoàn một phần không, có thu khoản phí hủy không, ai là người duyệt, sau khi duyệt thì thông báo với khách là bao nhiêu ngày. Đây là quyết định kinh doanh chứ không phải quyết định kỹ thuật. Không có quyết định thì không dựng được màn hình, và nếu bên phát triển tự quyết thì sau này sẽ phải làm lại. Nên đưa các mục này lên phần đầu của tài liệu yêu cầu.

Về đối soát, thứ bên phát triển tạo ra là dữ liệu dạng sổ dùng để khớp. Mã nối đơn hàng với giao dịch, phương thức đã dùng, trạng thái và thời điểm, mã giao dịch phía nhà cung cấp nên nằm cùng một dòng để kế toán khớp được. Còn tiền thực về lúc nào, phí bị trừ ra sao, xử lý thuế thế nào là phạm vi giữa doanh nghiệp với đơn vị xử lý thanh toán và ngân hàng. Việc đánh giá điều kiện pháp lý về hoạt động thanh toán và việc nắm giữ dòng tiền thuộc về cơ quan quản lý và đơn vị tư vấn, bên phát triển không phán đoán thay.

Những câu hỏi cần có lời đáp trước khi lập trình thường cố định. Chủ thể ký hợp đồng là ai, sẽ mở những phương thức nào, thông báo hoàn tất nhận theo cách nào và mang theo những trường gì, khi nào có tài khoản thử, thủ tục chuyển sang môi trường chính thức ra sao, hệ thống xử lý hoàn tiền được đến đâu, kế toán cần dữ liệu ở định dạng nào. Bắt đầu dựng màn hình khi những câu này còn bỏ trống thì phần chi phí làm lại sẽ xuất hiện ở cuối dự án.

Nên bắt đầu nhỏ. Mở một phương thức quen thuộc nhất, rồi cho người phụ trách chạy đối soát thật trong một tháng. Chính các câu hỏi phát sinh trong tháng đó sẽ cho biết nên thêm gì tiếp theo. Khách dừng lại ở đâu, hiểu nhầm nào lặp lại, mỗi ngày mất bao nhiêu thời gian cho việc kiểm tra, tất cả hiện ra lúc đó. Thêm phương thức mà không có quan sát này thì màn hình phức tạp hơn còn vận hành thì nặng hơn.

Thanh toán gần với quy trình hơn là với tính năng. Màn hình có thể dựng trong vài ngày, nhưng quy trình do con người vận hành. Vì vậy dự án nào sắp xếp trước việc cần xác nhận điều gì và ai quyết định thì lại kết thúc sớm hơn. Chỉ riêng việc không để phần thanh toán dồn vào những ngày cuối cũng đã tránh được phần lớn sự cố.