אינטגרציה של 1С-Битрикс עם БелВЭБ: היכן התשלום נשבר
אינטגרציה של 1С-Битрикс עם БелВЭБ לרוב נכשלת לא בשלב החיבור, אלא במפגש בין שער התשלומים לבין לוגיקת ההזמנה. הלקוח עובר לעמוד התשלום, הבנק מחייב את האמצעים, אבל Битрикс לא מקבל אישור — ההזמנה נשארת בסטטוס "ממתין לתשלום". הכסף עבר, הסחורה לא נשלחה, וצריך להתעסק בזה ידנית לפי דף החשבון.
הכשל הטיפוסי הראשון — ניתוק הסשן בחזרה מעמוד התשלום. אם המשתמש סגר את הלשונית או איבד את החיבור, הדפדפן לא מעביר את התוצאה בחזרה, וההזמנה נתקעת.
זה לא מטופל ב"שדרוג הכפתור", אלא בהודעה מהשרת של הבנק: השער עצמו מודיע למערכת על הצלחה או סירוב, ללא תלות בשאלה אם הקונה חזר לאתר.
השני — חוסר סנכרון של סטטוסי ההזמנות ב-Битрикс. החנות והבנק מפרשים באופן שונה מצבי ביניים: תשלום חלקי, החזקה, ביטול לאחר חיוב. בלי התאמה מפורשת בין קודי התגובה של השער לסטטוסים הפנימיים, ההזמנה עלולה "לקפוץ" בין מצבים או להיתקע לנצח.
השלישי — הודעות חוזרות. הבנק רשאי לשלוח אישור מספר פעמים, ובלי הגנה מפני כפילויות המערכת מזכה תשלום אחד פעמיים או מסירה החזקה מוקדם מדי. כאב ראש נפרד — התאמות: פער בין יומן הפעולות של הבנק לבין היסטוריית ההזמנות צף כבר בהנהלת החשבונות.
אנחנו מפרקים איך זה נסגר: הודעות מהשרת, מפת סטטוסים מפורשת ועיבוד אידמפוטנטי — כך כשל בתשלום באתר מפסיק להפוך להזמנות אבודות.
מה נותנת אינטגרציה נכונה של שער תשלומים
שער תשלומים שנבנה כראוי משנה לא את "הנוחות", אלא מדדים מדידים: שיעור התשלומים המוצלחים, הזמן מחיוב ועד אישור ההזמנה ומספר הבירורים הידניים בהנהלת החשבונות.
כאשר מודול הסליקה БелВЭБ מקושר לעיצוב ההזמנה ברמת הסטטוסים, ולא "מהצד", התשלום וההזמנה חיים בתרחיש אחד — וזה ההבדל בין תשלום שעובד לבין בירורים מתמשכים.
הצלחת התשלומים
התשלום נופל לא בשער עצמו, אלא בנקודת החיבור: הלקוח עבר לעמוד התשלום, חזר, וההזמנה בסטטוס "ממתין". אנו מטפלים גם בהפניה החוזרת וגם בהודעה האסינכרונית מהבנק, ולכן האישור אינו תלוי בשאלה אם הלקוח סגר את הלשונית. שיעור התשלומים שמגיעים לסטטוס "שולם" מפסיק ללכת לאיבוד בהחזרים ובפסקי זמן.
זמן אישור ההזמנה
ההזמנה עוברת ל"שולם" עם קבלת האישור מהבנק, ולא עם חזרת הלקוח לאתר. המנהל רואה את התשלום ברגע שהוא באמת עבר — בלי לבדוק ידנית את תדפיס החשבון ובלי להתקשר ללקוח. עבור שירות המשלוחים זה ההבדל בין "אוספים היום" לבין "מבררים מחר".
חיוב כפול והתאמות
סוג הכשלים היקר ביותר מבחינת המוניטין הוא חיוב חוזר בעת רענון העמוד או תקלת רשת. אידמפוטנטיות לפי מזהה ההזמנה וטיפול נכון בהודעות חוזרות מסירים אותו ברמת הלוגיקה, ולא בגישה של "אנחנו נחזיר אחר כך".
התאמת העסקאות מול תדפיס החשבון של הבנק מתבצעת לפי לוח זמנים: אי-התאמות צפות כדוח, ולא כתלונת לקוח אחרי שבוע.
מה זה נותן במספרים
בסך הכול: שיעור התשלומים המוצלחים עולה הודות לקטיעות שהוסרו בחזרה מהעמוד, זמן אישור ההזמנה מתקצר עד לרגע הגעת ההודעה, וההתאמות הידניות מוחלפות בדוח אוטומטי. הנהלת החשבונות מקבלת התאמה לכל עסקה, והתמיכה — פחות פניות מסוג "הכסף חויב, ההזמנה לא קיימת".
דרכי חיבור: מודול תשלומים, שער סליקה, התאמה ידנית
דרך קבלת התשלום נקבעת לפי האופן שבו החנות מקבלת אישור על הפעולה ומי אחראי על התאמת ההזמנה לתשלום. עבור БелВЭБ מיושמות בפועל שלוש סכמות: מודול תשלומים מוכן, אינטגרציה דרך שער סליקה בפרוטוקול, והתאמה ידנית של תשלומים.
הבחירה משפיעה על מהירות הזיכוי, היקף הפעולות הידניות, ואילו תרחישי החזר ותשלום חלקי זמינים ללא פיתוח נוסף.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול תשלומים | חנות טיפוסית על ענף מעודכן, תרחיש סטנדרטי של "תשלום עבור ההזמנה כולה" | תלוי בגרסת הליבה ובעדכוני המודול; לוגיקה לא סטנדרטית של הנחות ומשלוח דורשת התאמה של המטפל |
| שער סליקה | נדרשים תשלומים חלקיים, שריון סכום, החזרים מהאדמין, אזור אישי נפרד | דורש הגדרה נכונה של החתימה וטיפול בהתראות אסינכרוניות; בעת כשל ב-webhook סטטוס ההזמנה לא יתעדכן מעצמו |
| התאמה ידנית | תשלומים חד-פעמיים, תשלום לפי חשבונית, תנאים לא סטנדרטיים | סטטוס ההזמנה משתנה ידנית, גדל שיעור הטעויות והזמן עד למשלוח; אינו מתרחב עם גידול בזרימת התשלומים |
מודול תשלומים מכסה את רוב המשימות של חנות קטנה ובינונית: הוא מותקן כהרחבה, מוגדר דרך מצב התשלום באדמין ומעביר בעצמו את הסטטוס להזמנה. נקודת התורפה שלו — הצמדות ללוגיקה טיפוסית: אם יש לכם חישוב סל לא סטנדרטי או כמה ישויות משפטיות להזמנה אחת, יהיה צורך להתאים את המטפל.
שער סליקה מעניק יותר שליטה: חתימת הבקשה, אידמפוטנטיות של התראות חוזרות, טיפול נפרד בביטולים ובהחזרים. זה מוצדק כאשר יש הרבה תשלומים והתאמה אוטומטית חשובה.
התאמה ידנית נשארת אפשרות עובדת לתשלומים נדירים, אך בזרימה היא הופכת לצוואר בקבוק — סטטוס ההזמנה מפגר אחרי עובדת התשלום, ואי-התאמות יש לחפש ידנית.
כיצד אנו מיישמים סליקה: שלבי העבודה
העבודה מתנהלת מביקורת של תוכנית התשלום הנוכחית ועד למסירת מערכת מוגדרת עם תשלום בדיקה מאושר. סדר השלבים קבוע: כל שלב עוקב נשען על התוצאה של השלב הקודם, ולכן אי-התאמות נסתרות במדריכים פנימיים ובסטטוסים של הזמנות צפות כבר בהתחלה, ולא ביום ההשקה.
- ביקורת תשלומים. אנו מנתחים כיצד ההזמנה, התשלום והסטטוס במערכת החשבונאית קשורים זה לזה: אילו פרטי תשלום נשלחים לשער הסליקה, היכן נשמר מזהה העסקה, מה קורה בעת ביטול והחזר חלקי. התוצר — מפת התהליך הנוכחי ורשימת המקומות שבהם התשלום אינו תואם את ההזמנה.
- תכנון התוכנית. אנו קובעים איזה תרחיש נדרש: תשלום חד-פעמי, חשבונית לישות משפטית, תשלום בקישור או מהאזור האישי. אנו מקבעים אילו אירועים מאשרים הצלחה ואילו — סירוב, וכיצד הם באים לידי ביטוי בהזמנה ובמערכת החשבונאית.
- הגדרת הסליקה. אנו מחברים את החנות באזור האישי של הבנק, מגדירים שיטות תשלום ותרחישי אישור. מפתחות סודיים ופרמטרי חיבור אנו ממקמים באחסון מאובטח ולא בקוד — בעת החלפת מפתח אין צורך לבנות מחדש את האתר.
- מימוש ועיבוד סטטוסים. אנו כותבים מודול תשלום ומטפל בהתראות מהבנק: הוא מקבל את התוצאה, מאמת חתימה וסכום, ומעביר את ההזמנה לסטטוס הנדרש. התראות חוזרות ומאוחרות מזוהות ואינן יוצרות כפילויות של תשלומים.
- תשלום בדיקה. אנו מריצים מחזור מלא במעגל הבדיקה של הבנק: תשלום מוצלח, סירוב, ביטול, החזר. אנו בודקים לא רק את עצם החיוב, אלא גם שההזמנה, המכתב ללקוח והרשומה במערכת החשבונאית קיבלו סטטוס תואם.
- מסירת המערכת. אנו מוסרים גישות, תרשים מעבר התשלום, הנחיות לעובדים לטיפול בעסקאות שנויות במחלוקת וסדר פעולות בעת תקלה. אנו מראים היכן לצפות ביומן העסקאות וכיצד להשוות תשלום להזמנה.
- ליווי לאחר ההשקה. בתקופה הראשונה אנו עוקבים אחר מעבר התשלומים וההתאמה, ולאחר מכן עוברים לתמיכה מתוכננת: עדכוני המודול, תגובה לשינויים מצד הבנק, טיפול במקרים לא שגרתיים.
סדר כזה מעניק השקה צפויה: עד למועד מסירת המערכת תרחיש התשלום כבר נבדק על עסקאות אמיתיות, ולא רק על הנייר. תארו את תוכנית התשלום שלכם — נחזור עם הערכה ותוכנית עבודה.
מה נשאר אצל הלקוח לאחר ההטמעה
לאחר מסירת הפרויקט, אצל הלקוח נשאר לא רק מודול תשלומים פעיל, אלא גם סט מלא של חומרים שלפיהם ניתן לפתח את המערכת, להעביר לקבלן חדש ולעבור בדיקות. להלן מה בדיוק אנחנו מתעדים במסמכים ומעבירים יחד עם הפתרון.
- תרשים זרימות תשלומים — מהזמנה ב-1С-Битрикс ועד אישור התשלום והחזר כספי: אילו אירועים יוזמים את הבקשה, היכן נשמר סטטוס העסקה, כיצד מטופלות הודעות חוזרות מהבנק.
- תצורת האינטגרציה — פרמטרים של חיבור לסליקה, הגדרות של סביבת בדיקות וסביבת עבודה, רשימת השיטות שבשימוש ומטרתן, כך שניתן לשחזר את ההגדרות בעת פריסה בסביבה חדשה.
- תיעוד תשלומים — תיאור מחזור החיים של ההזמנה והעסקה, התנהגות המערכת בעת כשלים ופסקי זמן, כללים לשליחה חוזרת ולטיפול בסטטוסים.
- נוהל התאמות — סדר השוואת הנתונים מאזור הלקוח של הבנק מול ההזמנות במערכת, תדירות, אחראים ופעולות בעת אי-התאמות.
- מדריך מנהל — הנחיה שלב-אחר-שלב לעובדים: כיצד לבדוק סטטוס תשלום, לבצע החזר כספי, למצוא יומן פעולות ולאן לפנות בעת תקלה.
- מטריצת שגיאות ותגובות — קודי תגובה אופייניים של הסליקה ומה לעשות בכל מקרה: מניסיון חוזר ועד פנייה לתמיכת הבנק.
- יומן שינויים ונקודת שחזור — מה ומתי השתנה באינטגרציה, כיצד לחזור לתצורה פעילה קודמת ללא אובדן נתוני תשלומים.
סט כזה מסיר את התלות במבצע מסוים: כל מהנדס תיעוד משחזר את לוגיקת האינטגרציה וממשיך לעבוד ללא הנדסה לאחור. אם במהלך התפעול משתנים תעריפי הבנק או מתווספות דרכי תשלום, העדכון נכנס לאותם חומרים — הם נשארים רלוונטיים ולא הופכים לארכיון.
מקרה בוחן: צמצום הזמנות תקועות פי 4
הלקוח — חנות קמעונאית עם משלוחים ברחבי בלארוס, תשלום בכרטיס באמצעות סליקת אינטרנט БелВЭБ. לפני הפרויקט ההזמנות נוצרו ב-1С-Битрикс, ואישור התשלום הגיע כקובץ דוח נפרד, שאותו המפעיל עיבד ידנית.
אם התשלום עבר אך הדוח התעכב, ההזמנה נותרה בסטטוס "ממתין לתשלום" — וההזמנות התקועות הללו הצטברו עד 18% מכלל ההזמנות בחודש.
מה היה לפני
התשלום וההזמנה חיו בשני מעגלים לא מקושרים. תשלום נחשב מוצלח רק אם המפעיל הספיק להתאים אותו להזמנה ידנית — בפועל שיעור התשלומים המוצלחים עמד על 76%. את השאר עיבדו ידנית: השוו את הסכום, מספר ההזמנה וזמן התשלום, חלק מההזמנות בוטלו, וחלק הוחזרו ללקוח. העיבוד ארך 2-3 שעות ביום, וימי מכירות בשיא הפכו לתור של תשלומים לא מטופלים.
מה שינו
הקימו חילופי סטטוסים ישירים בין 1С-Битрикс לסליקה: התשלום מיוזם מהסל, והתוצאה חוזרת להזמנה אוטומטית, ללא דוח וללא התאמה ידנית. הוסיפו אידמפוטנטיות — תגובת בנק חוזרת אינה יוצרת כפילות תשלום, והזמנות תקועות עוברות לתור נפרד עם חזרה אוטומטית על בדיקת הסטטוס. למפעיל הושארו רק המקרים שבהם הבנק לא נתן תשובה חד-משמעית.
מה נהיה
שיעור התשלומים המוצלחים עלה מ-76% ל-94%, ומספר ההזמנות התקועות הצטמצם פי 4. העיבודים הידניים פחתו ב-80% — המפעיל עוסק בלקוחות ולא בהשוואת דוחות. ביטול הזמנות בגלל סטטוס תשלום "לא ברור" כמעט נעלם, וההחזרים ללקוחות הצטמצמו ביחס למספר ההזמנות התקועות.
מדדים לפני ואחרי: שיעור התשלומים המוצלחים 76% → 94%, הזמנות תקועות — מינוס 75%, עיבודים ידניים — מינוס 80%, זמן ההשוואה היומית — מ-2-3 שעות ל-20-30 דקות.
במה שונה תשלום בכרטיס מתשלום דרך ЕРИП?
תשלום בכרטיס ותשלום דרך ЕРИП הם שני תרחישים fundamentally שונים, וההבדל מתגלה כבר ברגע אתחול התשלום.
בעת תשלום בכרטיס הקונה אינו עוזב את האתר: טופס הזנת פרטי הכרטיס נפתח ישירות בחנות המקוונת, הבנק המסלק מאשר את הפעולה תוך שניות, ואישור התשלום מגיע כקריאה חוזרת לשרת ונרשם מיד בהזמנה. הסטטוס משתנה באופן סינכרוני — הלקוח רואה הצלחה, והמערכת כבר מוכנה לשלוח את הסחורה.
ЕРИП בנוי אחרת. הקונה מקבל חשבונית עם מספר ייחודי והולך לשלם אותה בבנקאות מקוונת, באפליקציית מובייל או בקופת הבנק. בין ביצוע ההזמנה לבין קבלת הכספים בפועל חולף זמן — מכמה דקות ועד כמה שעות, ולעיתים אף ימים.
אישור התשלום אינו מגיע באופן מיידי, אלא בהודעה נפרדת מהבנק, ולכן ההזמנה צריכה לדעת להתקיים בסטטוס ביניים "ממתין לתשלום" ולעבור באופן תקין ל"שולם" עם קבלת הזיכוי בפועל.
גם החזר התשלום פועל באופן שונה. עבור תשלום בכרטיס ההחזר מיוזם מפאנל הניהול של החנות ועובר באותו ערוץ שבו בוצע התשלום — הכסף מוחזר לאותו כרטיס. ב-ЕРИП ההחזר מורכב יותר: הוא קשור למסמך תשלום מסוים, וניתן להחזיר את הכספים רק דרך הבנק, בביצוע פעולה נפרדת. לכן במערכת חשוב לשמור את מספר מסמך התשלום ואת היסטוריית הסטטוסים שלו, אחרת ההחזר הופך לחיפוש ידני.
בפועל משמעות הדבר היא שאינטגרציה של 1С-Битрикс עם БелВЭБ חייבת לתמוך בשני התרחישים בו-זמנית: אישור סינכרוני של תשלום בכרטיס והתאמה אסינכרונית של תשלומי ЕРИП לפי דף חשבון. רק אז הזמנות לא נתקעות בסטטוס לא מוגדר, והנהלת החשבונות רואה תמונה אמיתית של התקבולים.
שאלות טכניות נפוצות בנושא אינטגרציה
אינטגרציה עם סליקה כמעט אף פעם אינה "הגדרתי ושכחתי": בבנק משתנים התעריפים, בחנות — תרחישי התשלום, בהנהלת החשבונות — דרישות להתאמה. להלן השאלות שעולות לרוב כבר לאחר ההשקה, וכיצד אנו סוגרים אותן ברמת הקונפיגורציה, ולא בעריכות ידניות.
כיצד לבדוק תשלום מבלי לבצע חיובים אמיתיים?
ל-BelVEB קיים מתחם בדיקות: שער התשלומים מקבל בקשות ומחזיר תשובות מוגדרות מראש — הצלחה, סירוב, פסק זמן. אנו פורסים סביבה עם העתק של הקטלוג והסל, מפנים אותה לכתובת הבדיקות ומריצים מחזור מלא: ביצוע הזמנה, מעבר לטופס התשלום, חזרה לאתר, שינוי סטטוס, ייצוא ל-1C. בנפרד אנו בודקים תרחישי סירוב ותשלום חוזר — דווקא הם נשברים לרוב בשטח.
מה לעשות בעת שינוי תעריף או פרטי חשבון בבנק?
תעריף, מזהה מסחרי ומערך אמצעי התשלום הזמינים — אלה פרמטרים, לא קוד. אנו מחזיקים אותם בקונפיגורציה של המודול ובמשתני סביבה, ולכן החלפת תעריף מסתכמת בעריכת ערכים והפעלה מחדש של המעבד, ללא בנייה מחדש של האתר.
אם הבנק משנה את פורמט החתימה או את הרכב השדות בתשובה, אנו מעדכנים את המתאם ומריצים את אותה ערכת בדיקות — הרגרסיה אורכת שעות, לא ימים.
כיצד בנויים לוגים של תשלומים וניתוח שגיאות?
כל בקשה ותשובה נרשמות ביומן נפרד עם מזהה הזמנה, סכום, סטטוס וזמן. לפיו ניתן לראות את כל השרשרת: האם הבקשה נשלחה לבנק, מה חזר, ובאיזה שלב ההזמנה נתקעה.
השגיאות מסווגות לפי מחלקות — רשת, סירוב בנק, אי-התאמת סכום, תשלום חוזר — ולכל אחת יש תגובה ברורה: ניסיון חוזר אוטומטי, התאמה ידנית או התראה לאחראי. זה מסיר את הכאב העיקרי של התמיכה: אין צורך לנחש אם התשלום אבד או שהלקוח סגר את החלון.
אם המקרה שלכם לא נכלל ברשימה — תארו את המשימה, ונחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלכם לאינטגרציה של 1С-Битрикс עם БелВЭБ
כדי שהאינטגרציה של 1С-Битрикс עם БелВЭБ תעבור בלי הפתעות, חשוב לנו לראות את סכימת התשלום הנוכחית שלכם: איך מתבצעת הזמנה, היכן נרשם הסטטוס, מי מבצע התאמה בין התקבולים לבין מסד הנתונים.
תארו את המשימה בצורה חופשית — נחזור עם הערכת עבודה ותוכנית הטמעה, שבה כל שלב קשור לתוצאה ולא ל"נגדיר תשלום" מופשט.
מה אנחנו נותנים בסוף:
- ניתוח התרחיש הנוכחי של התשלום והנקודות שבהן הקשר בין ההזמנה לתשלום נשבר.
- סכימת אינטגרציה של 1С-Битрикс עם סליקת אינטרנט של БелВЭБ בהתאמה לקטלוג, למשלוח ולכללי סטטוס ההזמנה שלכם.
- הערכת עבודה עם פירוט לפי שלבים: הגדרה, סביבת בדיקות, העלאה לסביבת העבודה.
- תוכנית הטמעה עם סדר הבדיקות בכל שלב ונקודת rollback.
- רשימת התאמות נדרשות, אם חלק מהלוגיקה כבר מיושם וצריך לשלב אותו בסכימה החדשה.
- נוהל תמיכה בתשלומים: איך לקרוא את יומן הפעולות, מה לעשות במקרה של אי-התאמת סטטוס, למי נשלחת התראה.
- סיכומים לגבי הרשאות גישה וחלוקת תחומי אחריות בין הצוות שלכם לצוות שלנו.
אנחנו לא צריכים מסמך טכני מוכן — מספיק תיאור של התהליך: איך אתם מקבלים תשלום כיום, אילו אמצעים כבר מחוברים, מה לא מתאים. לפי התיאור הזה המהנדסים שלנו יבנו הערכה ויציעו רצף עבודה. נדון במשימה — ונחזור עם תוכנית קונקרטית, לוחות זמנים והרכב השלבים.