Pagamentos padrão do Google:

FOP tokenizada

Visão geral

Uma FOP (forma de pagamento) tokenizada é um tipo de integração de pagamentos na Plataforma de pagamentos. Para que um usuário faça um pagamento com essa FOP, o Google e o integrador de pagamentos precisam fazer uma troca única de credenciais de identidade da conta. Isso, por sua vez, passa pelo fluxo de estabelecimento de um token, que representa essa forma de pagamento para esse usuário específico. Esse token pode ser usado para pagamento várias vezes. No momento, existem duas versões dessas APIs. A versão 2 suporta operadoras de celular e operadoras de números de referência. Todos os outros provedores FOP tokenizados 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 (autenticar) 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 forma de pagamento específica por parte de um usuário. O token poderá ser usado em compras futuras.

Depois que o token for estabelecido, o Google o usará durante o fluxo de compra para proporcionar ao usuário uma experiência de pagamento rápida e integrada. O Google usa esse token para representar uma instância de uma forma de pagamento feita por 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, toda a movimentação de dinheiro entre o banco do integrador e o banco do Google é feita no fluxo de remessa.

1) O usuário seleciona um produto para comprar

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

3) Agora, ele adiciona 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 mostra uma visão geral dos fluxos:

Visão geral da FOP tokenizada

De modo geral, a inclusão do seu serviço como uma forma de pagamento aos produtos do Google envolve estes 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 em mais detalhes nas seções abaixo e em mais detalhes na seção de guias.

Conceitos e terminologia

Símbolos e Convenções

As palavras-chave “PRECISA”, "NÃO PODE", "OBRIGATÓRIO" "SHALL", "NÃO DEVE" "DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "MAIO", e "OPTIONAL" nestes documentos devem ser interpretados conforme descrito em RFC 2119.

Carimbos de data/hora

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 = 1556051005000 milissegundos
• 16 de agosto de 2018 12:28:35 GMT = 1534422515.000 milissegundos

Valores

Os valores monetários nessa API estão em um formato chamado "micros", é um padrão no Google. Micros são um formato de precisão fixa 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:

• US$1,23 = 1230.000 microUSD
• US$0,01 = 10.000 microUSD

Idempotência

Todas as chamadas de método nessa API precisam ter comportamento idempotente. O Google vai repetir as solicitações esporadicamente para garantir que as transações estejam no mesmo estado nos dois lados. Os integradores não podem tentar reprocessar solicitações que já foram processadas. Em vez disso, a resposta do 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 não terminal (uma não HTTP 200 bem-sucedida) não pode ser processada de forma idempotente. Portanto, uma solicitação que antes recebeu um erro 400 (solicitação inválida/pré-condição com falha), quando chamada uma segunda vez, não pode retornar 400 de maneira idempotente e precisa ser reavaliada. Na reavaliação, ele pode retornar um erro 400 ou ser processado com êxito.

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

Integrador

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

Forma

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 feita por um cliente específico. Por exemplo, o cartão de crédito de um usuário ou a conta do PayPal. Uma FOP tokenizada para um determinado cliente também é um instrumento, porque é uma instância de uma forma de pagamento para esse cliente, armazenada com segurança em 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, um token também é um instrumento. Isso pode incluir informações como um número de conta que um usuário tem com o integrador.

Principais fluxos

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 suporte a duas maneiras de identificar e autenticar o usuário:

1. Autenticação OTP por SMS-MT (SMS celular 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 e fazer uma associação e, segundo, para solicitar as credenciais de um instrumento existente a um usuário. 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 desafiado e assim por diante. Além disso, o fluxo de autenticação pode ser usado em modo autônomo, não vinculado a nenhum fluxo subsequente.

Autenticação 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 insere a senha na interface do Google, que a envia ao integrador. Isso aciona uma resposta de êxito do integrador de pagamentos.

Quando a autenticação 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 enviada.

Autenticação de redirecionamento

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

Os redirecionamentos para Android e Web se comportam de forma semelhante. O Google redireciona o usuário para o app do integrador. O integrador identifica e autentica o usuário da forma que for mais natural para ele. Depois da autenticação, o integrador redireciona o usuário de volta à interface 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 é então usado como prova de identidade de autenticação durante a associação.

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

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

Esse mecanismo de autenticação dá mais liberdade ao integrador. Há muitas maneiras de autenticar e identificar um usuário. Nome de usuário + 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 cuida da autenticação do usuário. Dessa forma, o Google pretende aproveitar as diversas interfaces do usuário do integrador para autenticar o usuário e simplesmente fornecer ao Google um comprovante de autenticação.

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

Para saber mais 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 de pagamento do Google (GPT) para criar um instrumento. Esse fluxo faz o seguinte:

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

O resultado é que o GPT estabelecido é acordado entre o Google e o integrador.

É possível que dois usuários do Google compartilhem 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 mostra uma FOP tokenizada falsa chamada InvisiCash. Isso demonstra as etapas que um usuário vai seguir para o fluxo de autenticação e o fluxo de associação.

Visão geral do fluxo de associação

1. Uma usuária do Google com o e-mail [e-mail] quer adicionar a conta da InvisiCash à Google Play Store para fazer compras.
2. A Google Play Store abre o app InvisiCash para fazer a autenticação.

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

   Observação: há outras formas de autenticação. Esse é apenas um exemplo. Isso pode ser feito até na Web, e não em um app.

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

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

6. O servidor do Google envia uma mensagem ao servidor da 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 da InvisiCash armazenam o token de pagamento do Google (GPT) e o código da associação. Ambas estão associadas à conta da InvisiCash de Sally.

8. A InvisiCash aprova essa associação. Então, os Servidores do Google criam um instrumento que pode ser usado para compras futuras.