IOSOR

IOSOR ידע

Undelivered מול rejected מול expired: מילון סטטוסים למוצר ולחיוב

הפסיקו להתווכח על צילומי מסך: יישרו מוצר, תמיכה וחיוב prepaid סביב undelivered, rejected ו-expired — וסביב הפעולות שכל סטטוס באמת מתיר.

כשה-deliverability יורדת, המוצר מאשים את הצינור, התמיכה מדביקה צילומי מסך, והכספים שואלים למה הארנק prepaid זז. חלק גדול מהחום הוא כשל אוצר מילים. Undelivered, rejected ו-expired אינם מילים נרדפות — לדחוס אותם לדלי “failed” אחד ממציא retries שגויים, החזרים שגויים וחומרת תקלה שגויה.

IOSOR רוצה שצוותי B2B יפעילו messaging כ-white-label prepaid: מממנים פעם אחת, קוראים אירועי סטטוס עמידים, ושומרים על שפת שגיאה בטוחה למותג. המילון הזה הוא חוזה תפעולי בין UX מוצר, ops וה-ledger.

למה מילות סטטוס יוצרות יותר תקריות מתקלות

מחלקה דוגמאות המוצר צריך…
Intermediate queued, submitted, sent להראות התקדמות; לא לחגוג הצלחה במכשיר
Terminal success delivered לפתוח את ה-UX הבא; לעצור שליחה חוזרת אוטומטית
Terminal fail undelivered, rejected, expired (אם terminal) לבחור פעולה מורשית; לעולם לא retry אינסופי

אם ה-UI מקפל הכל ל-X אדום, ב-02:00 אף אחד לא פועל נכון.

מילון הסטטוסים: הגדרות שמוצר ובילינג יכולים להסכים עליהן

Undelivered בדרך כלל אומר שהעבודה נכנסה לנתיב messaging חי אבל אות downstream אומר שהמכשיר לא קיבל הצלחה. מניעים טיפוסיים: מכשיר כבוי, תיבה מלאה, עומס זמני במסדרון, מנוי בלתי ניתן להשגה.

פעולות מורשות:

  1. Auto-retry מוגבל רק אם מדיניות וראיות המסדרון תומכות
  2. “נסו שוב מאוחר יותר” גלוי למשתמש בלי לרמוז על הונאה

Undelivered מול rejected: מחלקות כשל שונות, תיקונים שונים

Rejected הוא כשל מדיניות או כניסה: מסנן תוכן, זהות שולח, שער ציות, יעד פגום, יתרה לא מספקת, או catalog-not-live ליכולת הזו. העבודה מעולם לא זכתה בהזדמנות הוגנת למשלוח למכשיר.

פעולות מורשות:

  • לתקן את השער (תבנית, רישום, יתרה, יושר קטלוג)
  • להציג לקוד סיבה usable ובטוח מותג למפעילים
  • לעולם לא לנסות שוב את אותו payload בתקווה ליקום אחר

סופות rejected הן קודם בעיות ציות וקטלוג — לא “יותר throughput”.

Expired: TTL, תורים וחלונות תזמון OTP

Expired אומר שחלון התוקף נסגר לפני הצלחה סופית. נפוץ ב-OTP (TTL), עבודות בתור שעברו SLA, או חלונות תוקף רשת. המוצר חייב להפריד user expired (משתמש תקוע) מ-network expired (הצינור לא מסר בזמן).

פעולות מורשות:

  • להציע שליחה חוזרת מבוקרת עם cooldown
  • לבטל את הקוד הקודם בזרימות Verify
  • לייחס spend בבירור כשניסיון חדש מחייב שוב

OTP שפג עם auto-resend בלי cooldown הוא מגבר הונאה ו-spend.

השלכות בילינג: מה מחויב, מזוכה או שנוי במחלוקת

סטטוס יציבת העתקת UX יציבת prepaid טיפוסית צעד ops הבא
Undelivered זמני / אי-ודאות מכשיר לפי מדיניות חיוב/החזר שפורסמה פרוסת מסדרון + חבילת ראיות
Rejected כשל שער בר-פעולה בדרך כלל אין ניסיון משלוח מוצלח לתקן שער; לעצור retries זהים
Expired חלון זמן נסגר חיוב על ניסיון שנצרך לפי מדיניות cooldown שליחה חוזרת; מזהה מתאם חדש

התחל עם IOSOR

הגדירו את קריאות הסטטוס החוזרות במסוף IOSOR כך ששילוב החיוב שלכם יפריד היטב בין דחיות מוקדמות לבין אירועים שלא נמסרו ותוקף תורים שפג. בדקו את ווּב-הוקס הפעילים כדי לוודא שקודי סיום של דוחות מסירה מעבירים מחלקات שגיאות מפורשות לספר הראשי שלכם במקום מצב כשל כללי. לאחר מכן, התאימו את פרמטרי שער המסירה כדי לדכא מיד ניסיונות חוזרים בדחיות קשות, תוך כוונון מגבלות זמן החיים להודעות אימות.

סיכום IOSOR

מדריך זה הראה שעמימות בסטטוס היא בעיית עיצוב מוצר וחשבונאות ולא תקלת רשת פשוטה. הבחנה בין דחיות ספקים, מצבים שבהם הודעות לא נמסרו ותוקפי זמן שפגו מבהירה את האחריות הפיננסית ומונעת מצוותי התמיכה לחפש באגים מתים בקוד האפליקציה.

אל תקבצו את כל נשירות המסירה לסטטוס בינארי של נשלח או נכשל שמסתיר אם הודעה נכשלה עקב עיצוב, סינון רשת או חלונות זמן שפגו. כן שיקפו את מצבי הווּב-הוק של דוחות המסירה ישירות לתוך ספר הראשי של החיוב כדי להבטיח התאמת חשבוניות שקופה.

האם המדריך הזה עזר?

מדריכים קשורים