پلتفرم Action Center از پیکربندی‌های مختلفی برای پرداخت‌ها پشتیبانی می‌کند. راهنمای فعال‌سازی پرداخت‌ها جنبه‌های یکپارچه‌سازی را که در همه یکپارچه‌سازی پرداخت‌ها مشترک است، پوشش می‌دهد، از جمله:
- در حال پیکربندی فیدها برای گنجاندن اطلاعات
tokenization_parameter - به روز رسانی سرور رزرو برای پذیرش اشیاء
payment_method_token - نمای کلی از اطلاعات مبادله شده بین یک کاربر، مرکز اقدامات، شریک / تاجر، و پردازشگر پرداخت.
در این راهنما، نحوه پیکربندی فیدهای خود را با جزئیات بیشتری توضیح خواهیم داد تا مشخص کنید کدام یک از انواع مختلف پیکربندی پرداخت برای تاجران و خدمات شما قابل اجرا است.
- بدون پرداخت / پرداخت در هنگام ورود
- پیش پرداخت کامل
- بدون هزینه نمایش / هزینه لغو
- سپرده گذاری
همه موارد استفاده برای پرداخت‌ها، پسوندهای مورد استفاده بدون پرداخت / پرداخت هنگام ورود هستند (که نیازی به پیکربندی پرداخت ندارد) بنابراین این آموزش با توصیف آن پیکربندی آغاز می‌شود و پیکربندی‌های دیگر را به‌عنوان افزونه در نظر می‌گیرد.
هر بخش همچنین فیلدهایی را برای ردیابی در سرور رزرو به منظور پذیرش پیکربندی پرداخت خاص پوشش می دهد.
بدون پرداخت / پرداخت در هنگام ورود
برای خدماتی که در زمان رزرو نیاز به پرداخت ندارند، هیچ پیکربندی پرداخت در سطح تاجر یا خدمات مورد نیاز نیست. با این حال، قیمت ها هنوز مورد نیاز است.
این پیکربندی پایه یک سرویس است که شامل نام، توضیحات و قیمت است. این یک پیام سرویس واحد در یک ServiceFeed خواهد بود:
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-1-a",
"name": "Men's haircut",
"description": "One of our stylists will cut your hair",
"price": {
"price_micros": 15000000,
"currency_code": "USD"
}
}
هیچ پیکربندی اضافی فراتر از اجرای استاندارد در سرور رزرو برای پشتیبانی از پرداخت هنگام ورود لازم نیست.
پیش پرداخت
این پیکربندی برای تعیین اینکه مبلغ سرویس باید به طور کامل در زمان رزرو پرداخت شود استفاده می شود.
پیش پرداخت در سطح خدمات از طریق قسمت prepayment_type Service مشخص می شود. برای نیاز به پرداخت برای یک سرویس، باید مانند مثال زیر روی REQUIRED تنظیم شود. توجه داشته باشید که قیمت به همان شکلی که مثال پرداخت در هنگام ورود مشخص شده است. در اینجا، به دلیل اینکه نوع پیش‌پرداخت را روی مورد نیاز تنظیم می‌کنیم، یک کارت اعتباری جمع‌آوری می‌شود و می‌توان این قیمت را در زمان پرداخت شارژ کرد.
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-2-b",
"name": "Spa Treatment",
"description": "A full spa treatment",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
"prepayment_type": "REQUIRED"
}
سرور رزرو
هنگام پذیرش پیش پرداخت، یک رمز پرداخت در تماس با CreateBooking از طریق فیلد payment_processing_parameters.unparsed_payment_method_token به سرور رزرو شما ارسال می شود. شما موظف هستید دقیقاً مبلغی را که از طریق قسمت قیمت در فیدها مشخص شده است شارژ کنید و باید از ارز مشخص شده در فیدها استفاده کنید. این هزینه‌ها باید از جریان تشریح شده در راهنمای فعال کردن پرداخت‌ها پیروی کنند.
هنگام بازگرداندن CreateBookingResponse قسمت booking.payment_information باید طوری تنظیم شود که به درستی نشان دهد که پیش پرداخت ارائه شده و پردازش شده است.
مشخصات PaymentInformation حاوی اسناد کامل برای همه گزینه های اطلاعات پرداخت است. یک مثال حداقلی برای پردازش پیش پرداخت در زیر ارائه شده است. مهم است که قیمت برگشتی در قسمت قیمت دقیقاً مطابق با آنچه در درخواست مشخص شده است باشد. علاوه بر این، اگر نرخ مالیاتی در فیدها/درخواست‌ها مشخص شده باشد، باید دقیقاً درج شود.
همچنین توجه داشته باشید که باید یک شناسه تراکنش ارائه دهید. این شناسه تراکنش حداقل باید در میان تراکنش‌های آن تاجر منحصربه‌فرد باشد. یک نامزد خوب برای شناسه تراکنش، شناسه تراکنش است که توسط پردازشگر پرداخت در اختیار شما قرار می گیرد.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
}
هزینه عدم نمایش
در صورت عدم حضور کاربر در رزرو، یا در صورت لغو پس از پنجره لغو، می توان هزینه عدم نمایش را از کاربر دریافت کرد. اگر پنجره لغو مشخص نشده باشد، به طور پیش فرض روی زمان شروع شکاف خواهد بود.
برای تعیین هزینه عدم نمایش، در فید سرویس، باید فیلد no_show_fee را همانطور که در مثال زیر نشان داده شده است قرار دهید:
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-2-b",
"name": "Spa Treatment",
"description": "A full spa treatment",
"price": {
"price_micros": 200000000,
"currency_code": "USD"
}
"scheduling_rules": {
"min_advance_online_canceling": 14400,
}
"no_show_fee": {
"fee": {
"price_micros": 25000000,
"currency_code": "USD"
}
"fee_type": "FIXED_RATE_DEFAULT"
}
}
در مثال بالا، شریک یا تاجر مجاز است در صورت عدم حضور دارنده قرار در قرار ملاقات، مبلغی با نرخ ثابت 25 دلاری را همانطور که در قسمت no_show_fee.fee.price_micros مشخص شده است، دریافت کند. در صورتی که کاربر ظرف 4 ساعت (14400 ثانیه) قبل از قرار ملاقات را لغو کند، همانطور که در قسمت scheduling_rules.min_advance_online_canceling مشخص شده است، ممکن است این هزینه نیز دریافت شود.
برای مشاهده اینکه چگونه می توان هیچ هزینه نمایشی را در سطح در دسترس بودن تعریف کرد، به این بخش مراجعه کنید.
سرور رزرو
هنگام پردازش درخواستی که شامل هزینه عدم نمایش است، یک رمز پرداخت در تماس با CreateBooking از طریق فیلد payment_processing_parameters.unparsed_payment_method_token به سرور رزرو شما ارسال می‌شود. این توکن به همان روشی که در مورد پیش پرداخت وجود دارد منتقل می شود. با این حال، از آنجایی که توکن فقط برای مدت زمان کوتاهی مجاز است، باید با API مربوطه پردازنده پرداخت خود تماس بگیرید تا این توکن را به نسخه‌ای ارتقا دهید که بتوانید در زمان بعدی از آن استفاده کنید. این در بخش راهنمای فعال کردن پرداخت‌ها درباره جریان نشانه کارمزد عدم نمایش توضیح داده شده است.
هنگام بازگرداندن CreateBookingResponse قسمت booking.payment_information باید طوری تنظیم شود که وضعیت هزینه عدم نمایش را به درستی بازتاب دهد، مانند مثال زیر.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
"no_show_fee": {
"fee": {
"price_micros": 25000000,
"currency_code": "USD"
}
"fee_type": "FIXED_RATE_DEFAULT"
}
}
توجه داشته باشید که no_show_fee تنظیم شده است تا منعکس کننده قیمت و ساختار هزینه ای باشد که ممکن است دریافت شود. همچنین توجه داشته باشید که مشابه مثال پیش پرداخت ها، یک transaction_id در این پیام مورد نیاز است.
همچنین توجه داشته باشید که booking_id تنظیم شده در CreateBookingResponse یک فیلد ضروری برای به‌روزرسانی‌های بی‌درنگ است که باید هنگام دریافت هزینه عدم نمایش ارسال شوند. انتظار می رود که این شناسه در کنار اطلاعات مربوط به رزرو ذخیره شود.
به روز رسانی در زمان واقعی
اگر کاربر برای رزرو برنامه‌ریزی‌شده خود نیامد، یا پس از پنجره لغو لغو را لغو کرد (مثلاً با تماس مستقیم با شما)، می‌توانید با استفاده از اطلاعات پرداختی که در زمان رزرو ذخیره کرده‌اید، هزینه عدم نمایش مشخص‌شده را دریافت کنید. هنگامی که هزینه عدم نمایش را دریافت می کنید، باید یک به روز رسانی بلادرنگ ارسال کنید و مشخص کنید که هزینه عدم نمایش دریافت شده است.
برای رزروهای ایجاد شده توسط CreateBooking ، یک به‌روزرسانی باید به notification.partners.bookings.patch ارسال شود. در متن این درخواست باید رزرو به روز شده باشد، با وضعیت تنظیم شده روی NO_SHOW_PENALIZED . این وضعیت به گوگل اطلاع می دهد که هزینه ای انجام شده است.
به عنوان مثال یک درخواست می تواند به:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
با بدنه درخواستی:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "NO_SHOW_PENALIZED"
}
سپرده گذاری
سپرده ها برای جمع آوری شارژ اولیه به عنوان شرط لازم برای رزرو استفاده می شود. ودیعه را می توان در زمان رزرو یا در زمان بعدی شارژ کرد. ممکن است لازم باشد تعریف کنید که تحت چه شرایطی ودیعه قابل استرداد است و همچنین چه زمانی می توان رزرو آنلاین را لغو کرد .
برای تعیین سپرده، در فید خدمات، باید فیلد deposit را مطابق مثال زیر وارد کنید:
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-2-b",
"name": "Spa Treatment",
"description": "A full spa treatment",
"price": {
"price_micros": 200000000,
"currency_code": "USD"
}
"scheduling_rules": {
"min_advance_online_canceling": 86400,
}
"deposit": {
"deposit": {
"price_micros": 25000000,
"currency_code": USD,
"min_advance_cancellation_sec": 14400,
}
"deposit_type": "FIXED_RATE_DEFAULT"
}
}
در این مثال، min_advance_online_canceling پنجره لغو را تعریف می کند و deposit.min_advance_cancellation_sec تعیین می کند که چه زمانی ودیعه قابل استرداد است. توجه داشته باشید که در مثال بالا یک واریز می تواند زمان انصراف را جدا از شرایط بازپرداخت مشخص کند. در این صورت، کاربر می تواند تا 24 ساعت قبل (86400 ثانیه) سرویس را به صورت آنلاین لغو کند. این تضمین می کند که تاجر مستقیماً از هرگونه لغو دیرهنگام مطلع می شود. با این حال، ممکن است کاربر همچنان واجد شرایط بازپرداخت مبلغ سپرده خود تا 4 ساعت قبل (14400 ثانیه) قبل از رزرو باشد (از طریق تماس با شما یا تاجر برای لغو)، که در شرایط هنگام تسویه حساب و در ایمیل تایید
برای مشاهده نحوه تعریف سپرده ها در سطح دسترسی، به این بخش مراجعه کنید.
سرور رزرو
هنگام پردازش درخواستی که شامل واریز می شود، یک رمز پرداخت در تماس با CreateBooking از طریق فیلد payment_processing_parameters.unparsed_payment_method_token به سرور رزرو شما ارسال می شود. این توکن به همان روشی که در مورد پیش پرداخت وجود دارد منتقل می شود. اگر در زمان رزرو وجه واریزی را شارژ کنید یا آن را نگه دارید، می توانید در طول این درخواست این کار را انجام دهید.
اگر قصد دارید مبلغ سپرده را در زمان دیگری شارژ کنید، زیرا رمز فقط برای مدت کوتاهی مجاز است، باید با API مربوطه پردازشگر پرداخت خود تماس بگیرید تا این توکن را به نسخه‌ای ارتقا دهید که بتوانید از آن استفاده کنید. زمان بعد این در بخش راهنمای فعال کردن پرداخت ها در مورد جریان توکن سپرده توضیح داده شده است.
هنگام بازگرداندن CreateBookingResponse قسمت booking.payment_information باید به درستی وضعیت سپرده را بازتاب دهد، مانند مثال زیر.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
"deposit": {
"deposit": {
"price_micros": 25000000,
"currency_code": USD,
"min_advance_cancellation_sec": 28800,
}
"deposit_type": "FIXED_RATE_DEFAULT"
}
}
توجه داشته باشید که سپرده به گونه ای تنظیم شده است که قیمت و ساختار سپرده ای را که شارژ یا نگهداری می شود منعکس کند. همچنین توجه داشته باشید که مشابه مثال پیش پرداخت ها، یک transaction_id در این پیام مورد نیاز است.
به روز رسانی در زمان واقعی
اگر کاربر رزرو خود را قبل از پنجره لغو واریز لغو کرد، باید هر مبلغی را که به کارت کاربران شارژ کرده‌اید بازپرداخت کنید. هنگام بازپرداخت ودیعه، باید یک به‌روزرسانی بی‌درنگ ارسال کنید که مشخص می‌کند سپرده بازپرداخت شده است.
برای رزروهای ایجاد شده توسط CreateBooking ، یک به‌روزرسانی باید به notification.partners.bookings.patch ارسال شود. در متن این درخواست باید رزرو به‌روزرسانی شده باشد، با وضعیت CANCELED و قسمت paymentInformation.prepaymentStatus روی PREPAYMENT_REFUNDED تنظیم شده است. این به گوگل اطلاع می دهد که وجه سپرده بازپرداخت شده است.
به عنوان مثال یک درخواست می تواند به:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
با بدنه درخواستی:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "CANCELED"
"paymentInformation": {
"prepaymentStatus": "PREPAYMENT_REFUNDED"
}
}
نیاز به کارت اعتباری
یک سرویس ممکن است به کارت اعتباری به عنوان تأیید هویت کاربر نیاز داشته باشد. با این حال، نباید برای پیش‌پرداخت، سپرده‌گذاری یا عدم کارمزد نمایش استفاده شود . اگر این موارد استفاده مورد نیاز است، باید به صراحت با استفاده از مراحل بالا پیکربندی شوند. همچنین لطفاً توجه داشته باشید که نیاز به کارت اعتباری اغلب منجر به کاهش قابل توجهی در رزرو این سرویس می شود.
برای درخواست ارائه کارت اعتباری در حین تسویه حساب، باید فیلد require_credit_card روی REQUIRE_CREDIT_CARD_ALWAYS تنظیم کنید.
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-1-a",
"name": "Men's haircut",
"description": "One of our stylists will cut your hair",
"price": {
"price_micros": 15000000,
"currency_code": "USD"
},
"require_credit_card": "REQUIRE_CREDIT_CARD_ALWAYS"
}
سرور رزرو
هنگام پردازش درخواستی که شامل نیاز به کارت اعتباری است، یک رمز پرداخت به سرور رزرو شما در تماس با CreateBooking از طریق فیلد payment_processing_parameters.unparsed_payment_method_token ارسال می‌شود. این توکن به همان روشی که در مورد پیش پرداخت وجود دارد منتقل می شود. با این حال، از آنجایی که توکن فقط برای مدت زمان کوتاهی مجاز است، باید با API مربوطه پردازنده پرداخت خود تماس بگیرید تا این توکن را به نسخه‌ای ارتقا دهید که بتوانید در زمان بعدی از آن استفاده کنید.
هیچ اطلاعات اضافی در پاسخ سرور رزرو فراتر از مورد استفاده پرداخت در هنگام ورود لازم نیست.
قیمت گذاری اصلی در سطح در دسترس بودن
در تمام مثال‌های بالا، ساختار قیمت / کارمزد در سطح خدمات مشخص شده است. در بیشتر موارد باید از این قیمت گذاری در سطح خدمات استفاده شود. با این حال، در برخی موارد، تغییر ساختار پرداخت برای اسلات‌های در دسترس بودن معین است. به عنوان مثال، شرایط زیر را می توان با افزایش قیمت / کارمزد در سطح دسترسی کنترل کرد:
- قیمت ها در روزهای سه شنبه کاهش و شنبه ها افزایش می یابد.
- برای در دسترس بودن بین ساعت 17:00 تا 19:00 هیچ هزینه ای برای نمایش اعمال نمی شود.
جدول زیر، برای هر روش پرداخت / کارمزد، فهرستی را نشان می‌دهد که از چه فیلدی در فید در دسترس بودن استفاده شود تا تعریف سطح خدمات لغو شود.
| نوع پرداخت | تعرفه هزینه / قیمت | قابل جبران است؟ |
|---|---|---|
| پرداخت در هنگام ورود | Service.price | قیمت قابل لغو از طریق Availability.payment_option_id ارجاع به Merchant.payment_option |
| پیش پرداخت | Service.price | قیمت از طریق Availability.payment_option_id ارجاع به Merchant.payment_option قابل لغو است |
| بدون هزینه نمایش | Service.no_show_fee | Availability.no_show_fee |
| سپرده گذاری | Service.deposit | Availability.deposit |
| نیاز به کارت اعتباری | Service.require_credit_card | Availability.require_credit_card |
توجه داشته باشید که برای لغو قیمت در سطح در دسترس بودن، ابتدا باید یک گزینه پرداخت در سطح تاجر تعریف کنید. علاوه بر این، برای راهنمایی در مورد افزودن پنجره‌های لغو در سطح دسترسی، لطفاً راهنمای نحوه افزودن ویندوز لغو را ببینید.