ביצוע הזמנה בתשלומים ב-1C-Bitrix: היכן זה נשבר
ביצוע הזמנה בתשלומים ב-1C-Bitrix כמעט תמיד נשבר לא ברגע חיבור מודול האשראי, אלא במפגש בין שלוש תת-מערכות: סל הקניות, שער התשלומים והחלפת נתונים עם 1С.
סל הקניות חי ב-session ושומר את הרכב ההזמנה, מודול האשראי יוצר בקשה בצד הבנק, וסטטוס הבקשה צריך לחזור חזרה ל-Bitrix ולהמשיך ל-1С. כל עוד שלושת המעגלים הללו מסונכרנים — הכל עובד; די שאחד מהם יפגר בצעד אחד, וההזמנה "נתקעת" במצב לא מוגדר.
הכשל הנפוץ ביותר — חוסר סנכרון בין סל הקניות למודול האשראי. המשתמש משנה את הרכב ההזמנה או את שיטת המשלוח כבר לאחר שהבקשה נשלחה לבנק, והסכום בהחלטת האשראי מפסיק להתאים לסכום בסל הקניות.
אם לא חוסמים עריכה בשלב זה, ההזמנה יוצאת ל-1С עם סכום אחד, והבנק מאשר סכום אחר — הפער צף כבר בשלב המשלוח.
סוג הבעיות השני — אובדן סטטוס הבקשה בחזרה משער התשלומים. הלקוח סוגר את הלשונית, מאבד את ה-session או חוזר בקישור ישן, והמטפל לא מקבל את תגובת הבנק: הבקשה נשארת בסטטוס "בטיפול", למרות שההחלטה כבר התקבלה. זה מטופל באמצעות מטפל אידמפוטנטי והשוואת סטטוסים לפי לוח זמנים, ולא רק לפי חזרת המשתמש.
הכשל השלישי — כפילויות הזמנות. לחיצה כפולה על כפתור האישור, קריאה חוזרת של המטפל או redirect מהשער יוצרים שתי הזמנות על בקשה אחת, ושתיהן מגיעות ל-1С. ההגנה — מפתח ייחודי לבקשה בצד Bitrix ובדיקה לפני יצירת הישות. נבחן כיצד זה נסגר ברמת ארכיטקטורת ההחלפה.
מה נותנת אינטגרציה נכונה של תשלומים
האפקט המרכזי של אינטגרציה נכונה אינו "כפתור תשלומים בעמוד", אלא תרחיש מקצה לקצה שבו בקשת ההלוואה וביצוע ההזמנה חיים בזרימה אחת.
כאשר המודול הבנקאי מקבל את נתוני הסל ישירות מההזמנה, הקונה אינו צריך להזין מחדש את הרכב הרכישה והסכום — זמן הביצוע מתקצר מדקות לכמה עשרות שניות, ושיעור הסלים הנטושים בשלב התשלום יורד פי כמה. דווקא בשלב זה אובדת עיקר הקבוצה שכבר הגיעה לצ'קאאוט ומוכנה פסיכולוגית לרכוש.
נקודת אובדן נפרדת היא החזרה מדף התשלום. אם הבנק דחה את הבקשה או שהקונה התחרט, באינטגרציה נאיבית הסל מתאפס וההזמנה אובדת: האדם חוזר לאתר ריק ועוזב.
בעיבוד נכון של סטטוס החזרה, הרכב הסל, שיטת המשלוח שנבחרה וההנחות שהוחלו נשמרים, ולקונה מוצעת מיד חלופה — תוכנית אחרת, מקדמה ראשונה קטנה יותר או תשלום רגיל.
זה מעביר את הסירוב מסיווג "לקוח אבוד" לסיווג "ניסיון חוזר", ושיעור הבקשות המאושרות עולה בזכות כך שהמערכת עצמה מתאימה תנאים מתאימים במקום אפשרות קשיחה אחת.
על המרת הצ'קאאוט משפיעה ישירות גם האופן שבו המודול מתקשר עם הבנק ברגע הביצוע.
בקשה סינכרונית עם המתנה לתשובה תולה את העמוד ומעוררת לחיצות חוזרות; סכמה אסינכרונית עם מצבים ברורים — "הבקשה נשלחה", "ההחלטה התקבלה", "נדרשים דיוקים" — משאירה את הקונה מעודכן ומונעת ממנו לסגור את הלשונית. תיעוד כל שלב ואידמפוטנטיות של הפעולות מגנים מפני הזמנות כפולות ושכפולי בקשות בעת ניתוק תקשורת.
בסך הכל זה נותן משפך צפוי: פחות סלים נטושים, נתיב קצר יותר לתשלום, שיעור גבוה יותר של בקשות מאושרות והחזרה נשלטת מדף התשלום במקום אובדן בלתי הפיך של הקונה.
אפשרויות חיבור לתשלומים: השוואת גישות
הבחירה בדרך חיבור התשלומים קובעת עד כמה תוכל לנהל את התנאים בגמישות וכמה מהר יעבור תהליך ביצוע ההזמנה.
המודול המובנה מכסה את התרחיש הטיפוסי של "אשר ובצע" ללא התאמות, שער התשלומים מספק תרחישי בנק ומסגרות אשראי מוכנים, ומעבד מותאם אישית נדרש במקומות שבהם לוגיקת האישור תלויה בנתונים שלך על הלקוח ועל המלאי.
| אפשרות | מתי מתאימה | מגבלות אינטגרציה |
|---|---|---|
| מודול מובנה | תרחיש תשלומים טיפוסי, תנאי בנק סטנדרטיים, חנות ללא לוגיקה מותאמת אישית | מצב ביצוע מוגדר מראש, גמישות נמוכה בכל הנוגע לאישור חלקי ותשלום משולב |
| שער תשלומים | יש צורך במספר בנקים שותפים, מסגרות אשראי מוכנות וניתוח סיכונים בצד הספק | תלות בזמינות השער, שליטה מוגבלת בלוגיקת האישור, סנכרון סטטוסים באמצעות וובהוקים |
| מעבד מותאם אישית | תנאים לא סטנדרטיים, חיבור ל-1С, בדיקת מסגרות אשראי ויתרות בזמן אמת | אחריות מלאה לעמידות בתקלות, טיפול בשגיאות ועמידה בדרישות הבנק |
בפועל, לרוב משלבים בין הגישות: המודול המובנה או השער לוקחים על עצמם את ביצוע התשלום, והמעבד המותאם אישית — את בדיקת הלקוח וחישוב הסכום הזמין. זה מספק ביצוע הזמנה צפוי ושליטה על סירובים בכל שלב.
שלבי הטמעת תשלומים בתשלומים בעיצוב ההזמנה
העבודה מתנהלת מה�audit של הצ'קאאוט הנוכחי ועד למסירה לתפעול: תחילה מתעדים כיצד ההזמנה מתבצעת כעת, לאחר מכן מתכננים את סכימת התשלומים ורק לאחר מכן נוגעים בקוד. סדר זה מונע עיבוד מחדש באמצע הדרך — כל שלב עוקב נשען על סכימה מוסכמת, ולא על השערות.
- Audit הצ'קאאוט. מנתחים את הסל, שלבי העיצוב, שיטות המשלוח והתשלום, כללי חישוב ההנחות והקופונים. בנפרד בוחנים היכן בהזמנה מאוחסנים הסכומים וכיצד הם עוברים למערכת החשבונאית — מכך תלוי היכן ישתלב התשלומים בתשלומים.
- סכימת האינטראקציה. מתאמים כיצד התשלומים בתשלומים משתלבים עם התשלום, המשלוח וסטטוסי ההזמנה: איזו שיטת תשלום מופיעה בצ'קאאוט, מה קורה לסכום כאשר ההזמנה עוברת למערכת החשבונאית וכיצד מגיע לשם סימן הזיהוי של התשלומים בתשלומים.
- הגדרת המודול. מחברים ומגדירים את המודול בהתאם לסכימה המוסכמת: תנאים, תקופות זמינות, מגבלות סכום ומוצרים, הרשאות גישה. מגדירים את החלפת הנתונים כך שמידע על התשלומים בתשלומים יוצג כראוי בהזמנה ובמערכת החשבונאית.
- בדיקת תרחישים. מריצים את מסלול הלקוח המלא: עיצוב עם תשלומים בתשלומים, החזרה חלקית, ביטול הזמנה, ניסיון תשלום חוזר, הזמנה עם קופון. בודקים גם את הצד ההפוך — נכונות הסטטוסים והסכומים במערכת החשבונאית לאחר כל תרחיש.
- מסירה לתפעול. מתעדים את ההגדרות, מתארים את נוהל השינויים ומעבירים לצוות הלקוח הוראות לפעולות שגרתיות. לאחר ההשקה נשארים בתמיכה — תיקוני תנאים וטיפול בתקלות מתבצעים לפי תהליך ברור.
כל שלב מסתיים בתיאום, ולכן בסופו של דבר הלקוח מקבל תשלומים בתשלומים פעילים בצ'קאאוט וסדר תמיכה עתידי שקוף.
מה הלקוח מקבל לאחר ההגדרה
הגדרת תשלומים היא לא רק מודול מופעל, אלא גם סט של נכסים שלפיהם המערכת חיה ומתפתחת לאחר המסירה. להלן — מה שנשאר אצל הצוות שלכם בצורה סגורה.
- תצורות המודול: פרופילים פעילים של תשלומים לכל אמצעי תשלום, שיוך לקבוצות מוצרים ולקטגוריות קונים, הגדרות ספי סכום הזמנה. הכול מופרד לפרופילים נפרדים — תרחיש חדש מתווסף בהעתקה, בלי לערוך את הליבה.
- תרשימי זרימת נתונים: כיצד בקשת תשלומים עוברת מהסל ועד לאישור — אילו שדות נשלחים למודול האשראי, מה חוזר בחזרה, היכן נשמר הסטטוס. התרשים מסיר את השאלה "למה ההזמנה תקועה" בדקות, ולא בשעות של ניתוח לוגים.
- מדיניות הרשאות: הפרדת תפקידים של מנהל, מפעיל ומנהל מערכת — מי רואה נתונים אישיים, מי משנה תנאי תשלומים, מי מאשר בקשה. ההרשאות מתוארות במפורש, ולא "כברירת מחדל לכולם".
- נהלי טיפול בבקשות: מה לעשות במקרה של סירוב מודול האשראי, כיצד לטפל בבקשות תקועות, באיזה שלב ההזמנה עוברת לתשלום, למי מועבר מקרה שנוי במחלוקת. הנהלים מכסים מצבים טיפוסיים בלי שיחה למפתח.
- הוראות למנהלים: תרחישים שלב-אחר-שלב בממשק הניהול — כיצד לבדוק סטטוס, כיצד לשלוח בקשה מחדש, כיצד ליצור קשר עם הקונה. כתובות עבור המסכים האמיתיים, ולא באופן מופשט.
- מפת אינטגרציות: רשימת השירותים החיצוניים המשתתפים בתשלומים, עם נקודות כשל והתנהגות המערכת בעת אי-זמינות של כל אחד מהם. עוזרת להבחין בין תקלה בצד שלנו לתקלה של השותף.
- יומן שינויים ונקודות שחזור: מה ומתי השתנה בתצורה, כיצד להחזיר את המצב הקודם. השחזור אורך דקות, ולא שעות של שחזור מגיבוי.
כל נכס מועבר בסביבה שלכם — עם גישה לצוות ואפשרות לעריכה בלעדינו. תארו את המשימה — נחזור עם הערכה ותוכנית לתרחיש התשלומים שלכם.
מקרה בוחן: איך תשלומים הפסיקו לאבד בקשות
הלקוח — רשת חנויות אלקטרוניקה — קיבל בקשות לתשלומים דרך טופס באתר, וההחלטה על כל בקשה נעשתה על ידי מנהל באופן ידני: השווה את נתוני הלקוח מול מסד הנתונים, בדק את המסגרת, והעביר את הסטטוס למערכת החשבונאית.
בהיקף של כמה מאות פניות בחודש, חלק מהבקשות נתקעו בין השלבים: הלקוח לא קיבל תשובה, והמנהל לא ראה את העסקה התקועה. שיעור הבקשות שאבדו הגיע ל-18%, והבדיקות הידניות גזלו 3-4 שעות ביום.
פירקנו את מסלול הבקשה לשלבים ומצאנו את צווארי הבקבוק: הסטטוס השתנה רק לאחר פעולה ידנית, וחלק מהבקשות כלל לא הגיעו למערכת החשבונאית בגלל חוסר סנכרון בין הטפסים למדריכים.
כתבנו מחדש את תרחיש ההגשה כך שכל בקשה מקבלת סטטוס אוטומטית בכניסה, וההחלטה על התשלומים נשלפת מהמערכת החשבונאית ללא מעורבות המנהל. את הבדיקות החלפנו בהעברת סטטוסים אוטומטית — המנהל רואה רק את הבקשות שבהן נדרשת החלטתו.
מה השתנה במספרים
לאחר ההטמעה שיעור הבקשות שאבדו ירד מ-18% ל-2% — המקרים שנותרו הם בקשות עם נתונים חסרים, שהמערכת מסמנת ומחזירה ללקוח להשלמה. הזמן לבדיקות ידניות הצטמצם מ-3-4 שעות ל-20-30 דקות ביום: המנהל מטפל רק בחריגים. הסירובים בשלב ההגשה ירדו כמעט בחצי — הלקוח מקבל תשובה לגבי התשלומים בתוך דקה, ולא ממתין לשיחה.
בנפרד סגרנו את הנושא של עסקאות תקועות: אם בקשה לא קיבלה סטטוס בזמן שהוקצב, המערכת מעלה אותה לתור נפרד ומ� notify את האחראי. בעבר מקרים כאלה נמצאו רק בבדיקה החודשית, כעת — באותו יום.
את הפרויקט הוביל מהנדס האינטגרציות שלנו, עבדנו על 1C-Bitrix עם החלפת נתונים דרך המודול הסטנדרטי של המערכת החשבונאית. את לוגיקת הסטטוסים וכללי הטיפול בחריגים תיארנו בתקנון, כדי שהתמיכה תוכל לשנות את תנאי התשלומים ללא שינוי בקוד.
במה שונה פריסה מתשלומים בתשלומים מהלוואה בצ׳קאאוט?
מנקודת המבט של הצ׳קאאוט מדובר בשני מודי תשלום שונים עם לוגיקת בדיקה משלהם, ולא "כפתור אחד עם כיתובים שונים".
פריסה מתשלומים היא הסכם עם בנק שותף או תוכנית פנימית של החנות: התשלום מתחלק לחלקים שווים, וההחלטה מתקבלת על בסיס סט מצומצם של נתונים — בדרך כלל די בדרכון, טלפון ואישור בקוד.
הלוואה היא מוצר אשראי נפרד: הבנק מבקש הכנסה, תעסוקה, היסטוריית אשראי, והאישור מגיע באופן אסינכרוני ולא תמיד ברגע ביצוע ההזמנה.
לוגיקת בדיקה שונה מחייבת דרישות שונות לנתונים. עבור פריסה מתשלומים די להעביר למודול התשלומים את הסכום, מספר התשלומים, הרכב הסל ומזהה הקונה — את השאר הבנק מחשב בעצמו.
עבור הלוואה יש לאסוף שאלון מורחב, להעביר אותו כראוי לשער הבנקאי ולטפל בתשובה מושהית: ההזמנה עשויה להישאר בסטטוס "ממתין להחלטה", והצ׳קאאוט חייב להציג זאת, ולא לאבד את הסל.
אם הנתונים חסרים או אינם תואמים לפרופיל המשתמש, הבנק יחזיר סירוב — ויש לתכנן מראש את תרחיש הסירוב, אחרת הקונה просто יעזוב.
גם תרחישי ההחזרה שונים. בפריסה מתשלומים החזרת המוצר מיוזמת החנות, הבנק מחשב מחדש את לוח התשלומים, ולקונה מוחזר החלק שכבר שולם — חשוב שסטטוס ההזמנה וסטטוס ההסכם יסונכרנו. בהלוואה ההחזרה מתבצעת דרך הבנק: החנות מאשרת את ההחזרה, הבנק סוגר את ההסכם, ורק לאחר מכן מתבטלת ההתחייבות. אם לא מאוטמטים את השרשרת הזו, הנהלת החשבונות תטפל בפערים ידנית.
בפועל שני המודים חיים באותו צ׳קאאוט, אך כענפי ביצוע נפרדים: טפסים שונים, מטפלי תשובת בנק שונים, סטטוסי הזמנה שונים וכללי ביטול שונים. אנו מפרידים ביניהם ברמת הלוגיקה, ולא ברמת הקוסמטיקה — ואז גם האישור, גם הסירוב וגם ההחזרה פועלים באופן צפוי. תארו את סכימת התשלום שלכם — נחזור עם הערכה ותוכנית אינטגרציה.
ספקות טכניים בעת חיבור תשלומים
לפני חיבור תשלומים כמעט תמיד עולים אותם שאלות טכניות: האם המודול החדש ישבור את לוגיקת ההזמנה הקיימת, מה יקרה אם הבנק ידחה את הבקשה, האם הפתרון ישרוד עדכון פלטפורמה והאם תגדל העומס על ביצוע ההזמנה. להלן — תשובות קצרות לכל אחד.
האם זה תואם למודולים ולתוספות הקיימים שלנו?
תשלומים משתלבים בתהליך ביצוע ההזמנה הרגיל כאמצעי תשלום נוסף, ולכן לא נוצרים קונפליקטים עם הקטלוג, סל הקניות והאזור האישי. מסובך יותר אם בביצוע ההזמנה יש תוספות לא סטנדרטיות: שדות מותאמים אישית, סדר שלבים שונה, מטפלי סטטוסים משלנו. מקומות כאלה אנחנו מנתחים לפני תחילת העבודה ומחברים את התשלומים מעליהם, בלי לשכתב את הלוגיקה הקיימת.
מה יקרה אם הבנק ידחה את הבקשה או לא יגיב?
ההזמנה לא הולכת לאיבוד ולא נתקעת בסטטוס לא מוגדר. אם הבנק דחה את הבקשה, הקונה רואה הודעה ברורה ויכול לבחור אמצעי תשלום אחר, וההזמנה נשארת במערכת עם סטטוס תקין. אם הבנק לא הגיב בזמן, הבקשה מסומנת כלא הושלמה, ושליחה חוזרת לא יוצרת כפילות של ההזמנה.
האם הפתרון ישרוד עדכון פלטפורמה?
כן, אם האינטגרציה בנויה על מנגנונים רגילים ולא על שינויים בליבה. אנחנו לא נוגעים בקבצי המערכת — את כל השינויים מוציאים למודול ולהגדרות נפרדים, ולכן עדכון הפלטפורמה לא מוחק את לוגיקת התשלומים. אחרי עדכונים גדולים אנחנו בודקים את עבודת ביצוע ההזמנה ובמידת הצורך מתקנים את האינטגרציה.
האם תגדל העומס על האתר בעת ביצוע ההזמנה?
העומס גדל באופן לא משמעותי: הבקשה לבנק נשלחת פעם אחת בעת אישור ההזמנה, ולא בכל שלב. עיקר העבודה מתבצעת בצד הבנק, האתר רק מעביר נתונים ומקבל תוצאה. במבצעי מכירות בשיא ביצוע ההזמנה נשאר מהיר — במידת הצורך מוציאים את התקשורת עם הבנק לתור נפרד, כדי שלא ישפיע על מהירות האתר.
אם נותרו שאלות לגבי התצורה שלכם — תארו את המשימה, נחזור עם הערכה ותוכנית.
נדון במשימה שלך להגדרת ביצוע ההזמנה
כדי לחזור עם הערכה מדויקת ותוכנית, ולא עם מילים כלליות, אנחנו צריכים נתוני מקור על החנות שלך. ספרו לנו על איזו מהדורה פועל הפרויקט — "עסק קטן" או "עסק", האם מודול התשלומים בתשלומים מחובר ואילו אמצעי תשלום כבר מוגדרים. זה קובע אם אנחנו משפרים תרחיש קיים או בונים ביצוע הזמנה מאפס.
בנפרד, הבהירו כיצד התשלומים בתשלומים צריכים להיראות עבור הקונה: כפתור נפרד בכרטיס המוצר, אפשרות תשלום בשלב האחרון של הסל או בחירת בנק שותף עם חישוב תשלום חודשי. מזה תלוי אילו נתונים אנחנו מושכים מהקטלוג וכיצד אנחנו בונים מחדש את תבנית ביצוע ההזמנה.
מה לשלוח יחד עם המשימה:
- קישור לאתר וגישת בדיקה עם הרשאות מנהל;
- רשימת בנקים ותוכניות תשלומים בתשלומים שאתם עובדים איתם;
- דרישות לחישוב התשלום: תקופה, תשלום ראשון, עמלה;
- דוגמאות להזמנות שבהן נדרש תשלום בתשלומים ובאילו לא;
- כללים לייצוא הזמנות ל-1С וסטטוסי תשלום;
- בקשות לגבי התראות לקונה ולמנהל.
לפי הנתונים האלה אנחנו מעריכים את היקף השיפור, מציינים לוחות זמנים ומראים אילו מקומות בביצוע ההזמנה אנחנו נוגעים בהם. אם חלק מהתרחישים כבר עובדים — מתעדים מה משאירים ללא שינוי, כדי לא לשבור מכירות קיימות.
השלב הבא — שיחה קצרה על המשימה: ננתח את נתוני המקור שלכם, נסיר שאלות לגבי אינטגרציה עם 1С ותוכניות בנקאיות ונחזור עם הערכה ותוכנית עבודה. תארו את המשימה בדרך הנוחה לכם — נכין הצעה לחנות שלכם.