סקירה כללית

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

כחלק מהשילוב של מרכז הפעולות עם 'הזמנות מקצה לקצה', אתם יכולים לאפשר למוכרים לקבל תשלום ממשתמשים כשהם מבצעים הזמנה, פגישה או הזמנת מקום. 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 לא חייב להינתן על ידי מעבד התשלומים, אלא יכול להיווצר על ידי שרת ההזמנות.

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

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

• כדי להפעיל את האפשרות של הפקדות, מגדירים את השדה 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.

שינויים ב-RTUs

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

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

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