Ưu Đãi Khi Mua Hosting
Mã giảm giá 10% : HOSTING1205
Khi tích hợp Eximbank bị timeout, không nên lập tức gửi lại mọi yêu cầu. Mất phản hồi không đồng nghĩa giao dịch thất bại: phía xử lý có thể đã hoàn tất nhưng ứng dụng chưa nhận được kết quả. Cách xử lý phù hợp là giới hạn thời gian chờ, phân loại thao tác được phép thử lại và đưa giao dịch chưa rõ kết quả vào luồng tra cứu, đối soát.
Hướng dẫn dưới đây dành cho lập trình viên vận hành website kết nối dữ liệu giao dịch hoặc nạp tiền liên quan đến Eximbank. Các mốc thời gian là ví dụ thiết kế, không phải thông số của ngân hàng. Khả năng tra cứu, webhook và cơ chế chống lặp phải được đối chiếu với tài liệu của kênh tích hợp thực tế.
Trước hết, cần biết ứng dụng đang làm việc với kênh chính thức được Eximbank cung cấp theo thỏa thuận hay dịch vụ trung gian hỗ trợ dữ liệu tài khoản Eximbank. Hai trường hợp có thể khác nhau về xác thực, hạn mức gọi, độ trễ và cách xác nhận giao dịch. Không mặc định ngân hàng có API công khai hoặc dịch vụ trung gian được ngân hàng bảo chứng.
Với từng thao tác, hãy ghi lại các thông tin sau từ tài liệu hoặc xác nhận của đơn vị cung cấp:
Nếu thiếu cơ chế xác định kết quả của một yêu cầu tạo thay đổi, lựa chọn an toàn là chuyển sang chờ đối soát thay vì gửi lại tự động.
Timeout kết nối xảy ra khi ứng dụng chưa thiết lập được kết nối trong thời gian cho phép. Timeout đọc xảy ra khi đã kết nối nhưng không nhận đủ phản hồi đúng hạn. Tuy nhiên, chỉ từ thông báo lỗi của thư viện HTTP không phải lúc nào cũng xác định được máy chủ đã nhận và xử lý yêu cầu hay chưa.
Vì vậy, cần phân loại theo cả lỗi kỹ thuật lẫn ý nghĩa nghiệp vụ. Yêu cầu đọc lịch sử giao dịch thường phù hợp với retry hơn yêu cầu tạo lệnh, nhưng vẫn phải tuân thủ giới hạn gọi của nhà cung cấp.
Không coi mọi mã 5xx là bằng chứng thao tác chưa được thực hiện. Với yêu cầu có tác động nghiệp vụ, kết quả vẫn có thể cần tra cứu.
Một chính sách retry cần có ba giới hạn độc lập: thời gian chờ mỗi lần gọi, tổng số lần gọi và thời hạn xử lý toàn bộ tác vụ. Chỉ giới hạn số lần thử là chưa đủ, vì từng lần gọi có thể kéo dài khiến worker bị chiếm dụng quá lâu.
Ví dụ giả định: một tác vụ đọc dữ liệu được phép gọi tối đa ba lần, gồm lần đầu và hai lần thử lại, trong ngân sách 20 giây. Mỗi lần có thời gian chờ tối đa 5 giây, thời gian nghỉ tăng dần và có độ ngẫu nhiên nhỏ. Trước mỗi lần gọi, ứng dụng tính thời gian còn lại; không mở lần gọi mới nếu đã hết ngân sách.
Khi lỗi kéo dài, có thể tạm ngừng gọi mới bằng circuit breaker: mở mạch sau một ngưỡng lỗi, chờ rồi thăm dò có kiểm soát. Cơ chế này bảo vệ tài nguyên, không thay thế đối soát giao dịch.
Với website nạp tiền qua chuyển khoản Eximbank, cần tách đơn nạp khỏi giao dịch ngân hàng. Đơn nạp ghi nhận người dùng, số tiền dự kiến, tài khoản nhận và mã nội dung đối chiếu. Giao dịch thực tế chỉ được ghi nhận khi dữ liệu từ nguồn được phép sử dụng đã được xác minh.
Dùng ràng buộc duy nhất cho mã giao dịch trong đúng phạm vi định danh của nguồn dữ liệu. Chỉ kiểm tra tồn tại bằng mã ứng dụng là chưa đủ, vì hai worker có thể cùng vượt qua bước kiểm tra. Ràng buộc cơ sở dữ liệu kết hợp transaction giúp tránh cộng tiền hai lần khi xử lý đồng thời.
Nếu có webhook, phải xác minh tính xác thực theo tài liệu nhà cung cấp; không tự giả định thuật toán chữ ký. Chỉ xác nhận tiếp nhận sau khi sự kiện đã được lưu bền vững theo thiết kế. Secret phải nằm phía server, không xuất hiện trong JavaScript hoặc log. Callback hay trang chuyển hướng trên trình duyệt không phải bằng chứng thanh toán.
Ví dụ minh họa: đơn nạp giả lập NAP-DEMO-01 chờ 200.000 đồng vào tài khoản nhận đã cấu hình. Tác vụ lấy dữ liệu giao dịch bị timeout. Hệ thống giữ đơn ở trạng thái chờ xác minh, không thông báo thanh toán thất bại và không cộng số dư dựa trên ảnh chuyển khoản.
Worker thử lại trong giới hạn cho phép. Khi nhận được giao dịch giả lập TX-DEMO-889, hệ thống đối chiếu đủ thông tin rồi ghi nhận thanh toán trong transaction. Nếu cùng giao dịch xuất hiện lần nữa từ webhook hoặc lượt truy vấn kế tiếp, ràng buộc duy nhất ngăn phát sinh lần cộng tiền thứ hai.
Nếu hết lượt thử mà chưa có dữ liệu, tác vụ được chuyển sang đối soát theo lịch riêng hoặc xử lý thủ công. Hết ngân sách retry không đồng nghĩa đơn nạp chắc chắn chưa thanh toán.
Trong môi trường thử nghiệm, hãy mô phỏng phản hồi chậm, mất phản hồi, sự kiện trùng và hai worker xử lý đồng thời. Với hệ thống thật, chỉ kiểm thử trong phạm vi được cấp phép.
Lỗi thường gặp là đặt timeout quá dài, retry không giới hạn, hoặc coi đơn hết hạn là giao dịch không thể đến muộn. Với giao dịch đến sau hạn, cần quy tắc xử lý riêng thay vì bỏ qua.
Log nên có mã đơn, mã tương quan, loại thao tác, số lần gọi, thời lượng và kết quả đã phân loại. Che dữ liệu tài khoản không cần thiết; không ghi token, secret hay toàn bộ nội dung nhạy cảm. Theo dõi tỷ lệ timeout và lượng đơn chờ đối soát để phát hiện sự cố kéo dài.
Không có con số chung. Hãy dựa vào tài liệu kênh kết nối, loại thao tác, hạn mức và thời hạn tác vụ. Ví dụ ba lần gọi trong bài chỉ là cấu hình minh họa.
Tăng timeout có thể phù hợp nếu phản hồi bình thường cần lâu hơn cấu hình hiện tại, nhưng không xử lý được lỗi mạng kéo dài. Cần đo độ trễ và kiểm tra tài nguyên trước khi điều chỉnh.
Có thể dùng truy vấn định kỳ nếu kênh tích hợp hỗ trợ và cho phép. Nếu không có cơ chế tự động phù hợp, cần quy trình đối soát thủ công bằng nguồn dữ liệu được cấp quyền.
Bước tiếp theo là liệt kê các thao tác trong tích hợp Eximbank, ghi rõ thao tác nào được retry, giới hạn thời gian và nơi chuyển giao khi chưa rõ kết quả. Chỉ triển khai sau khi đã kiểm thử tình huống phản hồi mất và giao dịch trùng. Nếu cần tư vấn giải pháp tích hợp, bạn có thể trao đổi nhu cầu với sieuthicode.com và yêu cầu xác nhận kênh kết nối, tài liệu cùng phạm vi hỗ trợ trước khi lựa chọn.
