סקירה כללית על תהליך תשלום מובנה

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

תהליך התשלום

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

התהליך הכללי הוא כזה:

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

מחזור החיים של סטטוס סשן התשלום

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

• ‫incomplete: הסטטוס הראשוני כשסשן נוצר. ההתראה הזו מציינת שחסר מידע חובה (כמו שיטות משלוח, מיסים או פרטי משתמש) או שהמידע לא מחושב.
• ‫ready_for_payment: הסטטוס שבו משתמשים אחרי שהמשתמש מעדכן את כתובת המשלוח שלו ואחרי שאתם מחשבים את אפשרויות המשלוח ואת הסכומים הכוללים, אבל לפני שהתשלום הסופי מתבצע.
• ‫ready_for_complete: הסטטוס שבו משתמשים במהלך אתחול מלא של אובייקט התשלום, אחרי שאמצעי התשלום נבחר וכל פרטי ההזמנה אומתו.
• ‫completed: הסטטוס הסופי שמוחזר אחרי עיבוד התשלום וביצוע ההזמנה.
• ‫canceled: הסטטוס שמוחזר אם סשן התשלום מבוטל.
• ‫error: הסטטוס שמוחזר אם שגיאה בלתי ניתנת לתיקון בלוגיקה העסקית מונעת את המעבר לתשלום. הסטטוס הזה זמין ב-UCP בגרסה 2026-04-08 ובגרסאות מתקדמות יותר.

תהליך תשלום על כמה פריטים:

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

1. המשתמש מתחיל את תהליך התשלום מממשק שמופעל בו UCP (למשל, על ידי לחיצה על 'קנייה עכשיו' במוצר).
2. מתבצעת קריאה ל-POST /checkout-sessions, כולל כל הפריטים השונים במערך line_items. המערך line_items יכיל אובייקט נפרד לכל פריט ייחודי שנבדק.
3. המשתמש יכול לעדכן את אמצעי התשלום, את פרטי ההזמנה או להחיל הנחות באמצעות קריאות ל-PUT /checkout-sessions/{id}.
4. כשמשתמש לוחץ על הלחצן 'תשלום באמצעות GPay', מתבצעת קריאה של POST /checkout-sessions/{id}/complete.

אימות

פרטים על אבטחת נקודות הקצה של Native Checkout API, כולל שיטות אימות נתמכות כמו מפתחות API ו-OAuth 2.0, זמינים במדריך אימות ואבטחה.

כלים למפתחים

כדי לעזור לכם בהטמעה של Native Checkout API, תוכלו למצוא את המשאבים הבאים במאגר Universal Commerce Protocol GitHub:

• מאגר UCP ב-GitHub: אפשר לעיין במאגר הראשי כדי למצוא מסמכים מקיפים, מפרטים ומקורות מידע מהקהילה.
• ערכות SDK: אפשר להשתמש בערכות הכלים לפיתוח תוכנה כדי להאיץ את השילוב. יש ערכות SDK ספציפיות לשפות, כולל:
  • Python SDK
  • JavaScript 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:

• גרסה 2026-04-08 של API בארכיטקטורת REST לתהליך תשלום מובנה
• ‫Version 2026-01-23 Native checkout REST API

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