La plataforma del Centro de acciones admite una variedad de configuraciones para recibir pagos. La guía para habilitar pagos abarca los aspectos de la integración que son comunes a todas las integraciones de pagos, incluidos los siguientes:
- Configura feeds para que incluyan información de
tokenization_parameter - Actualiza el servidor de reservas para aceptar objetos
payment_method_token - Una descripción general de la información intercambiada entre un usuario, el Centro de acciones, 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 configuraciones de pago se aplica a tus comercios y servicios.
- Sin pagos o pago al llegar
- Prepago completo
- 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 ningún pago o pago por llegada (que no requiere configuración de pago), por lo que en este instructivo comenzará la descripción de esa configuración y tratará otras configuraciones como extensiones.
En cada sección, también se abarcan los campos de los que se debe hacer un seguimiento en el servidor de reservas para aceptar la configuración de pagos 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 ninguna configuración de pagos a nivel del comercio o servicio. Sin embargo, los precios siguen siendo obligatorios.
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 una ServiceFeed:
JSON
{
"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 en el momento de la llegada.
Prepago
Esta configuración se utiliza para especificar que el importe del servicio se debe pagar en su totalidad en el momento de la reserva.
El prepago se especifica en el nivel de servicio a través del campo
prepayment_type de
Service. Para exigir pagos por un servicio, se debe configurar como REQUIRED, como en el siguiente ejemplo. Ten en cuenta que el precio se especifica de la misma manera que en el ejemplo de pago por llegada. En este caso, como configuramos el tipo de prepago como obligatorio, se cobrará una tarjeta de crédito y se podrá cobrar este precio en el momento de la confirmación de la compra.
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"
}
"prepayment_type": "REQUIRED"
}
Servidor de reservas
Cuando se aceptan prepagos, 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 que se especifica en el campo de precio de los feeds y utilizar la moneda especificada en los feeds. Estos cargos deben seguir el flujo descrito en la guía de habilitación de pagos.
Cuando se muestra un CreateBookingResponse, se debe configurar el campo booking.payment_information para que refleje correctamente que se proporcionó y procesó el prepago.
La especificación PaymentInformation contiene la documentación completa para todas las opciones de información de pago. A continuación, se incluye un ejemplo mínimo para
procesar el prepago. 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 con exactitud.
Además, ten en cuenta que debes proporcionar un ID de transacción. Este ID de transacción debe, como mínimo, ser único entre las transacciones realizadas con ese comercio. Un buen candidato para un ID de transacción es el ID de transacción que te proporciona el procesador de pagos.
JSON
{
"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
Las tarifas por no presentarse pueden cobrarse a un usuario si este no asiste a su reserva o si cancela después de transcurrido el 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 a
cobrar un cargo de tarifa fija de $25, como se especifica en el
campo no_show_fee.fee.price_micros, si el titular de la cita
no asiste a la cita. Esta tarifa también se puede cobrar si el usuario cancela dentro de las 4 horas (14,400 segundos) antes de la cita, 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 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
prepago. Sin embargo, debido a que el token solo se autoriza por un período breve, debes llamar a la API correspondiente de tu procesador de pagos para actualizarlo a una versión que puedas conservar para usar en otro momento. Esto se describe en la sección de la guía de habilitación de pagos en el flujo de token de tarifa por no presentarse.
Cuando se muestra un CreateBookingResponse, se debe configurar el campo booking.payment_information para repetir correctamente 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 el valor de no_show_fee se establece 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 prepago, en este mensaje se requiere un transaction_id.
Además, ten en cuenta que el valor de 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 cancela la reserva después del período de cancelación (p.ej., comunicándose directamente contigo), tienes la opción de cobrar la tarifa especificada por no presentarte con la información de pago que almacenaste en el momento de la reserva. Cuando cobras una tarifa por no presentarte, debes enviar una actualización en tiempo real que especifique que se cobró esa tarifa.
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 le informa a Google que se realizó un cargo.
Por ejemplo, se podría enviar una solicitud 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 utilizan para cobrar un cargo inicial como requisito para las reservas. 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, en el feed de servicios, debes incluir el campo deposit, 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, el min_advance_online_canceling define el período de cancelación y el deposit.min_advance_cancellation_sec define cuándo es reembolsable el depósito. Ten en cuenta que, en el ejemplo anterior, un depósito puede especificar una hora de cancelación separada de las condiciones de reembolso. En este caso, un usuario podrá cancelar el servicio en línea hasta 24 horas antes (86,400 segundos). De esta manera, se garantiza que se informe directamente al comercio sobre cualquier cancelación tardía. Sin embargo, es posible que el usuario cumpla con los requisitos para recibir un reembolso del depósito hasta 4 horas antes (14,400 segundos) antes de la reserva (es decir, si se comunica contigo o con el comercio para solicitar su cancelación), lo que se mostrará en las condiciones durante 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 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 de prepago. 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 correspondiente de tu procesador de pagos para actualizar este token a una versión que puedas conservar para usar en otro momento. Este proceso se describe en la sección sobre el flujo de tokens de depósito en la guía de habilitación de pagos.
Cuando se muestra un CreateBookingResponse, el campo booking.payment_information debe repetir correctamente el estado del depósito, como 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 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 prepago, en este mensaje se requiere un transaction_id.
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 cargado a la tarjeta del usuario. Cuando se reembolsa 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 configurado en PREPAYMENT_REFUNDED. De esta manera, se informa a Google que se reembolsó el depósito.
Por ejemplo, se podría enviar una solicitud 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 para verificar 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, se deben configurar de forma explícita siguiendo los pasos anteriores. Además, ten en cuenta que solicitar una tarjeta de crédito suele generar una disminución significativa en las reservas de este servicio.
Para solicitar 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": "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 al 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 se autoriza por un período breve, debes llamar a la API correspondiente de tu procesador de pagos para actualizarlo a una versión que puedas conservar para usar en otro momento.
No se requiere información adicional en la respuesta del servidor de reservas, además de la del caso de uso de pago por llegada.
Anula precios en el 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 debe usar este precio a nivel de servicio. Sin embargo, en algunos casos, conviene modificar la estructura de pagos para determinados horarios disponibles. Por ejemplo, las siguientes situaciones se podrían controlar anulando los precios o las tarifas en el nivel de disponibilidad:
- Los precios se reducen los martes y aumentan los sábados.
- 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, para cada método de pago o tarifa, se indica qué campo usar en el feed de disponibilidad para anular la definición del nivel de servicio.
| Tipo de pago | Definición de Tarifa / Precio | ¿Se puede anular? |
|---|---|---|
| Pagar al llegar | Service.price
|
Precio que se puede anular a través de Availability.payment_option_id que hace referencia a Merchant.payment_option
|
| Prepago | Service.price
|
El precio se puede anular a través de Availability.payment_option_id que haga referencia a Merchant.payment_option.
|
| 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 disponibilidad, primero debes definir una opción de pago a nivel del comercio. Además, si deseas 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.