תשלום במזומן

סקירה כללית

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

הוספת תשלום
1) המשתמש מוסיף אמצעי תשלום
בחירת מיקום לתשלום
2) אחר כך הם בוחרים איפה לשלם
הוראות תשלום
3) לבסוף, הם מקבלים הוראות תשלום

מושגים וטרמינולוגיה

סמלים כנסים

מילות המפתח "חייבים", "אסור", "REQUIRED", "הכול", "לא יהיה", "צריך", "אסור", "מומלץ", "MAY," ו'אופציונלי' במסמכים האלה, המערכת תפרש אותם כפי שמתואר ב-RFC 2119.

חותמות זמן

כל חותמות הזמן מיוצגות באלפיות שנייה החל מתחילת יוניקס (Unix epoch) (ב-1 בינואר 1970) לפי שעון UTC.

לדוגמה:

  • 23 באפריל 2019 20:23:25 לפי שעון גריניץ' (GMT) = 1556051005000 אלפיות השנייה
  • 16 באוגוסט 2018, 12:28:35 לפי שעון גריניץ' (GMT) = 1534422515000 אלפיות השנייה

סכומים

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

לדוגמה:

  • 1.23 דולר ארה"ב = 1230,000 מיקרו דולר ארה"ב
  • 0.01 דולר ארה"ב = 10,000 מיקרו דולר ארה"ב

האידמפוטנטיות

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

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

מידע נוסף על אידמפוטנטיות זמין במדריך המפורט הזה.

מבצע השילוב

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

אמצעי תשלום

אמצעי תשלום. זה כלי כללי יותר מכלי נגינה. Visa, Mastercard ו-PayPal הם אמצעי תשלום מסוג FOP.

מכשור

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

אסימון

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

תהליכי מפתח

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

  1. יצירת זרימה של מספרי אסמכתה.
  2. תהליך של מספר אסמכתה לתשלום.

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

התרשים הבא ממחיש כל אחד מהתהליכים האלה.

סקירה כללית על אמצעי תשלום במזומן

סקירה כללית ברמה גבוהה של אמצעי תשלום במזומן

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

יצירת מספר אסמכתה

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

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

יצירת זרימה של מספרי אסמכתה

מספר סימוכין ליצירת כסף

הנה רשימה של האובייקטים ומה הם מייצגים:

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

התהליך הזה מתחיל במשתמש שרוצה להשתמש באמצעי התשלום הזה במזומן.

  1. המשתמש ניגש לממשק המשתמש של Google ששולח בקשה למספר אסמכתה.
  2. ממשק המשתמש של Google שולח הודעה לשרת Google על כך שנדרש מספר סימוכין (getReferenceNumber).
  3. השרת של Google מבקש מהשרת לשילוב תשלומים ליצור מספר אסמכתה (generateReferenceNumber).
  4. השרת של שילוב התשלומים יוצר ושולח את מספר האסמכתה לשרת של Google.
  5. שרת Google יוצר הוראות תשלום יחד עם מספר האסמכתה. לאחר מכן הוא שולח את המידע הזה לממשק המשתמש של Google.
  6. ממשק המשתמש של Google שולח את ההוראות ואת מספר האסמכתה האלה למשתמש.

הערות לגבי מספרי אסמכתה

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

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

מספר הסימוכין של התשלום

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

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

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

לאחר התשלום, מספר האסמכתה והסכום ייכללו בהצהרת העברת הכספים שנשלחה ב-T+2 ימים.

הנה תרשים רצף שממחיש את התשלום של מספר אסמכתה.

תהליך עבודה עם מספר אסמכתה של תשלום

תהליך עבודה עם מספר אסמכתה של תשלום

האובייקטים בתרשים מייצגים את הדברים הבאים:

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

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

  1. המשתמש מגיע לחנות נוחות כדי לבצע תשלום.
  2. לאחר השלמת העסקה, נשלחת לחנות הנוחות הודעה על כך לשילוב התשלומים.
  3. נשלחת הודעת אימות לחנות הנוחות דרך השרת של שילוב התשלומים.
  4. חנות הנוחות מציינת שהעסקה בוצעה בהצלחה מבחינת המשתמש, והמוצרים יסופקו למשתמש בקרוב.
  5. השרת של שילוב התשלומים שולח הודעה לשרת של Google על כך שמספר האסמכתה שולם (referenceNumberPaidNotification). השלב הזה לא יכול לחסום את שלב 4.
  6. נשלחת מ-Google Server הודעת אישור לשרת של שילוב התשלומים.

ביטול מספר האסמכתה

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

אם תהליך התשלום כבר התחיל, לדוגמה, אם המשתמש הזין את מספר האסמכתה בקיוסק אבל עדיין לא שילם, מבצע השילוב צריך להחזיר קוד תגובה HTTP 423 עם ErrorResponse שמכיל את USER_ACTION_IN_PROGRESS.

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