סקירה כללית

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

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

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

יש תמיכה ב-3DS1 וב-3DS2. מומלץ לעיין במדריך הזה לגבי ההטמעה.

דרישות סף

כדי שהמוכרים שלך יקבלו תשלומים דרך מרכז הפעולות, עליך לעמוד בדרישות הבאות:

1. להשתמש בספק נתמך של שירותי תשלומים. הרשימה העדכנית ביותר של מעבדים נתמכים מופיעה באתר Google Pay.
2. מקבלים תשלומים שהומרו לאסימונים בהתאם לעיבוד הנתונים של מעבד המידע.
3. יש להשלים את תהליך אימות הזהות ואימות העסק שמתואר כאן.
4. אי אפשר לשלם עבור הזמנות שנדרש להן אישור אסינכרוני .

שינויים בפידים ובשרת ההזמנות של תשלומים

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

פידים

• פיד של מוכרים: מציינים את פרטי התשלום באמצעות השדה tokenization_parameter שמוגדר בשדה tokenization_config. ההגדרה תלויה במעבד התשלומים שנבחר. הקבוצה היא אותה קבוצה של paymentMethodTokenizationParameters.parameters שתועבר אל Google Pay אם תשלב אותה.
  הערה: אם אתם גובים תשלומים בשם המוכר, אתם יכולים לספק פרמטרים משלכם במקום הפרמטרים של המוכר.
• פידים של שירותים/זמינות: פירוט של דרישות תשלום בהתאם לתרחיש לדוגמה שלכם. מידע נוסף זמין במאמר תרחישים לדוגמה לתשלומים.

שרת הזמנות

• מטמיעים את השיטה CreateBooking בהתאם לסוג התשלומים שהמשתמשים מבצעים
• Google תשלח אסימוני תשלום בשדה payment_processing_parameters.unparsed_payment_method_token כחלק מהCreateBookingRequest. הערך הזה זהה ל-paymentData שיתקבל בהתקשרות חזרה בשילוב של Google Pay.
• בשדה CreateBookingResponse יש לכלול הודעת PaymentInformation לגבי סוג התשלום, הסטטוס, מזהה העסקה ומבנה המחיר והעמלה.
• מגדירים את השדה payment_information.payment_processed_by לערך PROCESSED_BY_PARTNER בשדה CreateBookingResponse.

תרחישים לדוגמה לתשלומים

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

הנה תרחישים לדוגמה לתשלומים:

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

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

השלמת הזמנות בתשלום מראש

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

איור 1: תרשים הרצף של הזמנות בתשלום מראש

• התשלום חייב להיות בגובה 100% מסכום עלות השירות. במילים אחרות, צריך לשלם על השירותים במלואם בזמן ההזמנה.

שינויים בפידים של שירותים

• מגדירים את השדה prepayment_type לערך REQUIRED עבור השירות הזה.
• מגדירים את השדה require_credit_card לערך REQUIRE_CREDIT_CARD_CONDITIONAL בשירות הזה.

הפקדות ועמלות של אי-הגעה

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

איור 2: תרשים רצף של הפקדות או אי-הצגה של הזמנות

ניתן להשתמש בהפקדות ובעמלות על אי-הגעה כדי להבטיח שהמשתמש יגיע לשלב ההזמנה.

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

שינויים בפידים של שירותים או זמינות

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

• כדי להפעיל הפקדות, צריך להגדיר את השדה deposit ברמת משבצת השירות או משבצת הזמינות.
• כדי לאפשר עמלות על אי-הגעה, צריך להגדיר את השדה no_show_fee ברמת השירות או משבצת הזמינות.
• מגדירים את השדה require_credit_card לערך REQUIRE_CREDIT_CARD_CONDITIONAL ברמת משבצת השירות או הזמינות.
• (אופציונלי) מגדירים את prepayment_type לערך REQUIRED או ל-OPTIONAL.

נדרש כרטיס אשראי

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

• מגדירים את השדה require_credit_card לערך REQUIRE_CREDIT_CARD_ALWAYS ברמת השירות או ברמת המיקום של הזמינות למוכר.

ביטולים והחזרים כספיים

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

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

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

שינויים ב-RTU

• אחרי ששולחים למשתמש החזר כספי, צריך לשלוח עדכון RTU של הזמנה כדי לשנות את סטטוס התשלום של ההזמנה. מגדירים את update_mask לערך status,payment_information.prepayment_status ומגדירים את payment_information.prepayment_status = PREPAYMENT_REFUNDED ו-status = CANCELED.
  • משתמשים בממשק החדש של BookingStatus = CANCELED וגם ב-PrepaymentStatus = PREPAYMENT_REFUNDED. הערך CANCELED_AUTOMATIC_REFUND enum יצא משימוש גם ל-מפות Google Booking API וגם לתבניות gRPC.

שינוי לשרת ההזמנות

• כשמרכז הפעולות שולח UpdateBookingRequest ופעולה זו מפעילה החזר כספי למשתמש, יש להגדיר booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED ב UpdateBookingResponse.