IOSOR Kiến thức

Undelivered vs rejected vs expired: từ điển trạng thái cho sản phẩm và billing

Ngừng cãi nhau vì ảnh chụp màn hình: căn chỉnh sản phẩm, hỗ trợ và billing trả trước quanh undelivered, rejected và expired — cùng hành động mỗi trạng thái thực sự cho phép.

Khi khả năng gửi đi giảm, sản phẩm đổ lỗi đường ống, hỗ trợ dán ảnh chụp, và tài chính hỏi vì sao ví trả trước dịch chuyển. Phần lớn sức nóng là thất bại từ vựng. Undelivered, rejected và expired không phải đồng nghĩa — gom chúng vào một thùng “failed” sẽ bịa retry sai, hoàn tiền sai và mức nghiêm trọng sự cố sai.

IOSOR muốn đội ngũ B2B vận hành messaging như white-label trả trước: nạp một lần, đọc sự kiện trạng thái bền, giữ ngôn ngữ lỗi an toàn thương hiệu. Từ điển này là hợp đồng vận hành giữa UX sản phẩm, ops và sổ cái.

Vì sao từ trạng thái gây nhiều sự cố hơn outage

Lớp Ví dụ Sản phẩm nên…
Intermediate queued, submitted, sent Hiện tiến trình; không ăn mừng thành công trên máy cầm tay
Terminal success delivered Mở UX tiếp theo; dừng gửi lại tự động
Terminal fail undelivered, rejected, expired (nếu terminal) Chọn hành động được phép; không bao giờ retry vô hạn

Nếu UI gộp mọi thứ thành dấu X đỏ, lúc 02:00 không ai hành động đúng.

Từ điển trạng thái: định nghĩa sản phẩm và billing thống nhất

Undelivered thường nghĩa là job đã vào đường messaging live nhưng tín hiệu downstream nói máy cầm tay không nhận kết quả thành công. Driver điển hình: máy tắt, hộp thư đầy, tắc corridor tạm thời, thuê bao không tới được.

Hành động được phép:

  1. Auto-retry có biên chỉ khi chính sách và bằng chứng corridor hỗ trợ
  2. “Thử lại sau” hiện cho người dùng mà không ám chỉ gian lận
  3. Ví theo quy tắc ghi nợ/hoàn đã công bố — không bịa hoàn im lặng trong chuỗi chat

Đừng coi mọi undelivered là “nền tảng sập”. Cắt theo corridor trước khi gọi pager cả thế giới.

Undelivered vs rejected: lớp lỗi khác, cách sửa khác

Rejected là thất bại chính sách hoặc nhập: bộ lọc nội dung, danh tính người gửi, cổng tuân thủ, đích lệch dạng, quỹ không đủ, hoặc catalog-not-live cho năng lực đó. Job chưa bao giờ được cơ hội công bằng để tới máy cầm tay.

Hành động được phép:

  • Sửa cổng (mẫu, đăng ký, số dư, trung thực catalog)
  • Hiển thị reason code dùng được và an toàn thương hiệu cho vận hành
  • Không bao giờ retry payload giống hệt mong vũ trụ khác

Bão rejected trước hết là vấn đề tuân thủ và catalog — không phải “thêm throughput”.

Expired: TTL, hàng đợi và cửa sổ timing OTP

Expired nghĩa là cửa sổ hiệu lực đóng trước thành công cuối. Thường gặp ở OTP (TTL), job xếp hàng quá SLA, hoặc cửa sổ hiệu lực mạng. Sản phẩm phải tách user expired (người dùng kẹt) với network expired (ống không giao kịp).

Hành động được phép:

  • Cung cấp gửi lại có kiểm soát kèm cooldown
  • Vô hiệu mã trước trong luồng Verify
  • Gán chi tiêu rõ khi lần thử mới ghi nợ lại

OTP hết hạn tự gửi lại không cooldown là bộ khuếch đại gian lận và chi tiêu.

Cờ đỏ

  • Chỉ tồn tại “failed”
  • Ảnh chụp là hệ thống trạng thái duy nhất
  • Bão auto-retry trên rejected
  • Ví dịch chuyển không có dấu vết trạng thái
  • Văn bản thương hiệu lạ trong lý do fail phía khách

Bắt đầu với IOSOR

Ánh xạ các lệnh gọi lại trạng thái trong bảng điều khiển IOSOR để tính năng tích hợp thanh toán của bạn tách bạch rõ ràng các trường hợp từ chối sớm với sự cố chưa gửi được ở hạ nguồn và việc hết hạn hàng đợi.

Tỷ lệ chuyển phát OTP chuẩn và tình trạng giảm chất lượng tuyến là gì? · Làm sao để chẩn đoán nguyên nhân gây trễ tin nhắn SMS? · Tại sao thiết bị nhận tin nhắn lại ép chuyển sang mã hóa UCS2?

Điểm chính IOSOR

Hướng dẫn này cho thấy sự mơ hồ về trạng thái là một vấn đề thiết kế sản phẩm và kế toán chứ không đơn thuần là lỗi mạng. Việc phân biệt giữa nhà mạng từ chối, trạng thái chưa gửi ở hạ nguồn và TTL hết hạn giúp minh bạch trách nhiệm tài chính và ngăn bộ phận hỗ trợ mất thời gian tìm kiếm lỗi ảo trong mã ứng dụng.

Hướng dẫn này có hữu ích không?

Hướng dẫn liên quan