Cómo habilitar los pagos

Nota: Por el momento, Reserva con Google no admite esta función para la nueva funcionalidad de complemento.

Como parte de la integración completa de Reserva con Google, puedes hacer que tus comercios reciban los pagos de los usuarios cuando hacen una reserva o una cita. Google trabaja con procesadores de pagos para configurar la asignación de tokens. Luego, los procesadores de pagos usan tokens únicos para pagarles a los comercios de forma segura.

En el caso de las reservas con pago seguro, procesamos un módulo de Información de pago en el flujo de confirmación de la compra. Esto le permite al usuario ingresar la información de su tarjeta de crédito.

La compatibilidad con 3DS1 y 3DS2 está disponible. Consulta este instructivo sobre la implementación.

Requisitos

Para que tus comercios puedan recibir pagos a través de Reserva con Google, debes cumplir con los siguientes requisitos:

1. Debes usar un procesador de pagos compatible. Puedes encontrar la lista más reciente de procesadores compatibles en el sitio web de Google Pay.
2. Acepta pagos con tokens de acuerdo con tu procesador.
3. No se puede habilitar el pago para reservas que requieren confirmación asíncrona .

Cambios en los feeds y en el servidor de reservas para los pagos

Los pagos se realizan mediante un proceso que debe aceptarse a nivel del comercio. Debes habilitar los pagos para cualquier comercio que necesite recibir un pago por cualquiera de sus servicios. Para habilitar los pagos, debes realizar cambios en los feeds y en el servidor de reservas.

Feeds

• Feed de comercios: Especifica la información de pago mediante el campo tokenization_parameter configurado en el campo tokenization_config. El conjunto depende del procesador de pagos elegido. Este es el mismo conjunto de paymentMethodTokenizationParameters.parameters que se pasaría a Google Pay si se realizara la integración con este.
  Nota: Si cobras pagos en nombre del comercio, puedes proporcionar tus propios parámetros en lugar de los del comercio.
• Feeds de servicios/disponibilidad: Especifica los requisitos de pago según el caso práctico apropiado. Para obtener más información, consulta Casos prácticos de pagos.

Servidor de reservas

• Según el tipo de pago que realicen los usuarios, implementa el método CreateBooking.
• Google enviará tokens de pago en el campo payment_processing_parameters.unparsed_payment_method_token como parte de CreateBookingRequest. Este es el mismo paymentData que recibiría tu devolución de llamada en una integración de Google Pay.
• En CreateBookingResponse, se incluye un mensaje de PaymentInformation que especifica el tipo de pago, el estado, el ID de la transacción y la estructura de precio o tarifa.
• Establece el campo payment_information.payment_processed_by en PROCESSED_BY_PARTNER en CreateBookingResponse.

Casos prácticos para pagos

Cuando decidas si deseas aceptar pagos para cada uno de estos casos prácticos, revisa nuestras Políticas de Pagos y asegúrate de poder satisfacer todas las políticas relevantes.

Estos son algunos casos prácticos de pagos:

• Reservas prepagas completas
• Depósitos requeridos para la reserva
• Tarifas por no presentarse en caso de que el usuario falte a la reserva
• Se requiere tarjeta de crédito para la reserva

Para obtener más información sobre cómo implementar cada uno de estos casos prácticos, consulta el instructivo Configura los pagos.

Reservas prepagadas completas

En la figura 1, se muestra el flujo de actividades entre los usuarios, tú (el socio de calendarización), Google y el procesador de pagos.

Figura 1: Diagrama de la secuencia de reservas prepagas

• Un pago debe ser por el importe total del costo del servicio. En otras palabras, los servicios deben pagarse en su totalidad en el momento de la reserva.

Cambios en los feeds de servicios

• Configura el campo prepayment_type como REQUIRED para ese servicio.
• Configura el campo require_credit_card como REQUIRE_CREDIT_CARD_CONDITIONAL para ese servicio.

Depósitos y tarifas por no presentarse

Los depósitos y las tarifas por no presentarse se configuran de manera similar. En la figura 2, se muestra el flujo de estas actividades entre los usuarios, tú (el socio de calendarización), Google y el procesador de pagos.

Figura 2: Diagrama de la secuencia de reservas con depósitos o tarifas por no presentarse

Los depósitos y las tarifas por no presentarse se pueden usar para garantizar que el usuario vaya a su reserva.

• Se puede cargar un depósito en la tarjeta de crédito del usuario por adelantado o más adelante.
• Se puede cobrar una tarifa por no presentarse al usuario si no se presenta a la reserva.
• Si es necesario, los depósitos y las tarifas por no presentarse se pueden aplicar en conjunto a una reserva.
• Incluso si no se requiere un pago por adelantado, el servidor de reservas debe responder a la solicitud CreateBooking con un PaymentInformation que contenga un payment_transaction_id, que debe ser único. No es necesario que el procesador de pagos proporcione el payment_transaction_id, sino que lo genera el servidor de reservas.

Cambios en los servicios o los feeds de disponibilidad

Los depósitos y las tarifas por no presentarse se pueden especificar a nivel del servicio o el horario disponible de la disponibilidad de un comercio. Si las especificas a nivel del horario disponible, se anulan las definiciones de nivel de servicio.

• Para habilitar los depósitos, configura el campo deposit a nivel del servicio o el horario disponible.
• Para habilitar las tarifas por no presentarse, configura el campo no_show_fee a nivel del servicio o el horario disponible.
• Establece el campo require_credit_card en REQUIRE_CREDIT_CARD_CONDITIONAL a nivel del servicio o el horario disponible.
• Configura prepayment_type como REQUIRED o OPTIONAL (opcional).

Se requiere tarjeta de crédito

Puede haber otros casos prácticos que requieran una tarjeta de crédito al momento de la reserva.

• Establece el campo require_credit_card en REQUIRE_CREDIT_CARD_ALWAYS en el nivel Servicio o en el nivel de espacio Disponibilidad para un comercio.

Cancelaciones y reembolsos

El socio (tú) o el usuario inician las cancelaciones y los reembolsos a través de Reserva con Google. En ambos casos, debes respetar el CancellationPolicy que se estableció en el nivel de servicio y que se comunicó al usuario durante la confirmación de la compra.

Si no proporcionas un CancellationPolicy, se supone que cualquier cancelación dentro del período de cancelación definido por min_advance_online_canceling que se estableció en el nivel de servicio es reembolsable. Si no se definió min_advance_online_canceling, es 0 (lo que significa que se puede cancelar en cualquier momento).

Si debes inhabilitar la cancelación del servicio de Reserva con Google, comunícate con tu POC de Google.

Cambios en las RTU

• Después de proporcionar un reembolso al usuario, debes enviar una actualización de la RTU de la reserva para cambiar el estado de pago de la reserva. Establece update_mask en status,payment_information.prepayment_status y establece payment_information.prepayment_status = PREPAYMENT_REFUNDED y status = CANCELED.
  • Usa los nuevos BookingStatus = CANCELED y PrepaymentStatus = PREPAYMENT_REFUNDED. El valor enumerador CANCELED_AUTOMATIC_REFUND dejó de estar disponible para la API de Maps Booking y las plantillas de gRPC.

Cambio en el servidor de reservas

• Cuando Reserva con Google envía un UpdateBookingRequest y esto genera un reembolso para el usuario, establece booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED en UpdateBookingResponse.