Обзор

Примечание. Центр действий в настоящее время не поддерживает эту функцию для новых дополнительных функций.

В рамках сквозной интеграции резервирования Центра действий вы можете разрешить своим продавцам получать оплату от пользователей, когда они совершают бронирование, встречу или бронирование. 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 (что означает возможность отмены в любой момент).

Если вам необходимо отключить отмену со стороны Центра действий, обсудите это с вашим POC 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 устарело как для Maps Booking API, так и для шаблонов gRPC.

Перейти на сервер бронирования

• Когда Центр действий отправляет UpdateBookingRequest и это вызывает возврат средств пользователю, установите booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED в UpdateBookingResponse .