> [!NOTE]
> **Note:** [Create a new support case in the Partner Portal](https://partnerdash.google.com/apps/reservewithgoogle/support/cases/create) if you are interested in enabling Payments Redirect.

![Overview](https://developers.google.com/static/actions-center/images/dining_reservations_payment_overview.png)

As part of the Actions Center's Reservations End-to-End integration, you can enable
any deposits, no-show fees, or prepaid inventory to be linkedout to your booking
page for any transactions that may requirement payments. Enabling payments in
this manner lets you handle the entire booking flow and transaction on the
booking page that you specify.

## Eligibility

To add payments to specific reservations, you must have the following
prerequisites:

1. An existing live E2E Integration.
2. The ability to deep link directly into a [booking page](https://developers.google.com/actions-center/verticals/reservations/e2e/policies/integration-policies#landing_page_requirements) that can handle payment processing.
3. Ensure compliance of our [Payment Redirect Policies](https://developers.google.com/actions-center/verticals/reservations/e2e/policies/integration-policies#payments_redirect_policies)

## Payments Redirect Implementation Steps

1. [Setting up your Url Template and additional fields.](https://developers.google.com/actions-center/verticals/reservations/e2e/add-ons/add-payments-redirect/url-templates)
2. [Specifying the payment types for your slots.](https://developers.google.com/actions-center/verticals/reservations/e2e/add-ons/add-payments-redirect/specifying-payment-types)
3. [Enabling conversion tracking for your integration.](https://developers.google.com/actions-center/verticals/reservations/e2e/add-ons/add-payments-redirect/conversion-tracking)

> [!IMPORTANT]
> **Important:** Partners using Real-Time Updates (RTU) must update them to include the new payments redirect fields. See [Real-Time API updates](https://developers.google.com/actions-center/verticals/reservations/e2e/e2e/integration-steps/real-time-api-updates) for more information.

## Booking Modifications

This section describes how booking modifications and cancellations interact
with Payments Redirect, including slot exclusion and error handling.

### Payments Redirect Bookings

Bookings created through Payments Redirect are completed directly on the
partner's booking platform. Google does not store or manage these bookings, so
users cannot view or modify them through
[Reserve with Google](https://www.google.com/maps/reserve/bookings). Any
modifications or cancellations for Payments Redirect bookings must be performed
directly on the partner's platform.

### Modifying End-to-End Bookings

When a user modifies an existing end-to-end reservation (originally created
using `CreateBooking`), Google automatically excludes all slots marked with
`linkout_required_reason: PAYMENT_REQUIRED` from the available options in the
modification view (rendering them unavailable or greyed out). This prevents
users from switching an end-to-end reservation to a payment redirect
(e.g. deposit-required) slot without completing payment.

### Handling UpdateBooking Requests

The `UpdateBooking` API endpoint does not support transitioning a user into
the Payments Redirect flow or returning a redirect URL. In the unlikely event
that the partner's server receives an `UpdateBooking` request for a payment
redirect (e.g. deposit-required) slot (for example, if a user attempts an edit
before updated availability has fully propagated across serving caches):

- **Reject the request** by returning an `UpdateBookingResponse` containing a `booking_failure`.
- **Failure Cause** : Set `booking_failure.cause` to `SLOT_UNAVAILABLE`. This surfaces a clear message to the user (*"Sorry, this time is no longer
  available."*) and prevents incorrect confirmation emails from being sent.
- **Failure Description** : Provide an explicit description (such as `"UpdateBooking not allowed on PR slots"`) in `booking_failure.description` to facilitate logging and troubleshooting.

### Sandbox Testing

Once Payments Redirect is enabled for the partner's integration, this behavior
can be verified directly in the Sandbox environment:

1. Create a standard end-to-end reservation using `CreateBooking`.
2. Provide availability slots with a mix of standard and `PAYMENT_REQUIRED` slots.
3. Open the reservation in the Sandbox booking management view to attempt a modification and confirm that `PAYMENT_REQUIRED` slots appear as unavailable (greyed out).
4. Verify that the server rejects unexpected `UpdateBooking` calls on paid slots with `SLOT_UNAVAILABLE`.