מבוא לתשלומים סטנדרטיים של Google לספקים

בעולם של Google Standard Payments, חיוב על ידי ספק נחשב לאמצעי תשלום (FOP) שעבר המרה לאסימונים. כלומר, Google והכלי לשילוב תשלומים מבצעים החלפה חד-פעמית של פרטי כניסה לזהות החשבון כדי ליצור אסימון. בהמשך, האסימון הזה מוצג חזרה לשילוב התשלומים כדי לזהות את החשבון לחיוב.

אמצעי תשלום אחרים משתמשים גם באסימון, לכן יש לנו סקירה כללית על אמצעי תשלום שעברו הצפנה באמצעות אסימון (טוקניזציה). המידע הזה רלוונטי בעיקר לחיוב על ידי ספק. השלבים Authentication, Association, Purchase ו-Remittance מפורטים בפירוט בסקירה הכללית הזו. בדף זה ניתן לקרוא פרטים נוספים על חיוב על ידי ספק.

הספקים שהצטרפו ל-Google Standard Payments מטמיעים את ממשקי ה-API שמרכיבים את התהליכים הבאים:

זרימה התיאור שווה ערך למפרט DCB3
אימות מזהה ומאמת את חשבון המשתמש במערכת של משלב התשלומים שישמש לביצוע תשלומי DCB SMS-MO עם GoogleUserToken
שיוך ממיר אסימון לטווח ארוך, ש-Google והכלי לשילוב תשלומים מסכימים לשימוש בו כדי לבצע תשלומים באמצעות החשבון של המשתמש לשלב תשלומים אישור קריאה חוזרת (callback) של משתמש באמצעות OperatorUserToken ו-GetResourceing()
FundsTransfer מעביר כספים באופן סינכרוני מחשבון משלב התשלומים של המשתמש. מעבירה את החבות למשלב התשלומים שורות Auth() ו-CHARGE בקובצי בקשות באצווה
החזר כספי מחזירה באופן סינכרוני חלק מהכספים או את כולם המשויכים ל-FundsTransfer קודם לחשבון שילוב התשלומים של המשתמש. העברת החבות ל-Google שורות להחזר כספי בקובצי בקשות באצווה
העברת כספים הסדרת חשבון מבוססת-API, עדיף על בסיס יומי קובץ PDF של החשבונית החודשית, קובץ פרטי החשבונית החודשית, קובץ שחזור יומי
UpdateAssociatedAccount מידע ל-Google על שינויים בחשבון של משתמש מסוג 'משלב תשלומים' (למשל, מגבלות על טרנזקציות או סטטוס הקצאה) סקר של Getהקצאותing()
הונאה מודיע ל-Google על עסקאות שבוטלו עקב מחלוקת של משתמש. הפעולה הזו משמשת לשיפור מנגנון הסיכונים של Google, אבל היא לא משפיעה על החבות הכספית ללא

השוואה כוללת למפרט של DCB3

המפרט של Google Standard Payments פותר את אותן בעיות שאפשר לפתור בעזרת המפרט של DCB3. עם זאת, נעשה בה שימוש בטכנולוגיות ובעיצובי API שונים לשיפור הפתרון. הנה בקצרה ההבדלים העיקריים:

השוואת טכנולוגיות בסטאק

כל התקשורת ב-API מתבצעת באמצעות בקשות HTTPS POST עם הצפנת PGP ו-JSON חתום. כלומר, ל-Google ולכלי שילוב התשלומים יש רק מפתח PGP אחד לסבב. גם בטכנולוגיות האלה יש תמיכה טובה יותר ב-SOAP. כאן ניתן למצוא פרטים נוספים על סטאק התקשורת.

השוואה לפילוסופיה של API

חיוב ישיר על ידי ספק מסתמך על קבצים כדי להתאים את מצב התשלום. אין קבצים ב-Google Standard Payments. יש לבצע ניסיון חוזר בקריאות ל-API באופן אוטומטי וללא הגבלת זמן, עד שייקבע המצב הסופי.

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

תכונות חדשות

התשלומים הרגילים של Google תומכים בתכונות חדשות, כולל:

  • Fraud API נועד לעדכן את מנגנון הסיכון של Google מפני נוכלים
  • לעדכן את Associated Account API כדי ליידע את Google לגבי ניהול ההקצאות, המגבלות על הטרנזקציות ושינויים בסטטוס החשבון
  • תמיכה נוספת באתגר האימות במהלך רכישות, כמו קודי אימות של USSD
  • מחזור תשלום יומי

חיוב ישיר על ידי ספק ל-Google על מפת המינוחים הסטנדרטיים של Google לתשלומים

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

  • ספק -> משלב תשלומים

אזהרה: כדי למנוע בלבול עם הקונספט של מבצע השילוב של חיוב ישיר על ידי ספק, המסמך הזה מנסה להשתמש ב "משלב תשלומים" וב "משלב חיוב ישיר על ידי ספק" במקום רק ב"כלי שילוב". עם זאת, בתיעוד הכללי של Google Standard Payments נעשה שימוש ב'משלב' באופן חופשי כקיצור של 'משלב תשלומים'

  • מזהה הסכם חיוב -> מספר חשבון של משלב תשלומים
  • OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
  • correlation_id -> requestId
  • חלוקת הכנסות -> עמלה

תהליך האימות

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

פרטים ספציפיים לגבי חיוב על ידי ספק

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

משלבים של תשלומים יכולים לעבוד עם Google כדי לבחור את מנגנוני האימות המתאימים ביותר למוצר שלהם.

השוואה ל-DCB3

תהליך האימות מחליף את הקריאה החוזרת (callback) של approveuser ב-Google מחוץ למפרט DCB3.

ב-DCB3, האימות והשיוך שולבו בתהליך אחד. ב-Google Standard Payments, האימות נפרד משיוך החשבון.

תהליך השיוך

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

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

אם שילוב התשלומים משיב שהוא רוצה אתגר נוסף של משתמש, הוכחת האימות תהיה כל הוכחת זהות שנוצרה על ידי מנגנון האימות המסוים שבו Google השתמשה באתגר הנוסף. לדוגמה, הוכחת האימות שנוצרת על ידי מנגנון ה-SMS-MT OTP היא requestId של method sendOtp וגם ה-OTP עצמו.

מאפייני הכלי

בקטע בסקירה הכללית של אמצעי התשלום שעברו הצפנה באמצעות אסימון (טוקניזציה) נדון במושגים של accountAlias, accountNickname ו-fullAccountNickname.

פרטים ספציפיים לגבי חיוב על ידי ספק

  • accountAlias צריך להיות מספר הטלפון של המשתמש. נשתמש בתמונה כדי לזהות את הכלי במקרה שהמשתמש יתקשר לתמיכה של Google בקשר לחשבון שלו.
  • accountNickname ו-fullAccountNickname הם שמות מוצגים שמשמשים לזיהוי הכלי בממשק המשתמש.

השוואה למפרט של DCB3

תהליך השיוך מחליף את הרכיבים הבאים במפרט של DCB3:

  • קריאה ל-SOAP בנוגע להקצאת הרשאות ידנית
  • קריאת SOAP של GetSubscriberAddress
  • נוצר על ידי ספק

הבדל גדול כאן הוא העובדה ש-Google יוצרת את אסימון Google Payment (GPT) במהלך תהליך השיוך, במקום על ידי הספק שיוצר אותו.

חשוב גם לציין שבניגוד ל-DCB3 שבו יציאות OUT מופקות לערך מסוים של BillingConsentId, ה-GPT לא משויך ל-PaymentIntegratorAccountID מסוים.

תהליך הרענון של האסימון

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

פרטים ספציפיים לגבי חיוב על ידי ספק

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

תהליך עדכון החשבון

תהליך עדכון החשבון מאפשר לשילוב התשלומים להודיע ל-Google על עדכונים בחשבון השילוב של המשתמש. השדות האלה סופקו במקור ל-Google במהלך תהליך השיוך. הנה כמה דוגמאות לנתוני חשבון שייתכן שמשלב התשלומים ירצה לעדכן:

  • מגבלות העסקאות החודשיות, היומיות והמוגדרות לכל פריט של המשתמש
  • סטטוס ההקצאה של חשבון מבצע השילוב של המשתמש
  • סוג החשבון של המשתמש לשילוב מוצרי Google (תשלום מראש, תשלום לאחר השימוש, ארגון וכו')
  • שם המשתמש 'accountAlias', 'accountNickname' או 'fullAccountNickname'
  • האם המשתמש הגדיר, הסיר או שינה קוד אימות סטטי ששותף מראש
  • האם המשתמש סגר את החשבון או שינה את מספר הטלפון שלו - ביטול התוקף של כלי המשתמש במערכת של Google.
  • מחיקת תהליך האסימון

השוואה למפרט של DCB3

תהליך עדכון החשבון מחליף את הרכיבים הבאים במפרט של DCB3:

  • דגימה של קריאה ל-GetProvideing SOAP
  • ביטול תוקף של אסימון תקופתי

תהליך הרכישה

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

פרטים ספציפיים לגבי חיוב על ידי ספק

ספקים מסוימים משתמשים ב-USSD או בטכנולוגיה אחרת כדי לאסוף קוד אימות מהמשתמשים שלהם במהלך כל רכישה. במקרה של ספקים כאלה, במקום להפעיל את Capture() , אנחנו קוראים ל-syncCapture() ולהמתין 30 שניות לספק בקשה להזין את קוד האימות שלו ולסיים את ההקלטה. כשנקבעת המצב הסופי של התשלום, הספק מודיע ל-Google על התוצאה באמצעות קריאה ל-captureResultNotification().

השוואה למפרט של DCB3

יש כאן שינויים משמעותיים.

  • קריאה לשיטה יחידה סינכרונית -- capture() במקום auth() + קובץ אצווה
  • אין קובצי אצווה בכלל
  • ללא שיטת Cancel() (צילום + החזר כספי במקום auth + cancel)
  • לא התקבל שדה user_message – קודי הדחייה ממופים להודעות בבעלות Google שמותאמות לשפת החשבון של המשתמש.
  • שינויים במינוחים העיקריים:
    • CorrelationId -> requestId
    • BillingConsentId -> paymentIntegratorAccountId
    • OperatorUserToken -> googlePaymentToken

תהליך רכישה בעייתי

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

תהליך ההחזר הכספי

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

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

פרטים ספציפיים לגבי חיוב על ידי ספק

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

השוואה למפרט של DCB3

ההחזרים הכספיים מופעלים על ידי קריאה סינכרונית ל-API במקום בקובץ. כמו כן, אפשר להגדיר כמה החזרים כספיים חלקיים על תשלום מקורי אחד במקום לחייב החזר כספי מלא.

תהליך העברת הכספים

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

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

פרטים ספציפיים לגבי חיוב על ידי ספק

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

  • revshareCategory
  • itemPrice
  • tax
  • חותמת זמן

אצל ספקים עם הסכם חלוקת הכנסות של 50/50 עם Google, העמלות המפורטות ב-remittanceStatementDetails נצברות לפי revshareCategory ולא מוצגות על בסיס כל אירוע.

השוואה למפרט של DCB3

תהליך ההעברה מחליף את המושגים הבאים במפרט של DCB3:

  • קובץ PDF של דוח חיובים חודשי/דוח תשלומים
  • קובץ CSV עם פרטי החשבונית החודשית
  • קובצי CSV יומיים לשימור

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

תהליך הדיווח על הונאות

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

פרטים ספציפיים לגבי חיוב על ידי ספק

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