עסקאות שמתבצעות ביוזמת המוכר (MIT)

סקירה כללית על תמיכה ב-MIT

עסקאות שמתבצעות על ידי מוכר (MIT) הן עסקאות שעוברות עיבוד בלי שהמשתמש נמצא בסשן פעיל. העדכון הזה ב-API של Google Pay Online מספק שקיפות משופרת לסוגי העסקאות האלה, חוויית משתמש משופרת באמצעות ממשק משתמש ייעודי לפרטי החיוב, ורציפות טובה יותר של התשלומים.

תרחישי שימוש עיקריים

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

‫MIT API Implementation

‫MIT API הוא תוסף ל-API הקיים של LoadPaymentData . מפתחי שילובים צריכים לכלול בדיוק אובייקט *TransactionInfo אחד כדי לציין את כוונת החיוב. ‫Google מספקת 3 אפשרויות בהתאם לסוג העסקה שהמוכר יזם:

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

שלבי ההטמעה

  1. מסמכים: אפשר לגשת לאתר למפתחים במהלך תוכנית הגישה המוקדמת. שלושת ההגדרות החדשות של האובייקטים נמצאות בקטע Object Reference, ויש קישור ישיר אליהן ברשימה הקודמת.
  2. הטמעה: משתמשים באובייקט או באובייקטים הרלוונטיים *TransactionInfo למערכת בבקשת ה-API.
    • שימו לב: אפשר להעביר רק אובייקט אחד לכל בקשה ל-API. המוֹכר הוא זה שקובע באיזה אובייקט להשתמש וממלא את השדות.
  3. בדיקה: משתמשים בסביבת הבדיקה כדי לוודא שפרטי החיוב מוצגים בצורה נכונה בגיליון התשלומים.
  4. הפעלה: מתחילים שידור חי אחרי שהפרמטרים מאומתים.

ניהול מחזור החיים של טוקנים (TLM)

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

אירועים מרכזיים של טוקנים

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

דרישות להגדרת השרת

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

דרישה תיאור
נקודת קצה (endpoint) נקודת קצה (endpoint) מאובטחת של HTTPS לקבלת קריאות POST.
אימות חייב לטפל באימות החתימה ובפענוח ההודעה.
תשובה מחזירים SUCCESS כדי להמשיך לשלוח התראות, או TOKEN_NOT_FOUND/TOKEN_NOT_IN_USE כדי להפסיק אותן.
התראה למוֹכרים ספקי שירותי התשלום צריכים להעביר למוֹכרים שלהם את סטטוס הטוקן.

הערות לגבי הטמעה

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

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