תשובת דחייה מכילה שלושה קודים שונים, לא אחד. איך קוראים קוד רשת, קוד הנחיה וקוד ספק, מה לבדוק לפני חיוב חוזר, ומה לשמור בלוג כדי לאבחן בדיעבד.
עיקרי הדברים
- תשובת דחייה מכילה בדרך כלל שלושה קודים שונים ולא אחד: קוד הדחייה של הרשת, קוד ההנחיה, והקוד המנורמל של ספק הסליקה.
- אותו מספר יכול להתפרש אחרת בין רשתות כרטיסים שונות. מאסטרקארד מכנה את קוד ההנחיה Merchant Advice Code.
- ההנחיה היא מה שמכריע: לא לנסות שוב עם הכרטיס הזה, לנסות מאוחר יותר, או לבקש מהלקוח לאמת את פרטי הכרטיס.
- חיוב חוזר שלא לפי ההנחיה עלול להפר את כללי רשתות הכרטיסים ולהפעיל בקרות הונאה. את מספר הניסיונות המותר קובעים כללי הרשת וההסכם מול הסולק שלכם.
- בלי שמירה של גוף התשובה המלא בזמן הדחייה, אין שום דרך לאבחן אותה בדיעבד.
תשובת דחייה בנויה משלוש שכבות: קוד הדחייה שהמנפיק החזיר דרך רשת הכרטיסים, קוד ההנחיה שנלווה אליו, ושכבת התרגום שספק הסליקה מוסיף מעליהם. המספר לבדו אינו מספיק, כי משמעותו משתנה בין רשתות הכרטיסים. מה שקובע אם מותר לנסות שוב הוא ההנחיה, ולא ההודעה שהלקוח ראה על המסך.
מה בעצם מגיע בתשובת הדחייה
תשובת דחייה אינה שדה אחד. היא ערימה של שדות שמקורם בגופים שונים, ורק אחד מהם נועד להנחות אתכם מה לעשות הלאה. Stripe, שמתעדת את המבנה הזה בפומבי, מפרידה במפורש בין network_decline_code לבין network_advice_code, ומציינת שכל אחד מהם הוא קוד בן 2 עד 4 ספרות שמגיע מהבנק המנפיק ושמשמעותו תלויה ברשת הכרטיסים.
| השכבה | מי מייצר אותה | מה אפשר להסיק ממנה |
|---|---|---|
| קוד דחייה של הרשת | הבנק המנפיק, דרך רשת הכרטיסים | הסיבה הגולמית. תלוית-רשת, ולעיתים ריקה לגמרי |
| קוד הנחיה (MAC אצל מאסטרקארד) | הבנק המנפיק | מה מותר ומה אסור לעשות הלאה |
| קוד מנורמל של ספק הסליקה | הסולק או ספק הסליקה | שם קריא כמו insufficient_funds או expired_card |
| ההודעה שהוצגה ללקוח | הקוד שלכם | שום דבר. זו מחרוזת שנכתבה בממשק |
השורה האחרונה היא זו שמכשילה הכי הרבה בירורים. "העסקה נדחתה, נסו כרטיס אחר" הוא טקסט שכתבתם, ואין בו מידע על מה שקרה בפועל.
למה הקוד המספרי לבדו לא מספיק?
כי אותו מספר אינו אותו דבר בשתי רשתות שונות. התיעוד של Stripe מנסח את זה ישירות: המשמעות של קוד משתנה לפי הרשת, ולכן יש לקחת בחשבון את המותג של הכרטיס בעת פרשנות הקוד. משמע, קוד שהתקבל על כרטיס ויזה וקוד זהה שהתקבל על כרטיס מאסטרקארד אינם בהכרח אותה בעיה.
שתי מסקנות מעשיות נובעות מכך:
- טבלת מיפוי פנימית שמתרגמת מספר לטקסט בלי לקחת בחשבון את מותג הכרטיס תייצר אבחון שגוי חלק מהזמן.
- שדה הקוד עשוי לחזור ריק. Stripe מציינת שכאשר לא התקבל קוד תשובה מהרשת, השדה מוחזר כ-null. קוד ריק אינו "אין בעיה", אלא "אין מידע".
שלוש הקטגוריות שמכריעות מה קורה הלאה
הקוד השימושי ביותר בתשובה הוא קוד ההנחיה, כי הוא נוסח כדי לענות בדיוק על השאלה "ומה עכשיו". בשכבת התרגום של Stripe הוא מופיע כשדה advice_code עם שלושה ערכים מתועדים:
do_not_try_again- הכרטיס נדחה ואין להשתמש בו שוב לאותה עסקה. פנייה של הלקוח למנפיק היא המסלול היחיד.try_again_later- המנפיק דחה, אך ניסיון חוזר אפשרי. זו הקטגוריה היחידה שבה חיוב חוזר הוא צעד סביר.confirm_card_data- הדחייה נובעת מפרט שגוי שנשלח. לא מנסים שוב את אותם נתונים, אלא מבקשים מהלקוח לאמת את הכרטיס.
שימו לב מה קורה כאן: שתיים מתוך שלוש הקטגוריות אומרות במפורש שחיוב חוזר עם אותם נתונים לא ייתן תוצאה אחרת. זו בדיוק הסיבה שמערכת שמנסה שוב אוטומטית אחרי כל דחייה עובדת נגד עצמה.
מה לבדוק לפני שמחייבים שוב את אותו כרטיס?
- מה קוד ההנחיה שהתקבל, ולא רק קוד הדחייה. אם אין קוד הנחיה, התייחסו לדחייה כאל סופית עד שיוכח אחרת.
- האם הדחייה נובעת מנתון שנשלח שגוי - מספר, תוקף או CVV. במקרה כזה תיקון הנתון הוא הפעולה, לא ניסיון נוסף.
- האם כבר יש חיוב מוצלח באותו סכום ובאותו כרטיס בדקות האחרונות. Stripe מגדירה
duplicate_transactionבדיוק לתרחיש הזה, וההנחיה שלה היא לבדוק אם התשלום כבר קיים. - כמה ניסיונות כבר בוצעו על אותה עסקה, ומתי. בלי מונה מתמשך אין דרך לדעת.
- האם הלקוח נוכח בתהליך. ללקוח שנמצא בקופה אפשר להציג שגיאה ולבקש אמצעי אחר; לחיוב שרץ ברקע אין את האפשרות הזו.
- האם הדחייה מרוכזת בקבוצה שלמה של לקוחות באותה חלון זמן. דפוס כזה מצביע על תקלה בצד הסולק, לא על כרטיסים.
- האם העסקה דורשת אימות 3D Secure שלא בוצע. במקרה כזה הפתרון הוא להריץ את זרימת האימות, לא לחזור על החיוב.
- מה קובע ההסכם מול הסולק שלכם בנוגע לניסיונות חוזרים, ואיזה חיוב נלווה לכל ניסיון.
איפה עובר הגבול של ניסיון חוזר
רשתות הכרטיסים מגבילות את מספר הפעמים שאפשר להגיש מחדש עסקה שנדחתה, והחריגה מהמגבלה נושאת השלכות מסחריות. גם Stripe מציינת בתיעוד שלה שהרשתות מגבילות את מספר הניסיונות החוזרים על חיוב יחיד, ושניסיונות עודפים עלולים להיראות למנפיקים כהתנהגות חשודה ולהעלות דווקא את שיעור הדחיות של עסקאות לגיטימיות.
הכללים המחייבים אתכם הם אלה של רשתות הכרטיסים ושל ההסכם מול הסולק, והם משתנים בין רשתות ובין סוגי דחייה. זהו תיאור טכני בלבד ואינו ייעוץ משפטי או חוזי - את מדיניות הניסיונות החוזרים יש לברר מול הסולק שלכם לפני שמממשים אותה בקוד.
מה שומרים בלוג כדי שהדחייה הבאה תיקח שתי דקות
- מזהה העסקה אצל ספק הסליקה, לא רק המזהה הפנימי שלכם.
- גוף התשובה המלא כפי שהתקבל, כולל כל שדות הקודים - גם אלה שאתם לא מפרשים היום.
- מותג הכרטיס וארבע הספרות האחרונות, כדי שאפשר יהיה לקשור ניסיונות זה לזה.
- חותמת זמן מדויקת ומספר הניסיון בסדרה.
- האם הלקוח היה נוכח, ומאיזו זרימה הגיע החיוב.
בלי ארבעת הראשונים, כל בירור מול הסולק מתחיל בשאלה שאין לכם עליה תשובה. ההבדל בין עסק שמברר דחייה בשתי דקות לבין עסק שמוותר עליה הוא כמעט תמיד ההחלטה אם לשמור את גוף התשובה או רק את המילה "נכשל".
איך זה נראה כשמיישמים את זה נכון
זרימת חיוב שמטפלת נכון בדחיות אינה מורכבת יותר, היא פשוט מפרידה בין שלוש החלטות שנוטים לערבב: מה קרה, מה מציגים ללקוח, ומה עושים אחר כך.
- שכבת האבחון קוראת את התשובה, שומרת אותה כפי שהיא, ומסווגת אותה לאחת משלוש הקטגוריות. זו השכבה היחידה שמכירה קודים.
- שכבת התצוגה מקבלת קטגוריה, לא קוד, ומחליטה מה לומר ללקוח. כך אפשר לשנות ניסוח בלי לגעת בלוגיקה.
- שכבת ההחלטה קובעת אם ומתי יבוצע ניסיון נוסף, על סמך הקטגוריה, מונה הניסיונות והמדיניות שסוכמה מול הסולק.
הפרדה כזו מונעת את התקלה הנפוצה ביותר בקוד תשלומים: תנאי אחד ארוך שמערבב הודעה ללקוח, החלטה על ניסיון חוזר ופרשנות של קוד, ושאף אחד לא מעז לגעת בו אחרי חצי שנה.
קשור: טיפול בקודי דחייה של טרנזילה וקארדקום, השוואת ספקי סליקה בישראל, אוטומציה של חשבוניות ותזכורות תשלום.
מקורות
שאלות נפוצות
למה ההודעה שהלקוח ראה לא זהה לסיבת הדחייה?
ההודעה במסך היא טקסט שנכתב בממשק שלכם, ולעיתים קרובות במכוון אינה חושפת את הסיבה. במקרים של חשד להונאה או כרטיס שדווח אבוד, ספקי סליקה ממליצים במפורש להציג הודעה גנרית ולא את הסיבה האמיתית, ולכן הסיבה קיימת רק בלוג.
קיבלתי קוד דחייה ריק. מה זה אומר?
שלא התקבל קוד תשובה מהרשת עבור אותה עסקה. זה לא אומר שהעסקה תקינה ולא שהיא נדחתה מסיבה ידועה - פשוט אין מידע. במצב כזה יש להסתמך על סטטוס העסקה אצל ספק הסליקה ולא לנסות לפרש את השדה הריק.
אפשר פשוט לנסות שוב אוטומטית אחרי כל דחייה?
לא. חלק ניכר מהדחיות מסומנות במפורש כדחיות שאין לנסות אחריהן שוב עם אותם נתונים, וניסיון חוזר במקרים האלה מבזבז ניסיונות מותרים וגם עלול להיראות חשוד. מדיניות ניסיונות חוזרים צריכה להיגזר מקוד ההנחיה ומההסכם מול הסולק.
איך מבדילים בין בעיה בכרטיס לבין תקלה אצל הספק?
לפי הפיזור. דחייה שמופיעה על כרטיס אחד היא כמעט תמיד עניין של המנפיק. עלייה חדה בדחיות על פני לקוחות רבים, בחלון זמן קצר ובקודים דומים, מצביעה על תקלה בצד הסולק או בהגדרות המסוף - ובמקרה כזה חיוב חוזר רק מגדיל את הנזק.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.