IOSOR

IOSOR ידע

חיוב משלוח OTP אינו סשן verify: שני קווי פנקס, משתמש אחד

מקטע SMS עם הקוד וסשן אימות הם שני אירועי prepaid על אותה הרשמה. אל תמזגו ל«עלות OTP אחת» ואל תסתירו את השורה השנייה מפיננסים.

המשתמש ביקש קוד. המוצר ראה OTP אחד. ארנק prepaid רשם שתי שורות: חיוב הודעות ל-SMS (מקטעים, יעד, נתיב DLR) וחיוב Verify לסשן (יצירה, חלון TTL, בדיקה). צוותים שממזגים ל«עלות OTP» או סופרים פעמיים ב-board pack או מסתירים את השורה השנייה עד סוף החודש. אף אחד מהם אינו בקרה.

IOSOR מריץ Verify prepaid ב-white-label ליד SMS על פנקס אחד. קטלוג live הוא ערוץ אמיתי; in setup אינו סשן חינם. ליד USD 1,000+ שימוש חודשי שורות SMS וסשני Verify הופכות לחומר סקירה מסחרית. אין מנוי פלטפורמה כדי «להשאיר Verify זמין».

סשן משתמש אחד, שני קווי prepaid

המסע אחד. הכסף שניים. קשורים, אף פעם לא מילים נרדפות:

  1. חיוב משלוח — SMS (או fallback קול/אימייל) שנשא את הקוד: קידוד, מקטעים, יעד, DLR סופי.
  2. חיוב סשן Verify — הונפק, המתין, נבדק, פג או מדיניות resend.

אם פיננסים רואים רק SMS, Verify נראה «חינם». אם המוצר רואה רק Verify, שאיבת SMS נראית כמו «עוד סשנים». תמונה: OTP בלי כאוס תפעולי. שמרו את שתי שורות הארנק גלויות.

חיוב משלוח אינו חיוב סשן verify

אירוע מה הארנק צריך להציג כשל טיפוסי במיזוג
קוד SMS נשלח חיוב מקטעים, יעד, קידוד «OTP אחד» מסתיר multipart UCS-2
DLR סופי אותה שורת SMS, סטטוס מעודכן Retry מחויב פעמיים בלי סשן
סשן נוצר חיוב Verify, TTL, ערוץ הסשן נראה כמו SMS נוסף
Check / expire אותה שורת Verify, סיבה סופית קודים שפגו מואשמים ב«עלות SMS»
Resend משתמש SMS חדש ± סשן חדש לפי מדיניות דילוג על cooldown, שריפה כפולה

מדיניות resend: TTL של OTP והמתנה לשליחה חוזרת. Cooldown שחוסם סשן אבל עדיין יורה SMS (או להפך) הוא איך שני פנקסים מתפצלים. Fallback קולי הוא צורת כסף שלישית אם הערוץ live — לא תוספת בלתי נראית על שורת ה-SMS.

איך צוותים סופרים פעמיים או קוברים את השורה השנייה

  • ה-board pack מוסיף הוצאת SMS OTP ועוד יחידות Verify שכבר כוללות את השליחות.
  • פיננסים מחזירים SMS שלא נמסר ומבטלים גם את הסשן.
  • לוחות מחוונים מציגים הצלחת סשן בעוד ה-SMS עדיין pending DLR.
  • Verify in setup ו-SMS live — סשנים מובטחים, SMS ממשיך לחייב.

ארנק prepaid שלא מסביר שני חיובים מאדם אחד הוא מדפסת קבלות. ייצאו את שתי השורות עם correlation id משותף. כללי עצירה: בקרת הוצאה בתשלום מראש.

התאמת SMS, DLR וניסיון verify

התאמה שבועית, מסדרון אחד:

  • ספרו סשנים שנוצרו מול ניסיונות SMS (או fallback).
  • התאימו DLR סופי לסוף סשן (delivered+checked, undelivered+expired, rejected+never checked).
  • הפרידו resend שמתחיל המשתמש מ-retry מערכת — בעלים שונים, cooldown שונה.
  • פרסמו p95 מיצירת סשן → קוד שנמסר, לא «השהיית OTP» גלובלית.

אם ניסיונות ≫ סשנים, אתם מפציצים. אם סשנים ≫ ניסיונות, אתם מחייבים Verify בלי ערוץ. שניהם נופלים בסקירה מסחרית.

דגלים אדומים

  • «עמלת OTP» מעורבת בלי פיצול SMS / סשן
  • Verify מחויב כמו blast שיווקי
  • החזרת SMS בלי לגעת בשורת הסשן (או להפך) בלי מדיניות
  • כפתור resend שמתעלם מ-cooldown באחד משני הנתיבים
  • שמות מותג upstream בשגיאות גלויות ללקוח
  • Verify מובטח בעוד הערוץ in setup

התחל עם IOSOR

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

סיכום IOSOR

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

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

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

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