כדי לאפשר למשתמשים לבצע צ'ק-אאוט, צריך להטמיע את השילוב של תהליך התשלום המובנה. התהליך כולל יצירה של API בארכיטקטורת REST שמאפשר ל-Google לנהל באופן פרוגרמטי את תהליך התשלום באמצעות השרתים שלכם. השיטה הזו מספקת את חוויית המשתמש החלקה ביותר. בשלב הראשון, Google תציג את ממשק המשתמש לקונה, ובעתיד היא תתמוך בחוויות נוספות שמבוססות על סוכנים.
תהליך התשלום
האינטגרציה המקורית מחייבת אתכם ליצור API בארכיטקטורת REST ש-Google יכולה להפעיל כדי ליצור ולנהל סשנים של מעבר לתשלום.
התהליך הכללי הוא כזה:
- יצירת סשן של מעבר לתשלום: המשתמש, ואופציונלית סוכן, נמצאים בלולאה שבה הם מוסיפים פריטים לסשן.
- העברה לממשק משתמש של Google: אחרי שהמשתמש מחליט לבצע צ'ק-אאוט, הסוכן (אם הוא פעיל) מעביר את השליטה לממשק משתמש של Google (כולל נתוני סשן הצ'ק-אאוט)
- תהליך תשלום ידני: המשתמש מקיים אינטראקציה רק עם ממשק המשתמש של Google כדי למלא פרטים רגישים לגבי אספקת המוצר והתשלום ולשלוח את ההזמנה. הסוכן לא מעורב בחלק הזה, כדי להבטיח דטרמיניזם.
- השלמה והחזרה: בממשק המשתמש של Google מוצג הדף 'תודה' לאישור ההזמנה. אפשרות נוספת היא להפנות את המשתמש בחזרה לסוכן, שאולי כבר קיבל הודעה על השלמת הרכישה.
מחזור החיים של סטטוס סשן התשלום
במהלך תהליך התשלום, אתם צריכים לעדכן את סשן התשלום status כדי לשקף את המצב הנוכחי שלו. הסשן עובר את מחזור החיים הבא:
-
incomplete: הסטטוס הראשוני כשסשן נוצר. ההתראה הזו מציינת שחסר מידע חובה (כמו שיטות משלוח, מיסים או פרטי משתמש) או שהמידע לא חושב. -
ready_for_payment: הסטטוס שבו צריך להשתמש אחרי שהמשתמש מעדכן את כתובת המשלוח שלו ואחרי שחישבתם את אפשרויות המשלוח ואת הסכומים הכוללים, אבל לפני שפרטי אמצעי התשלום סופיים. -
ready_for_complete: הסטטוס שבו משתמשים במהלך מילוי מלא של אובייקט של דף התשלום, אחרי שאמצעי התשלום נבחר וכל פרטי ההזמנה אומתו. -
completed: הסטטוס הסופי שמוחזר אחרי עיבוד התשלום וביצוע ההזמנה. -
canceled: הסטטוס שמוחזר אם סשן התשלום מבוטל. -
error: הסטטוס שמוחזר אם שגיאה בלתי הפיכה בלוגיקה העסקית מונעת את המעבר לתשלום. הסטטוס הזה זמין ב-UCP בגרסה2026-04-08ומעלה.
תהליך תשלום על כמה פריטים:
Google תומכת עכשיו במספר פריטים נפרדים בשורה בסשן תשלום יחיד. התהליך הכללי הוא כזה:
- המשתמש מתחיל את תהליך התשלום מממשק שמופעל בו UCP (למשל, על ידי לחיצה על 'קנייה עכשיו' במוצר).
- מתבצעת קריאה ל-
POST /checkout-sessions, כולל כל הפריטים הייחודיים במערךline_items. המערךline_itemsיכיל אובייקט נפרד לכל פריט ייחודי שנבדק. - המשתמש יכול לעדכן את אמצעי התשלום, את פרטי ההזמנה או להחיל הנחות באמצעות קריאות ל-
PUT /checkout-sessions/{id}. - כשמשתמש לוחץ על הלחצן 'תשלום באמצעות GPay', מתבצעת קריאה של
POST /checkout-sessions/{id}/complete.
אימות
פרטים על אבטחת נקודות הקצה של Native Checkout API, כולל שיטות אימות נתמכות כמו מפתחות API ו-OAuth 2.0, זמינים במדריך אימות ואבטחה.
כלים למפתחים
כדי לעזור לכם בהטמעה של Native Checkout API, תוכלו למצוא את המשאבים הבאים במאגר Universal Commerce Protocol GitHub:
- מאגר UCP ב-GitHub: אפשר לעיין במאגר הראשי כדי למצוא מסמכים מקיפים, מפרטים ומקורות מידע מהקהילה.
- ערכות SDK: אפשר להשתמש בערכות הכלים לפיתוח תוכנה כדי להאיץ את השילוב. יש ערכות SDK ספציפיות לשפות, כולל:
בדיקות התאמה: כדי לאמת את נקודות הקצה של ה-API בהתאם למפרט של UCP, משתמשים בחבילת בדיקות ההתאמה.
כך אפשר לוודא שההטמעה עומדת בסטנדרטים ובדרישות.
מומלץ מאוד להשתמש בכלים האלה כדי לייעל את תהליך הפיתוח והבדיקה.
יעדים למדידת רמת השירות (SLO)
היעדים הבאים למדידת רמת השירות (SLO) חלים על נקודות הקצה של Native Checkout REST API. עסקים שמבצעים שילוב עם Google צריכים לעמוד ביעדים האלה של ביצועים וזמינות של API.
| נקודת קצה | זמינות | זמן אחזור (האחוזון ה-50) | זמן אחזור (האחוזון ה-95) |
|---|---|---|---|
POST /checkout-sessions (יצירה) |
95% ומעלה | <= שנייה אחת | <= 4 שניות |
PUT /checkout-sessions/{id} (עדכון) |
95% ומעלה | <= שנייה אחת | <= 5 שניות |
POST /checkout-sessions/{id}/complete (הושלם) |
95% ומעלה | <= 6 שניות | <= 10 שניות |
החביון באחוזון ה-50 מציין שלפחות 50% מהבקשות צפויות להסתיים בתוך הזמן הזה. הערך של זמן האחזור באחוזון ה-95 מציין שלפחות 95% מהבקשות צפויות להסתיים בתוך הזמן הזה.
השלבים הבאים
אפשר לראות את מטען הנתונים (payload) של ה-API של דף התשלום ואת הפרטים הטכניים של ההטמעה בגרסה של UCP: