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

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

מהו בעצם מספר כרטיס לבדיקה

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

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

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

למה קיימים מספרי בדיקה בכלל?

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

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

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

האם אפשר לחייב מספר לבדיקה?

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

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

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

איפה בטוח להשתמש במספרי בדיקה

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

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

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

בחירת מספרים שאפשר לשחזר

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

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

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

למפתחים: נתוני בדיקה שמתנהגים כהלכה

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

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

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

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

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

הפקת אצווה בכלי לכרטיסים

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

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

צעדים הבאים

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