Enabling payments

As part of Reserve with Google end-to-end integrations, you can opt in your merchants to receive payment from users when they make a booking / appointment / reservation. Google works with payment processors to set up tokenization. Payment processors then use unique tokens to securely pay merchants.

For payment secured bookings, we will render a Payment Info module in the checkout flow, which will allow the user to enter their credit card information in order to support the use-cases outlined below.


For your merchants to receive payments through Reserve with Google, you must meet these requirements:

  1. Use a supported payment processor. The latest list of supported processors can be found on the Google Pay website.

  2. Accept tokenized payments in accordance with your processor.

Merchant-level opt-in and payment token

For each merchant you'd like to receive payments, you take the following steps in your merchants feed:

  1. Send Reserve with Google their unique set of tokenization_parameter in the tokenization_config field in the Merchant feed for that merchant. The set is dependent on the payment processor chosen. The set is the same set of paymentMethodTokenizationParameters.parameters that would be passed to Google Pay if you were integrating with it.

    • You can also opt to provide your own parameters instead of the merchant's if you collect payments on behalf of the merchant.
  2. For a booking that involves payment, Reserve with Google sends a payment_processing_parameters.unparsed_payment_method_token as part of the CreateBookingRequest. This is the same paymentData that would be received by your callback in a Google Pay integration. Reserve with Google also sets the CreateBookingRequest.payment_information.payment_processed_by field to PROCESSED_BY_PARTNER.

Setup overview

You can enable payments for some or all of your merchants. There are three main use-cases for payments: (1) complete prepaid booking, (2) deposits required for the booking, and (3) no show fee in the event the user does not show up for the booking.

1. System configuration for complete prepaid bookings

The diagram below shows the flow of activities between users, you (the scheduling partner), Google, and the payment processor.

Figure 1: Prepaid bookings sequence diagram
  • A payment must be for 100% of the service cost amount. In other words, services must be paid in full at the time of the booking.
  • Set the prepayment_type field to REQUIRED in the Service feed for that service.
  • Set the require_credit_card field to REQUIRE_CREDIT_CARD_CONDITIONAL in the Service feed for that service.

2. System configuration for deposits, no show fees, credit card requirement

The diagram below shows the flow of activities between users, you (the scheduling partner), Google, and the payment processor.

Figure 2: Deposits or No Show Fee bookings sequence diagram
  1. Deposits and no show fees can be specified at the Service level or at the Availability slot level for a merchant. If you specify it at the availability slot level, it overrides the service level definitions.

    • A deposit can be either charged upfront or at a later time to the user's credit card.
    • A no show fee can be charged to the user if they do not show up to the booking.
    • Both deposit and no show fee can be applied together for a booking if necessary.
    • Set the deposit field at the service or availability slot level.
    • Set the no_show_fee field at the service or availability slot level
    • Set the require_credit_card to REQUIRE_CREDIT_CARD_CONDITIONAL at the service or availability slot level.
    • Note that if a deposit and/or no-show fee is being collected, marking the associated service as prepaid is optional, not required.
  2. If a booking requires a user's credit card outside of the complete prepaid / deposit / no show fee use-cases, we provide the means to do so.

    • Set the require_credit_card to REQUIRE_CREDIT_CARD_ALWAYS at the service or availability slot level. This ensures that a credit card is required of the user and a valid token is provided to you that you can use as needed.

Cancellation and Refunds

  • Since the user pays directly to you (the partner) or the merchant (via you), Reserve with Google inherently does not support cancellations or refunds for bookings involving payment unless they are initiated by you (the partner).
  • The merchant is responsible for handling user-initiated cancellations and refunds.
  • For you (the partner) to initiate a refund, you must send changes to a payment status (e.g. the merchant refunds a payment) to Reserve with Google via the Maps Booking API UpdateBooking request. Set update_mask to booking.payment_information.prepayment_status and PrepaymentStatus = PREPAYMENT_REFUNDED.
  • The enum value CANCELED_AUTOMATIC_REFUND is deprecated for both Maps Booking API and gRPC templates. A cancellation where the refund should be processed is now denoted as BookingStatus = CANCELED, PrepaymentStatus = PREPAYMENT_REFUNDED.

Have questions?

Be sure to check out our FAQs.