Descripción general

Como parte de la integración de extremo a extremo de Reservas de Actions Center, puedes habilitar a tus comercios para que reciban pagos de los usuarios cuando hagan una reserva, una cita o una reserva. 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.

Para las reservas con pago seguro, procesamos un módulo de Información de pago en el flujo de confirmación de la compra. Esto permite que el usuario ingrese la información de su tarjeta de crédito.

Se ofrece compatibilidad con 3DS1 y 3DS2. Consulta este instructivo sobre la implementación.

Elegibilidad

Para que tus comercios reciban pagos a través del Centro de Acciones, 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. Completa el proceso de verificación de identidad y de empresa que se describe aquí.
4. No se puede habilitar el pago para reservas que requieran una 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 pagos por cualquiera de sus servicios. Para habilitar los pagos, se deben realizar cambios en los feeds y en el servidor de reservas.

Feeds

• Feed de comercios: Especifica la información de pago a través del tokenization_parameter configurado en el campo tokenization_config. El conjunto depende del procesador de pagos elegido. El conjunto es el mismo conjunto de paymentMethodTokenizationParameters.parameters que se pasaría a Google Pay si la integraras a la plataforma.
• Feeds de servicios/disponibilidad: Especifica los requisitos de pago según el caso de uso adecuado. Para obtener más detalles, consulta Casos prácticos de pagos.

Servidor de reservas

• Implementa el método CreateBooking según el tipo de pago que realicen los usuarios.
• 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 la CreateBookingResponse, incluye un mensaje de PaymentInformation que especifique el tipo de pago, el estado, el ID de la transacción y la estructura de precios o tarifas.
• Establece el campo payment_information.payment_processed_by en PROCESSED_BY_PARTNER en CreateBookingResponse.

Casos prácticos para pagos

Cuando decidas si recibir pagos para cada uno de estos casos prácticos, revisa nuestras Políticas de Pagos y asegúrate de cumplir con todas las políticas pertinentes.

Estos son los casos de uso de los 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 Cómo configurar los pagos.

Reservas prepagadas completas

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

• Un pago debe ser por el importe total del costo del servicio. Es decir, los servicios se deben pagar en su totalidad en el momento de la reserva.

Cambios en los feeds de servicios

• Establece el campo prepayment_type en REQUIRED para ese servicio.
• Establece el campo require_credit_card en 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 planificación), Google y el procesador de pagos.

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

• Se puede cargar un depósito en la tarjeta de crédito del usuario por adelantado o posteriormente.
• 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 para 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 el servidor de reservas puede generarlo.

Cambios en los feeds de servicios o disponibilidad

Los depósitos y las tarifas por no presentarse se pueden especificar en el nivel del Servicio o el del horario de Disponibilidad para un comercio. Si los especificas a nivel del horario disponible, se anulan las definiciones a nivel del 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.
• (Opcional) Configura prepayment_type como REQUIRED o OPTIONAL.

Se requiere tarjeta de crédito

Puede haber otros casos de uso que requieran una tarjeta de crédito en el momento de la reserva.

• Establece el campo require_credit_card en REQUIRE_CREDIT_CARD_ALWAYS a nivel del Servicio o en el nivel del horario disponible de Disponibilidad para un comercio.

Cancelaciones y reembolsos

El socio (tú) o el usuario inicia las cancelaciones y los reembolsos a través del Centro de acciones. En ambos casos, debes respetar el CancellationPolicy que se estableció a nivel del Servicio y que se le informó al usuario en la confirmación de la compra.

Si no proporcionas CancellationPolicy, se considerará que cualquier cancelación dentro del período de cancelación definido por min_advance_online_canceling que se haya establecido en el nivel de servicio es reembolsable. Si no se define min_advance_online_canceling, es 0 (lo que significa que se puede cancelar en cualquier momento).

Si debes inhabilitar la cancelación desde el Centro de acciones, habla 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. Configura update_mask como status,payment_information.prepayment_status y configura payment_information.prepayment_status = PREPAYMENT_REFUNDED y status = CANCELED.
  • Usa los nuevos valores BookingStatus = CANCELED y PrepaymentStatus = PREPAYMENT_REFUNDED. El valor enum CANCELED_AUTOMATIC_REFUND dejó de estar disponible para la API de Maps Booking y las plantillas de gRPC.

Cambio al servidor de reservas

• Cuando el Centro de acciones envía un UpdateBookingRequest y esto activa un reembolso para el usuario, configura booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED en UpdateBookingResponse.