Enabling payments

As part of Reserve with Google's end-to-end integration, you can opt in your merchants to receive payment from users when they make a booking, appointment, or 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 render a Payment Info module in the checkout flow. This allows the user to enter their credit card information.

Support for 3DS1 and 3DS2 is available, please refer to this tutorial on the implementation.

Eligibility

For your merchants to receive payments through Reserve with Google, you must meet the following 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.

Changes to feeds and booking server for payments

Payments are done through an opt-in process at the merchant level. You must enable payments for any merchant who needs to receive payment for any of their services. To enable payments, changes must be made to the feeds and to the booking server.

Feeds

• Merchant Feed: Specify payment information through the tokenization_parameter set in the tokenization_config field. 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 to integrate with it.

  Note: If you collect payments on behalf of the merchant, you can provide your own parameters instead of the merchant's.

• Services/Availability Feeds: Specify payment requirements based on your appropriate use case. For more details, see Use cases for payments.

Booking Server

• Based on the type of payments users are making, implement either the CreateBooking method or the CreateOrder method

  • If users make single booking requests, like those applicable to fitness, beauty, and dining, use CreateBooking.
  • If users are buying tickets, applicable to things-to-do, use CreateOrder.

• Google will send payments tokens in the field payment_processing_parameters.unparsed_payment_method_token as part of the CreateBookingRequest or the CreateOrderRequest. This is the same paymentData that would be received by your callback in a Google Pay integration.

• In the CreateBookingResponse or CreateOrderResponse include a PaymentInformation message that specifies the payment type, status, transaction id and price / fee structure.

• Set the payment_information.payment_processed_by field to PROCESSED_BY_PARTNER in the CreateBookingResponse or the CreateOrderResponse.

Use cases for payments

There are four main use cases for payments:

• Complete prepaid bookings
• Deposits required for the booking
• No-show fees in case the user doesn't show up for the booking
• Credit card required for the booking

For more information on how to implement each of these use cases see the tutorial on Configuring Payments.

Complete prepaid bookings

Figure 1 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.

Changes to services feeds

• Set the prepayment_type field to REQUIRED for that service.
• Set the require_credit_card field to REQUIRE_CREDIT_CARD_CONDITIONAL for that service.

Deposits and no-show fees

Deposits and no-show fees are set up in similar ways. Figure 2 shows the flow of these activities between users, you (the scheduling partner), Google, and the payment processor.

Figure 2: Deposits or no-show fee bookings sequence diagram

Deposits and no-show fees can be used to ensure a user shows up for their booking.

• A deposit can be charged to the user's credit card either upfront or at a later time.
• A no-show fee can be charged to the user if they don't show up to the booking.
• If necessary, both deposits and no-show fees can be applied together for a booking.
• Even if there is no payment required upfront, the booking server must respond to the CreateBooking request with a PaymentInformation containing a payment_transaction_id, which must be unique. The payment_transaction_id does not need to be provided by the payment processor, but it can instead be generated by the booking server.

Changes to services or availability feeds

Deposits and no-show fees can be specified at the Service level or at the Availability slot level for a merchant. If you specify them at the availability slot level, that overrides the service-level definitions.

• To enable deposits, set the deposit field at the service or availability slot level.
• To enable no-show fees, set the no_show_fee field at the service or availability slot level.
• Set the require_credit_card field to REQUIRE_CREDIT_CARD_CONDITIONAL at the service or availability slot level.
• (optional) Set prepayment_type to REQUIRED or OPTIONAL.

Credit card required

There may be other use cases that require a credit card at the time of booking.

• Set the require_credit_card field to REQUIRE_CREDIT_CARD_ALWAYS at the Service level or at the Availability slot level for a merchant.

Cancellation and Refunds

Cancellations and refunds are initiated by the partner when a payment is involved with the booking. Reserve with Google doesn't allow users to use the Reserve with Google interface to cancel bookings with payments. That's because all payments are processed by you.

Changes to the booking server

• After you provide a refund to the user, you must send an UpdateBooking booking server call to change the payment status of the booking. Set update_mask to booking.payment_information.prepayment_status and PrepaymentStatus = PREPAYMENT_REFUNDED.

  • Use the new BookingStatus = CANCELED and PrepaymentStatus = PREPAYMENT_REFUNDED. The enum value CANCELED_AUTOMATIC_REFUND is deprecated for both Maps Booking API and gRPC templates.