Introdução ao Google Standard Payments para operadoras

No mundo da Google Standard Payments, o faturamento via operadora é considerado uma forma de pagamento tokenizada (FOP, na sigla em inglês), o que significa que o Google e o integrador de pagamentos realizam uma troca única de credenciais de identidade da conta para estabelecer um token. Depois, esse token é apresentado ao integrador de pagamentos para identificar a conta a ser cobrada.

Outras formas de pagamento também usam tokenização. Portanto, temos uma visão geral das FOPs tokenizadas mais relevantes para o faturamento via operadora. Os fluxos de Autenticação, Associação, Compra e Remessa são descritos com mais detalhes nesta visão geral. Nesta página, você encontra mais detalhes em um contexto específico do faturamento por operadora.

As operadoras integram o Google Standard Payments, implementando as APIs que compõem os seguintes fluxos:

Fluxo Descrição Equivalente de especificação de DCB3
Autenticação Identifica e autentica a conta do usuário no sistema do integrador de pagamentos que será usado para fazer pagamentos DCB. SMS-MO com GoogleUserToken
Associação Troca um token de longa duração que o Google e o integrador de pagamentos podem ser usado para fazer pagamentos usando a conta do integrador de pagamentos do usuário aprove o callback do usuário com OperatorUserToken e GetProvisioning()
FundsTransfer Transfira fundos de maneira síncrona para fora da conta do integrador de pagamentos do usuário. Transfere responsabilidade para o integrador de pagamentos Linhas Auth() e CHARGE em arquivos de solicitação em lote
Reembolso Retorna de maneira síncrona alguns ou todos os fundos associados a uma FundsTransfer anterior para a conta do integrador de pagamentos do usuário. Transfere a responsabilidade para o Google Linhas REFUND em arquivos de solicitação em lote
Remessa liquidação baseada em API, de preferência com base diária Fatura mensal em PDF, arquivo de detalhes da fatura mensal, arquivo de reconciliação diária
UpdateAssociatedAccount Informa o Google sobre mudanças na conta do integrador de pagamentos de um usuário (por exemplo, limites de transação ou status de provisionamento) Enquete GetProvisioning()
Fraude Informa o Google sobre transações que foram revertidas devido a uma disputa do usuário. Isso é usado para melhorar o mecanismo de risco do Google, mas não afeta a responsabilidade financeira Nenhum

Comparação geral com a especificação DCB3

A especificação do Google Standard Payments resolve os mesmos problemas que as especificações do DCB3. No entanto, ele usa diferentes tecnologias e designs de API que melhoram a solução. Estas são as principais diferenças:

Comparação de tecnologias de pilha

Toda a comunicação da API é feita usando POSTs HTTPS com JSON criptografado e assinado por PGP. Isso significa que o Google e o integrador de pagamentos têm apenas uma chave PGP para alternar. Essas tecnologias também têm um suporte melhor do que o SOP. Mais detalhes sobre a pilha de comunicação podem ser encontrados aqui.

Comparação de filosofia de API

O DCB3 depende muito de arquivos para reconciliar o estado de pagamento. O Google Standard Payments não tem arquivos. As chamadas de API são repetidas de modo idempotente e indefinidamente até que um estado final seja determinado.

Os estados finais são realmente finais para uma chave de idempotência específica. Bugs e estados indeterminados não são modelados como recusas, mas como respostas HTTP diferentes de 200. Isso permite detectar bugs mais rapidamente e evitar mascará-los como recusações.

Novos recursos

O Google Standard Payments oferece suporte a novos recursos, incluindo:

  • API Fraud para informar o mecanismo de risco do Google contra fraudadores
  • Atualização da API Associated Account para informar o Google sobre provisionamento, limites de transação e mudanças no status da conta.
  • Mais suporte a desafios de autenticação durante compras, como PINs USSD
  • Ciclo de remessa diário

Mapa de terminologia do DCB3 para o Google Standard Payments

Nesta documentação e na própria especificação, você verá uma terminologia que parece nova, mas que, na verdade, é apenas palavras diferentes para conceitos atuais.

  • Operadora -> Integrador de pagamentos

AVISO: para evitar confusão com o conceito de integrador de DCB, este documento tenta usar "Integrador de pagamentos" e "Integrador de DCB" em vez de apenas "integrador". No entanto, a documentação geral do Google Standard Payments usa "integrador de pagamentos" geneticamente como uma abreviação de "integrador de pagamentos".

  • ID do contrato de faturamento -> ID da conta do integrador de pagamentos
  • OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
  • correlação_id -> requestId
  • Repartição de receita -> taxa

Fluxo de autenticação

Para uma visão geral do fluxo de autenticação para FOPs tokenizadas, consulte esta página.

Especificações de faturamento via operadora

No faturamento via operadora, o objetivo do fluxo de autenticação é provar que o usuário tem o controle do chip vinculado à conta da operadora. Os usuários do faturamento via operadora podem ser autenticados usando qualquer um destes três mecanismos:

Os integradores de pagamentos podem trabalhar com o Google para escolher os mecanismos de autenticação mais adequados ao produto deles.

Comparação com o DCB3

O fluxo de autenticação substitui o callback approveuser para o Google por FORA da especificação DCB3.

No DCB3, a autenticação e a associação foram combinadas em um único fluxo. No Google Standard Payments, a autenticação é uma questão separada da associação de contas.

Fluxo de associação

Para uma visão geral do fluxo de associação de FOPs tokenizadas, consulte esta página.

A principal diferença entre o fluxo de associação usado para instrumentos de faturamento via operadora e o fluxo geral de FOPs tokenizadas é que o comprovante de autenticação fornecido no método associateAccount varia dependendo de o integrador de pagamentos ter solicitado ou não um desafio de usuário extra.

Se o integrador de pagamentos responder que queria outro desafio de usuário, a comprovação de autenticação será qualquer prova de identidade produzida pelo mecanismo de autenticação específico usado pelo Google no desafio extra. Por exemplo, a prova de autenticação produzida pelo mecanismo de OTP por SMS-MT é o requestId de um método sendOtp mais a própria OTP.

Atributos do instrumento

A seção "Atributos de instrumento" da visão geral da FOP tokenizada discute o conceito de accountAlias, accountNickname e fullAccountNickname.

Especificações de faturamento via operadora

  • accountAlias precisa ser o número de telefone do usuário. Ele será usado para ajudar a identificar o instrumento caso o usuário ligue para o Suporte do Google sobre a conta.
  • accountNickname e fullAccountNickname são nomes de exibição usados para identificar o instrumento na interface.

Comparação com a especificação DCB3

O fluxo de associação substitui os seguintes componentes da especificação DCB3:

  • Chamada SSO GetProvisioning
  • Chamada SSO GetSubscriberAddress
  • Saída gerada pela operadora

Uma grande diferença aqui é o fato de que o Google gera o Google Payment Token (GPT) durante o fluxo de associação, e não a operadora que o gera.

Também é importante observar que, ao contrário do DCB3, em que as OUTs têm como escopo um BillingContractId específico, a GPT não tem escopo para nenhum PaymentIntegratorAccountID específico.

Atualizar fluxo de tokens

Para ter uma visão geral do fluxo de token de atualização para FOPs tokenizadas, consulte esta página.

Especificações de faturamento via operadora

Para instrumentos de faturamento via operadora, não é recomendável usar tokens de pagamento do Google que expirem, porque isso resulta no cancelamento dos pedidos de assinatura. Em vez de expirar tokens e depender do fluxo de tokens de atualização para corrigi-los, geralmente, é possível usar o fluxo de atualização de conta descrito abaixo.

Fluxo de atualização da conta

O fluxo de atualização de conta permite que o integrador de pagamentos informe o Google sobre atualizações na conta de integrador do usuário. Esses campos são fornecidos originalmente ao Google durante o fluxo de associação. Alguns exemplos de dados da conta que o integrador de pagamentos pode querer atualizar:

  • os limites de transação mensais, diários e por item do usuário;
  • o status de provisionamento da conta do integrador do usuário
  • o tipo de conta do integrador do usuário (pré-paga, pós-paga, empresarial etc.)
  • o "accountAlias", "accountalias" ou "fullAccount anexo;"
  • Se o usuário configurou, removeu ou alterou um PIN estático pré-compartilhado
  • independentemente de o usuário ter fechado a conta ou alterado o número de telefone, invalidando o instrumento do usuário no sistema do Google.
  • excluir fluxo de tokens

Comparação com a especificação DCB3

O fluxo de atualização de conta substitui os seguintes componentes da especificação DCB3:

  • Pesquisa da chamada Software GetProvisioning
  • Invalidação de token periódica

Fluxo de compra

Para ter uma visão geral do fluxo de compra das FOPs tokenizadas, consulte esta página.

Especificações de faturamento via operadora

Algumas operadoras usam o USSD ou outra tecnologia para coletar um PIN dos usuários durante cada compra. Para essas operadoras, em vez de chamar capture(), chamamos aasyncCapture() e damos 30 segundos para que a operadora solicite o PIN do usuário e finalize a captura. Quando o estado final do pagamento é determinado, a operadora informa o resultado ao Google chamando captureResultNotification().

Comparação com a especificação DCB3

Há grandes mudanças aqui.

  • Chamada de método única e síncrona -- capture() em vez de auth() + arquivo em lote
  • Nenhum arquivo em lote
  • Nenhum método cancel() (captura + reembolso em vez de auth + cancelamento)
  • Nenhum campo user_message na resposta. Os códigos de recusa são mapeados para mensagens do Google localizadas no idioma da conta do usuário.
  • Principais mudanças na terminologia:
    • CorrelationId -> requestId
    • BillingContractId -> paymentIntegratorAccountId
    • OperatorUserToken -> googlePaymentToken

Fluxo de compra com desafio

O desenvolvimento está em andamento para oferecer suporte a um fluxo de compra que inclui um desafio de autenticação para o usuário antes de cada compra. A maioria dos métodos de autenticação que podem ser usados antes do fluxo de associação também pode ser usada antes do fluxo de compra desafiado para fornecer autenticação de usuário adicional.

Fluxo de reembolso

Para uma visão geral do fluxo de reembolso para FOPs tokenizadas, consulte esta página.

A FOP tokenizada é compatível com um fluxo de reembolso de mensagem única. O método de reembolso é compatível com o reembolso de uma compra total ou de parte dela. Vários reembolsos parciais podem reembolsar uma única compra.

Especificações de faturamento via operadora

Não há nada de especial em relação aos instrumentos de faturamento via operadora no fluxo de reembolso.

Comparação com a especificação DCB3

Os reembolsos são acionados por uma chamada de API síncrona em vez de um arquivo. Além disso, vários reembolsos parciais podem ser criados para um único pagamento original, em vez de oferecer suporte apenas a um único reembolso de valor total.

Fluxo de remessa

Para uma visão geral do fluxo de remessa para FOPs tokenizadas, consulte esta página.

O fluxo de remessa é como o Google e o integrador de pagamentos realizam a liquidação. O Google é o sistema contábil de registro e contabiliza as transferências de remessa. Normalmente, o Google envia uma fatura de remessa ao integrador de pagamentos. A declaração fornece um resumo do valor que o integrador de pagamentos deve ao Google, além de instruções sobre como pagar o Google. Para que o integrador de pagamentos possa reconciliar, ele pode consultar ao Google os detalhes no nível da transação que compõem a declaração de remessa.

Especificações de faturamento via operadora

Os remittanceStatementDetails do faturamento via operadora incluem outros campos ainda não listados nas definições da API do fluxo de remessa. São eles:

  • revshareCategory
  • itemPrice
  • tax
  • carimbo de data/hora

Para as operadoras com um contrato de divisão da receita de 50/50 com o Google, as taxas apresentadas no remittanceStatementDetails são agregadas por revshareCategory, e não por evento.

Comparação com a especificação DCB3

O fluxo de remessa substitui os seguintes conceitos na especificação DCB3:

  • PDF do Relatório de cobrança mensal/Relatório de pagamento
  • Arquivo CSV com detalhes da fatura mensal
  • Arquivos CSV de reconhecimento diário

As principais diferenças são a remoção dos arquivos e o suporte para remessas diárias. Em vez de arquivos, o valor a ser enviado é entregue por uma API síncrona, e outra API aceita a consulta de detalhes sobre o extrato de remessa.

Fluxo de relatórios de fraudes

Com o fluxo de relatório de fraudes, um integrador de pagamentos pode informar o Google sobre transações potencialmente fraudulentas chamando o método fraudNotification. Esse fluxo é usado para atualizar o mecanismo de risco interno do Google e não inicia nenhum movimento de dinheiro.

Especificações de faturamento via operadora

Não há nada de especial em relação aos instrumentos de faturamento via operadora no fluxo de notificação de reversão de pagamento.