Executando verificação de segurança...
Respondendo a [Não disponível] dentro da publicação Entendendo o Payload do Pix (Copia e Cola) e gerando um qr-code estático
3
usrbinenv

Muito obrigado DevDoLangualyzer!

Posso sim, abaixo descrevi em 6 passos como funciona os passos cronologicos request/response do pix dinamico via qr-code, acredito que pode te dar uma luz sobre as respostas.

Alem dessa resposta, te aconselho a olhar o yml do OPEN API do PIX no github do BACEN, isso meu ajudou muito a entender os request e respostas ao lidar com a API do PIX, vale a pena gastar um tempo nesse arquivo!

Nesse exemplo, descrevo os 6 passos que devemos observar ao lidar com pix dinamico, vamos assumir que o nosso banco de exemplo se chama "BancoTAB".

1. Payload do QR Code Dinâmico (BR Code)

O QR Code dinâmico, ao ser escaneado pelo aplicativo "BancoTAB Cliente", não contém diretamente todos os dados da transação, mas sim uma URL (conhecida como "location") que aponta para um endpoint do PSP recebedor (neste caso, "BancoTAB Comercial").

Exemplo de payload do QR Code dinâmico (BR Code) que o usuário pagador escaneia, com as quebras de linha para facilitar a visualização (no código real, é uma única string contínua):

000201                                       # Payload Format Indicator: sempre '01'
010212                                       # Point of Initiation Method: '12' para QR dinâmico
2694                                         # Merchant Account Information Template
  0014BR.GOV.BCB.PIX                         # GUI: Identificador do arranjo Pix
  2572https://qrcodes.bancotab.com.br/qr/dynamic-pix-payment-1a2b3c4d5e6f7g8h9i0j # URL do Payload
52040000                                     # Merchant Category Code: '0000' para genérico
5303986                                      # Transaction Currency: '986' para Real Brasileiro
5802BR                                       # Country Code
5919BANCOTAB COMERCIAL                       # Merchant Name
6009SAO PAULO                                # Merchant City
630469C1                                     # CRC16: Checksum para validação

No Pix dinâmico, os campos de valor (ID 54) e TXID (subcampo 05 do ID 62) no QR Code podem ser omitidos ou não ter efeito, pois os dados da transação são obtidos via URL.

2. Requisição para Obter o Payload da Cobrança

Ao ler o QR Code, o aplicativo "BancoTAB Cliente" extrai a URL presente no subcampo 25 (neste exemplo, https://qrcodes.bancotab.com.br/qr/dynamic-pix-payment-1a2b3c4d5e6f7g8h9i0j).

O aplicativo pagador então realiza uma chamada HTTP GET para esta URL para recuperar os detalhes da cobrança. Estes endpoints (locations) que servem o payload da cobrança são abertos para conexão por qualquer cliente da internet e não exigem autenticação OAuth2.

Requisição (GET):

GET https://qrcodes.bancotab.com.br/qr/dynamic-pix-payment-1a2b3c4d5e6f7g8h9i0j HTTP/1.1
Host: qrcodes.bancotab.com.br
User-Agent: BancoTABClienteApp/1.0
Accept: application/jose

3. Resposta da Requisição (Estrutura JWS)

O servidor do "BancoTAB Comercial" (PSP recebedor) responde a esta requisição com uma estrutura JWS (JSON Web Signature). O JWS garante a integridade e o não-repúdio das informações da transação, pois seu payload é assinado digitalmente pelo PSP recebedor.

A estrutura JWS é composta por três partes, separadas por pontos (.), codificadas em Base64url: Cabeçalho (JOSE Header), Payload (JWS Payload) e Assinatura Digital (JWS Signature). O cabeçalho JWS deve incluir, no mínimo, o parâmetro "alg" (Algorithm), que define o algoritmo de assinatura digital usado (por exemplo, "RS256" ou superior, "ES256" ou superior; "HS*" e "none" são proibidos).

O aplicativo "BancoTAB Cliente" (PSP pagador) valida a assinatura digital do JWS. Somente se a assinatura for válida, ele processa o conteúdo do payload JSON.

Exemplo de Resposta (JWS):

HTTP/1.1 200 OK
Content-Type: application/jose
Content-Length: [tamanho_do_jws]

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjYWxlbmRhcmlvIjp7ImNyaWFjYW8iOiIyMDIwLTA5LTE1VDE5OjM5OjU0LjAxM1oiLCJhcHJlc2VudGFjYW8iOiIyMDIwLTA0LTAxVDE4OjAwOjAwWiIsImV4cGlyYWNhbyI6MzYwMH0sInR4aWQiOiJmYzlhNDM2NmZmM2Q0OTY0YjVkYmM2YzkxYTg3MjJkMyIsInJldmlzYW8iOjMsInN0YXR1cyI6IkFUSVZBIiwidmFsb3IiOnsib3JpZ2luYWwiOiI1MDAuMDAiLCJtb2RhbGlkYWRlQWx0ZXJhY2FvIjowfSwiY2hhdmUiOiI3NDA3YzljOC1mNzhiLTExZWEtYWRjMS0wMjQyYWMxMjAwMDIiLCJzb2xpY2l0YWNhb1BhZ2Fkb3IiOiJJbmZvcm1hciBjYXJ0YW8gZmlkZWxpZGFkZSIsImluZm9BZGljaW9uYWlzIjpbeyJub21lIjoicXVhbnRpZGFkZSIsInZhbG9yIjoiMiJ9XX0. [ASSINATURA_DIGITAL_DO_PSP_RECEBEDOR_AQUI]

O [ASSINATURA_DIGITAL_DO_PSP_RECEBEDOR_AQUI] representa a assinatura digital gerada pelo "BancoTAB Comercial" (PSP Recebedor) sobre o cabeçalho e o payload, utilizando sua chave privada e um algoritmo como RS256. O certificado vinculado à assinatura do payload JWS associado aos QR Codes dinâmicos deve ser emitido por uma Autoridade Certificadora (AC) amplamente conhecida e ser cadastrado no Pix. É responsabilidade do participante pagador verificar o status de revogação do certificado do site associado ao QR Code do PSP recebedor.

4. Conteúdo do Payload JWS (JSON)

Após a validação da assinatura, o "BancoTAB Cliente" extrai o payload JSON (a parte do meio do JWS) que contém os detalhes da cobrança. Utilizaremos o exemplo cobPayload1 dos fontes, adaptado para o contexto "BancoTAB":

{
  "calendario": {
    "criacao": "2020-09-15T19:39:54.013Z",
    "apresentacao": "2020-04-01T18:00:00Z",
    "expiracao": 3600
  },
  "txid": "fc9a4366ff3d4964b5dbc6c91a8722d3",
  "revisao": 3,
  "status": "ATIVA",
  "valor": {
    "original": "500.00",
    "modalidadeAlteracao": 0
  },
  "chave": "7407c9c8-f78b-11ea-adc1-0242ac120002",
  "solicitacaoPagador": "Informar cartao fidelidade",
  "infoAdicionais": [
    {
      "nome": "quantidade",
      "valor": "2"
    }
  ]
}

Este JSON contém todas as informações da cobrança, como:

  • calendario: Data de criação (criacao), apresentação (apresentacao) e tempo de expiração (expiracao).
  • txid: Identificador único da transação, criado pelo usuário recebedor para conciliação.
  • revisao: Número da revisão da cobrança.
  • status: Estado do registro da cobrança (neste caso, "ATIVA").
  • valor: O valor original da cobrança, neste caso, "500.00".
  • chave: A chave Pix do recebedor ("7407c9c8-f78b-11ea-adc1-0242ac120002" - exemplo de chave EVP).
  • solicitacaoPagador: Uma mensagem opcional para o pagador ("Informar cartao fidelidade").
  • infoAdicionais: Informações adicionais ("quantidade": "2").

5. Início do Processo de Pagamento (internamente pelo PSP Pagador)

Com os dados da cobrança em mãos (extraídos do payload JWS), o aplicativo "BancoTAB Cliente" (PSP pagador) apresenta as informações ao usuário para confirmação.

Após a confirmação do usuário, o PSP pagador (BancoTAB Cliente) não realiza uma chamada direta a uma API do PSP recebedor para efetivar o pagamento. Em vez disso, ele constrói e envia uma mensagem de pagamento (PACS.008) para o Sistema de Pagamentos Instantâneos (SPI). Essa mensagem inclui o txid e todos os detalhes necessários para a liquidação da transação.

A API Pix (OpenAPI Specification) padroniza os serviços oferecidos pelo PSP recebedor, como o gerenciamento de cobranças (criar/revisar Cob, CobV, CobR, Rec), o acompanhamento de Pix e suas devoluções, e consultas. Ela não especifica o endpoint que o PSP pagador usaria para iniciar um Pix, pois essa é uma funcionalidade interna do PSP pagador que se comunica com o SPI.

6. Registros de Auditoria (Logs)

Tanto o PSP pagador quanto o PSP recebedor são obrigados a manter registros detalhados de auditoria das mensagens e transações.

  • Mensagens enviadas e recebidas com a ICOM (Interface de Comunicação) devem ser armazenadas por 10 anos, incluindo conteúdo XML e dados de assinatura digital.
  • Requisições de consulta ao DICT (Diretório de Identificadores de Contas Transacionais) devem ser armazenadas por 2 anos, enquanto requisições de escrita (como atualização de entrada, criação de reivindicação) devem ser mantidas por 10 anos.
  • Informações de requisições geradas a partir de incidentes de cibersegurança, ataques de varredura ou fraudes também devem ser armazenadas por 10 anos.
  • Todos os certificados digitais utilizados no Pix, mesmo os desativados, devem ser armazenados para eventual consulta histórica e validação da assinatura digital.

Por fim, este fluxo detalha como as informações do QR Code dinâmico são utilizadas para processar uma transação Pix, desde a leitura inicial até a etapa de confirmação, e as validações de segurança envolvidas.

Carregando publicação patrocinada...