ספקי סליקה מתחזקים קטלוג קטן משלהם של כרטיסי בדיקה, והסיבה מעשית ולא נדיבה: סביבת בדיקה שאינה יכולה להפיק סירוב אינה יכולה לבדוק את מסלול הקוד שמטפל בו. אין להשתמש לשם כך באמצעי תשלום אמיתיים, גם מפני שזה מסוכן וגם מפני שהתוצאה תהיה בלתי צפויה, ולכן הספקים מפרסמים מספרים שהתנהגותם נקבעת מראש בידי המערכות שלהם.
המאמר מסביר מהם המספרים האלה, למה ספק יפרסם אותם בכלל, כיצד מדמים סירובים ואימות, והיכן מתחילים הגבולות של רשימה שמספק הספק.
מהו כרטיס בדיקה של ספק סליקה
כרטיס בדיקה הוא מספר שסביבת הבדיקה של ספק הסליקה מזהה. כשהוא מופיע בבקשת תשלום, הסביבה אינה יוצרת קשר עם שום בנק. היא מחפשת את המספר בטבלה, מחליטה מה צריכה להיות התוצאה של הבקשה, ומחזירה את התוצאה הזו—הצלחה, סיבת סירוב מסוימת, או בקשה לאימות נוסף.
החיפוש הזה הוא כל המנגנון. המספר אינו צריך להיות שייך למישהו, תאריך התוקף אינו צריך להיות אמיתי כל עוד הוא בעתיד, וקוד האבטחה נבדק רק מול הצורות שסביבת הבדיקה מצפה להן. מפני שההתנהגות מתוסרטת ולא נפתרת, שני מפתחים שמשתמשים באותו כרטיס בדיקה בחשבונות שלהם באותה סביבה מקבלים את אותה תוצאה, וזו הסיבה שדיווחי תקלות בזרימות תשלום ניתנים לשחזור.
למה ספקי סליקה מפרסמים מספרי בדיקה משלהם?
כל שער סליקה מיישם פרשנות משלו לתשובות של רשתות הכרטיסים. קודי סירוב, שלבי אימות והתנהגות ניסיון חוזר נבדלים בין ספקים, וההבדלים האלה הם בדיוק הדברים שבדיקת אינטגרציה צריכה להריץ. מספר בדיוני גנרי יכול להוכיח שטופס מקבל שש עשרה ספרות; רק מספר שהספק מזהה יכול להוכיח שהאפליקציה מטפלת בדרך הספציפית של הספק לומר שהכרטיס סורב.
יש גם טיעון של בטיחות. המפרסמים רוצים שמפתחים ישתמשו במספרים שבאופן ודאי אינם מתפענחים לחשבון אמיתי, בכל סביבה ובכל תצורה. רשימה מסודרת היא הדרך של הספק להבטיח שבדיקה בסביבת בדיקה לא תהפוך במקרה לעסקה אמיתית.
הקטלוג משתנה כשהספקים מוסיפים תכונות, ולכן הרשימה המוסמכת היא תמיד התיעוד של הספק עצמו. יש לקרוא אותה שם ולא לסמוך על גרסה שהועתקה לפוסט או למאגר, כולל זה.
כרטיס הבדיקה שכולם משתמשים בו
מבין המספרים ש-Stripe מתעדת, אחד הפך לברירת מחדל בפועל: ערך בן שש עשרה ספרות שמתחיל בארבע ומורכב מחזרה של אותה תבנית קצרה—4242424242424242. עם כל תאריך תוקף עתידי וכל קוד אבטחה בן שלוש ספרות הוא מפיק חיוב מוצלח בסביבת הבדיקה.
הפופולריות שלו מובנת. קל לזכור אותו, הוא עומד בכללי התבנית שכרטיס אמיתי עומד בהם, והוא מאפשר למפתח לעבור זרימת תשלום שלמה בתוך דקות מתחילת העבודה. זו גם הסיבה שכה רבים מאינטגרציות התשלום נבדקות באופן שטחי, מפני שמקרה הצלחה אחד אינו אומר דבר על מה שקורה כשתשלום נסרב.
שתי אזהרות ראויות להיאמר בבירור. ראשית, המספר הזה משמעותי רק בתוך סביבת בדיקה של ספק; הפנייתו לשער חי תפיק סירוב אישור ורשומה ביומני ההונאה של מישהו. שנית, חיוב מוצלח בסביבת בדיקה הוא תוצאה מדומה ולא ראיה לכך שהכרטיס אמיתי או שהחשבון שמאחוריו קיים—סביבת הבדיקה מעולם לא שאלה.
איך מדמים סירוב?
סירובים מונעים בדרך כלל בידי מספרים שהספק שומר לתוצאות מסוימות, והרשימה מכסה בדרך כלל את המקרים שקוד האינטגרציה צריך להסתעף עליהם:
- סירוב גנרי, שנבדק איתו שהטופס מציג שגיאה שאפשר להתאושש ממנה ולא קריסה.
- סירוב שמציין שהמנפיק מבקש מהלקוח ליצור קשר, וזו דרך ללא מוצא לזרימת התשלום.
- אין מספיק אמצעים, הסירוב היחיד שמשתמש יכול לתקן באופן סביר באמצעות כרטיס אחר.
- תשובה של כרטיס שפג תוקפו, שבודקת אם אימות התאריך בטופס והשער מסכימים ביניהם.
- שגיאת עיבוד, שבדרך כלל יש לנסות שוב ולא להציג ללקוח כתשובה סופית.
- חסימה בחשד להונאה, שאמורה לעצור את הזרימה ולא לדחוף את המשתמש לניסיון חוזר.
כל אחד מאלה ראוי למסלול מכוון באפליקציה: הודעה אחרת, מדיניות ניסיון חוזר אחרת, ורשומה אחרת במסד הנתונים של המערכת. שימוש במספר סירוב אחד לכולם מסתיר את ההבדלים עד שלקוח נתקל באחד מהם.
בדיקת אימות וזרימות 3-D Secure
תשלומי כרטיס מודרניים כוללים לעיתים קרובות שלב שבו הלקוח מופנה או מוצג לו אתגר מוטמע כדי לאשר את התשלום מול הבנק שלו. סביבות בדיקה מדמות זאת במספרים ייעודיים: חלקם מפעילים אתגר שעובר תמיד, אחרים אתגר שנכשל תמיד, ואחרים זרימה שמסתיימת בלי אתגר כלל.
המקרים שכדאי לכסות אינם נוגעים למסלול התקין. מה קורה כשהלקוח נוטש את האתגר באמצע וחוזר לאתר? האם ההזמנה נשארת במצב ממתין לנצח, או שהיא מגיעה לתוצאה מוגדרת? האם ניסיון חוזר יוצר הזמנה שנייה? אימות מוסיף שלב שבו המערכת מאבדת שליטה על המשתמש לכמה שניות, ולכל אינטגרציה יש לפחות תקלה אחת בחלון הזה.
למפתחים: רשימת תרחישים עדיפה על מספר קסם אחד
ההרגל שכדאי לאמץ הוא לתכנן כיסוי בדיקות כרשימת תוצאות ולא כרשימת מספרים. יש לרשום את המצבים שבהם זרימת התשלום יכולה להסתיים—מאושר, נדחה כניתן לניסיון חוזר, נדחה כסופי, נדרש אימות, אימות נכשל, נטישה, פסק זמן—ולמצוא לכל אחד קלט אחד בסביבת הבדיקה.
את המיפוי הזה יש לשמור במאגר לצד הבדיקות, עם הערה מאיזו גרסת תיעוד של הספק הוא נלקח, ולבחון אותו מחדש כשהספק מעדכן את הקטלוג. כשחוקרים תקלת תשלום בדיעבד, המיפוי הוא מה שמאפשר לומר אילו מצבים הורצו ואילו מעולם לא כוסו.
כמה נקודות קטנות חוסכות זמן אמיתי. יש לשמור את פרטי הגישה של סביבת הבדיקה רק בסביבת הבדיקה, ולבדוק את התצורה לפני שמריצים משהו, מפני שכרטיס בדיקה מול מפתח חי הוא בדיוק המקרה שכל הנוהג הזה נועד למנוע. יש לאמת את התוצאה שהמערכת עצמה רשמה ולא רק את התשובה שהתקבלה מהשער, מפני שתקלות מעניינות חיות בין השניים. וכדאי להחליט מוקדם כיצד יבחינו בטבלאות של המערכת בין עסקת בדיקה לעסקה אמיתית, כדי שבדיקה עתידית לא תצטרך לנחש.
הפקת כרטיסים בלי חשבון אצל ספק
קטלוגים של ספקים הם הכלי הנכון כשצריך תוצאה מתוסרטת, והכלי הלא נכון כשצריך כמות. טופס שצריך לקבל מאה כרטיסים שונים, הדגמה שצריכה להציג מגוון רשתות, או סט מתקנים שמשתרע על אורכים וקידומות—כולם נענים טוב יותר בנתונים מופקים.
מחולל מספרי הכרטיס באתר הזה מפיק מספרים לרשת נבחרת או לתערובת אקראית, עם תאריכי תוקף וקודי אבטחה של מציין מקום, ואף אחד מהם אינו קשור לחשבון. כל ערך נכון מבנית ומעולם לא הונפק, ולכן בדיקת תבנית תקבל אותו וכל שער אמיתי יסרב לו. כל אלה מיועדים לבדיקות תוכנה בלבד.
יש להשתמש בשני סוגי הנתונים למשימות שונות: מספרי בדיקה של ספק לתוצאות מתוסרטות של השער, ומספרים מופקים לכל מה שהשער אינו רואה. השוואת הרשתות שימושית כשצריך כרטיס אחד מכל מותג, ורשימת הבדיקות לטופס תשלום מפרטת את הזרימות שבהן הכרטיסים האלה אמורים להופיע.
צעדים הבאים
כדאי לרשום את רשימת התוצאות של זרימת התשלום, למפות כל סעיף לקלט מסביבת הבדיקה מהתיעוד העדכני של הספק, ולהוסיף לרשימת מטלות גלויה את אלה שאי אפשר עדיין להפיק. לאחר מכן יש להפיק אצווה נפרדת של כרטיסים בדיוניים לבדיקות ברמת הטופס, כדי ששני סוגי נתוני הבדיקה לא יתערבבו.