Descripción general

Como parte de la integración de reservas de extremo a extremo del Centro de Acciones, puedes hacer que los comercios opten por recibir pagos de los usuarios cuando hacen 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 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 su implementación.

Requisitos

Para que tus comercios puedan recibir 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 la empresa que se describe aquí.
4. No se puede habilitar el pago para las reservas que requieren 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 todos los comercios que necesiten 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 mediante el conjunto tokenization_parameter, establecido en el campo tokenization_config. El conjunto depende del procesador de pagos elegido. Además, es el mismo conjunto de paymentMethodTokenizationParameters.parameters que se pasaría a Google Pay si la integración fuese con este servicio.
• Feeds de servicios/disponibilidad: Especifica los requisitos de pago según el caso de uso que resulte adecuado para ti. Para obtener más detalles, consulta Casos de uso 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 la CreateBookingRequest. Este es el mismo paymentData que recibiría tu devolución de llamada en una integración de Google Pay.
• En el CreateBookingResponse, incluye un mensaje de PaymentInformation que especifique 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 aceptarás pagos para cada uno de estos casos de uso, revisa nuestras Políticas de Pagos y asegúrate de poder satisfacer todas las políticas relevantes.

Estos son los casos de uso para 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 de uso, consulta el instructivo sobre 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 programación), Google y el procesador de pagos.

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

Cambios en los feeds de servicios

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

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

• Se puede cobrar un depósito en la tarjeta de crédito del usuario por adelantado o más tarde.
• Se puede cobrar una tarifa por no presentarse si el usuario falta 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, ya que también puede generarlo el servidor de reservas.

Cambios en los feeds de servicios o disponibilidad

Los depósitos y las tarifas por no presentarse se pueden especificar a nivel del Servicio o el horario indicado en la Disponibilidad de 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). Establece prepayment_type en 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.

• Configura el campo require_credit_card como REQUIRE_CREDIT_CARD_ALWAYS a nivel del Servicio o del horario indicado en la Disponibilidad de un comercio.

Cancelaciones y reembolsos

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

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

Si debes inhabilitar la cancelación desde el lado de Actions Center, comunícate con tu punto de contacto de Google.

Cambios en las RTU

• Después de proporcionar un reembolso al usuario, debes enviar una RTU de actualización de reserva para cambiar el estado de pago de la reserva. Establece update_mask en 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 enumerador CANCELED_AUTOMATIC_REFUND dejó de estar disponible para la API de Maps Booking y las plantillas de gRPC.

Cambia al servidor de reservas

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