IOSOR ידע
שליחת משתמש קצה עדיין מחייבת ספר ראשי מראש אחד
שליחה מוטמעת עדיין מחייבת את ארנק המפתח (ISV). אל תמציאו ספר ראשי שני שהמוצר אינו מממן — החזקות, ניסיונות חוזרים ואידמפוטנטיות נשארים מדויקים.
הודעות מוטמעות מרגישות חינמיות למשתמש הקצה: הם לוחצים על שלח בתוך ממשק ה-SaaS ורואים וי ירוק. מתחת לפני השטח, כל שליחה מוצלחת עדיין מחייבת ספר ראשי מראש אחד בבעלות ה-ISV. שום ארנק שני לא מופיע רק מכיוון שהמוצר הטמיע API. אם ה-ISV אינו מממן החזקות, השליחה חייבת להיכשל עם שגיאת מוצר אמינה — ולא עם סטטוס נמסר מזויף.
חשבונאות פיקטיבית היא מצב הניקז: מד קרדיט באפליקציה שאינו מגובה בארנק IOSOR, זיכויים ב-SaaS בזמן שהספר הראשי נשרף, או ניסיונות חוזרים ללא אידמפוטנטיות שמחייבים כפולה עבור OTP אחד. ההטמעה מסתירה את הלוח; ה-ISV נשאר הגורם המממן.
שורת מסמך ארכיטקטורה: שליחת משתמש קצה ≡ חיוב מראש של ISV. כל סקירת עיצוב מתחילה שם.
ספר ראשי אחד, גם כשהממשק מציג קרדיטים של המוצר
חבילות הודעות שנמכרות לדיירים הן שכבה מסחרית של ה-ISV. הן חייבות להתמפות להחזקות וחיובים מראש בארנק IOSOR היחיד שה-ISV מממן. יתרת דייר שאינה מותאמת לעולם לשורות הספר הראשי היא פצצת חוב של תמיכה. יצאו שימוש דיירים שבועי מול שורות הארנק כדי שהכספים יראו את אותו הניצול שהמוצר רואה.
אל תפתחו חשבון IOSOR שני לכל דייר אלא אם כן בידוד שותפים הוא החוזה המפורש. פיילוטים מוטמעים כמעט תמיד נשארים בחשבון ISV אחד עם מגבלות שיתוף הוגן פנימיות.
החזקות ואידמפוטנטיות עדיין מחייבות בנתיבים מוטמעים
שליחה בצד השרת חייבת להשתמש במפתחות אידמפוטנטיות עבור OTP ו-SMS עסקי. לחיצה כפולה בממשק ה-SaaS אסור שתצור שני חיובים עבור פעולת משתמש אחת. ניסיונות חוזרים לאחר פסק זמן עוקבים אחר אותו מפתח עד ל-DLR סופי או שגיאה ממופה.
כאשר הארנק אינו יכול לבצע החזקה, החזירו סטטוס מקורי של המוצר על חוסר במזומן או שליחה מוקפאת. לעולם אל תחזירו HTTP 200 עם משמעות של נמסר כאשר ההחזקה נכשלה.
מיפוי שגיאות מוצר לאמת של הספר הראשי
| אות ממשק SaaS | אמת הספר הראשי | שלב הבא מותר |
|---|---|---|
| נשלח / נמסר | חיוב + נתיב DLR קיים | הצג מזהה קבלה |
| בתור | החזקה פתוחה או שליחה התקבלה | דגום סטטוס |
| נכשל / הוקפא | החזקה נדחתה או שער עצירה | נסה שוב רק עם כוונה חדשה |
| הצלחה מזויפת | ללא חיוב / ללא החזקה | אסור |
אלפו את התמיכה על העמודה האמצעית. קריאות על סימנים ירוקים בממשק ללא שורות בספר הראשי מבזבזות את שבוע הפיילוט.
העברות ערוצים נשארות על אותו ארנק
אם המוצר מוסיף מאוחר יותר דואל או קול לצד SMS, ההוצאה עדיין נוחתת על אותו ספר ראשי מראש אלא אם כן תבצעו העברת ערוץ שני באישור הכספים. הטמעה אינה יוצרת ערוץ צדדי חינמי. קראו סמיכות ארנק לפני הפעלת אריח בלייב נוסף בהגדרות ה-SaaS.
נתיבי תפעול קשורים
- ערוץ שני בארנק: העברת ניהול הוצאות
- אידמפוטנטיות, ניסיונות חוזרים וכסף
- אכיפה בטוחה של מגבלות קצב עבור חשבונות מרובי-דיירים
התחל עם IOSOR
פתח את מסוף IOSOR ומפה את מערכת האשראי של השוכר שלך ישירות אל ספר החשבונות של ארנק התשלום מראש הראשי. ודא שכל בקשות ההטמעה בצד השרת מעבירות מפתח אידמפוטנטיות דטרמיניסטי כדי למנוע כפילויות לפני יצירת החזקה בארנק המרכזי. הגדר את נקודת הקצה של הווב-הוק שלך כדי לעבד אישורי מסירה נכנסים כך שהחזקות פתוחות יוסדרו באופן נקי כחיובים סופיים או כשוחרורים בספר החשבונות.
סיכום IOSOR
ממשק תוכנה מוטמע יכול להציג קרדיטים הודעות מותאמים אישית למשתמשי הקצה, אך כל שליצה אמיתית קשורה לארנק התשלום מראש היחיד הממומן על ידי ספק תוכנה עצמאי. נסיונות חוזרים, הרחבות ערוצים ואותות מצב משתמש חייבים להיות מותאמים ישירות מול החזקות בארנק במקום הפשטות ממשק משתמש שאינן מגובות.
אכוף מפתחות אידמפוטנטיות קפדניים בצד השרת ומפה כל מצב ממשק משתמש של שוכר לתגובות אישור מסירה אמיתיות בספר החשבונות. אל תמציא ארנקים משניים שאינם מגובים ואל תאפשר לנסיונות חוזרים בממשק המשתמש של השוכר להתבצע ללא החזקות ספר חשבונות מוחשיות.
האם המדריך הזה עזר?
מדריכים קשורים
- הטמעת API מול פורטל שותפים ב-White-Label
מוצרי SaaS שמטמיעים הודעות נשארים על משטח ה-ISV. פורטלי שותפים ב-White-Label נשארים תחת Partner — אין לערבב מותג, מפתחות ובעלות תפעולית.
- מתי מגבלת דייר מובנית חייבת לעצור את השליחה
מגבלות חלוקה הוגנת בתוך מוצר ISV חייבות לעצור לחלוטין את השליחה עבור אותו דייר — לעולם אל תחזיר API 200 מדומה של נמסר כאשר המגבלה מושגת.