חיבור תשלום ERIP (סליקה) ל-1C-Bitrix

תשלום דרך ERIP נשבר בשלב אישור ההזמנה

לרוב הכשל מתבטא כך: הלקוח משלם עבור הזמנה דרך ERIP, הכסף יוצא, אך בחשבון האישי ההזמנה עדיין נמצאת בסטטוס "ממתין לתשלום".

המנהל רואה הזמנה שלא שולמה, מתקשר ללקוח, הלקוח שולח קבלה — ורק אז מתברר שהתשלום עבר. הסיבה כמעט תמיד היא שהאינטגרציה של 1C-Bitrix עם ERIP מוגדרת לקבל תשלום אך לא לאשר אותו: המערכת לא מקבלת או מעבדת באופן שגוי את הודעת הבנק על סטטוס העסקה.

הכשל הטיפוסי השני הוא חשבוניות כפולות. כאשר ניגשים שוב לתשלום (רענון עמוד, חזרה מ-ERIP, לחיצה חוזרת), המערכת יוצרת חשבונית חדשה עבור אותה הזמנה, ושתי תשלומים עם מספרים שונים נשלחים לבנק.

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

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

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

סיבה נפרדת היא דה-סינכרון בין האתר למערכת הנהלת החשבונות. ההזמנה נוצרת ב-1C-Bitrix, בעוד שתנועת הכסף בפועל נרשמת ב-1C; אם ההחלפה פועלת לפי לוח זמנים ולא לפי אירוע, סטטוס התשלום מגיע באיחור ולא תואם את המציאות.

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

מה מספקת אינטגרציה נכונה של 1C-Bitrix עם ERIP

אינטגרציה נכונה של 1C-Bitrix עם ERIP מסירה את המקור העיקרי לעבודה ידנית בחנות מקוונת — בדיקת תשלומים "בעין".

כאשר התשלום מגיע למערכת באופן אוטומטי, ההזמנה עוברת לסטטוס "שולם" ללא מעורבות מפעיל: שיעור ההזמנות המאושרות ללא מגע אדם מגיע ל-95–98%, וזמן הזיכוי בסטטוס ההזמנה מתקצר משעות ל-1–3 דקות לאחר אישור התשלום על ידי הבנק.

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

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

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

הדבר מבטל מחלקה שלמה של שגיאות: הזמנה לא נכנסת להרכבה ללא כסף ולא נשארת "ממתינה לתשלום" לאחר שהכסף כבר הגיע.

עבור הלקוח, אינטגרציה של 1C-Bitrix עם ERIP משמעה עומס צפוי על המפעילים: ככל שיש יותר הזמנות, כך קטן שיעור הפעולות הידניות לכל הזמנה. להלן נפרט כיצד הדבר פועל ומה נדרש להגדרה.

דרכים לשילוב תשלום ERIP: השוואת אפשרויות

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

להלן השוואה המבוססת על תנאי התאמה, ולא על מחיר: העלות של כל שלוש האפשרויות מורכבת ממערך שונה של עבודות, ובהתחלה זה לא תמיד ברור.

חיבור ישיר

כאן אתה מפיק את החשבונית בעצמך עם מזהה במערכת "Расчёт" ומקבל את סטטוס התשלום מהבנק. זה נותן שליטה מלאה: ניתן לסגור הזמנות אוטומטית, לשלוח התראות ולבנות דוחות על בסיס קבלות בפועל.

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

סולק וייצוא ידני

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

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

בואו נבין איזו אפשרות מכסה את מערכת החשבונאות שלך ללא התאמות מיותרות.

שלבים ליישום תשלום ERIP ב-1C-Bitrix

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

1. ביקורת הזמנות וסכימת התשלום הקיימת. אנו בוחנים כיצד נוצרות הזמנות, אילו סטטוסים בשימוש, היכן נשמרים הסכומים וכיצד הנתונים מגיעים ל-1C. אנו מזהים צווארי בקבוק: התאמות ידניות, הזמנות כפולות, אי-התאמות סטטוס לאחר תשלום.

2. תכנון תרחיש התשלום. אנו קובעים באיזה שלב הקונה עובר ל-ERIP, כיצד הוא חוזר לאתר ומה קורה בביטול ובניסיון חוזר.

   אנו מסכמים את לוגיקת הסטטוסים: "ממתין לתשלום", "שולם", "בוטל" — כך שהנהלת החשבונות והמחסן רואים את אותו הדבר.

3. הגדרת ההחלפה עם 1C. אנו מגדירים ייצוא הזמנות, סנכרון פריטים והעברה נכונה של סכומים. ההחלפה פועלת לפי לוח זמנים ולפי אירועים — ההזמנה לא "נתקעת" במצב ביניים.

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

5. בדיקת תשלומים. אנו עוברים על התרחישים: תשלום מוצלח, ביטול, ניסיון חוזר, תשלום מאוחר. אנו מוודאים שהסכומים, הסטטוסים והנתונים ב-1C תואמים בכל שלב.

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

7. תמיכה לאחר ההשקה. אנו תומכים במחזורי התשלום הראשונים, עוקבים אחר אי-התאמות ומתאימים את ההחלפה אם התנאים או הפריטים משתנים.

סדר זה סוגר את הסיכון המרכזי — אי-התאמה בין האתר, התשלום והנהלת החשבונות. תארו את סכימת ההזמנות וההחלפה עם 1C שלכם — נחזור עם הערכת עלות ותוכנית לפי שלבים.

מה הלקוח מקבל לאחר הקמת האינטגרציה

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

• תצורות החלפה: פרופילים עובדים לאינטגרציה של 1C-Bitrix עם ERIP ומערכת הנהלת החשבונות, פרמטרים למיפוי פריטים, תעריפים וסטטוסים של הזמנות, הגדרות לתורי ניסיון חוזר כאשר השער אינו זמין.
• תרשים החלפה: מפת זרימות "עגלת קניות → חשבונית → אישור תשלום → מסמכי סגירה" עם נקודות אידמפוטנטיות כך שקריאה חוזרת לא תיצור תשלום כפול.
• מדיניות גישה: הפרדת הרשאות לשיטות תשלום ולייצוא, חשבונות שירות ייעודיים, סבב מפתחות וכללים לאחסון יומני עסקאות.
• תיעוד: תיאורים של תרחישי תשלום והחזר, רשימת קודי שגיאה של ERIP עם הסברים ופעולות מפעיל, ומדריך למנהל להתאמה ידנית של חשבוניות תקועות.
• תקנות תחזוקה: תדירות התאמת התשלומים מול דף החשבון הבנקאי, נהלים לטיפול באי-התאמות סכומים ונקודות בקרה לאחר עדכוני פלטפורמה ומודולים.
• כלי אבחון: תיעוד בקשות ותגובות של שער התשלומים, סביבת בדיקה להרצת תרחישי תשלום והחזר ללא חיובים אמיתיים.
• תוכנית חזרה לאחור: הנוהל לחזרה לשיטת התשלום הקודמת תוך שמירה על תקינותן של עסקאות שכבר עובדו.

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

מקרה בוחן: כיצד ביטלנו חיובים כפולים עבור תשלומים דרך ERIP

הלקוח — ספק שירותים עם פורטל לקוחות על 1C-Bitrix — קיבל תשלומים דרך ERIP וטיפל בבקשות באופן ידני. הבעיה לא הופיעה באופן קבוע, אלא במקבצים: כאשר החיבור בין השער לאתר נפסק, הקונה ראה שגיאה, חזר על התשלום, ושני החיובים עברו.

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

איך זה היה לפני ההטמעה

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

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

מה שינינו

העברנו את אישור התשלום לסכימה אסינכרונית: ההזמנה נסגרת בהתבסס על התראה משער התשלומים, ולא על חזרת הקונה לאתר.

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

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

מה הייתה התוצאה

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

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

במה שונה תשלום דרך ERIP מסליקת אשראי?

סליקת אשראי היא תהליך מבוסס כרטיס: הקונה מזין את פרטי הכרטיס, הבנק המסלק מאשר את העסקה באופן מקוון ומשיב ברגע התשלום.

הכספים אינם נזקפים באופן מיידי אלא דרך מחזור סליקה, אך סטטוס "שולם" מגיע באופן סינכרוני, וניתן לעבד את ההזמנה ב-1C כמעט באופן מיידי.

ERIP בנוי אחרת: זוהי מערכת תשלומים עם עץ שירותים, שבה כל שירות מתאים לקוד בהיררכיה, והתשלום מיוזם מצד הבנק או מסוף התשלומים, ולא מהאתר.

ההבדל המרכזי טמון במנגנון האישור. בסליקת אשראי האתר עצמו שולח בקשה לבנק ומקבל תשובה בערוץ מאובטח. ב-ERIP האתר רק מפיק חשבונית עם מספר ייחודי וקוד שירות, הקונה עובר לבנקאות מקוונת ומשלם שם, והאישור מגיע באמצעות הודעת callback מהבנק או באמצעות התאמת מרשם התשלומים.

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

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

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

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

עבור סליקת אשראי די במודול תשלום ובעיבוד callback. בפועל, פרויקטים רבים מתחזקים את שתי השיטות: סליקת אשראי לתשלום מהיר בכרטיס, ERIP למי שנוח לו יותר לשלם דרך הבנק.

שאלות טכניות נפוצות בנושא אינטגרציית תשלומים

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

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

כבר פרוסה אצלנו מערכת על 1C — האם נצטרך לבנות אותה מחדש? לא. האינטגרציה מוטמעת בסביבה הקיימת: נתוני האסמכתא של הפריט, הצד שכנגד והחוזה נשארים כפי שהם; רק שכבת החלפת סטטוסי התשלום משתנה.

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

מה הבעיה בייצוא תשלומים ידני, ומתי הוא עדיין מקובל? ייצוא ידני אינו מתרחב: עם עשרות טרנזקציות ביום מופיעים אי-התאמות, וההתאמה אורכת שעות. הוא מוצדק רק בהתחלה או עבור תשלומים חד-פעמיים נדירים, עד להגדרת החלפה אוטומטית.

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

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

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

בואו נדון במשימת אינטגרציית התשלומים שלכם

כדי לחזור עם הערכת עלות ותוכנית יישום ולא עם כלליות, אנחנו צריכים תמונה של המערך הנוכחי שלכם: איך הזמנות נכנסות ל-1C, היכן נוצרות חשבוניות, מי מבצע התאמות תשלומים, ומה קורה כשיש אי-התאמה.

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

• באיזו תצורת 1C משתמשים ואיך היא מחוברת לאתר: החלפה דרך מודול, שירותי ווב, או ייצוא ידני.
• איך מתקבלים תשלומים כיום: ЕРИП, סליקה, מזומן — ואילו סטטוסים של הזמנות מוגדרים ידנית.
• היכן נשמרים רשומות הזמנות ופריטים: ב-1C, ב-Битрикс24, או בשתי המערכות במקביל.
• האם יש התאמות אישיות בהחלפה הסטנדרטית ומי מתחזק אותן — זה משפיע על היקף העבודה.
• אילו דוחות נדרשים בסופו של דבר: התאמת תשלומים, ייצוא להנהלת חשבונות, התראות למנהלים.
• האם יש מגבלות על גישה, אחסון ולוח הזמנים של העדכונים.

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