Configura diferentes tipos de pago

La plataforma de Actions Center admite una variedad de configuraciones por recibir pagos. El La guía para habilitar pagos abarca los aspectos de la integración que son comunes a todas las integraciones de pagos, incluidas las siguientes:

1. Configura feeds para incluir información de tokenization_parameter
2. Actualizando el servidor de reservas para aceptar payment_method_token objetos
3. Visión general de la información que se intercambia entre un usuario, el Centro de acciones, entre el socio o el comercio y el procesador de pagos.

En esta guía, veremos con más detalle cómo configura tus feeds para especificar cuál de los diferentes configuración de pagos sea aplicable a tus comercios y servicios.

1. Sin pagos / pago al llegar
2. Prepago completo
3. Tarifa por no presentarse o de cancelación
4. Depósito

Todos los casos de uso de pagos son extensiones de la opción "sin pagos" de pago al llegar a destino (que no requiere configuración de pagos), por lo que comienza por describir esa configuración y tratar otras de configuraciones como extensiones.

En cada sección, también se cubrirán los campos a los que se debe hacer un seguimiento en la servidor de reservas con el fin de aceptar el pago específico configuración.

Sin pagos / 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 en el comercio o servicio. a nivel de organización. Sin embargo, los precios aún son obligatorios.

Esta es la configuración del modelo de referencia de un servicio, que contiene un nombre, descripción y precio. Sería un solo mensaje de Service en un 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 al llegar.

Prepago

Esta configuración se usa para especificar que la cantidad se deben pagar en su totalidad en el momento de la reserva.

El prepago se especifica en el nivel de servicio mediante el prepayment_type del campo Service Para solicitar pagos por un servicio que se debe configurar 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 al llegar. Toma Debido a que establecimos el tipo de prepago como obligatorio, se utilizará una tarjeta de crédito y este precio podrá cobrarse en el momento de la confirmación de la compra.

Punto clave: A menos que se especifique lo contrario con cancellation_policy (uso limitado, consulta con tu PDC de Google) se asume que "cancelable" significa 100% reembolsable. Asegúrate de configurar correctamente ventana de cancelación.

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

Al aceptar prepagos, se transfiere un token de pago a tu reserva servidor en la llamada para CreateBooking a través del campo payment_processing_parameters.unparsed_payment_method_token Debes cobrar exactamente el importe especificado mediante el 'precio' [price] en los feeds, y debes usar la moneda especificadas en los feeds. Estos cargos deben seguir el flujo que se describe en la Guía para habilitar pagos

Cuando se devuelve un CreateBookingResponse el campo booking.payment_information se debe configurar como refleje que se proporcionó y procesó el prepago.

El La especificación PaymentInformation contiene información completa documentación para todas las opciones de información de pago. Un ejemplo mínimo para el procesamiento del prepago se proporciona a continuación. Es importante que el precio que se devuelven en el campo de precio coinciden exactamente con lo que se especifica en el para cada solicitud. Además, si se especifica una tasa impositiva en los feeds o las solicitudes, también deben incluirse exactamente.

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 con ese comercio. R buen candidato para un ID de transacción es el ID de transacción proporcionado a a través del 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

Se pueden cobrar tarifas por no presentarse si no asiste al reserva o si se cancela después de la ventana de cancelación. Si no se especifica un período de cancelación, la hora de inicio predeterminada del horario disponible.

Para especificar una tarifa por no presentarse, incluye en el feed de servicio la siguiente información 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 tasa fija de USD 25, según se especifica en no_show_fee.fee.price_micros si el titular de la cita no asiste a la cita. Esta tarifa también puede cobrarse si el usuario se cancela dentro de las 4 horas (14,400 segundos) antes de la cita, especificadas en el scheduling_rules.min_advance_online_canceling .

Punto clave: A menos que se especifique lo contrario con cancellation_policy (uso limitado, consulta con tu PDC de Google) se asume que "cancelable" significa 100% reembolsable. Asegúrate de configurar correctamente ventana de cancelación.

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 crea un token se pasan 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 la opción de prepago para determinar si este es el caso. Sin embargo, debido a que el token solo se autoriza durante un período breve debes llamar a la API correspondiente de tu procesador de pagos para actualiza este token a una versión que puedas conservar para su uso a un en el futuro. Esto se describe en la sección de la guía Habilita los pagos. activado Flujo de token de tarifa por no presentarse:

Cuando se devuelve un CreateBookingResponse el campo booking.payment_information se debe configurar para Repite el estado de la tarifa por no presentarse, 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"
    }
    "no_show_fee": {
        "fee": {
            "price_micros": 25000000,
            "currency_code": "USD"
        }
        "fee_type": "FIXED_RATE_DEFAULT"
    }
}

Ten en cuenta que se configuró no_show_fee para reflejar el precio y la estructura de la tarifa que se puede cobrar. Además, ten en cuenta que, al igual que con el ejemplo de prepagos, se requiere un transaction_id en este mensaje.

Además, ten en cuenta que el booking_id establecido en el CreateBookingResponse es un campo obligatorio para las actualizaciones en tiempo real que se deben enviar cuando se realiza la carga 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., comunicándose directamente con usted), puede cobrar opcionalmente la tarifa por no presentarse especificada usando la información de pago que almacenaste en el momento de la reserva. Cuando cobras una tarifa por no presentarte, debes enviar un Actualización en tiempo real en la que se especifica que se cobró la tarifa por no presentarse.

Para las reservas creadas por CreateBooking, se debe enviar una actualización a notification.partners.bookings.patch En el cuerpo de esta solicitud la reserva actualizada, con el estado establecido en NO_SHOW_PENALIZED Este estado informa a Google que se aplicó un cargo en la nube.

Por ejemplo, se podría enviar una solicitud a la siguiente dirección:

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 recaudar un cargo inicial como requisito para reserva. Los depósitos se pueden cobrar en el momento de la reserva o más adelante tiempo. Es posible que debas definir las condiciones en las que se puede reembolsar el depósito como así como Cuándo se puede cancelar una reserva en línea.

Para especificar un depósito, en el feed de servicio debes incluir la 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, min_advance_online_canceling define la ventana de cancelación y la 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 tiempo de cancelación separado de las condiciones del reembolso. En este caso, el usuario podrá cancelar el servicio en línea hasta 24 horas antes (86,400 segundos). Esto garantiza que el comercio informar directamente sobre cualquier cancelación tardía. Sin embargo, es posible que el usuario apto para un reembolso en su depósito hasta 4 horas antes (14,400 segundos) antes de la reserva (comunicándose contigo o con el comercio para su cancelación) que se mostrará en las condiciones en el momento de la confirmación de la compra y en el correo electrónico de confirmación.

Punto clave: A menos que se especifique lo contrario con cancellation_policy (uso limitado, consulta con tu PDC de Google) deposit.min_advance_cancellation_sec, se asume que "cancelable" significa 100% reembolsable. Asegúrate de configurar correctamente ventana de cancelación.

Para ver cómo se pueden definir los depósitos a nivel de disponibilidad, consulta esta sección.

Servidor de reservas

Al procesar una solicitud que incluye un depósito, se crea un token de pasan 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 cobrar el depósito o retirar la retención en el momento de la reserva, puedes hacerlo durante esta solicitud.

Si piensas cobrar el depósito más adelante, ya que el token del solo se autorizó por un período breve, debes llamar al la API correspondiente de tu procesador de pagos para actualizar este token a un que puedes conservar para usarlos en otro momento. Este es como se describe en la sección Habilita los pagos en flujo de token de depósito.

Cuando se devuelve un CreateBookingResponse: el campo booking.payment_information debe reproducir correctamente el estado del depósito, 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"
    }
    "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 con el ejemplo de prepagos, 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, tú debe reembolsar cualquier depósito que haya cobrado a la tarjeta del usuario. Cuándo reembolsar un depósito, debes enviar un Actualización en tiempo real que especifica 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 este de entrada debe ser la reserva actualizada, con el estado establecido en CANCELED y las Se estableció el campo paymentInformation.prepaymentStatus en PREPAYMENT_REFUNDED Esto informa a Google que el depósito se se reembolsó.

Por ejemplo, se podría enviar una solicitud a la siguiente dirección:

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

Es posible que los servicios requieran de una tarjeta de crédito como complemento la verificación de la identidad del usuario. Sin embargo, no debe usarse para prepago, depósitos o tarifas por no presentarse. Si esos casos de uso son se deben configurar de forma explícita con los pasos arriba. Además, ten en cuenta que solicitar una tarjeta de crédito a menudo genera una 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 para 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

Al procesar una solicitud que incluye un requisito de tarjeta de crédito, se puede token se pasa 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 la opción de prepago para determinar si este es el caso. Sin embargo, debido a que el token solo se autoriza durante un período breve debes llamar a la API correspondiente de tu procesador de pagos para actualiza este token a una versión que puedas conservar para su uso a un en el futuro.

No se requiere información adicional en la respuesta del servidor de reservas más allá del caso de uso de pago al llegar.

Anula precios en el nivel de disponibilidad

En todos los ejemplos anteriores, se especifica la estructura de precios y tarifas. a nivel del servicio. En la mayoría de los casos, estos precios por nivel de servicio que se usan. Sin embargo, en algunos casos, tiene sentido modificar la estructura de pagos. para determinados horarios disponibles. Por ejemplo, las siguientes situaciones se podría manejar anulando los precios o las tarifas a nivel de disponibilidad:

• Los precios se reducen los martes y se aumentan los sábados.
• Las tarifas por no presentarse se aplican a la disponibilidad entre las 5:00 p.m. y las 7:00 p.m.

En la siguiente tabla, se indica qué campo corresponder a cada forma de pago o tarifa 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 reemplazable hasta Referencia de Availability.payment_option_id Merchant.payment_option
Prepago	Service.price	El precio se puede anular hasta Referencia de Availability.payment_option_id 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, como guía para agregar períodos de cancelación a nivel de disponibilidad, consulta la guía Cómo agregar ventanas de cancelación.