Visão geral

Observação:no momento, o Centro de ações não oferece suporte a esse recurso para novas funcionalidades de complementos.

Como parte da integração completa de reservas do Centro de ações, você pode permitir que seus comerciantes recebam pagamentos quando os usuários fizerem um agendamento, um compromisso ou uma reserva. O Google trabalha com processadores de pagamento para configurar a tokenização. Eles usam tokens exclusivos para pagar os comerciantes com segurança.

Para agendamentos protegidos por pagamento, processamos um módulo de Informações de pagamento no fluxo de finalização da compra. Com isso, o usuário pode inserir as informações do cartão de crédito.

O suporte para 3DS1 e 3DS2 está disponível. Consulte este tutorial para saber mais sobre a implementação.

Qualificação

Para que seus comerciantes recebam pagamentos pelo Centro de ações, você precisa atender aos seguintes requisitos:

1. Usar um processador de pagamento compatível. A lista mais recente de processadores compatíveis pode ser encontrada no site do Google Pay.
2. Aceitar pagamentos tokenizados de acordo com o processador.
3. Conclua o processo de verificação de identidade e da empresa descrito aqui.
4. O pagamento não pode ser ativado para reservas que exigem confirmação assíncrona .

Alterações nos feeds e no servidor de agendamento para pagamentos

Os pagamentos são feitos por meio de um processo de ativação no nível do comerciante. É necessário ativar os pagamentos para os comerciantes que precisam receber pagamentos por serviços prestados. Para ativar os pagamentos, é necessário fazer mudanças nos feeds e no servidor de agendamento.

Feeds

• Feed do comerciante:especifique as informações de pagamento por meio do conjunto tokenization_parameter no campo tokenization_config. O conjunto depende do processador de pagamentos escolhido. Esse é o mesmo conjunto de paymentMethodTokenizationParameters.parameters que seria transmitido ao Google Pay se você o integrasse à ferramenta.
  Observação:se você receber pagamentos em nome do comerciante, poderá informar os próprios parâmetros em vez dos do comerciante.
• Feeds de serviços/disponibilidade:especifique os requisitos de pagamento com base no seu caso de uso. Para mais detalhes, consulte Casos de uso para pagamentos.

Servidor de agendamento

• Com base no tipo de pagamento que os usuários estão fazendo, implemente o método CreateBooking
• O Google vai enviar tokens de pagamento no campo payment_processing_parameters.unparsed_payment_method_token como parte do CreateBookingRequest. Esse é o mesmo paymentData que seria recebido pelo seu callback em uma integração do Google Pay.
• Em CreateBookingResponse, inclua uma mensagem PaymentInformation que especifique o tipo de pagamento, o status, o ID da transação e a estrutura de preço / taxa.
• Defina o campo payment_information.payment_processed_by como PROCESSED_BY_PARTNER no CreateBookingResponse.

Casos de uso para pagamentos

Ao decidir se aceita pagamentos para cada um destes casos de uso, consulte nossas políticas de pagamentos e verifique se você está em conformidade com todas as políticas relevantes.

Estes são os casos de uso para pagamentos:

• Concluir agendamentos pré-pagos
• Depósitos necessários para o agendamento
• Taxas de não comparecimento se o usuário não honrar o agendamento
• Cartão de crédito obrigatório para o agendamento

Para mais informações sobre como implementar cada um desses casos de uso, consulte o tutorial sobre Como configurar pagamentos.

Concluir agendamentos pré-pagos

A Figura 1 mostra o fluxo de atividades entre usuários, você (o parceiro de agendamento), o Google e o processador de pagamentos.

Figura 1: diagrama da sequência de agendamentos pré-pagos

• O pagamento precisa corresponder a 100% do valor do serviço. Em outras palavras, os serviços precisam ser pagos integralmente no momento da reserva.

Alterações nos feeds de serviços

• Defina o campo prepayment_type como REQUIRED para esse serviço.
• Defina o campo require_credit_card como REQUIRE_CREDIT_CARD_CONDITIONAL para esse serviço.

Depósitos e taxas de não comparecimento

Essas duas atividades são configuradas de maneira semelhante. A Figura 2 mostra o fluxo dessas atividades entre usuários, você (o parceiro de agendamento), o Google e o processador de pagamentos.

Figura 2: diagrama da sequência de agendamento com depósito ou taxa de não comparecimento

Os depósitos e as taxas de não comparecimento podem ser usados para garantir que um usuário compareça.

• Um depósito pode ser cobrado no cartão de crédito do usuário antecipadamente ou após o compromisso.
• A taxa de não comparecimento pode ser cobrada se o usuário não aparecer no horário agendado.
• Se necessário, os depósitos e as taxas de não comparecimento podem ser aplicados juntos em um agendamento.
• Mesmo que não haja necessidade de pagamento antecipado, o servidor de agendamento precisa responder à solicitação CreateBooking com um PaymentInformation contendo um payment_transaction_id, que precisa ser exclusivo. O payment_transaction_id não precisa ser fornecido pelo processador de pagamentos, mas pode ser gerado pelo servidor de agendamento.

Alterações nos feeds de serviços ou disponibilidade

Depósitos e taxas de não comparecimento podem ser especificados no nível do serviço ou do espaço disponível para um comerciante. Se você os especificar no nível do espaço disponível, isso substituirá as definições no nível do serviço.

• Para ativar os depósitos, defina o campo deposit no nível do serviço ou do espaço disponível.
• Para ativar as taxas de não comparecimento, defina o campo no_show_fee no nível do serviço ou do espaço disponível.
• Defina o campo require_credit_card como REQUIRE_CREDIT_CARD_CONDITIONAL no nível do serviço ou do espaço disponível.
• (Opcional) Defina prepayment_type como REQUIRED ou OPTIONAL.

Cartão de crédito obrigatório

Pode haver outros casos de uso que exigem um cartão de crédito no momento da reserva.

• Defina o campo require_credit_card como REQUIRE_CREDIT_CARD_ALWAYS no nível do serviço ou do espaço disponível de um comerciante.

Cancelamentos e reembolsos

Os cancelamentos e reembolsos são iniciados pelo parceiro (você) ou pelo usuário na Central de ações. Em ambos os casos, é preciso respeitar o CancellationPolicy definido no nível de serviço e comunicado ao usuário na finalização da compra.

Se você não fornecer CancellationPolicy, presumiremos que qualquer cancelamento dentro do período de cancelamento definido por min_advance_online_canceling que foi definido no nível de serviço é reembolsável. Se min_advance_online_canceling não estiver definido, será 0 (o que significa que pode ser cancelado a qualquer momento).

Se você precisar desativar o cancelamento no Actions Center, converse com seu POC do Google.

Mudanças nos RTUs

• Depois de reembolsar o usuário, envie uma RTU de atualização de reserva para mudar o status de pagamento da reserva. Defina update_mask como status,payment_information.prepayment_status e defina payment_information.prepayment_status = PREPAYMENT_REFUNDED e status = CANCELED.
  • Use os novos BookingStatus = CANCELED e PrepaymentStatus = PREPAYMENT_REFUNDED. O valor de enumeração CANCELED_AUTOMATIC_REFUND foi descontinuado para a API Maps Booking e os modelos gRPC.

Mudar para o servidor de agendamento

• Quando o Actions Center envia uma UpdateBookingRequest e isso aciona um reembolso para o usuário, defina booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED no UpdateBookingResponse.