תוכנות תוכנה משולבת 3D Secure Integration
מדריך אינטגרציה 3D Secure
החל מיום 01.01.2021 על אימות דו-גורמי יושם כחובה חובה לכל עסקאות תשלום בכרטיסי מסחר אלקטרוני. על מנת לעמוד בחובה זו,
מפעילי רשתות כרטיסי אשראי ישתמשו בנוהל שנקרא 3D Secure. מבחינתך כסוחר חובה להיות מסוגל לבצע הליך זה עבור לקוחותיך מ
01.01.2021. בהמשך תמצאו תיאור של דרכי השילוב השונות וכיצד יש ליישם את הליך 3D Secure עבורם.
אנא בחר את שיטת האינטגרציה בה אתה משתמש
- האם אתה משתמש בטופס הקופה hCO?
- האם אתה משתמש בטופס הקופה hPF?
- האם אתה מעבד תשלומים ללא שימוש בטופס המסופק על ידי מערכת Unzer?
שימו לב: חשוב גם באיזו דרך נעשים חיובים או אישור מראש (הסתייגויות). גם אם אתה משתמש בטופס תשלום של Unzer GmbH לרישום נתוני הכרטיסים, התהליך 3D Secure יתבצע ללא טופס קופה כאשר נתוני הכרטיס יחויבו או יאושרו לראשונה. במקרה זה הדרך השלישית לשילוב ללא טופס המסופק על ידי Unzer חלה.
שימו לב גם:
אם אתה משתמש בתשלומים חוזרים (תשלומי מנוי), הקפד לקרוא את החלק "תשלום מאובטח ותמחור 3D".
הליך מאובטח בתלת-ממד בעת שימוש בטופס קופת hCO
טופס התשלום של hCO כבר מיועד להליך 3D Secure. אין צורך בפעולה נוספת מהצד שלך ליישום ההליך. עם זאת, אתה
עליך לוודא שהמערכת שלך יכולה להתמודד עם התשובות המתאימות של מערכת התשלומים שלנו במקרה שמתחיל תהליך 3D Secure. בתגובה האסינכרונית מה-
מערכת התשלומים לשרת שלך, תוצאת העסקה מועברת ויש להעריך אותה לפני החזרה URL מועבר למערכת התשלומים.
לשם כך יש להעריך את הפרמטרים הבאים.
- Processing.RETURN.CODE = 000.200.000
- PROCESSING.RETURN = עסקה + בהמתנה
- PROCESSING.RESULT = ACK
הסבר: סטטוס העסקה "בהמתנה", הפרמטר PROCESSING.RESULT
מייצג רק תוצאה ראשונית. כל עוד התהליך 3D Secure מתבצע, הסטטוס
להישאר בהמתנה.
התוצאה הסופית של העסקה היא אז
- Processing.RETURN.CODE = 000.000.000
- PROCESSING.RESULT = ACK
or - Processing.RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
- עיבוד. תוצאות = NOK
במקרה הראשון העסקה הושלמה בהצלחה, במקרה השני היא נכשלה בסך הכל. לסיבות האחרונות יכולות להיות סיבות שונות, כולל סירוב לאימות. אתה
קבל מידע מפורט יותר בפרמטרים "PROCESSING.RETURN" ו- "PROCESSING.RETURN.CODE".
אנו ממליצים לך לבצע בדיקה לשתי ההודעות. למידע נוסף על אופן ביצוע הבדיקה ובאילו פרטי כרטיס אשראי תוכלו להשתמש לבדיקה, אנא ראו להלן.
הליך 3D Secure בעת שימוש בטופס התשלום של hPF
טופס התשלום של hPF נועד גם להשתמש בהליך 3DS. אין צורך בפעולה נוספת מהצד שלך ליישום ההליך. כפי שתואר
לצורך הטמעת ה- hCO התגובה ממערכת התשלומים מתבצעת בשני שלבים ולכן המערכת שלך חייבת לבדוק את הערך של ה- PROCESSING.RETURN.CODE
פרמטר בעת עיבוד התגובה.
לשם כך יש להעריך את הפרמטרים הבאים.
- Processing.RETURN.CODE = 000.200.000
- PROCESSING.RETURN = עסקה + בהמתנה
- PROCESSING.RESULT = ACK
הסבר: סטטוס העסקה "בהמתנה", הפרמטר PROCESSING.RESULT מייצג רק תוצאה ראשונית. כל עוד התהליך 3D Secure מתבצע, הסטטוס
להישאר בהמתנה.
התוצאה הסופית של העסקה היא אז
- Processing.RETURN.CODE = 000.000.000
- PROCESSING.RESULT = ACK
or - Processing.RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
- עיבוד. תוצאות = NOK
במקרה הראשון העסקה הושלמה בהצלחה, במקרה השני היא נכשלה בסך הכל. לסיבות האחרונות יכולות להיות סיבות שונות, כולל סירוב לאימות. אתה
קבל מידע מפורט יותר בפרמטרים "PROCESSING.RETURN" ו- "PROCESSING.RETURN.CODE".
אנו ממליצים לך לבצע בדיקה לשתי ההודעות. למידע נוסף על אופן ביצוע הבדיקה ובאילו פרטי כרטיס אשראי תוכלו להשתמש לבדיקה, אנא ראו להלן.
הליך 3D Secure עם חיבור ישיר
אם אינך משתמש בטופס תשלום המסופק על ידי Unzer (לשעבר היידלפיי) לצורך עיבוד תשלומי כרטיסי אשראי, או אם אתה פשוט רושם כרטיס באמצעות אחד מהטפסים ומעבד את האישור (ההזמנה) מראש או את החיוב כהפניה לרישום תקשורת ישירה עם מערכת התשלומים, עליך ליישם את התהליך 3D Secure.
זרימת עסקה אסינכרונית:
זהו תהליך אסינכרוני בו השרת שלך מקבל העברה URL (הפניה מחדש URLממערכת התשלומים שלנו. על השרת שלך להעביר את הלקוח לכך URL כדי שהוא יוכל לבצע את האימות באמצעות הליך 3D Secure. התוצאה של אימות 3D Secure זה מדווחת ישירות ל- Unzer על ידי הבנק המנפיק את הכרטיס.
לאחר אימות מוצלח, העסקה עוברת עיבוד נוסף במערכת Unzer באופן שאתה כבר מכיר על ידי שליחת התוצאה הכוללת של המערכת שלך בסוף, עליה אתה משיב
עם הפניה מחדש URL. מערכת התשלומים תפנה את הלקוח בחזרה למערכת שלך באמצעות הפניה זו URL ממערכת
שימו לב: בתהליך עבודה זה המערכת שלכם מקבל שתי תשובות ממערכת התשלומים:
- אחד עם הסטטוס "בהמתנה" (PROCESSING.RETURN.CODE = 000.200.000 ו- PROCESSING.RETURN = עסקה + בהמתנה) והפרמטרים להפניה מחדש לבנק המנפיק את הכרטיס של הלקוח
- אחת עם התוצאה הסופית של החיוב או ההזמנה. יש גם שני הפניות מחדש URLהמוזכרים בתהליך זה, מערכת ממערכת התשלומים אליה יש לנתב את הלקוח כדי לאמת בבנק המנפיק את הכרטיס שלו ואחד ממערכתך, בעת קבלת התוצאה הסופית, כדי להפנות את הלקוח חזרה למערכת שלך.
השינויים הבאים יבוצעו בנוהל הרגיל. לידיעתך, בשל הטמעת שיטות תשלום אסינכרוניות אחרות, כגון Paypal, חלקן
תהליכים עשויים כבר להתקיים ביישום שלך.
- תְגוּבָה URL
בשיחה הראשונה (מספר 2 בתרשים) למערכת התשלומים, "תגובה URL"חייבים לעבור בקבוצת החזית.
שימו לב: הפרמטר IDENTIFICATION.REFERENCEID רלוונטי רק אם אתה מתייחס לרישום או לעסקה אחרת שכבר קיימת - הפניית עיבוד מחדש URL אם נדרש אימות, הפניה מחדש URL ופרמטרים אחרים בקבוצת ההפניות מועברים בתגובה ממערכת התשלומים (מספר 5 בתרשים).
- העברת הלקוח להפניה מחדש URL
אם קבוצת ההפניות מגיבה באמצעות הפניה מחדש URL, יש להפנות אליו את דפדפן הלקוח URL (מס' 6 בתרשים) לביצוע אימות. יש להעביר את הפרמטרים הנוספים מקבוצת ההפניה אל החיצוני webאתר כפרמטרי POST.
שימו לב: פרמטרים נוספים מוחזרים בקבוצת "PROCESSING.REDIRECT.xxx" רק עם 3D Secure Version 1 (גם שם המספר והשיום עשויים להשתנות), ואילו ב- 3D Version 2 רק PROCESSING.REDIRECT.URL כמוצג להלן מוחזר: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run המשמעות היא שללא קשר לסוג ומספר הפרמטרים, על דפדפן הלקוח להפנות מחדש ל- PROCESSING.REDIRECT.URL.
להלן תמצא קוד פשוט למשלampכיצד ניתן לבצע הפניה מחדש כזו. ה חלק נועד ליידע לקוחות קצה שהמערכות שלהם אינן תומכות ב-Javascript או שהן מושבתות. אנו ממליצים בחום שההפניה מחדש תתבצע בתוך חלון הדפדפן הפעיל של הלקוח ולא להשתמש בחלונות קופצים או חלונות דפדפן חדשים, שכן הדבר עלול
לעצבן את הלקוחות ולהוביל אותם לסגור את הדף אליו הם מופנים.
- בדיקת תוצאה אסינכרונית
תוצאת האימות נשלחת בצורה לא סינכרונית לשרת שלך. מערכת התשלומים מצפה לתוקף URL כתגובה. (מס '12 & 13 בתרשים). להצלחה או לדחייה
תשלומים, שונה URL ניתן להגיב כאן על ידי המערכת שלך. - נתיב החזרה של הלקוח
מערכת התשלומים מפנה את הלקוח אל ה- URL מסופק על ידי מערכת הסוחר לאחר השלמת תהליך האימות ועסקת התשלום.
שימו לב: שלבים 4.) ו- 5.) ממשיכים בדיוק באותו אופן כפי שכבר מכירים בעסקאות NONE 3D Secure קיימות.
תשלום מאובטח וחוזר בתלת ממד
החל מה -1 בינואר 2021, 3D Secure יהיה חובה לכל עסקאות כרטיסי מסחר אלקטרוני. עם זאת, מכיוון שזה בקושי חל על תשלומים חוזרים, הבנקאות
למערכות יש זרימת עבודה נפרדת לכך.
לצורך כך הבנקים מבחינים בין
- CIT = עסקאות שאותחלו הלקוח
- MIT = עסקאות שאותחמו סוחר
יש לאמת את העסקה הראשונה של כרטיס בחשבון הסוחר שלך באמצעות 3D Secure החל מה- 01.01.2021 ואילך. אימות מוצלח שכזה הוא חובה חובה ב-
כדי להיות מסוגל לאחר מכן להגיש הזמנות נוספות על אותו כרטיס ללא 3D Secure. לכן יש להעביר את הלקוח לבנק המנפיק את הכרטיס לצורך החיוב הראשון
בהתאם לנוהל המתואר לעיל ולאמת את עצמו שם כבעל הכרטיס. אם לא מתוכנן חיוב בזמן ההזמנה, למשלampעקב תקופת ניסיון, יש לבצע הזמנה (אישור מראש) של לפחות יורו אחד עם 3D Secure בנוכחות הלקוח במקום זאת. אין צורך ללכוד הזמנה זו.
עם זאת, עבור לקוחות קיימים אין צורך להמציא אימות 3D Secure. אם החיוב המוצלח הראשון התקיים לפני 01.01.2021, ניתן להניח כי גם שיא הלקוח
אומתו בהצלחה. לעומת זאת, עבור לקוחות חדשים החל מיום 01.01.2021, אימות 3D Secure הוא חובה עבור החיוב או ההזמנה הראשונה (אישור מראש).
שימו לב: מבחינה זו, המערכת הבנקאית בוחנת את נתוני הכרטיסים, לא את נתוני הלקוחות. אז אם לקוח קיים משתמש בכרטיס חדש לאחר 01.01.2021, למשלample כי הקודם
תוקף אחד פג או בגלל שהוא החליף את הבנק שמנפיק את הכרטיסים שלו, זהו מחזור חדש שחוזר על עצמו מהנקודה של הבנקים view וחייב להיות מאומת עם 3D Secure עבור ההזמנה הראשונה.
לאחר ביצוע אימות ראשוני זה בהצלחה, כל העסקאות הנוספות פטורות מחובת השימוש ב- 3D Secure. התנאים המשתלמים לתשלום חוזר ללא 3D Secure הם לפיכך:
- יש לפחות חיוב או הזמנה מוצלחים (אישור מראש) שבוצעו באמצעות 3D Secure או שהתקיימו לפני 01.01.2021.
- זה מתייחס לרישום וחיוב קיימים עם הגשתו
כדי ליידע את מערכת התשלומים, שמדובר בתשלום חוזר, יש לשלוח גם את הפרמטר RECURRENCE.MODE = REPEATED. זה מאותת למערכת כי א
יש לדווח על תשלום חוזר למערכות הבנקאות.
שימו לב: אם נכנס הפרמטר RECURRENCE.MODE = REPEATED כאשר כרטיס חדש נטען בפעם הראשונה, העברת 3D Secure תתבצע למרות פרמטר זה.
בדיקת יישום 3D Secure
אתה יכול לבדוק את חיבור 3D Secure בכל עת דרך מערכת התשלומים שלנו. כדי לעשות זאת, השתמש במצב "CONNECTOR_TEST" עבור עסקה, כפי שמוצג בדוגמהampלס למעלה.
נתוני חיבור לבדיקה זו:
| אבטחה | 31HA07BC8142C5A171745D00AD63D182 |
| כניסת משתמש | 31ha07bc8142c5a171744e5aef11ffd3 |
| USER.PWD | 93167DE7 |
| TRANSACTION.CHANNEL | 31HA07BC8142C5A171749A60D979B6E4 |
| מטבעות שהוגדרו לגרסה תלת ממדית 3 | EUR, USD, SEK |
| מטבעות שהוגדרו לגרסה תלת ממדית 3 | GBP, CZK, CHF |
נקודת הקצה של שער המערכת היא או
שער SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - מקודדת לטינית -15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - מקודד UTF-8
שער NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
נתוני כרטיסי אשראי לבדיקה זו:
| מותגים | מספרי כרטיסים | CVV | תאריך תפוגה | פֶּתֶק |
| מאסטרקארד | 5453010000059543 | 123 | תאריך עתידי | תלת ממד - סיסמה: סודי 3 |
| וִיזָה | 4711100000000000 | 123 | תאריך עתידי | 3DS - סיסמה: סודי! 33 |
שימו לב: עבור 3D Secure גרסה 2, אינכם צריכים להזין סיסמה, אלא פשוט לחצו על הקישור "לחץ כאן להשלמת האימות.
הדרך היחידה לדמות שגיאה עם 3D Secure Version 2 היא לתת לדף עם הקישור זמן קצוב (כ- 18 דקות).
קרא עוד על מדריך זה והורד PDF:
מסמכים / משאבים
 |
מדריך תוכנות 3D Secure Integration [pdfתיעוד Unzer, מדריך אינטגרציה, 3D Secure |
