לכל ספק סליקה שדה תשובה משלו ומילון קודים משלו. איך קוראים את התשובה, למה אסור להעתיק טבלת קודים מהאינטרנט, ואיך בונים החלטה חוזרת מול לא חוזרת.
עיקרי הדברים
- הקוד לבדו אינו מספיק. תמיד שומרים גם את מחרוזת התיאור שחזרה מהספק.
- מילוני הקודים אינם משותפים בין הספקים. אותו מספר אצל שניים אינו אותה משמעות.
- אל תעתיקו טבלת קודים מבלוג. הספק הוא המקור, והטבלה משתנה עם מסלולי סליקה וסוגי עסקה.
- החלוקה שקובעת התנהגות היא חוזר או לא חוזר, לא הניסוח של ההודעה.
- לקוח לא צריך לראות קוד. הוא צריך לראות מה לעשות עכשיו.
תשובת סליקה נדחית מגיעה משלושה מקורות אפשריים - הוולידציה שלכם, שער הסליקה, או מנפיק הכרטיס - וכל אחד מהם דורש פעולה אחרת. Cardcom מחזירה בממשקי v11 שדה ResponseCode שבו 0 הוא הצלחה, לצד Description. ב-Tranzila שדה התשובה הוא בן שלושה תווים, ו-000 הוא אישור.
שלושה מקורות לאותה מילה "נדחה"
לפני שמפרשים קוד כלשהו, צריך לדעת מי כתב אותו:
- הקוד שלכם. שדה חסר, סכום לא חוקי, מטבע לא נתמך, מספר כרטיס שנפל בבדיקת לוהן לפני שיצא בכלל לרשת. זו לא דחייה של סליקה.
- שער הסליקה. מסוף לא מוגדר, פרטי התחברות שגויים, עסקה כפולה, כשל באימות 3-D Secure. הבעיה אצלכם או בהגדרות, והלקוח לא יפתור אותה.
- מנפיק הכרטיס. אין יתרה, כרטיס חסום, כרטיס פג תוקף, סירוב שדורש פנייה לחברת האשראי. רק כאן הלקוח הוא הגורם שיכול לפעול.
הבלבול הרגיל הוא לטפל בכל השלושה באותו מסך שגיאה. התוצאה היא שהלקוח מתבקש לנסות כרטיס אחר בגלל מסוף שלא הוגדר נכון.
איפה בדיוק נמצא הקוד אצל כל ספק
| Cardcom | Tranzila | |
|---|---|---|
| שדה התשובה המרכזי | ResponseCode | שדה תשובה בן שלושה תווים |
| ערך הצלחה | 0 | 000 |
| טקסט מלווה | Description | מחרוזת הודעה שמלווה את הקוד |
| מקור המילון | תיעוד Cardcom | תיעוד Tranzila |
| מה לא לעשות | להסתמך על שדות של הממשקים הישנים | להניח שאותו מספר זהה לספק אחר |
השורה האחרונה היא הנקודה. שתי אינטגרציות שנכתבו על ידי אותו מפתח, לאותה חנות, יחזירו מספרים שונים לאותו מצב בעולם. כל ניסיון לאחד אותם למילון אחד שהועתק מהרשת יוצר החלטות שגויות בשקט.
איזו דחייה בכלל שווה לנסות שוב?
זו השאלה היחידה שמעניינת את הקוד. סווגו כל תשובה לאחת מארבע קטגוריות, ותנו לכל קטגוריה התנהגות אחת:
| הקטגוריה | דוגמה למצב | הפעולה | לנסות שוב |
|---|---|---|---|
| הצלחה | אישור | להמשיך את התהליך | לא רלוונטי |
| כשל זמני | תקלת תקשורת, זמן קצוב | ניסיון חוזר מושהה, פעם אחת | כן |
| דחייה של המנפיק | סירוב, יתרה, תוקף | לבקש אמצעי תשלום אחר | לא באותו כרטיס |
| כשל תצורה | מסוף, הרשאות, פרמטר | להתריע לצוות, לא ללקוח | לא |
הכלל הפשוט: אם הדחייה מתארת מצב אצל הלקוח, ניסיון חוזר על אותו כרטיס בעוד שנייה לא ישנה כלום. אם היא מתארת תקלת תשתית, ניסיון חוזר יחיד עם השהיה הגיוני. ניסיון חוזר בלולאה על סירוב של מנפיק נראה כמו התנהגות חשודה.
מה הלקוח אמור לראות?
לא את הקוד. הלקוח צריך משפט אחד שמסביר מה עכשיו, ולא מספר שהוא לא יכול לעשות איתו דבר.
- כשלון תשתית: "לא הצלחנו להשלים כרגע, נסו שוב בעוד רגע."
- דחיית מנפיק: "התשלום לא אושר. נסו כרטיס אחר או פנו לחברת האשראי."
- כשל תצורה: הודעה כללית ללקוח, והתראה מיידית לצוות עם כל הפרטים.
- בכל המקרים: מזהה עסקה קצר שאפשר להקריא בטלפון לשירות.
מה שאסור בשום מקרה: לבקש מלקוח לשלוח צילום מסך של הכרטיס, את שלוש הספרות שבגב, או להקריא מספר כרטיס מלא בטלפון. גם אם זה יפתור את התקלה, זה יוצר בעיה גדולה יותר.
למה חיוב חוזר נדחה אחרת מחיוב בקופה
בחיוב שמתבצע כשהלקוח יושב מול המסך, הדחייה מגיעה אליו והוא יכול להגיב מיד. בחיוב חוזר על טוקן שמור, שרץ בשלוש לפנות בוקר, אף אחד לא נמצא שם. זה הופך את אותה קטגוריה של קוד למשהו אחר לגמרי מבחינת התהליך.
- כרטיס שפג תוקפו הוא הסיבה הנפוצה לכשל בחיוב חוזר, והיא ידועה מראש. אפשר להתריע לפני מועד החיוב במקום להיכשל בו.
- דחייה של מנפיק בחיוב חוזר מחייבת ערוץ תקשורת ללקוח, ולא רק שורה ביומן. אם לא יצרתם קשר, המנוי פשוט מפסיק לשלם.
- ניסיון חוזר בחיוב חוזר צריך להיות מתוזמן בימים, לא בשניות. הסיבה הנפוצה - יתרה - משתנה עם הזמן ולא עם ניסיון נוסף.
- ספרו כמה מחזורים רצופים נכשלו לאותו לקוח. אחרי מספר שהגדרתם מראש, המנוי עובר לטיפול אנושי ולא לניסיון נוסף.
- בזרימות שכוללות שלב אימות לפני החיוב, כשל בשלב האימות אינו דחיית סליקה. סווגו אותו בנפרד, אחרת דוח הדחיות שלכם מודד שני דברים שונים.
איך בונים את שכבת ההחלטה פעם אחת
- הגדירו טבלת מיפוי בבסיס הנתונים: ספק, קוד, קטגוריה, האם חוזר, מה מציגים ללקוח.
- אכלסו אותה מהתיעוד של כל ספק בנפרד. אין ברירת מחדל משותפת.
- הגדירו קטגוריית "לא מוכר" שמתריעה לצוות במקום לנחש. קוד חדש יופיע יום אחד.
- שמרו לכל ניסיון: מזהה עסקה אצל הספק, זמן, סכום, מטבע, סוג פעולה, הקוד והתיאור המלא.
- אל תשמרו לעולם מספר כרטיס מלא, קוד אבטחה או נתוני אימות. שמרו ארבע ספרות אחרונות וסוג הכרטיס.
- הפיקו דוח שבועי של הקודים לפי שכיחות. אחד או שניים מסבירים בדרך כלל את רוב הכשלים, וזה מה ששווה לתקן.
התיעוד הזה הוא גם מה שמאפשר לענות לשאלה שתמיד נשאלת: האם שיעור הדחיות עלה, או שרק נפח העסקאות גדל.
זהו תיאור טכני של תהליך טיפול בתשובות סליקה, ולא ייעוץ פיננסי. את משמעות הקודים המחייבת יש לקחת מתיעוד הספק ומהסכם הסליקה.
קשור: אינטגרציה ל-API של Cardcom, אינטגרציה ל-API של Tranzila, השוואת שערי סליקה בישראל.
מקורות
שאלות נפוצות
האם אפשר להשתמש באותה טבלת קודים לשני הספקים?
לא. לכל ספק שדה תשובה משלו ומילון משלו, ואותו מספר אצל השניים אינו מייצג בהכרח את אותו מצב. הטבלה שלכם צריכה להיות מפתח מורכב של ספק וקוד, ולא קוד בלבד, אחרת ההחלטה תהיה שגויה ברגע שתוסיפו ספק.
מה הערך שמעיד על הצלחה בכל אחד מהם?
ב-Cardcom, בממשקי v11, בודקים ש-`ResponseCode` שווה 0, וקוראים את `Description` כשהוא אינו אפס. ב-Tranzila שדה התשובה הוא בן שלושה תווים, ו-000 מציין עסקה מאושרת. כל ערך אחר מחייב סיווג לפי המילון של אותו ספק.
כמה פעמים מותר לנסות עסקה שנדחתה?
זה תלוי בקטגוריה ולא במספר. כשל תשתית מצדיק ניסיון חוזר יחיד עם השהיה. דחייה של מנפיק אינה מצדיקה ניסיון חוזר על אותו כרטיס כלל, כי הסיבה לא השתנתה. ניסיונות חוזרים בלולאה עלולים להיראות כהתנהגות חריגה ולפגוע בחשבון הסולק.
מה בשום אופן לא נשמר ביומן?
מספר כרטיס מלא, קוד האבטחה שבגב הכרטיס, וכל נתון אימות של בעל הכרטיס. שומרים ארבע ספרות אחרונות, סוג כרטיס, מזהה העסקה אצל הספק, הקוד והתיאור. זה מספיק לחלוטין כדי לאבחן דחייה ולפתוח פנייה לתמיכה.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.