הוספת תמיכה ב-3DS1 וב-3DS2

3DS1 ו-3DS2 זמינים לשילוב מקצה לקצה של ההזמנות במרכז הפעולות. אתם יכולים להטמיע אחת מהאפשרויות האלה (או את שתיהן) בשילוב עם השילוב.

3DS1 או 3DS2 יעמדו בדרישה לאימות לקוחות חזק של PSD2, אבל יש כמה הבדלים עיקריים:

• 3DS1: אפשר להפעיל את 3DS1 לביצוע עסקה כשיש אותות שמצביעים על כך שהחיוב בוצע בתרמית.
  • כדי להטמיע את 3DS1, צריך לבצע שינויים בשרת ההזמנות.
• 3DS2: 3DS2 ישמש רק לעסקאות שחלה עליהן PSD2 (הבנק המקבל והבנק של הלקוח נמצאים ב-EEA).
  • כדי להטמיע את 3DS2, צריך לבצע שינויים בפיד המוכרים.

הטמעת 3DS2

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

שינויים בפיד של Merchant Center

• merchant_of_record_name: שם המוכר הנוכחי (MOR). השם הגלוי למשתמש יוצג באתגרים של 3DS2.
• payment_country_code: המדינה שבה הטרנזקציה תעובד, בפורמט ISO 3166-1 alpha-2.
• הודעה CardNetworkParameters: ההודעה הזו חוזרת על עצמה עם ערכים ספציפיים לרשתות שונות (נדרש רק ל-Visa ול-American Express)
  • card_network: הרשת (Visa, American Express) שהערכים האלה חלים עליה
  • acquirer_bin: מספר זיהוי הבנק של הבנק המקבל המשמש לעיבוד הכרטיס.
  • acquirer_merchant_id: מזהה המוכר שהוקצה למוכר על ידי הרוכש לצורך שימוש באישור עסקאות (לעסקאות ב-Visa וב-American Express).

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

הטמעת 3DS1

שינויים בשרת ההזמנות

אנחנו נשלח בקשה של CreateBooking, ואם יוחלט ש-3DS1 נדרש לביצוע העסקה, נחזיר Booking Failure משיטת הבידינג CreateBooking שבה השתמשת, ומציינים שהסיבה לכך היא PAYMENT_REQUIRES_3DS1. במקרה של תגובה לכשל, יהיה עליך לציין גם את ההודעה ThreeDS1Parameters בתוך ההודעה PaymentFailureInformation:

• acs_url = כתובת ה-URL שממנה יש לטעון טופס ולהציג אותו למשתמש לצורך אימות.
• pa_req = בקשת PaymentAuthentication. יש לפרסם אותו בטופס של ACSUrl.
• transaction_id = מזהה המשמש את ספק ה-ACS. יש לפרסם אותו בטופס של ACSUrl.
• md_merchant_data = נתונים לגבי שיתוף של מרכז הפעולות עם ספק ה-ACS, אם סיפקתם נתונים.

לאחר מכן נשלח מחדש את הבקשה המקורית, CreateBooking , עם המספר pa_response שמופיע בהודעה PaymentInformation. השדה pa_response יכיל את המטען הייעודי (payload) שמוחזר אלינו מספק ACS, ועליך להשתמש בו כדי לאשר את העסקה עם מעבד המידע שלך.

הנה תרשים שמתאר את זרימת 3DS1: