La plataforma de Actions Center admite una variedad de configuraciones para recibir pagos. En la Guía para habilitar pagos, se abordan los aspectos de la integración que son comunes a todas las integraciones de pagos, incluidos los siguientes:
- Cómo configurar feeds para incluir información de
tokenization_parameter - Actualiza el servidor de reservas para que acepte objetos
payment_method_token - Descripción general de la información que se intercambia entre un usuario, el Centro de Acciones, el socio o comercio y el procesador de pagos.
En esta guía, explicaremos con más detalle cómo configurar tus feeds para especificar cuál de los diferentes tipos de configuraciones de pago se aplica a tus comercios y servicios.
- Sin pagos o pago al llegar
- Prepago total
- Tarifa por no presentarse o tarifa de cancelación
- Depósito
Todos los casos de uso de pagos son extensiones del caso de uso de pagos sin pago o pago a la llegada (que no requiere configuración de pagos), por lo que este instructivo comenzará por describir esa configuración y tratará otras configuraciones como extensiones.
En cada sección, también se abordarán los campos de seguimiento en el servidor de reservas para aceptar la configuración de pago específica.
Sin pagos o pago al llegar
En el caso de los servicios que no requieren ningún pago en el momento de la reserva, no se requiere la configuración de pagos a nivel del comercio o del servicio. Sin embargo, los precios siguen siendo obligatorios.
Esta es la configuración del modelo de referencia de un servicio, que contiene un nombre, una descripción y un precio. Este sería un solo mensaje de servicio dentro de un ServiceFeed:
{ "merchant_id": "merchant-1", "service_id": "service-1-a", "name": "Men's haircut", "description": "One of our stylists will cut your hair", "price": { "price_micros": 15000000, "currency_code": "USD" } }
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.
Prepago
Esta configuración se usa para especificar que el importe del servicio se debe pagar en su totalidad en el momento de la reserva.
El pago por adelantado se especifica a nivel del servicio a través del campo prepayment_type de Service. Para solicitar pagos por un servicio, este se debe establecer en REQUIRED, como en el siguiente ejemplo. Ten en cuenta que el precio se especifica de la misma manera que en el ejemplo de pago a la llegada. Aquí, como configuramos el tipo de prepago como obligatorio, se recopilará una tarjeta de crédito y se podrá cobrar este precio en el momento de la confirmación de la compra.
{ "merchant_id": "merchant-1", "service_id": "service-2-b", "name": "Spa Treatment", "description": "A full spa treatment", "price": { "price_micros": "200000000", "currency_code": "USD" } "prepayment_type": "REQUIRED" }
Servidor de reservas
Cuando aceptas pagos por adelantado, 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.
Debes cobrar exactamente el importe especificado en el campo de precio de los feeds y usar la moneda que se indica en ellos. Estos cargos deben seguir el flujo que se describe en la Guía para habilitar pagos.
Cuando se muestra un CreateBookingResponse, el campo booking.payment_information debe configurarse para reflejar correctamente que se proporcionó y procesó el pago por adelantado.
La especificación de PaymentInformation contiene la documentación completa de todas las opciones de información de pago. A continuación, se proporciona un ejemplo mínimo para procesar el pago anticipado. Es importante que el precio que se muestra en el campo de precio coincida exactamente con el que se especifica en la solicitud. Además, si se especifica una tasa impositiva en los feeds o la solicitud, también se debe incluir de forma exacta.
Ten en cuenta que debes proporcionar un ID de transacción. Este ID de transacción debe ser, como mínimo, único entre las transacciones con ese comerciante. Un buen candidato para un ID de transacción es el que te proporciona el procesador de pagos.
{ "prepayment_status": "PREPAYMENT_PROVIDED", "payment_processed_by": "PROCESSED_BY_PARTNER", "payment_transaction_id": "[this-transaction-id]", "price": { "price_micros": "200000000", "currency_code": "USD" } }
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 establecerá 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:
{ "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á autorizado a cobrar una tarifa fija de USD 25, como se especifica en el campo no_show_fee.fee.price_micros, si el titular de la cita no asiste a ella. Esta tarifa también se puede cobrar si el usuario cancela la cita dentro de las 4 horas (14,400 segundos) anteriores, 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.
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 pago por adelantado. Sin embargo, como el token solo está autorizado por un período breve, debes llamar a la API relevante de tu procesador de pagos para actualizarlo a una versión que puedas conservar para usarla más adelante. Esto se describe en la sección de la guía para habilitar pagos sobre el flujo de tokens de la tarifa por no presentarse.
Cuando se muestra un CreateBookingResponse, se debe configurar el campo booking.payment_information para que refleje correctamente el estado de la tarifa por no presentarse, como se muestra en el siguiente ejemplo.
{ "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 no_show_fee está configurado para reflejar el precio y la estructura de la tarifa que se puede cobrar. Además, ten en cuenta que, al igual que en el ejemplo de pagos por adelantado, se requiere un transaction_id en este mensaje.
Además, ten en cuenta que el booking_id configurado 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., si se comunica contigo directamente), puedes cobrar la tarifa de no presentación especificada de forma opcional con la información de pago que almacenaste en el momento de la reserva. Cuando cobras una tarifa por no presentarse, debes enviar una Actualización en tiempo real en la que especifiques que se cobró la tarifa por no presentarse.
En el caso de las reservas creadas por CreateBooking, se debe enviar una actualización a notification.partners.bookings.patch. En el cuerpo de esta solicitud, debe aparecer la reserva actualizada, con el estado establecido como NO_SHOW_PENALIZED. Este estado informa a Google que se realizó un cargo.
Por ejemplo, una solicitud se puede enviar a los siguientes destinos:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Con un cuerpo de solicitud:
{ "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 la reserva. Los depósitos se pueden cobrar en el momento de la reserva o más adelante. Es posible que debas definir en qué condiciones se reembolsa un depósito y cuándo se puede cancelar una reserva en línea.
Para especificar un depósito, en el feed de servicios, debes incluir el campo deposit como se muestra en el siguiente ejemplo:
{ "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 reembolsa el depósito. Ten en cuenta que, en el ejemplo anterior, un depósito puede especificar un tiempo de cancelación por separado de las condiciones de reembolso. En este caso, el usuario podrá cancelar el servicio en línea con hasta 24 horas de anticipación (86,400 segundos). Esto garantiza que el comercio se informe directamente de las cancelaciones tardías. Sin embargo, es posible que el usuario aún sea
apto para recibir un reembolso de su depósito hasta 4 horas con anticipación
(14,400 segundos) antes de la reserva (si se comunica contigo o con el comercio para cancelarla),
que se mostrará en las condiciones de la 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.
Servidor de reservas
Cuando se procesa 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 del pago por adelantado. Si cobras el depósito o quitas la retención en el momento de la reserva, puedes hacerlo durante esta solicitud.
Si deseas cobrar el depósito más adelante, debido a que el token solo está autorizado por un período breve, debes llamar a la API relevante de tu procesador de pagos para actualizar este token a una versión que puedas conservar para usarla más adelante. Esto se describe en la sección de la guía de habilitación de pagos sobre el flujo de tokens de depósito.
Cuando se muestra un CreateBookingResponse, el campo booking.payment_information debe repetir correctamente el estado del depósito, como en el siguiente ejemplo.
{ "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 se establece para reflejar el precio y la estructura del depósito que se cobrará o retendrá. Además, ten en cuenta que, al igual que en el ejemplo de pagos por adelantado, se requiere un transaction_id en este mensaje.
Actualizaciones en tiempo real
Si un usuario cancela su reserva antes del período de cancelación del depósito, debes reembolsar cualquier depósito que hayas cobrado a su tarjeta. Cuando reembolses un depósito, deberás enviar una Actualización en tiempo real en la que especifiques que se reembolsó el depósito.
En el caso de las reservas creadas por CreateBooking, se debe enviar una actualización a notification.partners.bookings.patch. En el cuerpo de esta
solicitud, debe aparecer la reserva actualizada, con el estado configurado como
CANCELED y el campo
paymentInformation.prepaymentStatus configurado como
PREPAYMENT_REFUNDED. De esta manera, se le informa a Google que se reembolsó el depósito.
Por ejemplo, una solicitud se puede enviar a los siguientes destinos:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Con un cuerpo de solicitud:
{ "name": "partners/12345678/bookings/123123123" "merchantId": "merchant-1" "serviceId": "service-2-b" "status": "CANCELED" "paymentInformation": { "prepaymentStatus": "PREPAYMENT_REFUNDED" } }
Se requiere tarjeta de crédito
Es posible que un servicio requiera una tarjeta de crédito como verificación adicional de la identidad del usuario. Sin embargo, no debe usarse para prepagos, depósitos ni tarifas por no presentarse. Si esos casos de uso son necesarios, deben configurarse de forma explícita con los pasos anteriores. Además, ten en cuenta que, a menudo, solicitar una tarjeta de crédito genera una disminución significativa en las reservas de este servicio.
Para exigir que se proporcione una tarjeta de crédito durante la confirmación de la compra, debes configurar el campo require_credit_card en REQUIRE_CREDIT_CARD_ALWAYS.
{ "merchant_id": "merchant-1", "service_id": "service-1-a", "name": "Men's haircut", "description": "One of our stylists will cut your hair", "price": { "price_micros": 15000000, "currency_code": "USD" }, "require_credit_card": "REQUIRE_CREDIT_CARD_ALWAYS" }
Servidor de reservas
Cuando se procesa 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 pago por adelantado. Sin embargo, como el token solo está autorizado por un período breve, debes llamar a la API relevante de tu procesador de pagos para actualizarlo a una versión que puedas conservar para usarla más adelante.
No se requiere información adicional en la respuesta del servidor de reservas más allá de la del caso de uso de pago a la llegada.
Cómo anular los precios a nivel de la 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 del servicio. Sin embargo, en algunos casos, tiene sentido alterar la estructura de pagos para ciertos horarios de disponibilidad. Por ejemplo, se podrían controlar las siguientes situaciones si se anulan los precios o las tarifas a nivel de la disponibilidad:
- Los precios se reducen los martes y aumentan los sábados.
- No se aplican tarifas por no presentarse a la disponibilidad entre las 5:00 p.m. y las 7:00 p.m.
En la siguiente tabla, se indica, para cada método de pago o tarifa, qué campo se debe usar en el feed de disponibilidad para anular la definición del nivel de servicio.
| Tipo de pago | Definición de tarifas o precios | ¿Se puede anular? |
|---|---|---|
| Pagar al llegar | Service.price
|
El precio se puede anular a través de una referencia de Availability.payment_option_id a Merchant.payment_option.
|
| Prepago | Service.price
|
El precio se puede anular a través de una referencia de Availability.payment_option_id a Merchant.payment_option.
|
| Tarifa por no presentarse | Service.no_show_fee
|
Availability.no_show_fee
|
| Depósito | Service.deposit
|
Availability.deposit
|
| Se requiere 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, para obtener orientación sobre cómo agregar ventanas de cancelación a nivel de la disponibilidad, consulta la guía Cómo agregar ventanas de cancelación.