La plataforma de Reserva con Google admite una variedad de configuraciones para realizar pagos. La Guía para habilitar pagos abarca los aspectos comunes a todas las integraciones de pagos, incluidos los siguientes:
- Configurar feeds para incluir información de
tokenization_parameter - Actualiza el servidor de reservas para que acepte objetos
payment_method_token - Una descripción general de la información intercambiada entre un usuario, Reserva con Google, el socio o comercio y el procesador de pagos.
En esta guía, analizaremos en más detalle cómo configurar tus feeds para especificar cuál de los diferentes tipos de configuración de pagos se aplica a tus comercios y servicios.
- Sin pagos ni pagar al llegar
- Prepago completo
- Tarifa por no presentarse / cancelación
- Depósito
Todos los casos prácticos de pagos son extensiones del caso práctico sin pagos o pago a la llegada (que no requiere configuración de pago), por lo que este instructivo comenzará a describir esa configuración y tratará otras configuraciones como extensiones.
En cada sección, también se abarcarán los campos a los que se hará un seguimiento en el servidor de reservas para aceptar la configuración de pagos específica.
Sin pagos ni pagar al llegar
En el caso de los servicios que no requieren ningún pago en el momento de la reserva, no se requiere ninguna configuración de pagos a nivel del comercio o del servicio.
Esta es la configuración de referencia para un servicio, que contiene un nombre, una descripción y un precio. Este sería un solo mensaje de servicio dentro de un ServiceFeed:
JSON
{
"merchant_id": "merchant-1",
"service_id": "reservation",
"name": "reservation",
"description": "Food reservation"
}
No se requiere ninguna configuración adicional más allá de la implementación estándar en el servidor de reservas para admitir el pago a la llegada.
Tarifa por no presentarse
Se pueden cobrar tarifas por no presentarse a un usuario si no asiste a su reserva o si la cancela después del período de cancelación. Si no se especifica un período de cancelación, se usará de forma predeterminada la hora de inicio del horario disponible.
Para especificar una tarifa por no presentarse, en el feed de servicios, debes incluir el campo no_show_fee como se muestra en el siguiente ejemplo:
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-2-b",
"name": "Spa Treatment",
"description": "A full spa treatment",
"price": {
"price_micros": 200000000,
"currency_code": "USD"
}
"scheduling_rules": {
"min_advance_online_canceling": 14400,
}
"no_show_fee": {
"fee": {
"price_micros": 25000000,
"currency_code": "USD"
}
"fee_type": "FIXED_RATE_DEFAULT"
}
}
En el ejemplo anterior, el socio o el comercio están autorizados para cobrar un cargo fijo de USD 25, como se especifica en el campo no_show_fee.fee.price_micros si el titular de la cita no asiste a la cita. Es posible que esta tarifa también se cobre si el usuario cancela la membresía antes de las 4 horas (14,400 segundos), como se especifica en el campo scheduling_rules.min_advance_online_canceling.
Para ver cómo se pueden definir las tarifas por no presentarse a nivel de la disponibilidad, consulta esta sección.
De forma opcional, se puede configurar la tarifa por no presentarse para que se cobre por la reserva por persona. En este caso, no_show_fee.fee.fee_type se puede establecer en PER_PERSON.
Servidor de reservas
Cuando se procesa una solicitud que incluye una tarifa por no presentarse, se pasa un token de pago a tu servidor de reservas en la llamada a CreateBooking a través del campo payment_processing_parameters.unparsed_payment_method_token.
Este token se pasa de la misma manera que en el caso de prepago. Sin embargo, debido a que el token solo está autorizado por un período corto, debes llamar a la API relevante de tu procesador de pagos para actualizarlo a una versión que puedas conservar para su uso más adelante. Esto se describe en la sección Guía de habilitación de pagos, en Flujo de tokens de tarifa por no presentarse.
Cuando se muestra un campo CreateBookingResponse, se debe configurar el campo booking.payment_information para que refleje de forma adecuada el estado de la tarifa por no presentarse, como se muestra en el siguiente ejemplo.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
"no_show_fee": {
"fee": {
"price_micros": 25000000,
"currency_code": "USD"
}
"fee_type": "FIXED_RATE_DEFAULT"
}
}
Ten en cuenta que la no_show_fee está configurada para reflejar el precio y la estructura de la tarifa que se puede cobrar. Además, ten en cuenta que, de manera similar al ejemplo de prepago, se requiere un transaction_id en este mensaje.
Además, ten en cuenta que el campo booking_id establecido en CreateBookingResponse es un campo obligatorio para las actualizaciones en tiempo real que se deben enviar cuando se cobra una tarifa por no presentarse. Se espera que este ID se almacene junto con la información sobre la reserva.
Actualizaciones en tiempo real
Si un usuario no llega a su reserva programada o la cancela después del período de cancelación (p.ej., contactándote directamente), es posible que se te cobre la tarifa por no presentarse usando la información de pago que almacenaste en el momento de la reserva. Cuando se cobra una tarifa por no presentarse, debes enviar una actualización en tiempo real en la que se especifique que se cobró la tarifa por no presentarse.
Para las reservas creadas por CreateBooking, se debe enviar una actualización a notification.partners.bookings.patch. En el cuerpo de esta solicitud, se debe incluir
la reserva actualizada, con el estado establecido en
NO_SHOW_PENALIZED. Este estado informa a Google que se realizó un cargo.
Por ejemplo, una solicitud podría enviarse a:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Con un cuerpo de solicitud:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "NO_SHOW_PENALIZED"
}
Depósito
Los depósitos se usan para cobrar un cargo inicial como requisito para hacer la reserva. Los depósitos se pueden cobrar al momento de la reserva o más adelante. Es posible que debas definir en qué condiciones se puede reembolsar un depósito y cuándo se puede cancelar una reserva en línea.
Para especificar un depósito, debes incluir el campo deposit en el feed de servicio como se muestra en el siguiente ejemplo:
JSON
{
"merchant_id": "merchant-1",
"service_id": "service-2-b",
"name": "Spa Treatment",
"description": "A full spa treatment",
"price": {
"price_micros": 200000000,
"currency_code": "USD"
}
"scheduling_rules": {
"min_advance_online_canceling": 86400,
}
"deposit": {
"deposit": {
"price_micros": 25000000,
"currency_code": USD,
"min_advance_cancellation_sec": 14400,
}
"deposit_type": "FIXED_RATE_DEFAULT"
}
}
En este ejemplo, min_advance_online_canceling define el período de cancelación y deposit.min_advance_cancellation_sec define cuándo se realiza el depósito reembolsable. Ten en cuenta que en el ejemplo anterior, un depósito puede especificar una hora de cancelación diferente de las condiciones de reembolso. En este caso, el usuario podrá cancelar el servicio en línea hasta 24 horas antes (86400 segundos). Esto garantiza que se informe directamente al comercio sobre cualquier cancelación tardía. Sin embargo, es posible que el usuario sea apto para un reembolso de su depósito hasta 4 horas antes (14,400 segundos) antes de la reserva (se comunica contigo o con el comercio para cancelar), lo que se mostrará en las condiciones de confirmación de la compra y en el correo electrónico de confirmación.
Para ver cómo se pueden definir los depósitos a nivel de la disponibilidad, consulta esta sección.
Ten en cuenta que, al igual que las tarifas por no presentarse, un depósito se puede cobrar a una tarifa fija o por persona. En este caso, el depósito es una tarifa fija de USD 25, como lo especifica "deposit_type": "FIXED_RATE_DEFAULT". Si la reserva incluye una
cantidad de personas, el depósito podría especificarse como un depósito por persona si
se establece "deposit_type": "PER_PERSON".
Servidor de reservas
Cuando procesas una solicitud que incluye un depósito, se pasa un token de pago a tu servidor de reservas en la llamada a CreateBooking a través del campo payment_processing_parameters.unparsed_payment_method_token.
Este token se pasa de la misma manera que en el caso de prepago. Si
cobras el depósito o quitas la retención en el momento de la reserva, puedes
hacerlo durante esta solicitud.
Si quieres cobrar el depósito más adelante, porque el token solo está autorizado por un período corto, debes llamar a la API relevante de tu procesador de pagos para actualizar este token a una versión que puedas conservar para su uso más adelante. Esto se describe en la sección Guía de habilitación de los pagos, en Flujo de tokens de depósito.
Cuando se muestra un campo CreateBookingResponse, el campo booking.payment_information debe repetir el estado del depósito, como se muestra en el siguiente ejemplo.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
"deposit": {
"deposit": {
"price_micros": 25000000,
"currency_code": USD,
"min_advance_cancellation_sec": 28800,
}
"deposit_type": "FIXED_RATE_DEFAULT"
}
}
Ten en cuenta que el depósito está configurado para reflejar el precio y la estructura del depósito que se cobrará o retendrá. Además, ten en cuenta que, de manera similar al ejemplo de prepago, se requiere un transaction_id en este mensaje.
Actualizaciones en tiempo real
Si un usuario cancela su reserva antes de que finalice el período de cancelación, deberás reembolsar el depósito que se haya cobrado a la tarjeta de usuarios. Cuando realizas el reembolso de un depósito, debes enviar una actualización en tiempo real que especifique que se reembolsó el depósito.
Para las reservas creadas por CreateBooking, se debe enviar una actualización a notification.partners.bookings.patch. En el cuerpo de esta solicitud, se debe incluir la reserva actualizada, con el estado establecido en CANCELED y el campo paymentInformation.prepaymentStatus establecido en PREPAYMENT_REFUNDED. De esta manera, se informa a Google que se reembolsó el depósito.
Por ejemplo, una solicitud podría enviarse a:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Con un cuerpo de solicitud:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "CANCELED"
"paymentInformation": {
"prepaymentStatus": "PREPAYMENT_REFUNDED"
}
}
Solicitar tarjeta de crédito
Un servicio puede requerir una tarjeta de crédito como verificación adicional de la identidad del usuario. Sin embargo, no se debe usar para prepagos, depósitos ni tarifas por no presentarse. Si esos casos prácticos son necesarios, deben configurarse explícitamente de acuerdo con los pasos anteriores. Además, ten en cuenta que solicitar una tarjeta de crédito a menudo genera una reducción significativa en las reservas para este servicio.
Para requerir que se proporcione una tarjeta de crédito durante la confirmación de la compra, debes configurar el campo require_credit_card como REQUIRE_CREDIT_CARD_ALWAYS.
JSON
{
"merchant_id": "merchant-1",
"service_id": "reservation",
"name": "reservation",
"description": "Food reservation",
"require_credit_card": "REQUIRE_CREDIT_CARD_ALWAYS"
}
Servidor de reservas
Cuando procesas una solicitud que incluye un requisito de tarjeta de crédito, se pasa un token de pago a tu servidor de reservas en la llamada a CreateBooking a través del campo payment_processing_parameters.unparsed_payment_method_token.
Este token se pasa de la misma manera que en el caso de prepago. Sin embargo, debido a que el token solo está autorizado por un período corto, debes llamar a la API relevante de tu procesador de pagos para actualizarlo a una versión que puedas conservar para su uso más adelante.
No se requiere información adicional en la respuesta del servidor de reservas más allá de la del caso práctico del pago por llegar.
Anula los precios a nivel de disponibilidad
En todos los ejemplos anteriores, la estructura de precios o tarifas se especifica a nivel del servicio. En la mayoría de los casos, se deben usar estos precios a nivel de servicio. Sin embargo, en algunos casos, tiene sentido modificar la estructura de pagos para ciertos horarios disponibles. Por ejemplo, las siguientes situaciones se pueden abordar si anulas los precios o las tarifas a nivel de disponibilidad:
- Los precios se reducen los martes y aumentan los sábados.
- La tarifa por no presentarse se aplica a la disponibilidad entre las 5:00 p.m. y las 7:00 p.m.
- Se requieren depósitos para grupos de personas que sean mayores de 6.
- Para reservar en una habitación determinada, se requiere una tarjeta de crédito.
En la siguiente tabla, se indica qué campo usar con cada forma de pago o tarifa en el feed de disponibilidad para anular la definición de nivel de servicio.
| Tipo de pago | Definición de tarifa / precio | ¿Se puede anular? |
|---|---|---|
| Tarifa por no presentarse | Service.no_show_fee
|
Availability.no_show_fee
|
| Depósito | Service.deposit
|
Availability.deposit
|
| Solicitar tarjeta de crédito | Service.require_credit_card
|
Availability.require_credit_card
|
Ten en cuenta que, para anular el precio a nivel de la disponibilidad, primero debes definir una opción de pago a nivel del comercio. Además, si quieres obtener orientación para agregar períodos de cancelación a nivel de disponibilidad, consulta la guía Cómo agregar ventanas de cancelación.