חיבור יעד שריג (Yaad Sarig) ל-AI ולאוטומציות
יעד שריג (Yaad Sarig) מפעיל בשקט את הסליקה של פלח גדול מהעסקים הקטנים, העמותות ונותני השירות בישראל — זה השער שיושב מאחורי אינספור דפי תרומה, הרשמות לקורסים וחשבוניות חד-פעמיות. כל חיוב מוצלח, כל ניסיון שנכשל וכל הוראת קבע הם אירוע עסקי נקי שברוב ההטמעות מסיים את חייו כמייל אישור שאף אחד לא מעבד. יעד שריג ניתן לתכנות הרבה יותר ממה שנראה: יש בו עמוד תשלום מאובטח (Hosted Page), API שרת-לשרת, callbacks של עסקאות וטוקניזציה של כרטיסים לחיובים חוזרים. הנה איך מהנדס בכיר מחבר את יעד שריג ל-AI ולאוטומציות, למה כל חלק באמת מיועד, ומתי קיצור דרך ב-no-code באמת מספיק לעומת מתי רוצים קוד אמיתי.
ליעד שריג יש מוניטין של שער תשלומים פשוט ותכליתי שמחברים לאתר כדי לסלוק כרטיסי אשראי, ואז שוכחים ממנו. בדיוק בגלל זה כל כך הרבה כסף עובר דרכו בלי מעקב: התשלום מצליח, הלקוח מקבל קבלה, ושום דבר אחר לא קורה. אבל השער נותן לכם כל מה שצריך כדי שכל עסקה תהיה תחילתו של תהליך אוטומטי במקום קצה מת. אם העסק שלכם גובה תשלומים, תרומות או מנויים דרך יעד שריג — הדאטה הזו נגישה לחלוטין, ואתם אף פעם לא צריכים להחליף ספק כדי להוסיף מעליו AI או אוטומציה. המטרה זהה לכל מערכת קיימת: להגיב למה שיעד שריג כבר יודע ברגע שכרטיס עובר, ולהניע אוטומטית את כל מה שבא אחרי — אישור בוואטסאפ, רשומה ב-CRM, חשבונית מס ישראלית, סיכום AI של פדיון היום — בלי שאף אחד יקליד שום דבר מחדש.
הדרכים שבהן יעד שריג חושף את התשלומים שלכם
לשער יש כמה דלתות פנימה נבדלות, והתאמת הדלת הנכונה לכל תהליך היא רוב עבודת התכנון. אבני הבניין המעשיות שמרכיבים הן:
- עמוד התשלום המאובטח (Hosted Page) — מפנים את הלקוח לעמוד המאובטח של יעד שריג עם פרמטרים חתומים (סכום, תיאור, מספר הזמנה), הכרטיס מוקלד בשרתים שלהם, והלקוח חוזר אליכם. כך פרטי הכרטיס הגולמיים לא נוגעים במערכות שלכם בכלל — וזה מה שמוציא אתכם מהחלקים הקשים של תקן PCI.
- ה-API שרת-לשרת — קריאת HTTP ישירה לחיוב טוקן שמור, ביצוע זיכוי או שאילתה על עסקה, כך שהשרת שלכם יכול לפעול על תשלומים בלי שאדם ילחץ על כפתורים בממשק.
- Callbacks ופרמטרים בחזרה — אחרי חיוב, יעד שריג מחזיר את התוצאה ל-URL שבשליטתכם (וגם יכול לשלוח אותה בצד שרת), עם מזהה העסקה, קוד האישור והסטטוס, כך שאתם מגיבים בזמן אמת במקום לתשאל.
- טוקניזציה של כרטיסים (תהליכי J5/J4) — השער יכול לאמת ולשמור כרטיס כטוקן לשימוש חוזר, כך שהוראות קבע, מנויים ו'לחייב שוב בחודש הבא' קורים מהשרת שלכם בלי שתחזיקו אף פעם את מספר הכרטיס בעצמכם.
- מנגנון החתימה (APISign) — יעד שריג חותם על התשובות שלו, והקוד שלכם חייב לאמת את החתימה לפני שהוא סומך על 'תשלום אושר', אחרת כל מי שיגלה את כתובת ה-callback יוכל לזייף חיוב מוצלח.
ההרגל הכי חשוב הוא להתייחס לחזרת הלקוח לאתר כרמז, לא כהוכחת תשלום — ולאמת את החתימה בצד השרת. דפדפן יכול להיסגר באמצע ההפניה, רשת יכולה ליפול, וכתובת החזרה ניתנת לזיוף. הדפוס האמין הוא לסמוך על ה-callback החתום שרת-לשרת, לאמת את חתימתו עם המפתח שלכם, ואז — לפני שפועלים — לוודא את הסטטוס המחייב של העסקה דרך ה-API. זה מה שמשאיר אתכם נכונים כשלקוח לא חוזר לעמוד ה'תודה' למרות שהכרטיס שלו חויב.
מה באמת אפשר לבנות
- מתשלום לחשבונית ל-CRM: חיוב שעבר דוחף פרטים ישירות למערכת החשבוניות הישראלית שלכם (חשבונית ירוקה/Morning, iCount, SUMIT, רווחית), מפיק חשבונית מס/קבלה אוטומטית, מתעד את הלקוח ב-CRM ושולח אישור בעברית בוואטסאפ — בלי הקלדה ידנית.
- שחזור תשלום שנכשל: חיוב שנדחה או ננטש מפעיל מעקב מותאם הקשר, בניסוח AI בעברית, בוואטסאפ או במייל, עם קישור תשלום חדש — ומחזיר הכנסה שאחרת פשוט נעלמת בשקט.
- אוטומציה למנויים ותרומות: חיובי טוקן חוזרים רצים לפי לוח זמנים מהשרת שלכם, וחידוש שנכשל מתריע ללקוח ומסמן את החשבון אוטומטית לפני שהוא נוטש.
- אנליטיקה בשיטת 'שאל-את-הפדיון': 'איך היה הפדיון מול השבוע שעבר, איזה מוצר מייצר זיכויים, אילו תורמים נשרו החודש?' — נענה בעברית פשוטה מנתוני עסקאות חיים במקום לייצא את הדוח של השער לאקסל.
- התראות הונאה וחריגות: שכבת AI עוקבת אחר זרם העסקאות ומזהה דפוסים חריגים — רצף חיובי בדיקה קטנים, קפיצה בשעות מוזרות, דחיות חוזרות מאותו כרטיס — ומתריעה לפני שזה הופך לבעיית ביטול חיוב.
איפה העבודה האמיתית
מודל ה-AI הוא החלק הקל; ההנדסה היא בהפיכת אינטגרציית תשלומים לאמינה. החלקים הקשים הם הלא-זוהרים: לאמת את החתימה של כל callback ולשמור את פרטי הטרמינל בצד השרת, אף פעם לא בדפדפן או ב-repo; להפוך כל מטפל לאידמפוטנטי, כי callback יכול להגיע פעמיים ומטפל כפול פירושו חשבונית כפולה או חיוב כפול; ליישב את מסלול החזרה בדפדפן מול ה-callback שרת-לשרת כדי שחיוב לא ייספר פעמיים ולא יאבד; לטפל נכון בזיכויים, בתפיסות חלקיות ובמטבע; ולמפות את קודי הסטטוס והשגיאה הקצרים של השער על משהו שה-CRM והחשבוניות שלכם באמת מבינים. כלום מזה לא נראה בדמו של חמש דקות — וכל זה מה שמבדיל בין אינטגרציה שאפשר לסמוך עליה עם כסף אמיתי לבין כזו שמחייבת לקוח פעמיים בשקט על רשת תקולה.
עם שער תשלומים, סיכום ה-AI הוא הנחמד-שיש, אבל העבודה המשעממת — לאמת כל חתימה, לשמור כל callback אידמפוטנטי, ליישב את החזרה בדפדפן מול התוצאה בצד השרת — היא מה שמוודא שכל שקל נספר בדיוק פעם אחת.
No-code או קוד מותאם?
לתהליכים הכי פשוטים — 'תשלום הצליח, פרסם לסלאק' או 'הוסף שורה לגיליון' — תרחיש של Make או Zapier שיושב על webhook באמת מספיק, ואני אגיד לכם ביושר מתי זה כל מה שצריך, כי לשלם על קוד מותאם שלא צריך זו עסקה גרועה. אבל כסף הוא בדיוק המקום שבו מצבי הכשל יקרים: ברגע שרוצים חתימות מאומתות, טיפול אידמפוטנטי תחת עומס אמיתי, חשבוניות ישראליות אוטומטיות, חיובים חוזרים מבוססי טוקן, או לוגיקת AI ספציפית לעסק שלכם — עברתם לעבודה שדורשת מהנדס אמיתי. אם אתם מחפשים מתכנת שיחבר את יעד שריג — או כל שער תשלומים ישראלי — ל-AI ולשאר המערכות, זה בדיוק מה שאני עושה: בונה את השכבה האמינה בין השער לכל מה שבא אחריו. טופס יצירת הקשר בעמוד הזה מגיע ישירות אליי; ספרו לי מה צריך לקרות ברגע שתשלום עובר, ואני אבנה את זה.
מחפשים מתכנת לחבר את המערכות שלכם ל-AI?
אני אריאל גלברג — מהנדס תוכנה בכיר ושותף טכנולוגי. אני בונה את האינטגרציות והאוטומציות שמחברות את העסק שלכם ל-AI, מקצה לקצה.
בואו נדבר