IOSOR ידע
חיוב MO נכנס מול MT יוצא: שורות ארנק דו-כיווניות על ספר prepaid אחד
תשובות, STOP ואירועי מספר שכור מחייבים. אם הכספים מידלו רק יוצא, הספר משקר. מוצר דו-כיווני חייב לראות MO ו-MT באותו ייצוא, עם תקרת תשובה אוטומטית.
המצגת מדברת על יוצא. בייצור המספר השכור מקבל תשובות, STOP ולפעמים חזרות קול, ומופיעות שורות שהכספים לא כתבו במודל. MO נכנס אינו נימוס חינם. מוצר דו-כיווני מזיז MT ו-MO על אותו ספר prepaid. אם הייצוא סופר רק «נשלחו», הכספים מתייחסים לחיוב הנכנס כרעש עד שהשימוש ליד USD 1,000+ הופך אותו לנושא מסחרי.
IOSOR הוא prepaid ב-white-label: יוצא ונכנס על ledger אחד, שגיאות בטוחות ללקוח, בלי פורטל זר ליום-יום. live הוא ייצור דו-כיווני; in setup אינו תיבה זולה. ראו מדריך לתיבת דואר דו-כיוונית ו-אירועי תיבה במספרים שכורים. קודם ראיה, אחר כך קנה מידה.
חיובים MO שהכספים לא תכננו
אם המודל הפיננסי מכפיל רק תעריף MT, נשמטות שורות MO של המספר השכור: SMS נכנס, אישורי מילת מפתח, לפעמים אירועי קול. השורות האלה מחייבות כשהתשובה מגיעה, לא בלוח השיווק. המוצר אומר «אנחנו דו-כיווניים»; הכספים שואלים «איזו שורה נכנסת». בלי תשובה אין שליטה.
| כיוון | מה הארנק רואה | מה המוצר לעיתים קרובות משמיט |
|---|---|---|
| MT יוצא | יחידות / מקטעי שליחה | שהנכנס גם מחייב |
| MO נכנס | יחידות נכנס + תשובת מילת מפתח | מתאם עם שרשור היוצא |
| תשובה אוטומטית | MT נוסף | תקרת לולאה |
MT מול MO באותו ייצוא
שימו MT ו-MO באותו ייצוא: זמן, מספר, כיוון, חיוב, correlation ID. הכספים חייבים לסנן לפי כיוון, לא לערבב נכנס בממוצע יוצא. STOP/HELP היא שורת ציות ויכולה גם לחייב. מחזור החיים של המספר השכור קשור לתיבה: שחרור המספר חייב לחתוך נקי אירועי נכנס, אחרת שורות רפאים מופיעות בחודש הבא. אל תתנו לממוצע עולמי להסתיר מסדרון נכנס יקר.
לולאת תשובה אוטומטית מרוקנת את הארנק
תשובה אוטומטית בלי תקרה הופכת MO אחד לשורת MT עד שהארנק ריק. בוט מול בוט, HELP שמצטט את המקור, ניסיונות webhook לא אידמפוטנטיים, שואבים prepaid. תקרת תשובות לכל שרשור ו-STOP כהדחקה מיידית. ראו לולאות מענה אוטומטי נכנס. כשהמדיניות אומרת עצור, הארנק עוצר גם אם המוצר רוצה «לאשר עוד פעם». דגימות לולאה ליד USD 1,000+ נכנסות לקריאה מסחרית, לא לכרטיס ב-02:00.
אירועי תיבה ומתאם
התיבה היא ראיה, לא צעצוע צ׳אט. כל אירוע נכנס חייב להראות מספר, חותמת זמן וגוף מצונזר בבטחה, ולקשר להקשר יוצא כשיש שרשור. התפעול צריך תור מכתבים מתים שניתן להריץ מחדש, לא לשפוך מטענים במעלה הזרם לסוכנים. בלי מתאם הכספים לא מסבירים את חיוב ה-MO והמוצר לא מוכיח שהדו-כיווני «עובד». השכרות עוקבות אחרי חודש לוח UTC; בעל התיבה חייב לדעת מתי המספר נגמר.
דגלים אדומים
- מודל פיננסי רק עם תעריף MT
- ייצוא שאינו מבחין בכיוון
- תשובה אוטומטית בלי תקרה לשרשור
- STOP כפטפוט, בלי הדחקה
- סוכנים רואים מטענים במעלה הזרם גולמיים
- מספר ששוחרר עם חיובים נכנסים שעדיין חיים
- קטלוג in setup שהובטח כייצור דו-כיווני
להתחיל עם IOSOR
שלחו MO נכנס אחד ו‑MT יוצא אחד על אותו DID שכור. ייצאו את שתי שורות הארנק והוכיחו קודי סיבה שונים. תקרה לתשובה האוטומטית כדי שנכנס לא יטביע MT בלי גבול. זו יושרת שורות prepaid דו‑כיווניות, לא דוח תערובת של שבוע חשבונית ולא תקרת אחסון מדיה.
סיכום IOSOR
MO ו‑MT חולקים ארנק, לא שורה.
עשו: סמנו חיוב נכנס בנפרד מיוצא. אל: אל תנטו את ה‑MO לתוך MT ואל תסתירו שורות נכנסות עד סוף החודש.
האם המדריך הזה עזר?
מדריכים קשורים
- הגדרת מענה חלופי לשיחות קוליות נכנסות שלא נענו לטריגרים של SMS
למד כיצד להגדיר טריגרים אוטומטיים של SMS עבור שיחות קוליות נכנסות שלא נענו ואותות תפוסה בתוך קונסולת ה-CPaaS הממותגת של IOSOR.
- אחסון בחוצץ (Buffer) של עיבוד וובהוק נכנס כנגד פיקים בשיהוי הספקים
למדו כיצד להגדיר כללי חציצה נכנסים של IOSOR כדי להגן על הוובהוקים שלכם מפני עיכובים במסירת ספקים, פיקי במקביליות ושגיאות פסק זמן upstream.
- סנכרון מילות הסרה נכנסות בין חשבונות רב-דייריים
שלוט בסנכרון הסרה ממסרים בריבוי דיירים ב-IOSOR. למד כיצד מילות עצירה נכנסות מנהלות מחיקות גלובליות תוך בידוד תתי-חשבונות.