סקירה כללית

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

TBD: תוכלו לראות הדגמה של תהליך השימוש בארנק האלקטרוני אחרי שתוסיפו את FoP לישויות של Google.

התהליכים העיקריים של Google Standard Payments שמעורבים בעסקה בארנק אלקטרוני מתוארים בהמשך.

תהליך השיוך

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

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

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

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

הפלט של תהליך האימות הוא הוכחה לאימות.

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

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

תהליך השיוך

הערות בתרשים הזה:

  • בשלבים 1 ו-3, חשוב לשים לב שזהות המשתמש (אימייל) שונה בין Google לבין InvisiCash. sf@gmail.com ו-sally@otheremail.com בהתאמה. המצב הזה תקין וצפוי.
  • בין השלבים 3 ו-4, אפליקציית InvisiCash (או ממשק המשתמש באינטרנט, אם האפליקציה לא מותקנת אצל המשתמש) יכולה לבצע את מה שנדרש לאימות המשתמש, כולל שיחה עם שרת InvisiCash.

תהליך רכישה

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

הדוגמה למטה ממשיכה אחרי שהמשתמש sf@gmail.com ביצע את השיוך ונוצר אמצעי. המשתמש רוצה כעת לרכוש מוצרים.

תהליך קנייה פשוט

מדי פעם, גם הכלי לשילוב תשלומים וגם Google עשויים לדרוש אימות מהמשתמשים לפני ביצוע הרכישה. יש לזה כמה סיבות. לדוגמה:

  • מנגנון הסיכונים של Google מזהה שתשלום נראה חשוד
  • לפי הדרישות הרגולטוריות, יש להזין OTP בכל רכישה

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

בדוגמה שלמטה, המשתמש sf@gmail.com ביצע את השיוך ונוצר אמצעי. בתהליך הרכישה, השרת של Google רוצה לאתגר את המשתמש הזה כדי להגן עליו מפני הונאה:

שלבי הקנייה
באתגר של משתמש

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

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

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

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

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

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

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

זוהי דוגמה לתהליך עבודה: העברת
תשלומים