Definir diferentes tipos de pagamento

A plataforma da Central de ações oferece suporte a diversas configurações por receber pagamentos. A O Guia de ativação de pagamentos abrange os aspectos da integração que são comuns a todas as integrações de pagamentos, incluindo:

1. Como configurar feeds para incluir informações de tokenization_parameter
2. Atualizando o servidor de agendamento para aceitar payment_method_token objetos
3. Informações gerais sobre as informações trocadas entre um usuário, a Central de ações o parceiro / comerciante e o processador de pagamentos.

Neste guia, vamos saber mais sobre como configure seus feeds para especificar quais dos diferentes tipos de são aplicáveis aos seus comerciantes e serviços.

1. Sem pagamentos / pagamento na chegada
2. Pré-pagamento total
3. Taxa de não comparecimento / taxa de cancelamento
4. Depósito

Todos os casos de uso para pagamentos são extensões da ausência de pagamentos. / pagamento na chegada (que não requer configuração de pagamento), por isso, tutorial começa descrevendo essa configuração e tratando outras configurações como extensões.

Cada seção também abrange os campos a serem acompanhados na servidor de reserva para aceitar o pagamento específico. configuração do Terraform.

Sem pagamentos / pagamento na chegada

Para serviços que não exigem pagamento no momento da reserva, Nenhuma configuração de pagamento é necessária no comerciante ou serviço. nível No entanto, os preços ainda são obrigatórios.

Essa é a configuração de valor de referência para um serviço, que contém um nome, descrição e preço. Seria uma única mensagem de serviço em um ServiceFeed:

{
    "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"
    }
}

Nenhuma outra configuração é necessária além da implementação padrão. no servidor de reserva para aceitar o pagamento na chegada.

Pré-pagamento

Essa configuração é usada para especificar que a quantidade de devem ser pagos integralmente no momento da reserva.

O pré-pagamento é especificado no nível de serviço por meio de prepayment_type do Service. Para exigir pagamentos por um serviço que este precisa ser definido como REQUIRED, como no exemplo abaixo. Observe que o preço é especificado da mesma forma que no exemplo de pagamento na chegada. Aqui, porque estamos definindo o tipo de pré-pagamento como obrigatório, um cartão de crédito foi coletado, e esse preço pode ser cobrado no momento da finalização da compra.

{
    "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 agendamento

Ao aceitar pré-pagamentos, um token de pagamento é transmitido para sua reserva na chamada para CreateBooking no campo payment_processing_parameters.unparsed_payment_method_token Você deve cobrar exatamente o valor especificado por meio do preço nos feeds, e é necessário usar a moeda especificado nos feeds. Essas cobranças devem seguir o fluxo descrito no Guia de ativação de pagamentos.

Ao retornar um CreateBookingResponse o campo booking.payment_information deve ser definido como indicam que o pré-pagamento foi fornecido e processado.

A A especificação PaymentInformation contém documentação para todas as opções de informações de pagamento. Um exemplo mínimo para o processamento do pré-pagamento é fornecido abaixo. É importante que o preço retornado no campo de preço corresponder exatamente ao especificado solicitação. Além disso, se uma taxa fiscal for especificada nos feeds/na solicitação, ela também precisam ser incluídas.

Você também precisa fornecer um ID da transação. Este ID de transação precisam, no mínimo, ser exclusivos entre as transações do comerciante. Um um bom candidato a ID de transação é o ID de transação fornecido ao para você pelo processador de pagamentos.

{
    "prepayment_status": "PREPAYMENT_PROVIDED",
    "payment_processed_by": "PROCESSED_BY_PARTNER",
    "payment_transaction_id": "[this-transaction-id]",
    "price": {
        "price_micros": "200000000",
        "currency_code": "USD"
    }
}

Taxa de não comparecimento

Taxas de não comparecimento podem ser cobradas de um usuário se ele não comparecer ao reserva ou se cancelarem após o janela de cancelamento. Se nenhuma janela de cancelamento for especificada, será definido por padrão como o horário de início do espaço.

Para especificar uma taxa de não comparecimento, inclua no feed de serviço o seguinte: no_show_fee, como mostrado no exemplo abaixo:

{
    "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"
    }
}

No exemplo acima, o parceiro ou comerciante está autorizado a cobrar uma taxa fixa de US $25,00, conforme especificado no_show_fee.fee.price_micros se o responsável pelo agendamento não comparecer ao agendamento. Essa taxa também poderá ser cobrada se o usuário cancela dentro de 4 horas (14.400 segundos) antes do agendamento, conforme especificado em scheduling_rules.min_advance_online_canceling .

Para acessar como as taxas de não comparecimento podem ser definidas no nível de disponibilidade, consulte nesta seção.

Servidor de agendamento

Ao processar uma solicitação que inclui uma taxa de não comparecimento, um token de pagamento é transmitido para o servidor de agendamento na chamada CreateBooking no campo payment_processing_parameters.unparsed_payment_method_token Esse token é transmitido da mesma maneira que na fase de pré-pagamento caso. No entanto, como o token só é autorizado por um curto período, tempo, você precisa chamar a API relevante do seu processador de pagamentos para atualize esse token para uma versão que você possa persistir para uso em mais tarde. Isso é descrito na seção do guia "Ativar pagamentos" ativado Fluxo de token de Taxa de não comparecimento.

Ao retornar um CreateBookingResponse o campo booking.payment_information deve ser definido como corretamente Repita o status da taxa de não comparecimento, como no exemplo abaixo.

{
    "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"
    }
}

Observe que no_show_fee está definido para refletir o preço e estrutura da taxa que pode ser cobrada. Observe também que, assim como exemplo de pré-pagamentos, é necessário um transaction_id nesta mensagem.

Observe também que o booking_id definido no CreateBookingResponse é um campo obrigatório para as atualizações em tempo real que devem ser enviadas ao carregar uma taxa de não comparecimento. Espera-se que esse ID seja armazenado com informações sobre a reserva.

Atualizações em tempo real

Se um usuário não chegar para o agendamento programado ou cancelar a assinatura Depois da janela de cancelamento (por exemplo, entrando em contato diretamente com você), pode cobrar a taxa de não comparecimento especificada usando as informações de pagamento armazenados no momento da reserva. Quando você cobra uma taxa de não comparecimento, precisa enviar um Atualização em tempo real especificando que a taxa de não comparecimento foi cobrada.

Para agendamentos criados por CreateBooking, uma atualização será enviada para notification.partners.bookings.patch No corpo dessa solicitação, deve ser a reserva atualizada, com o status definido como NO_SHOW_PENALIZED: Esse status informa ao Google que uma cobrança foi feitas.

Por exemplo, uma solicitação pode ser enviada para:

PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status

Com um corpo de solicitação:

{
    "name": "partners/12345678/bookings/123123123"
    "merchantId": "merchant-1"
    "serviceId": "service-2-b"
    "status": "NO_SHOW_PENALIZED"
}

Depósito

Os depósitos são usados para coletar uma cobrança inicial como requisito para reserva. Os depósitos podem ser cobrados no momento da reserva ou depois tempo de resposta. Talvez seja necessário definir sob quais termos um depósito pode ser reembolsado como bem como quando um agendamento pode ser cancelado on-line.

Para especificar um depósito, no feed de serviços, você deve incluir o campo deposit, como mostrado no exemplo abaixo:

{
    "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"
    }
}

Neste exemplo, min_advance_online_canceling define a janela de cancelamento e o deposit.min_advance_cancellation_sec define quando o depósito será reembolsável. No exemplo acima, um depósito pode especificar um o horário de cancelamento separadamente dos termos de reembolso. Nesse caso, o usuário pode cancelar o serviço on-line com até 24 horas de antecedência (86.400 segundos). Isso garante que o comerciante seja diretamente informados sobre cancelamentos tardios. No entanto, o usuário ainda pode ser qualificado para reembolso do depósito com até quatro horas de antecedência (14.400 segundos) antes do agendamento (ao entrar em contato com você ou com o comerciante para fazer o cancelamento) que aparece nos termos ao finalizar a compra e no e-mail de confirmação.

Para ver como os depósitos podem ser definidos no nível de disponibilidade, consulte nesta seção.

Servidor de agendamento

Ao processar uma solicitação que inclui um depósito, um token de pagamento é transmitidos para o servidor de agendamento na chamada CreateBooking no campo payment_processing_parameters.unparsed_payment_method_token Esse token é transmitido da mesma maneira que no caso de pré-pagamento. Se você cobrar o depósito ou retirar a retenção no momento da reserva, você pode fazer isso durante a solicitação.

Se você pretende cobrar o depósito em um momento posterior, como o token for autorizado apenas por um curto período, você deve chamar o método API relevante do seu processador de pagamentos para atualizar esse token em um que você pode manter para usar em outro momento. Isso é descritos na seção do guia "Ativar pagamentos" fluxo de token de depósito.

Ao retornar um CreateBookingResponse, o campo booking.payment_information precisa repetir corretamente o status do depósito, como no exemplo abaixo.

{
    "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"
    }
}

O depósito está definido para refletir o preço e a estrutura do que será cobrado ou retido. Observe também que, assim como exemplo de pré-pagamentos, é necessário um transaction_id nesta mensagem.

Atualizações em tempo real

Se um usuário cancelar a reserva antes da janela de cancelamento do depósito, você deverá reembolsar qualquer depósito cobrado no cartão do usuário. Quando reembolso de um depósito, você deverá enviar um Atualização em tempo real especificando que o depósito foi reembolsado.

Para agendamentos criados por CreateBooking, uma atualização será enviada para notification.partners.bookings.patch No corpo do deve ser a reserva atualizada, com o status definido como CANCELED e o O campo paymentInformation.prepaymentStatus foi definido como PREPAYMENT_REFUNDED Isso informa ao Google que o depósito foi feito reembolsados.

Por exemplo, uma solicitação pode ser enviada para:

PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status

Com um corpo de solicitação:

{
    "name": "partners/12345678/bookings/123123123"
    "merchantId": "merchant-1"
    "serviceId": "service-2-b"
    "status": "CANCELED"
    "paymentInformation": {
      "prepaymentStatus": "PREPAYMENT_REFUNDED"
    }
    
}

Exigir cartão de crédito

Um serviço pode exigir um cartão de crédito como valor adicional a verificação da identidade do usuário. No entanto, ele não deve ser usado de pré-pagamento, depósitos ou taxas de não comparecimento. Se esses casos de uso forem precisam ser configurados explicitamente usando as etapas acima. Além disso, solicitar um cartão de crédito geralmente resulta queda significativa no número de reservas desse serviço.

Para exigir o fornecimento de um cartão de crédito durante a finalização da compra, defina o campo require_credit_card para REQUIRE_CREDIT_CARD_ALWAYS.

{
    "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 agendamento

Ao processar uma solicitação que inclui uma exigência de cartão de crédito, um pagamento é transmitido ao seu servidor de agendamento na chamada CreateBooking no campo payment_processing_parameters.unparsed_payment_method_token Esse token é transmitido da mesma maneira que na fase de pré-pagamento caso. No entanto, como o token só é autorizado por um curto período, tempo, você precisa chamar a API relevante do seu processador de pagamentos para atualize esse token para uma versão que você possa persistir para uso em mais tarde.

Nenhuma informação adicional é necessária na resposta do servidor de agendamento além do caso de uso de pagamento na chegada.

Substituição de preços no nível de disponibilidade

Em todos os exemplos acima, a estrutura de preço / taxa é especificada. no nível de serviço. Na maioria dos casos, esses preços de nível de serviço usados. Em alguns casos, no entanto, faz sentido alterar a estrutura de pagamentos para determinados horários disponíveis. Por exemplo, as seguintes situações pode ser resolvida substituindo os preços / taxas no nível de disponibilidade:

• Os preços são reduzidos às terças-feiras e aumentam aos sábados.
• As taxas de não comparecimento se aplicam à disponibilidade entre 17h e 19h.

A tabela abaixo lista, para cada forma de pagamento / taxa, os campos a serem usar no feed de disponibilidade para substituir a definição de nível de serviço.

Para substituir o preço no nível de disponibilidade, primeiro é preciso definir uma opção de pagamento no nível do comerciante. Além disso, para orientação sobre como adicionar janelas de cancelamento em nível de disponibilidade, consulte o guia Como adicionar janelas de cancelamento.