תשובה קצרה: תכונת תשלום נחשבת עובדת רק כשהספק רשם אותה. בודקים בשלושה מקומות ומשווים: מה שהמשתמש ראה במסך, מה שהאפליקציה שמרה, ומה שהספק רשם. אם שלושת המספרים לא זהים, התכונה לא גמורה, גם אם הכל נראה תקין אצלכם.
הבעיה: "נשמר" הוא לא "התקבל"
אתם מבקשים מכלי AI להוסיף הנחה, קופון, תוכנית חודשית או החזר. הכלי כותב קוד, המסך מציג את המחיר החדש, והרשומה במסד הנתונים נראית נכון. מרגיש גמור.
אבל התשלום עצמו לא מתבצע אצלכם. הוא מתבצע אצל הספק, מערכת נפרדת שמקבלת בקשה בפורמט מסוים. כדי שההנחה תתקיים באמת, הבקשה צריכה לכלול אותה, להגיע לאובייקט הנכון ולחזור בהצלחה. אם אחד מהשלבים האלה חסר, הלקוח רואה מחיר מוזל וחויב במחיר מלא, או שהחיוב נכשל, או שההנחה נרשמה אצלכם בלבד.
זה כשל שקט במיוחד, כי סוכן הקוד בדק בדרך כלל את הצד שלו: הערך נשמר, המסך התעדכן. צד הספק הוא מערכת חיצונית עם מפתחות, סביבות וחוקים משלה, ולא תמיד נבדק.
הבדיקות למטה לא דורשות לקרוא קוד. הן דורשות עסקה אחת בסביבת טסט ודשבורד פתוח.
שש בדיקות
1. מגדירים מראש מה אמור לקרות אצל הספק
לפני שבודקים, כותבים משפט אחד: "עסקה של 200 שקלים עם קוד הנחה של 10 אחוזים אמורה להירשם אצל הספק כחיוב של 180 שקלים, עם הקוד מצורף". בלי המשפט הזה אין למה להשוות.
2. מריצים עסקה אחת מקצה לקצה, בסביבת הטסט של הספק
לא מסתפקים בבדיקה של הכפתור. עוברים את כל הדרך, כולל מסך התשלום של הספק. רושמים בצד שלושה מספרים:
| מה בודקים | איפה רואים |
|---|---|
| מה המשתמש ראה | המסך לפני הלחיצה על תשלום |
| מה האפליקציה שמרה | מסד הנתונים או לוח הניהול שלכם |
| מה הספק רשם | הדשבורד של הספק, ברשימת התשלומים |
תוצאה רעה: המספר השלישי שונה מהראשון. למשל, המסך הראה 180 והספק רשם 200.
3. פותחים ביומן הבקשות של הספק
בדשבורד של רוב הספקים יש יומן של כל קריאה שהגיעה אליהם, עם הגוף שנשלח והתשובה. ב-Stripe הוא נמצא באזור המפתחים, תחת הלוגים. מחפשים את הקריאה שנוצרה בעסקה שלכם.
מה בודקים:
- האם הקריאה בכלל קיימת.
- האם הגוף כולל את השדה של ההנחה, הקופון, התוכנית או ההחזר.
- האם התשובה היא הצלחה, ואם לא, מה הודעת השגיאה.
תוצאה רעה: קריאה שמחזירה שגיאה בשקט, או קריאה שחסר בה השדה. שגיאה כזו לא תופיע במסך שלכם אם הקוד בולע אותה.
4. מוודאים שהאובייקט קיים בסביבה הנכונה
בספקים רבים מוצרים, מחירים וקופונים נוצרים בנפרד בסביבת הטסט ובסביבה החיה. תכונה שעובדת בטסט יכולה להישבר בחי רק כי הקופון לא נוצר שם, או כי המפתח שבשימוש שייך לסביבה האחרת.
איך בודקים: מחפשים בדשבורד החי את אותו מוצר או קופון לפי השם ואת המזהה שהקוד משתמש בו. בודקים גם איזה מפתח מוגדר בסביבת ההפצה, ושהוא לא מפתח טסט.
5. בודקים את הדרך חזרה
אחרי התשלום הספק שולח לכם הודעה (webhook) שהחיוב הצליח. אם התכונה שלכם תלויה בה, כמו הפעלת מנוי או סימון הזמנה כשולמה, צריך לוודא שההודעה מגיעה, שהחתימה מאומתת, ושההודעה החוזרת פעמיים לא מפעילה את הפעולה פעמיים. תקלות בנושא הזה מתועדות במדריך לתקלות Stripe Webhooks.
6. בודקים סכומים, מטבע ועיגול
מקור קבוע לפערים קטנים: ספקים רבים מקבלים סכומים ביחידה הקטנה של המטבע (אגורות), ואילו המסך שלכם מציג שקלים. הנחה באחוזים על סכום שאינו עגול נותנת שבר. בדקו סכום אחד עגול ואחד לא עגול, ושהמטבע זהה בשני הצדדים.
מה מבקשים מהכלי שכתב את הקוד
אל תשאלו "זה עובד?". בקשו שני דברים:
- את הבקשה המדויקת שהקוד שולח לספק במקרה הזה.
- את המזהה של האובייקט שנוצר אצל הספק.
אחר כך מחפשים את המזהה בדשבורד של הספק. אם הוא שם, והסכום נכון, התכונה הגיעה. אם הכלי לא יודע לתת מזהה, כנראה שהקריאה לא נשלחה.
מה לא נבדק כאן
הבדיקות מכסות את הקשר בין האפליקציה לספק. הן לא בודקות אבטחה של התשלום, חוקיות של הנחות והחזרים, ולא את החוויה של הלקוח. אפליקציה שגובה כסף צריכה גם בדיקה של הרשאות ושל מפתחות חשופים.
האפליקציה כבר גובה כסף או עומדת להתחיל? הבדיקה לפני השקה עוברת על התשלומים, מסד הנתונים והמפתחות, ואפשר לקבוע שיחת וואטסאפ חינמית של 20 דקות.
