Pagamentos padrão do Google:

Forma de pagamento tokenizada

Informações gerais

Uma FOP (forma de pagamento) tokenizada é um tipo de integração de pagamento na plataforma de pagamentos. Para que um usuário faça um pagamento com essa forma de pagamento, o Google e o integrador de pagamentos precisam fazer uma troca única das credenciais de identidade da conta. Isso, por sua vez, passa pelo fluxo de estabelecer um token, representando essa forma de pagamento para aquele usuário específico. Esse token pode ser usado para pagamento repetidamente. No momento, existem duas versões dessas APIs. A versão 2 é compatível com operadoras de celular e provedores de números de referência. Todos os outros provedores de FOP tokenizadas devem implementar a versão 1. O restante deste documento se concentra na versão 1.

O Google usa dois fluxos para estabelecer a identidade e criar esse token:

1. Fluxo de autenticação: identifica e verifica (autentica) o usuário.
2. Fluxo de associação: estabelece um token para um usuário (novo ou previamente identificado e autenticado). Esse token representa uma determinada forma de pagamento por um usuário específico. O token poderá ser usado em compras futuras.

Assim que o token for estabelecido, o Google o usará durante o fluxo de compra para que o usuário tenha uma experiência de pagamento rápida e integrada. O Google usa esse token para representar uma instância de uma forma de pagamento de um cliente. Isso também é chamado de instrumento. Um cliente do Google pode ter mais de um instrumento para pagar por produtos e serviços.

Por fim, todo o movimento de dinheiro entre o banco do integrador e o banco do Google é feito no fluxo de remessa.

1) O usuário seleciona um produto para comprar.

2) Em seguida, ele seleciona uma forma de pagamento.

3) Agora essa pessoa adicionou uma nova forma de pagamento.

4) Eles são redirecionados para autenticação

5) Por fim, eles são autenticados e podem comprar.

Este diagrama ilustra uma visão geral ampla dos fluxos:

Visão geral da FOP tokenizada

De modo geral, a inclusão do seu serviço como uma forma de pagamento nos produtos do Google envolve os seguintes fluxos:

1. Fluxo de autenticação
2. Fluxo de associação
3. Fluxo de compra
4. Fluxo de reembolso
5. Fluxo de remessa

Esses fluxos são descritos com mais detalhes nas seções abaixo e com ainda mais detalhes na seção de guias.

Conceitos e terminologia

Símbolos e convenções

As palavras-chave "PRECISA", "NÃO PODE", "OBRIGATÓRIO", "DEVE", "NÃO DEVE", "DEVE", "NÃO DEVE", "RECOMENDADO", "PODE" e "OPCIONAL" nestes documentos devem ser interpretadas conforme descrito na RFC 2119 (em inglês).

Marcações de tempo

Todos os carimbos de data/hora são representados em milissegundos desde a época Unix (1o de janeiro de 1970) em UTC.

Exemplo:

• 23 de abril de 2019, 20:23:25 GMT = 155.6051005.000 milissegundos
• 16 de agosto de 2018, 12h28min35s GMT = 1534422515000 milissegundos

Valores

Os valores monetários nesta API estão no formato "micros", um padrão do Google. Micros são um formato de precisão fixa e baseado em números inteiros. Para representar um valor monetário em micros, multiplique o valor da moeda padrão por 1.000.000.

Exemplo:

• USD 1,23 = 1230.000 micro USD
• USD 0,01 = 10.000 micro USD

Idempotência

Todas as chamadas de método nessa API precisam ter comportamento idempotente. O Google repetirá as solicitações esporadicamente para garantir que as transações estejam no mesmo estado em ambos os lados. Os integradores não podem tentar reprocessar solicitações já processadas. A resposta de processamento bem-sucedido deve ser informada. Todos os métodos têm um RequestHeader comum que contém um requestId. Esse requestId é a chave de idempotência para todas as chamadas.

Qualquer resposta que não seja de terminal (uma operação sem HTTP 200) não pode ser processada de maneira idempotente. Portanto, uma solicitação que anteriormente recebeu um erro 400 (solicitação inválida/pré-condição com falha), quando chamada pela segunda vez, não deve retornar 400 de maneira idempotente, ela precisa ser reavaliada. Na reavaliação, ela pode retornar um erro 400 ou ser processada.

Para mais informações sobre idempotência, consulte este guia detalhado.

Integrador

Uma empresa que usa a plataforma de pagamentos do Google nos negócios. Pode ser um conteúdo interno (próprio, como YouTube ou Google AdWords) ou uma empresa externa (3P) que quer integrar o serviço para trabalhar com o ecossistema do Google.

Forma de pagamento

Forma de Pagamento. Isso é mais geral do que um instrumento. Visa, MasterCard e PayPal são FOPs.

Instrumento

Uma instância específica de uma forma de pagamento realizada por um cliente específico. Por exemplo, o cartão de crédito de um usuário ou a conta do PayPal dele. Uma FOP tokenizada para um cliente específico também é um instrumento, porque é uma instância de uma forma de pagamento para aquele cliente, armazenada com segurança no nosso sistema.

Token

Uma representação no sistema do Google da forma de pagamento de um usuário específico. Como ele contém todas as informações necessárias para fazer uma compra, o token também é um instrumento. Isso pode incluir informações como um número de conta que o usuário tem no integrador.

Fluxos de chaves

Fluxo de autenticação

A autenticação é o primeiro fluxo que precisa ocorrer. O objetivo do fluxo de autenticação é identificar e autenticar o usuário no integrador. A autenticação pode ocorrer de várias maneiras. As FOPs tokenizadas oferecem duas maneiras de identificar e autenticar o usuário:

1. Autenticação de OTP por SMS-MT (SMS encerrado, senha única)
2. Autenticação de redirecionamento

Durante a integração, os integradores trabalham com o Google para escolher os mecanismos de autenticação mais adequados ao produto.

Os fluxos de autenticação podem ser usados em dois contextos: primeiro, para identificar um novo cliente, a fim de fazer uma associação, e, segundo, para desafiar um usuário a solicitar as credenciais de um instrumento existente. O resultado do fluxo de autenticação pode ser usado como entrada para vários fluxos, como o fluxo de associação, o fluxo de token de atualização, o fluxo de compra com desafio e assim por diante. Além disso, o fluxo de autenticação pode ser usado no modo autônomo, não vinculado a nenhum fluxo subsequente.

Autenticação de OTP por SMS-MT

Nesse mecanismo de autenticação, o usuário insere um número de telefone em uma interface do Google. O Google envia esse número de telefone para o integrador (usando o método sendOtp). O integrador envia uma senha única ao usuário. O usuário digita a senha na interface do Google, que a envia para o integrador. Isso aciona uma resposta de sucesso pelo integrador de pagamentos.

Quando a autenticação de OTP por SMS-MT é usada no modo independente, o valor da OTP é enviado ao integrador usando o método verifyOtp. Esse método verifica se a OTP fornecida foi a enviada.

Autenticação de redirecionamento

A autenticação de redirecionamento ocorre quando o Google redireciona o usuário para um aplicativo de propriedade do integrador. Esse aplicativo pode ser da Web ou para Android.

Os redirecionamentos para Android e Web se comportam de maneira semelhante. O Google redireciona o usuário para o app do integrador. O integrador identifica e autentica o usuário da forma mais natural para ele. Depois da autenticação, o integrador redireciona o usuário de volta à IU do Google para concluir a associação. Após o redirecionamento, o Google fornece um requestId para identificar essa sessão de autenticação. Esse identificador é usado como um comprovante de autenticação durante a Associação.

Os integradores que escolhem esse fluxo precisam fornecer um URL de autenticação da Web, porque esse é o denominador mais comum em todas as plataformas (computador ou dispositivo móvel). No entanto, a autenticação do Android é altamente recomendada, porque oferece a melhor experiência do usuário em dispositivos móveis.

Dependendo do contexto do dispositivo e dos apps instalados, as IUs do Google escolherão o redirecionamento de app para Android ou Web.

Esse mecanismo de autenticação dá mais liberdade ao integrador. Há muitas maneiras de autenticar e identificar um usuário. Nome de usuário e senha ou informações biométricas e perguntas de segurança são soluções viáveis. O Google não pretende ditar como um integrador verifica um usuário. O integrador autentica o usuário. Dessa forma, o Google pretende usar as várias interfaces de usuário do integrador para autenticar o usuário e simplesmente fornecer ao Google um comprovante de autenticação.

Observação :se o integrador for usar a OTP por SMS-MT durante o redirecionamento, o Google sugerirá que você use a autenticação de OTP por SMS-MT já mencionada. Ele oferece ao usuário uma experiência mais integrada nos Serviços do Google.

Para mais informações sobre autenticação, consulte este guia detalhado.

Fluxo de associação

Após o fluxo de autenticação por meio de um dos mecanismos mencionados acima, o usuário passa pelo fluxo de associação. O objetivo do fluxo de associação é estabelecer um token do Google Payments (GPT) para a criação de um instrumento. Esse fluxo faz o seguinte:

1. Negocia uma identidade chamada token para representar este usuário.
2. Fornece informações da conta para informar o mecanismo de risco do Google.
3. Coleta as informações necessárias de configuração inicial para criar e estabelecer o GPT.

O resultado é que o Google e o integrador definem o GPT estabelecido.

Dois usuários do Google podem compartilhar a mesma conta de usuário com o integrador. Nesse caso, cada usuário teria um instrumento diferente. Para cada instrumento, há um fluxo de associação independente e, portanto, um GPT exclusivo.

Esta ilustração vai ajudar você a usar uma FOP tokenizada falsa chamada InvisiCash. Isso demonstra as etapas que um usuário segue para os fluxos de autenticação e associação.

Visão geral do fluxo de associação

1. Um usuário do Google com o endereço de e-mail [e-mail] quer adicionar a conta do InvisiCash à Google Play Store para usá-la em compras.
2. A Google Play Store abre o aplicativo InvisiCash para fazer a autenticação.

3. A usuária faz login na conta do InvisiCash com o endereço de e-mail [e-mail]. Talvez ela use o endereço de e-mail do Gmail em ambos se esse for o login da conta do InvisiCash.

   Observação :há outras formas de autenticação. Esse é apenas um exemplo. É possível até mesmo na Web, e não em um app.

4. O app InvisiCash envia o ID de autenticação de volta à Google Play Store.

5. A Google Play Store envia o ID de autenticação aos servidores do Google.

6. O servidor do Google envia uma mensagem ao servidor do InvisiCash para associar a conta. Essa associação inclui um ID de autenticação, um GPT (token de pagamento do Google) e um ID de associação.

7. Os servidores do InvisiCash armazenam o Google Payment Token (GPT) e o ID de associação. Ambos agora estão associados à conta InvisiCash de Sally.

8. O InvisiCash aprova esta associação. Em seguida, os servidores do Google criam um instrumento que pode ser usado para compras futuras.