Trong nỗ lực thiết kế một hệ thống thanh toán, chúng ta sẽ tiếp tục tìm hiểu các thành phần khác nhau trong hệ thống thanh toán.
Trong bài viết này, chúng ta sẽ tập trung vào việc làm cho hệ thống nhanh hơn, mạnh mẽ hơn và an toàn hơn. Chúng ta sẽ học cách xử lý các lỗi thanh toán do kết nối mạng kém, xử lý nhiều lần bấm nút “thanh toán” và hậu quả của nó. Ngoài ra, chúng ta sẽ đi sâu vào một số chủ đề chính như được liệt kê dưới đây:
– Tích hợp PSP (nhà cung cấp dịch vụ thanh toán).
– Xử lý đối chiếu.
– Xử lý chậm trễ xử lý thanh toán.
Tích hợp PSP
Nếu hệ thống thanh toán có thể kết nối trực tiếp với ngân hàng hoặc bất kỳ nhà cung cấp mạng lưới tài chính nào như Visa hoặc Mastercard thì việc thanh toán có thể được thực hiện trực tiếp mà không cần PSP, một điều không phổ biến và có tính chuyên môn cao.
Những kết nối như vậy thường được dành riêng cho các tổ chức có thể xem các giao dịch đó là một khoản đầu tư. Mặt khác, hệ thống thanh toán sẽ tích hợp với PSP theo hai cách.
(1). Nếu một công ty có thể lưu trữ thông tin thanh toán nhạy cảm một cách an toàn, PSP có thể được tích hợp thông qua API (giao diện lập trình ứng dụng), trong đó tổ chức sẽ chịu trách nhiệm tạo trang web thanh toán, thu thập và lưu trữ thông tin thanh toán nhạy cảm. PSP chịu trách nhiệm kết nối với ngân hàng hoặc các chương trình thẻ.
(2). Nếu một công ty chọn không lưu trữ thông tin nhạy cảm do các quy định phức tạp và lo ngại về bảo mật, PSP sẽ cung cấp ‘trang thanh toán’ được lưu trữ trên máy chủ để thu thập chi tiết thẻ và lưu trữ chúng một cách an toàn trong PSP. Phương pháp này đang được hầu hết các tổ chức sử dụng.
Hãy thảo luận về dịch vụ thanh toán – nó điều phối toàn bộ quá trình thanh toán.
(1). Khi người dùng nhấp vào nút thanh toán, một sự kiện sẽ được kích hoạt để gọi dịch vụ thanh toán kèm theo thông tin đơn hàng thanh toán.
(2). Sau khi nhận được thông tin ‘lệnh thanh toán’, dịch vụ thanh toán sẽ gửi yêu cầu đăng ký thanh toán tới PSP (nhà cung cấp dịch vụ thanh toán, biên tập). Yêu cầu đăng ký này chứa thông tin thanh toán như số tiền, loại tiền tệ, ngày hết hạn của yêu cầu thanh toán và URL chuyển hướng.
Vì lệnh thanh toán chỉ được đăng ký một lần nên có trường UUID (mã định danh duy nhất toàn cầu). UUID này còn được gọi là ‘nonce’, được xem là ID của lệnh thanh toán.
(3). PSP trả lại mã thông báo cho dịch vụ thanh toán mà UUID ở phía PSP – xác định duy nhất việc đăng ký thanh toán. Mã thông báo này giúp tìm trạng thái của lệnh thanh toán.
(4). Dịch vụ thanh toán lưu trữ mã thông báo trong cơ sở dữ liệu trước khi gọi đến trang thanh toán được lưu trữ trên máy PSP.
(5). Sau khi mã thông báo được xác nhận, máy khách sẽ hiển thị trang được lưu trữ trên PSP. Ứng dụng di động sử dụng tích hợp SDK của PSP cho chức năng này.
Hãy sử dụng ‘tích hợp web’ của Paypal làm ví dụ. Paypal cung cấp thư viện JS hiển thị giao diện người dùng, thu thập thông tin thanh toán và ‘gọi’ trực tiếp đến PSP để hoàn tất thanh toán. Thông tin nhạy cảm được Paypal thu thập và không bao giờ đến được hệ thống thanh toán. Trang thanh toán được lưu trữ cần có 2 thông tin:
(a). Mã thông báo nhận được từ PSP được sử dụng để truy xuất thông tin chi tiết về yêu cầu thanh toán từ dịch vụ phụ trợ của nó, bao gồm cả số tiền sẽ được thu.
(b). Một thông tin khác là URL được chuyển hướng được gọi khi thanh toán hoàn tất. Khi PSP hoàn tất thanh toán, nó sẽ chuyển hướng trình duyệt đến một URL chuyển hướng thường là trang web của người bán cung cấp cho bạn trạng thái thanh toán.
(6). Người dùng điền chi tiết thanh toán trên trang web của PSP và bắt đầu quá trình xử lý thanh toán.
(7). PSP trả về trạng thái thanh toán.
(8). Trang web hiện được chuyển hướng đến URL được chuyển hướng. Trạng thái thanh toán nhận được ở bước trên sẽ được thêm vào URL có thể là
“https://merchant-company.com/?tokenID=ABCSASFS&payResult=xa89da”
(9). Không đồng bộ, PSP gọi dịch vụ thanh toán với trạng thái thanh toán qua web-hook. Web-hook là một URL được đăng ký với PSP trong quá trình thiết lập ban đầu.
Khi hệ thống thanh toán nhận được các sự kiện thanh toán thông qua web-hook, nó sẽ trích xuất trạng thái thanh toán và cập nhật trường payment_order_status trong bảng cơ sở dữ liệu ‘lệnh thanh toán’.
Lưu ý: Luồng thanh toán ở trên là trường hợp tốt nhất vì tất cả các hệ thống đều hoạt động tốt và không có bất kỳ lỗi nào. Trên thực tế, kết nối mạng có thể không đáng tin cậy và tất cả 9 bước trên đều có thể không thành công. Để xử lý trường hợp thất bại, chúng ta có một hệ thống gọi là ‘điều hòa’.
Điều hòa trạng thái ‘thanh toán’
Khi các thành phần hệ thống giao tiếp không đồng bộ, không có gì đảm bảo rằng, tin nhắn sẽ được gửi hoặc phản hồi sẽ được trả lại.
Điều này rất phổ biến trong lĩnh vực thanh toán, vốn thường sử dụng giao tiếp không đồng bộ để tăng hiệu suất hệ thống.
Các hệ thống bên ngoài, chẳng hạn như PSP hoặc ngân hàng cũng thích giao tiếp không đồng bộ hơn. Đây là lúc ‘điều hòa’ phát huy tác dụng.
Điều hòa là một phương pháp so sánh định kỳ các trạng thái giữa các dịch vụ liên quan để xác minh rằng chúng có sự thống nhất.
Hàng đêm, PSP hoặc các ngân hàng gửi hồ sơ quyết toán cho khách hàng của họ, trong đó có số dư tài khoản ngân hàng cùng với tất cả các giao dịch diễn ra đối với tài khoản của họ vào ngày hôm đó. Hệ thống đối chiếu phân tích tệp quyết toán và so sánh chi tiết với hệ thống sổ cái (edger system).
Việc đối chiếu cũng được sử dụng để xác minh tính nhất quán của hệ thống thanh toán. Ví dụ, trạng thái trong ‘sổ cái’ và ‘ví’ khác nhau và chúng ta muốn sử dụng phương pháp đối chiếu để khắc phục vấn đề này. Đối chiếu tìm những điểm không phù hợp và yêu cầu bộ phận tài chính khắc phục thủ công. Những sự không phù hợp và điều chỉnh này được phân thành 3 loại.
(1). Sự không phù hợp có thể được phân loại khi việc điều chỉnh có thể được thực hiện tự động. Trong trường hợp này, chúng ta biết nguyên nhân của sự không khớp, cách khắc phục và việc tự động điều chỉnh sẽ hiệu quả về mặt chi phí.
(2). Sự không phù hợp có thể được phân loại khi việc điều chỉnh không thể được tự động hóa. Trong trường hợp này, chúng ta đã biết nguyên nhân gốc rễ và biết cách khắc phục, nhưng chi phí cho việc tự động hóa quá cao. Do đó, sự không phù hợp sẽ được đưa vào ‘chờ đợi công việc’ và nhóm tài chính sẽ khắc phục sự không phù hợp theo cách thủ công.
(3). Sự không phù hợp là không thể phân loại được. Trong trường hợp này, chúng ta không biết sự không khớp xảy ra như thế nào. Sự không phù hợp được đưa vào ‘hàng chờ đợi công việc’ đặc biệt được nhóm tài chính điều tra theo cách thủ công.
Xử lý sự chậm trễ trong xử lý thanh toán
Yêu cầu thanh toán từ đầu đến cuối chảy qua nhiều thành phần, liên quan đến cả bên trong và bên ngoài.
Mặc dù trong hầu hết các trường hợp, yêu cầu thanh toán sẽ hoàn tất sau vài giây, nhưng có những trường hợp yêu cầu thanh toán bị đình trệ và đôi khi mất hàng giờ hoặc vài ngày trước khi yêu cầu đó được hoàn thành hoặc bị từ chối.
Dưới đây là một số trường hợp trong đó việc thanh toán có thể mất nhiều thời gian hơn bình thường.
(a). PSP cho rằng yêu cầu thanh toán có rủi ro cao và có thể cần có sự xem xét của con người.
(b). Thẻ tín dụng yêu cầu bảo vệ bổ sung như ‘xác thực an toàn 3D’ yêu cầu thêm thông tin chi tiết từ chủ thẻ để xác minh giao dịch mua.
Dịch vụ thanh toán phải có khả năng xử lý các yêu cầu thanh toán này và họ thực hiện điều đó bằng các cách sau:
(a). PSP sẽ trả về trạng thái chờ xử lý cho khách hàng, trạng thái này được hiển thị cho người dùng cùng với trang hiển thị trạng thái của lệnh thanh toán.
(b). PSP thay mặt chúng ta theo dõi số tiền đang chờ xử lý và thông báo cho dịch vụ thanh toán về mọi cập nhật trạng thái thông qua web-hook đã đăng ký với PSP.
Ngoài ra, thay vì cập nhật dịch vụ thanh toán qua web-hook, một số PSP lại đặt gánh nặng lên dịch vụ thanh toán để thăm dò ý kiến cập nhật trạng thái theo yêu cầu đang chờ xử lý từ PSP.
Tôi đã viết ‘bài viết này’ ngắn gọn vì nó nói về 2 hệ thống mới và quy trình làm việc của chúng, điều này sẽ cần một chút thời gian để hiểu nó. Trong phần 3, chúng ta sẽ khám phá sự giao tiếp giữa các dịch vụ nội bộ, xử lý các khoản thanh toán không thành công, tính nhất quán và bảo mật thanh toán.
Tác giả: Sourav Mansingh
Nguồn: Sourav Mansingh – medium.com – Ấn Độ
Xem thêm: Thiết kế hệ thống thanh toán (Phần 1)
