Esta página foi traduzida pela API Cloud Translation.

Informações gerais

Como parte da integração completa de reservas da Central de ações, você pode permitir que seus comerciantes recebam pagamentos de usuários quando eles 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 reservas protegidas por pagamento, renderizamos um módulo de Informações de pagamento no fluxo de finalização da compra. Isso permite que o usuário insira as informações do cartão de crédito.

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

Qualificação

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

Usar um processador de pagamento compatível. A lista mais recente desses processadores está disponível no site do Google Pay.
Aceitar pagamentos tokenizados de acordo com o processador.
Conclua o processo de verificação de identidade e de empresa descrito aqui.
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. Ative os pagamentos para os comerciantes que precisarem receber pagamentos por serviços prestados. Para ativar os pagamentos, faça mudanças nos feeds e no servidor de agendamento.

Feeds

Feed do comerciante:especifique as informações de pagamento usando o tokenization_parameter definido no campo tokenization_config. O conjunto depende do processador de pagamentos escolhido. Esse conjunto é o mesmo de paymentMethodTokenizationParameters.parameters que seria transmitido ao Google Pay se você fosse integrado a ele.
Observação:se você recebe pagamentos em nome do comerciante, pode fornecer seus próprios parâmetros em vez dos parâmetros dele.
Feeds de serviços/disponibilidade: especifique os requisitos de pagamento com base no seu caso de uso apropriado. Para mais detalhes, consulte Casos de uso para pagamentos.

Servidor de agendamento

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

Casos de uso para pagamentos

Para decidir se aceita pagamentos para cada um desses 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:

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 os usuários, você (o parceiro de agendamento), o Google e o processador de pagamentos.

Figura 1: diagrama de sequência de reservas pré-pagas — **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.

Mudanças 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 agendamentos de taxa de não comparecimento ou depósitos — **Figura 2**:diagrama da sequência de agendamentos de depósitos ou taxas de não comparecimento

Depósitos e taxas de não comparecimento podem ser usados para garantir que o usuário compareça ao agendamento.

Um depósito pode ser cobrado no cartão de crédito do usuário antecipadamente ou mais tarde.
Uma taxa de não comparecimento poderá ser cobrada do usuário se ele não aparecer no agendamento.
Se necessário, os depósitos e as taxas de não comparecimento podem ser aplicados juntos na reserva.
Mesmo que não haja necessidade de pagamento antecipado, o servidor de reserva 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.

Mudanças nos feeds de disponibilidade ou serviços

Os depósitos e as taxas de não comparecimento podem ser especificados no nível do Serviço ou do espaço de Disponibilidade de um comerciante. Se você especificá-los no nível do espaço disponível, isso modificará as definições no nível de 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

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 que foi definido no nível do serviço e informado ao usuário na finalização da compra.

Se você não informar o CancellationPolicy, vai presumir que qualquer cancelamento dentro da janela definida por min_advance_online_canceling definida no Nível de serviço será reembolsável. Se a min_advance_online_canceling não estiver definida, o valor será 0, o que pode ser cancelado a qualquer momento.

Se você precisar desativar o cancelamento na Central de ações, converse com seu POC do Google.

Mudanças nas RTUs

Depois de fornecer um reembolso ao usuário, envie uma RTU de reserva atualizada para alterar o status de pagamento da reserva. Defina update_mask como status,payment_information.prepayment_status e 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 para os modelos gRPC.

Mudar para o servidor de agendamento

Quando a Central de ações enviar um UpdateBookingRequest e acionar um reembolso para o usuário, defina booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED no UpdateBookingResponse.