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

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

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

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

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

הטמעה של MIT API

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

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

שלבי ההטמעה

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

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

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

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

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

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

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

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

הערות להטמעה

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

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