As part of the Actions Center's Reservations 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 the Actions Center, you must meet the following requirements:
- Use a supported payment processor. The latest list of supported processors can be found on the Google Pay website.
- Accept tokenized payments in accordance with your processor.
- Complete the identity and business business verification process outlined here.
- Payment cannot be enabled for bookings that requires asynchronous confirmation .
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 thetokenization_config
field. The set is dependent on the payment processor chosen. The set is the same set ofpaymentMethodTokenizationParameters.parameters
that would be passed to Google Pay if you were to integrate with it. - 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 the
CreateBooking
method - Google will send payments tokens in the field
payment_processing_parameters.unparsed_payment_method_token
as part of theCreateBookingRequest
. This is the samepaymentData
that would be received by your callback in a Google Pay integration. - In the
CreateBookingResponse
include a PaymentInformation message that specifies the payment type, status, transaction id and price / fee structure. - Set the
payment_information.payment_processed_by
field toPROCESSED_BY_PARTNER
in theCreateBookingResponse
.
Use cases for payments
When deciding whether to take payments for each of these use cases, please review our Payments Policies and ensure that you are able to comply with all relevant policies.
There are the 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](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/rwg_payments_prepaid_flow_diagram.png?authuser=0000)
- 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 toREQUIRED
for that service. - Set the
require_credit_card
field toREQUIRE_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](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/rwg_payments_deposits_noshowfee_flow_diagram.png?authuser=0000)
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 fo a booking.
- Even if there is no payment required upfront, the booking server must
respond to the CreateBooking request with a
PaymentInformation
containing apayment_transaction_id
, which must be unique. Thepayment_transaction_id
does not need to be provided by the payment processor, but it can instead be generated by the booking server.
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 toREQUIRE_CREDIT_CARD_CONDITIONAL
at the service or availability slot level. - (optional) Set
prepayment_type
toREQUIRED
orOPTIONAL
.
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 toREQUIRE_CREDIT_CARD_ALWAYS
at the Service level or at the Availability slot level for a merchant.
Cancellation and Refunds
Cancellations and refunds are either initiated by the partner (you) or by the user through the
Actions Center. In both cases, you must respect the
CancellationPolicy
that was set at the Service level
and communicated to the user at booking checkout.
If you do not provide
CancellationPolicy
,
it is assumed that any cancellation within the cancellation window defined by
min_advance_online_canceling
that was set at the
Service level
is refundable.
If min_advance_online_canceling
is not defined it's 0 (meaning cancellable any time).
If you must disable cancellation from the Actions Center side, please discuss with your Google POC.
Changes to RTUs- After you provide a refund to the user, you must send an
update booking RTU to change the payment status of the
booking. Set
update_mask
tostatus,payment_information.prepayment_status
and setpayment_information.prepayment_status = PREPAYMENT_REFUNDED
andstatus = CANCELED
.- Use the new
BookingStatus = CANCELED
andPrepaymentStatus = PREPAYMENT_REFUNDED
. The enum valueCANCELED_AUTOMATIC_REFUND
is deprecated for both Maps Booking API and gRPC templates.
- Use the new
- When the Actions Center sends an
UpdateBookingRequest
and this triggers a refund for the user, setbooking.payment_information.prepayment_status = PREPAYMENT_REFUNDED
in theUpdateBookingResponse
.