שילוב תשלומי קריפטו ב-1C-Bitrix: מודול, הגדרה, וובהוק

אינטגרציה של תשלומי קריפטו ב-1С-Битрикс: היכן אובדות הזמנות

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

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

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

אינטגרציה של תשלומי קריפטו ב-1С-Битрикс לא נסגרת בכפתור «התחבר», אלא בסכמה: התאמה בין ההזמנה לתשלום לפי מזהה ייחודי, עיבוד אידמפוטנטי של התראות, התאמה תקופתית מול שירות התשלומים והתנהגות מוגדרת מראש במקרה של תשלום חסר, תשלום יתר וביטול. להלן — איך זה בנוי ואיפה זה נקרע לרוב.

מה משתנה לאחר החיבור: אישורים, התאמות, סירובים

אם קליטת תשלומי קריפטו מוטמעת ב-1С-Битрикс ברמת הלוגיקה העסקית של ההזמנה, ולא מוצאת לדף תשלום נפרד, כל המעגל משתנה: האישור מגיע מהרשת, המודול מתאים את הסכום, כתובת הנמען ומספר האישורים הנדרש — ההזמנה עוברת מעצמה לסטטוס «שולם». המנהל לומד על התשלום לא מהתכתבות, אלא מהסטטוס.

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

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

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

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

דרכים לקליטת תשלומי קריפטו: שער, רשת ישירה, שירות קסטודיאלי

ב-1С-Битрикс קליטת קריפטו לא מסתכמת בכפתור «שלם»: המודול יוצר חשבונית, מוסר כתובת וסכום, ומטפל ה-webhook משנה את סטטוס ההזמנה — הוא מקבל אישור מהרשת או מהספק ורושם את ההאש של העסקה במאפייני ההזמנה. מכאן הכול תלוי בשאלה אחת: היכן נמצאים המפתחות הפרטיים ומי מאשר את עצם התשלום. מכך נגזרים זמני הזיכוי, מתווה ההחזרים והיקף מה שהצוות מתחזק בכוחות עצמו.

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

בפועל משלפים בין השיטות: הזרימה העיקרית עוברת דרך אפשרות אחת, הגיבוי דרך אחרת, וההתאמה מתקיימת כנוהל נפרד. ב-1С-Битрикс כל אחת מהן היא מודול עם מטפל webhooks, לוג עסקאות וקישור בין ההזמנה להאש; השונה הוא רק מעגל אחסון המפתחות והיקף התחזוקה.

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

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

רצף השלבים

1. ביקורת מעגל התשלומים. בודקים אילו מטפלים כבר מחוברים, היכן נשמר ומשתנה סטטוס ההזמנה, איך בנויים ההחזרים, התשלומים החלקיים והניסיונות החוזרים, ומה נכנס ללוג האירועים.
2. סכמת התשלום והתיאום. קובעים את מקומו של תשלום הקריפטו במחזור החיים של ההזמנה: אמצעי תשלום נפרד או משולב, מי קובע את השער, כמה זמן חיה החשבונית, ולפי אילו כללים היא מתבטלת.
3. הגדרת מודול התשלום. רושמים את המטפל במערכת, מגדירים את מפתחות החנות, כתובות ההתראות משער התשלומים, בחירת הרשת והתאמת סטטוסי ההזמנה לסטטוסי העסקה.
4. בדיקת תרחישי התשלום. מריצים תשלום מוצלח, תשלום חסר ותשלום יתר, התראה חוזרת, חשבונית שפגה, ביטול מצד הקונה — ובנפרד בודקים שמעבר הסטטוס מופעל פעם אחת ולא מכפיל את ההזמנה.
5. בדיקות במעגל סגור. עובדים על העתק של האתר עם רשת בדיקה ו-sandbox של השער: הרצות ידניות ובנוסף בדיקות אוטומטיות לאידמפוטנטיות ולאובדן התראות.
6. מעבר למצב עבודה. מחליפים את המפתחות למפתחות ייצור, מגבילים גישות לפי תפקידים, מפעילים לוג והתראות על הזמנות שנתקעות זמן רב בסטטוס ביניים.
7. מסירת הנהלים. מוסרים את סכמת הסטטוסים, הוראות למנהלים, סדר הפעולות בעת אי-התאמה וגישה ללוגים.

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

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

לאחר המסירה נשאר בפרויקט לא רק קוד עובד, אלא גם שכבה שמאפשרת להפעיל את אינטגרציית תשלומי הקריפטו ב-1С-Битрикс בלעדינו. להלן — התוצרים שהמזמין מקבל לידיו יחד עם גישה למאגר הקוד ולסביבות הבדיקה.

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

מקרה בוחן: שיעור ההזמנות שלא הושלמו וההתאמות הידניות — לפני ואחרי

חנות על 1С-Битрикс קיבלה תשלומים בקריפטו, אבל אישור התשלום נשאר ידני: המנהל קיבל התראה משירות התשלומים למייל, התאים את הסכום ואת כתובת הארנק להזמנה, ורק אחר כך העביר אותה לסטטוס «שולם». בלילה ובסופי שבוע התור הצטבר עד הבוקר, חלק מהקונים הספיקו לבצע הזמנה חוזרת או פשוט עזבו.

מה היה לפני

מתוך 1,200 הזמנות בתשלום קריפטו, 214 נתקעו בשלב האישור — 18% מההזמנות במצב תלוי. ההתאמה הידנית ארכה בממוצע 7 דקות להזמנה, ופערים בגלל עמלת הרשת טופלו בנפרד.

מה שינו ומה נהיה אחרי

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

2% הנותרים — תשלומים עם רמת אישור נמוכה ברשת: הם לא הולכים לאיבוד, אלא ממתינים למספר האישורים הנדרש בלי מעורבות אדם.

מה לעשות אם תשלומי הקריפטו כבר מחוברים באופן חלקי

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

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

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

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

הפונקציונליות הסטנדרטית של 1С-Битрикс מתרחבת ולא מוחלפת: עמוד התשלום, המיילים והדוחות נשארים במקומם, ורק שכבת אישור התשלום משתנה.

מגבלות ותרחישים שנויים במחלוקת: מתי קליטת קריפטו לא מתאימה

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

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

השכבה השלישית היא החשבונאות. ב-1С-Битрикс התשלום מגיע כ-webhook, וצריך לקשר אותו להזמנה ולתעד את הסכום ואת השער ברגע הזיכוי, אחרת ההכנסות וחשבונאות המלאי לא יתאמו. בנפרד — בדיקות בצד הספק: כתובת או מטבע עשויים להיות מסומנים כחשודים, והכספים מוקפאים כבר אצלו.

נדון במשימה: נחזור עם הערכה, סכמה ותוכנית עבודה

כדי לחזור עם הערכה מדויקת ולא עם טווח «מכמה ועד כמה», אנחנו צריכים לראות את מעגל קליטת התשלומים הנוכחי. תארו איך בנויה החנות על 1С-Битрикс: אילו אמצעי תשלום כבר מחוברים, היכן נשמרות ההזמנות והאם יש שירות חיצוני שמקבל התראות משערי תשלומים.

מצד המזמין מספיק להכין:

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

בתמורה נחזיר:

• הערכת מאמץ לפי שלבים ותוכנית עבודה כוללת עם לוחות זמנים;
• סכמת מעבר התשלום: סל, חשבונית, אישורים ברשת, webhook, שינוי סטטוס ההזמנה;
• רשימת המודולים והשינויים הנדרשים, עם הערכת ההשפעה על עדכוני הפלטפורמה העתידיים;
• נוהל בדיקה ברשת הבדיקה ותרחישי rollback אם האישור לא הגיע.

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