ID da conta
O ID da conta é enviado de volta do servidor do integrador durante a associação flow; ela é usada para ajudar o Google a identificar a conta de duas maneiras. Primeiro, para identificar vários instrumentos que usam o mesmo usuário subjacente para avaliar riscos e fraudes. Além disso, ele é usado pelo Google agentes de atendimento ao cliente para identificar esta conta. Esse valor precisa ser identifica a conta de usuário nas solicitações de associação, e ela precisa ser imutável na conta específica e ela deve ser identificável pelo usuário.
Por exemplo, se um integrador usa um endereço de e-mail como identidade, isso pode ser o endereço de e-mail. Mas se o integrador usar um endereço de e-mail para fazer login mas ele puder ser alterado, o endereço de e-mail não será uma boa escolha para ID da conta de serviço. Independentemente do que for escolhido, o valor precisa ser o mesmo para vários de tentativas de associação com a mesma identidade de usuário do integrador de pagamentos.
Pacote de app Android (APK)
O formato de arquivo do pacote usado pelo sistema operacional Android para distribuição e instalação de apps para dispositivos móveis.
Controle de versões da API
Esta especificação oferece suporte ao controle de versões. As versões compatíveis são configuradas no servidor do Google. Ao mudar da versão N para a M (em que M é a versão principal) maior que N) o integrador precisa oferecer suporte a N e M até que o Google faça a verificação que todo o tráfego foi migrado para M. As versões são identificadas de forma diferente com base no contexto. As APIs do Android e as APIs WebRedirect transmitirão a API versão como um parâmetro para a solicitação. As chamadas de servidor para servidor passam o como uma parte do caminho do URL.
As versões não são fixas por fluxo. Então, durante a migração de N para M, um integrador pode ter uma captura com a versão M e um reembolso com a versão N para o mesmo transação. Durante a associação, o integrador pode receber uma solicitação de autenticação da versão M com uma solicitação de associação da versão N.
ID da associação
O associationID identifica a associação entre a conta do cliente
e o instrumento do Google. O associationId é muito semelhante à GPT. Em
Ele tem o mesmo ciclo de vida da GPT e uma cardinalidade de 1:1. A
A sensibilidade do associationId é diferente da GPT. A GPT é um conjunto
token usado para pagamentos. O associationId é um identificador público que
representa a mesma relação, mas não é tão sensível por natureza.
O associationId é transmitido para o integrador de pagamentos durante
associateAccount. Esse mesmo valor é transmitido durante a reautenticação para o
integrador. Isso permite que o integrador tenha contexto sobre qual conta precisa
ser autenticado. Se o ID de associação for transmitido, a mesma conta que foi
identificados durante a associação original precisam ser pré-preenchidos e autenticados
contra.
O integrador de pagamentos precisa armazenar todos os IDs de associação e associar a uma conta de integrador específica durante todo o ciclo de vida do contrato entre o integrador e o Google.
ID da solicitação de autenticação
Os métodos refreshToken, associateAccount e (opcional) capturam uma
a uma autenticação. Essa referência está no formato requestId
da autenticação específica a que o Google se refere. Este campo deve ser
usado pelo integrador de pagamentos para verificar se realmente o método foi realizado
uma autenticação bem-sucedida.
Os métodos de captura podem ter um requestId de autenticação preenchido. Isso acontece
em dois casos. Se o Google autenticar o usuário logo antes de uma captura,
preenche o campo requestId de autenticação. Além disso, muitas vezes o Google autentica
o usuário no momento de configuração, quando um calendário de pagamentos automatizado está definido. Google
grava o requestId de autenticação nessa programação e envia o
requestId com todas as capturas associadas a essa programação específica.
Espera-se que os integradores de pagamentos armazenem todas as requestIds de autenticação por 30
dias. Se um integrador de pagamentos quiser auditar a autenticação requestIds
que podem estar presentes em uma solicitação de captura, incluindo aquelas incluídas no pagamento
programações, o integrador precisa armazenar todas as requestIds de autenticação para
a vida útil do contrato entre o integrador e o Google.
Empresa
Uma empresa é um conceito definido na configuração e no contrato do Google. Um empresa define a relação entre o integrador e o Google. chaves PGP e (opcionalmente) as CAs raiz do SSL são associadas à empresa. Mais importante ainda, a empresa está associada a um ou mais IDs da conta do integrador de pagamentos. GPT criados em uma empresa funcionam principalmente para todos os IDs de conta do integrador de pagamentos. dentro da empresa. Algumas exceções se aplicam. Por exemplo, se a GPT for associado a uma conta denominada em uma moeda (e não aceita FX e está tentando fazer uma compra com o ID da conta de um integrador de pagamentos em uma moeda diferente.
Forma de pagamento (FOP, na sigla em inglês)
Todas as transações incluem uma ou mais formas de pagamento (FOPs, na sigla em inglês), como um cartão de crédito ou Transferência eletrônica de fundos, que são usados pelos usuários para pagar ao Google de produtos ou serviços ou pelo Google para pagar usuários, no caso de usuários e desenvolvedores do Google Play. As formas de pagamento também são frequentemente chamadas de pagamento Instrumentos, Instrumentos e Formas de Pagamento.
Token de pagamento do Google (GPT)
A GPT é um valor codificado em base64 seguro para a Web gerado pelo servidor do Google em o horário da associação e transmitidos ao servidor do integrador. A GPT é uma tag identificador que representa o vínculo entre a conta do usuário com o integrador e o instrumento do Google. O GPT é um token que substitui o usuário credenciais ou um ID de conta. Esse token é usado durante os fluxos de compra para identificar à conta para crédito ou débito e é secreto para ambas as partes. A GPT nunca deve ser enviados em texto não criptografado e criptografados para garantir a privacidade.
A GPT é diferente de associationId porque associationId não está protegido
e é transmitido livremente através de meios públicos (URLs, conexões não seguras). A GPT é
conhecidas apenas pelo Google e pelo integrador.
O integrador de pagamentos deve armazenar todas as GPTS e associá-las a um conta de integrador específica durante a vida útil do contrato entre o integrador e o Google.
Idempotência
Uma operação idempotente pode ser aplicada várias vezes sem
alteração do resultado ou novos efeitos colaterais além da aplicação inicial
da operação. Normalmente, a idempotência usa uma “chave” para identificar o mesmo
solicitação. Todas as solicitações definidas entre os dois servidores usam uma idempotência
chave definida no cabeçalho da solicitação. O cabeçalho da solicitação tem um ID que é
usada como chave de idempotência. O ID da solicitação é globalmente exclusivo. Idempotente
devem ter exatamente o mesmo corpo JSON, com uma exceção. A
requestTimestamp será diferente para cada solicitação. É importante
distinção. O requestTimestamp é o horário em que o servidor enviou essa solicitação. E
é único por tentativa. Isso ajuda a reduzir a possibilidade de ataques repetidos.
Da mesma forma, uma resposta idempotente deve ter exatamente o mesmo corpo JSON, exceto o
responseTimestamp vai ser diferente para cada resposta.
Todos os métodos de servidor para servidor, exceto o método Echo, precisam ser idempotentes. As solicitações de autenticação para a interface do integrador (seja para Android ou Web) não são idempotente.
Para exemplos de comportamento idempotente, consulte a documento de referência.
Identificador (ID)
Os identificadores representam uma transação ou comunicação entre o integrador e o Google.
Instrumento
O instrumento representa uma forma de pagamento armazenada associada a um único cliente do Google. Exemplos de instrumentos incluem:
- Um número de cartão de crédito salvo
- Uma conta bancária e número identificador
Os usuários podem ter vários instrumentos associados à identidade do Google.
Micros
Os valores monetários nessa API são representados por um formato chamado "micros", um padrão do 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
Integrador de pagamentos
O integrador externo que processa pagamentos de uma transação do usuário.
ID da conta do integrador de pagamentos
Esse identificador representa as restrições relacionadas ao contrato entre o Google e ao integrador. O ID da conta do integrador é gerado pelo Google e atribuído a ao integrador durante a configuração. Normalmente, isso é chamado de "MID". Todos As solicitações e respostas precisam incluir esse ID. Esse identificador é opaco e deve nunca serão analisados. O formato deste identificador pode não ser consistente em todas e documentos de identidade emitidos.
Esse identificador nunca é alterado durante a vida útil de uma transação. No caso de para coleta e reembolso, o mesmo identificador será usado.
As restrições do ID da conta do integrador são definidas pelo próprio contrato. Geralmente, as restrições estão relacionadas ao faturamento. Por exemplo, um integrador aceita CAD e MXN faturados como USD, mas exige que as transações em EUR sejam faturadas em euros. Nesse caso, dois IDs de conta diferentes do integrador de pagamentos serão um para faturamento em USD e outro para faturamento em EUR.
O identificador pode ser descontinuado e substituído por novos identificadores. No caso em que
um identificador estiver sendo descontinuado, o Google deixará de iniciar capturas para esse
identificador. No entanto, o integrador precisa aceitar os reembolsos das transações feitas.
em relação a esse identificador por um ano a partir do último início da captura (captura
início definido como o requestTimestamp encontrado no requestHeader).
PII
As informações de identificação pessoal (PII) são dados identifique um indivíduo e quaisquer outros dados que possam ser razoavelmente vinculados ao essas informações fornecidas pelo Google, como nome, endereço de e-mail, endereço de correspondência endereço ou número de telefone, individualmente ou em conjunto
Solicitar ID
O requestId identifica toda a comunicação entre o Google e o
integrador.
SPII
As informações sensíveis de identificação pessoal (SPII, na sigla em inglês) são um subconjunto informações de identificação pessoal (PII) que apresentem um alto risco ao usuário caso sejam comprometida ou usada indevidamente. SPII geralmente têm processamento e armazenamento restritivos de conformidade impostos por entidades legais, regulatórias ou de compliance.
Token
Os tokens adicionam uma camada extra de segurança quando credenciais confidenciais, como PII ou SPII são trocadas entre o Google e o integrador.
Endereço do usuário
No momento da criação do instrumento, o Google verifica se o usuário é um Cliente do Google Payments. Isso não depende de ser um cliente do Google. Para ser um cliente do Google Payments, precisamos do endereço de faturamento do usuário. Algumas agências reguladoras exigem que o Google saiba o endereço completo do usuário, enquanto enquanto outros precisam de um subconjunto desse endereço.
Se o integrador de pagamentos tiver um endereço registrado para esse usuário, o Google vai obter esse endereço durante o fluxo de associação para preencher previamente o formulário de endereço para o usuário. O usuário tem a opção de alterar o campo pré-preenchido endereço IP. O preenchimento automático do endereço do usuário diminui o atrito na adição de um e aumenta a taxa de conversão dos usuários que adicionam esses instrumentos.
Se o endereço for compartilhado, o Google também vai usá-lo para calcular o risco um modelo de machine learning. Isso permite que o mecanismo de risco do Google entenda o endereço que o usuário diz eles são cobrados ao comparar com o local do IP em que o usuário está no momento
O compartilhamento de endereços é meramente uma otimização. Tudo bem, e é esperado que algumas os integradores não têm um endereço de faturamento do usuário ou não podem compartilhar esse endereço IP.
Codificação em Base64 segura para a Web
O padrão de codificação especificado na seção 5 RFC 4648, Codificação Base 64 com URL e Filename Safe Alphabet, também conhecidos como "Base64 seguro para a Web" ou "base64url" e codificação. (Isso é o mesmo que a codificação base64 com URL e alfabeto seguro de nome de arquivo da seção 4 do RFC 3548). Todos os valores criptografados e assinados precisam ser codificados usando esse padrão.