Grow (לשעבר משולם): זרימת התשלום הדו-שלבית

הדבר הראשון שכדאי לדעת הוא ששם המוצר השתנה: משולם היא כיום Grow, והתיעוד למפתחים יושב ב-grow.business/api-developers. חיפוש "משולם API" עדיין מחזיר חומר, אבל חלקו ותיק ולא בהכרח תואם לממשק הנוכחי - שווה לפתוח את התיעוד הרשמי ולא להסתמך על דוגמה שמצאת.

הזרימה - וההבדל שמפיל אינטגרציות

הדפוס המרכזי הוא דו-שלבי, וזו הנקודה שהכי חשוב להבין:

1. createPaymentProcess - השרת שלך יוצר תהליך תשלום. מקבל בחזרה דף תשלום שאפשר להטמיע ב-iframe או להפנות אליו.
2. הלקוח משלם בדף של Grow. פרטי הכרטיס לא עוברים דרכך.
3. Grow מודיעה לשרת שלך בקולבק.
4. approveTransaction - השרת שלך מאשר את העסקה.

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

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

מה לעשות בין השלבים

ברגע שהקולבק מגיע ולפני approveTransaction:

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

תשלומים - היכולת שמשנה את הרישום

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

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

כשלקוח משלם ב-6 תשלומים, האם המסמך משקף את הסכום המלא במועד העסקה, או שכל תשלום מייצר רישום משלו?

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

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

הקולבק הוא מקור האמת

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

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

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

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

מי מפיק את המסמך

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

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

אבטחה

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

צ'קליסט לפני העלייה לאוויר

1. לפתוח את התיעוד ב-grow.business/api-developers - לא לחפש "משולם", השם השתנה.
2. לוודא ש-approveTransaction נקרא בכל מסלול מוצלח. זו הבדיקה שהכי מרבים לפספס.
3. לבדוק את התרחיש שבו הלקוח משלם וסוגר מיד את הלשונית - האם ההזמנה עודכנה?
4. לבדוק קולבק כפול - האם ההזמנה סומנה פעמיים?
5. לקבל מרואה החשבון בכתב איך נרשמת עסקה בתשלומים.
6. לוודא שאין הפקת מסמך כפולה.
7. לבדוק כישלון אמיתי, לא רק הצלחה.

להשוואה בין הסולקים הישראליים, ראה השוואת סולקים ישראליים למפתחים.