Sử dụng thương hiệu nhắn tin thuộc sở hữu của tài khoản
Sử dụng tài khoản API đã được kích hoạt qua HTTPS từ địa chỉ IP nguồn được phép. Hỗ trợ xác thực Basic và Bearer. Mã định danh thương hiệu phải thuộc tài khoản đó. Giữ kín các mã thông báo của nhà cung cấp, dữ liệu nhận dạng thương hiệu và các báo cáo được trả về.
Sử dụng kết quả hiện có của nhà cung cấp
Sử dụng PUT để liên kết kết quả thẩm định hiện có từ một nhà cung cấp được hỗ trợ với thương hiệu của bạn. Thao tác này không đặt một lượt kiểm tra mới. Lấy mã định danh giao dịch chính xác của nhà cung cấp và mã thông báo xác nhận, nếu có, trực tiếp từ nhà cung cấp đó, đồng thời bảo đảm báo cáo thuộc cùng một danh tính doanh nghiệp.
AUTHPLUS không hỗ trợ quy trình nhập này. Các quy tắc đối chiếu riêng của từng nhà cung cấp vẫn được áp dụng; yêu cầu nhập không miễn trừ các quy tắc đó và cũng không bảo đảm đủ điều kiện cho mọi trường hợp sử dụng chiến dịch.
Chuẩn bị nhập kết quả
| Trường | Giá trị |
|---|---|
| evpId | Mã định danh của nhà cung cấp được hỗ trợ, dài 1–10 ký tự. |
| vettingId | Mã định danh giao dịch thẩm định thực tế của nhà cung cấp, tối đa 255 ký tự. Không thay bằng mã định danh thương hiệu hoặc tự tạo mã định danh. |
| vettingToken | Mã thông báo xác nhận khi nhà cung cấp yêu cầu, tối đa 65535 ký tự. Bảo mật mã này như một thông tin bí mật và không gửi khi nhà cung cấp không yêu cầu. |
Tạo vetting-import.json bằng các giá trị thực tế từ nhà cung cấp. Không gửi các trường điểm số, trạng thái hoặc dấu thời gian chỉ có trong phản hồi với kỳ vọng chúng có thể thay đổi kết quả.
Nhập kết quả một lần
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request PUT \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary @vetting-import.json \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"Hiểu các khoản phí hiện có
Proxy này không ghi nhận kết quả mới nhập là một đơn hàng trả phí mới. Điều này không hủy lượt kiểm tra đã đặt trước đó: khi cùng một vettingId đã có đơn hàng đang chờ kết quả hoặc chờ tính phí, việc nhập kết quả ACTIVE hoặc FAILED có thể quyết toán khoản phí đã lưu của đơn hàng đó. Nhánh đồng bộ hóa này không tính phí lại đối với bản ghi đã được tính phí trước đó.
Theo dõi kết quả thực tế
Phản hồi HTTP thành công có thể chứa bản ghi thẩm định đang chờ xử lý. Lưu lại vettingId của bản ghi và kiểm tra vettingStatus, lý do, điểm số và ngày hiệu lực/hết hạn nếu có. PENDING và UNSCORE cần được tiếp tục theo dõi; ACTIVE, FAILED và EXPIRED mô tả các kết quả khác nhau. Chỉ riêng việc được chấp nhận ở cấp HTTP không chứng minh rằng điểm số thuận lợi hoặc đủ điều kiện cho chiến dịch.
Sử dụng trạng thái thẩm định bên ngoài để theo dõi bản ghi. Việc đọc hoặc nhập kết quả ở trạng thái kết thúc có thể quyết toán một đơn hàng trả phí trước đó; thao tác này không nhất thiết được miễn khoản phí còn tồn đọng hiện có.
Thử lại đúng yêu cầu dự định ban đầu
Sử dụng một Idempotency-Key cho mỗi thao tác dự định thực hiện và giữ nguyên chính xác phương thức, đường dẫn, truy vấn và các byte của phần thân. Khóa hỗ trợ 1–128 ký tự ASCII có thể in được, không chứa dấu cách. Yêu cầu trùng lặp trong khi yêu cầu ban đầu đang xử lý có thể trả về 409 kèm Retry-After. Các yêu cầu đã hoàn tất sẽ trả lại phản hồi đã lưu, bao gồm cả lỗi. Tuân thủ giới hạn tần suất yêu cầu.
Lỗi truyền tải có thể dẫn đến phản hồi 502 được lưu trong bộ nhớ đệm. Phản hồi 500 được lưu trong bộ nhớ đệm kèm requestId có thể có nghĩa là hệ thống đăng ký đã chấp nhận thao tác nhưng việc lưu trữ lâu dài tại hệ thống cục bộ hoặc tính phí đã thất bại. Giữ lại mã định danh yêu cầu, kiểm tra các bản ghi hiện tại và đối soát với bộ phận hỗ trợ trước khi sử dụng khóa mới. Không mặc định rằng lỗi có nghĩa là không có đơn hàng nào tồn tại.