bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.

Especificação da API Pix

• O presente repositório define as especificações funcionais em formato OpenAPI 3.0 referentes à API Pix.

• Os aspectos de segurança da API Pix transcendem o escopo deste repositório. Maiores detalhes sobre segurança podem ser encontrados no Manual de Padrões Para Iniciação do Pix e no Manual de Segurança do Pix.

Link para visualização da API Pix

O branch master da API pode ser visualizado aqui.

Release atual: 2.6.3

• A release atual da API Pix pode ser encontrada neste link.

pix-api's Issues

Design de nova funcionalidade: Reuso de Location no QR Code Dinâmico

No Manual de Padrões para Iniciação do Pix v 1.1, a nota de rodapé 30 informa que:
"No Pix, como um mesmo BR Code dinâmico pode ser reutilizado para vários pagamentos, Valor e txId - obtidos via URL - podem mudar a cada transação. Assim, esses campos BR Code devem ser ignorados pelo pagador em qualquer caso de uso de QR Code dinâmico."

Porém, a v. 2 da API de Recebimento não permite ainda este funcionamento, já que não é possível associar uma nova cobrança (com novos valor e txid) a um Endpoint de acesso ao Payload JSON (campo "location") criado para outra cobrança. Certo?

Ou existe uma forma, com a versão atual da API de Recebimentos, de usar o mesmo BR Code Dinâmico para múltiplos pagamentos?

[Sugestão] Criar Cobrança – Inclusão do campo payloadQrcode no retorno

/cob/{txid} Criar Cobrança

Prezados,

Alguns de nossos clientes nos pediram que essa API de criação de cobrança (e até nas de consultas) retornasse também a String do payload. Desta forma o próprio estabelecimento pode apresentar ao seu cliente a imagem do qr-code para que possa ser pago através do app do PSP do pagador.

Consulta dos QR Codes Estáticos no API Pix

No Manual "II_ManualdepadroesparainiciacaodoPix-versao1.1.pdf" consta:

"O QR estático pode ser criado diretamente pela automação do usuário recebedor".

Entendemos que o usuário final pode gerar um QR Code Estático manualmente apenas inserindo os dados no formato EMV e gerando o QR Code.

Minha Dúvida: Esse QR Code Estático que foi criado manualmente pelo usuário e que tenha um txid(por exemplo "Churrasco") vai ser passível de consulta na API Pix?

Pergunto porque neste mesmo documento consta:

"Os Pix recebidos que tenham sido iniciados via QRs Estáticos que estejam associados a um txid podem ser consultados via API Pix".

Neste caso o QR Code Estático tem um txid, mas como que a API Pix vai conseguir consultar os dados deste QR Code Estático, visto que o QR Code Estático não é criado pela API Pix.

[Dúvida] em [PAGAMENTOS] - Transações em Lote

Descreva sua dúvida ou problema
Será possível desenvolver uma espécie de "carrinho de compras" com o PIX no QR dinâmico (o mesmo para o futuro link de pagamentos)? Vejo que ficar fazendo múltiplas transações pra cada produto comprado é inviável, especialmente se essas compras forem a distancia. Por exemplo: Uma seleção com diferentes frutas e vegetais.

Acredito que uma transação em lote pouparia custos para quando esse tipo de operação ocorrer.

Sistema ou Área
Iniciação de Pagamentos

Dúvida sobre end-point com payload

Na versão 2.0.0, passou a ser especificado também o endpoint usado por apps pagadores para baixar o QR-Code dinâmico, https://{fdqnPSPRecebedor}/{pixEndpoint}/v1/{pixUrlAcessToken} .

Isso é uma adição para que o estabelecimento comercial possa baixar diretamente o payload se quiser checá-lo, ou o mesmo end-point que atende os apps das outras IFs/IPs deve ser usado para atender os consumidores da API de Recebimento ? Ou nenhuma das duas coisas é a junção é apenas para documentar num único repositório mas são end-points independentes ?

[SEGURANÇA] Mitigação contra transações de baixo valor

Uma possível vulnerabilidade no Pix é que enquanto o pagador pessoa física não paga nada, o recebedor pessoa jurídica paga. Se o recebimento custar 50 centavos para a PJ, 1 pessoa pode gastar R$ 1 mil para enviar 100 mil Pix de um centavo cada, e causar um prejuízo de R$49 mil.

Assim, gostaria de saber se as seguintes mitigações seriam permissíveis pelo BACEN:

• Se um EC pode instruir seu PSP a não aceitar Pix que não seja de um QR-Code dinâmico que ele tenha emitido
• Se um EC pode instruir seu PSP a aceitar Pix apenas acima de determinado valor
• Se um PSP pode limitar o valor mínimo de Pix recebido ao da tarifa independente de solicitação do EC
• Se um PSP pode rejeitar um Pix que venha em valor diferente dos permitidos na geração do QR-Code dinâmico
• Se em qualquer dos métodos acima, se o PSP ao recusar o recebimento não pagará a tarifa de recebimentos cobrada pelo BACEN

[PIX Link] - Contribuições técnicas

Descreva sua dúvida ou problema
Pelo que li nas especificações de iniciação do PIX, entendi que o Banco Central irá registrar o aplicativo de cada PSP para ativar App Links (para Android) e Universal Links (para iOS).
A documentação sempre trabalha com a premissa de que o sistema operacional irá permitir ao usuário escolher a aplicação que irá abrir aquele link (ou definir um padrão) dentre as que tem instalado. O que é válido para o Android.
Porém, no iOS, não é possível escolher o aplicativo aberto por um universal link.
Meu entendimento é que o primeiro aplicativo listado no https://pix.bcb.gov.br/.well-known/apple-app-site-association que o usuário tiver instalado será aberto.

Isso dito, tenho duas dúvidas:

1. Qual será a ordem usada no https://pix.bcb.gov.br/.well-known/apple-app-site-association para listar os aplicativos de cada PSP? Tinha a impressão de ser na ordem alfabética pelo nome de cada instituição mas não achei a especificação.
2. Existe alguma intenção de mitigar esse caso? Creio um usuário ter mais um aplicativo compatível com PIX Links será um cenário bastante comum.

Sistema ou Área
PIX Link

[Duvida] Utilização da Api

olá, gostaria de saber se a API esta disponível, pois tenho projeto que envolve o PIX e gostaria de entender melhor sua utilização, se tiverem algum material que possam me ajudar fico agradecido.

[Dúvida] OAuth ClientCredentials Flow

Estamos com algumas dúvidas em relação ao fluxo de autenticação ClientCredentials citado nas especificações 2.0.0 da API. Lendo a RFC 6749, na seção 4.4.3, diz que no fluxo ClientCrendentials não se deve emitir um refreshToken, até porque no fluxo de validação do refreshToken deve-se autenticar também o usuário, não sendo vantagem sobre o ClientCredentials.

Porém, na documentação atual da API existem dois endpoints
https://pix.example.com/oauth/token
https://pix.example.com/oauth/refresh
quer dizer que deveremos emitir um refreshToken no fluxo de clientCredentials?

[Dúvida] na Iniciação de Pagamentos - Scopes de OAuth no client

Descreva sua dúvida ou problema

Segundo a documentação das APIs:

No processo de adesão, o Client_ID disponibilizado pelo PSP deve possuir um conjunto de escopos que determinarão as funcionalidades às quais o Usuário Recebedor terá acesso. Os critérios de autorização nos escopos são de responsabilidade do PSP, que pode criar critérios diferenciados em função das características do Usuário Recebedor. Dessa forma, é possível, por exemplo, que determinadas funcionalidades estejam acessíveis apenas por usuários que cumpram requisitos adicionais de segurança estipulados por cada PSP.

Faz sentido um Usuário Recebedor criar um Client no PSP e utilizar o accessToken desse Client para autenticar nas APIs. Porém, o conceito de scope aqui não se aplica. Scopes são utilizados primariamente quando um Client solicita permissão de um terceiro para executar determinadas ações em nome desse terceiro, o que não é o caso aqui. O Usuário Recebedor, tem total liberdade para usar todos os endpoints da API, pq ele teria que gerar scopes de permissão pra si mesmo?
Qualquer tipo de permissão que possa ser concedida ou negada a esse usuário, é feita via processo de KYC, anterior a etapa de de autenticação.

Existe algum caso de uso claro com scopes no OAuth?

[Dúvida] no [QR Code] - API de Recebimento (API PIX 2.0.0)

Estamos com uma dúvida sobre a API de recebimento (Api PIX 2.0.0)

Em revisar cobranças (/api/v1/cob/{txid}) existe o parâmetro Status, na documentação está definido assim:
O único status que pode ser informado na revisão da Cobrança é o REMOVIDA_PELO_USUARIO_RECEBEDOR.

Isso quer dizer que o endpoint de revisar cobrança serve apenas para remover uma cobrança? Ou posso utilizar o endpoint para atualizar a cobrança e deixar o Status vazio para quando desejo modificar algum campo da cobrança, e utilizar o campo Status apenas quando desejo REMOVER a cobrança?

Sistema ou Área
QR Code,

Dúvidas API de Webhook

Caros, boa tarde!
Ficamos com algumas preocupações nas APIs de webhook documentadas:

1. O nome da URL é genérica (/webhook), isso não criará problemas de identificação da transação?
2. Como a URL de callback (do cliente recebedor) cadastrada será protegida?

Obrigado

Webhook para devolução

Ao ser solicitada uma devolução (PUT ​/pix​/{e2eid}​/devolucao​/{id} ), deve haver uma notificação via webhook, com a atualização do pix (inclusão do campo 'devolucoes')?

Ou as devoluções só são verificáveis através de consulta (GET ​/pix​/{e2eid}​/devolucao​/{id} )?

[UX] Uso das informações adicionais

Os campos chave e valor do item Informações Adicionais possuem tamanho máximo de 50 e 200 caracteres.

Pelo que entendemos o mobile é o canal principal do Pix definido pelo BC.

Fizemos um exercício de UX no pagamento Pix iniciado por QR-code dinâmicos e percebemos que, quando essa Informação Adicional possui tamanhos de maiores, a experiência do usuário dentro do canal mobile não foi satisfatória.

Vocês entendem isso como um problema?

[Dúvida] Funcionamento da máquina de status da entidade "Cobrança"

Descreva sua dúvida ou problema

Olá! Gostaria de tirar algumas dúvidas sobre a API PIX 2.0

1 - Uma cobrança pode receber mais de um PIX desde que os PIXs tenham o mesmo txId, correto?

a) Nesse caso, o PSP só pode mudar o status da cobrança para CONCLUIDA quando o total de PIXs atingir o valor total da cobrança?
b) Se sim, enquanto a cobrança não passa para concluída, ela fica como ATIVA?
c) O que deve acontecer se o usuário recebedor tentar remover uma cobrança que está ativa, mas que já recebeu alguns PIXs? Os PIXs devem ser devolvidos?

2 - O ato de remover uma cobrança, é apenas atualizar o status da cobrança? Ou seja, se o usuário pagador ler a URL, o payload deve ser retornado, mas com a situação REMOVIDA_PELO_USUARIO_RECEBEDOR"  ou "REMOVIDA_PELO_PSP"? ou devemos tornar indisponível o payload?

3 - No serviço que consulta uma lista de cobranças (GET /cob/), se usado como filtro o campo CPF ou CNPJ do pagador, devemos considerar que o pagador é a informação do campo "devedor" disponível no serviço que cria uma cobrança, ou quando realizamos a busca devemos procurar pelo pagador contido na PACS.008?

4 - No serviço que consulta um PIX pelo endToEndId (GET /pix/{e2eid}) pode ser retornado um recebimento mesmo que seja um recebimento que não tem txtId?

5 - O endpoint abaixo é o serviço que deve ser implementado pelo usuário recebedor, para que ele possa receber as notificações de recebimento via webhook, correto?

Sistema ou Área
QR Code

[Dúvida] Request para consulta da URL e decode deve obrigatoriamente ser do aplicativo?

Descreva sua dúvida ou problema
Em fluxo de utilização do QR Code dinâmico pelo usuário pagador - As requests para consulta a URL (decode + validações de segurança) relativas a URL contida no QR CODE DINÂMICO devem ser obrigatoriamente disparadas a partir do aplicativo do PSP (camada app)??? Ou elas podem estar em uma camada de backend onde uma api disponibilizaria as funções de decode e validações ao aplicativo no momento da solicitação de consulta a URL (leitura de um QR Code dinâmico para pagamento)?

Sistema ou Área
Iniciação de Pagamentos, QR Code, Segurança

Identificador do Problema
ResourceId - Consulta URL (QR Code Dinâmico (SPI)

Mensagens Enviadas / Recebidas
N/D

URL de conexão
N/D

Dados adicionais

Manual de Segurança do Pix - Versão 3.0 - 4.3. Validações a serem feitas pelos aplicativos - https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Manual%20de%20Seguranca%20do%20PIX%20v3.0.pdf

Especificações técnicas e de negócio do ecossistema de pagamentos instantâneos brasileiro - 1.2.2.2. QR CODE DINÂMICO - https://www.bcb.gov.br/content/estabilidadefinanceira/forumpireunioes/Documento%20de%20especifica%C3%A7%C3%B5es%20-%20vers%C3%A3o%206.1.pdf

[Dúvida] na [API PIX] - Varios assuntos

Caros,

A flag de aceite após vencimento foi retirada na versão 2.0.0 da API PIX, bem como juros, multas e descontos. No entanto, ainda consta do manual de experiência do usuário, pag 46, atualizado após publicação da API PIX. Isso dado:

(1) Os campos retirados (juros, descontos e multas) serão incluídos numa versão futura? Alguma previsão?

(2) Poderá o PSP, respeitando o padrão BR Code, criar arranjo próprio no ID 27, diferente do Pix, para atender essa necessidade (aceitar pagamento após data de vencimento com cobrança de juros) e servir por meio de outra API privada?

(3) Todo PSP terá que recusar o pagamento por uma cobrança após a data de expiração?

Considere o seguinte caso:
Uma empresa gera uma cobrança de luz (QR code dinâmico com txId1) pelo PSP1 para Fulano pagar;
Fulano possui duas contas cadastradas no Pix no PSP1;
Fulano gera um QR code estático, de forma independente, com o mesmo txId1, mas trocando apenas a chave Pix – a chave do payload da cobrança era [email protected], já a chave do QR code estático é preenchida com [email protected], que está ligada a uma das contas do Fulano. Em seguida, Fulano realiza um pagamento por meio do QR code estático, ou seja, a si próprio (transferência entre contas):

(4) Como o PSP1 vai reconhecer que esse pagamento não se trata de uma quitação da cobrança, sendo que eles possuem o mesmo TxId? Qual a outra informação que estou esquecendo de considerar?

Outras questões relativas a API PIX:

(5) O retorno do método PUT /cob/{txid} (criar cobrança) está com revisão igual a 1. Não deveria ser 0, uma vez que se trata da criação da cobrança, e conforme a descrição ela se iniciaria em 0?

(6) A API PIX poderá ser usada pelo PSP para a funcionalidade de extrato (transações Pix)? Ou seja, ela exibirá todas as transações Pix (manual, por chave, por QR estático e por QR dinâmico)?

(7) GET cob/ lista uma devolução de 10, relativa a um pagamento de 110 de uma cobrança cujo valor original é 100. Como o usuário conseguiu pagar 110, se ele não poderia mudar o valor original da cobrança que é de 100?

(8) Quando uma cobrança assume o status de CONCLUÍDA? Uma vez concluída ela pode voltar para o status de ATIVA? As regras de mudança de status talvez precise ser melhor documentadas. Embora elas possam ser inferidas, isso pode levar a diferentes tratativas pelos PSPs.

Obrigado

QRCode na API de recebimento - Resposta da API

Atualmente a API de Recebimentos retorna uma série de infomações a partir das quais o QRCode deve ser montado pelo Usuário Recebedor.
Ou seja, ela não retorna um LINK com o QRCode já gerado. Partindo do principio que se trata de uma API de Recebimentos, ao meu ver faria sentido que ela incluisse em sua resposta tanto o LINK do QRCODE, como o LINK DE PAGAMENTO, discutido até algumas semanas atrás.

Dado que as APIs de Recebimento não cumprem essa necessidade (que convenhamos, tem um escopo bastante básico) nós, PSPs, poderíamos então oferecer uma API que cumpra com o objetivo final do usuário e retorne o LINK pro QRCode, já criado? Evitando assim que o usuário Recebedor precise montar o QRCode do lado dele?

Correlação do "ManualdepadroesparainiciacaodoPix" com a API Pix - Juros e Multa

No Manual "II_ManualdepadroesparainiciacaodoPix-versao1.1.pdf" consta:
"O QR Code dinâmico no Pix deve ser gerado por meio da API Pix".

Neste mesmo manual mostra que a cobrança pode ter valores de juros e multas, mas na API Pix não consta a entrada destes campos.

Minha dúvida é, no app iremos apresentar em tela para o usuário criar um QR Code Dinâmico com a opção de incluir Juros e Multa, mas não poderemos usar nesse momento a API Pix para criar a cobrança visto que não consta na API Pix?

/pix Vs. /cob

Mais dúvida do que issue, a publicação da V2 trouxe um endpoint para cobrança e outro para o Pix, poderiam descrever qual a diferença e o real caso de uso para as ambas atualmente e no futuro.

Aproveitando o ticket também gostaria de entender: porque o /pix/* requer um e2eid de PACS00*. Se eu nesse caso eu sou um gateway/facilitador como ficaria minha utilização desses endpoints? Eu receberia somente e2eid uma vez que a cobrança está paga?

Qr Code dinâmico - "API Criar Cobrança"

No retorno 200 da API Criar Cobrança, não seria necessário ter o campo para retornar a imagem no formato base64 do Qr?

[Dúvida] no [API Pix] - Quem pode consumir a API

Descreva sua dúvida ou problema
Na documentação Iniciação Pix, é especificado que a API Pix é oferecida pelo PSP Recebedor, nesse caso, o Participante Indireto poderia ter credenciais para acesso a API Pix independente do seu Participante Direto?

Sistema ou Área
API Pix

Identificador do Problema
N/A

Mensagens Enviadas / Recebidas
N/A

URL de conexão
N/A

Dados adicionais
Ou seja, o se um Participante Indireto está relacionado a um Participante Direto que ainda não oferece a API, o Indireto consegue acessar e oferecer ela independentemente?

[Dúvida] no [QR Code] - Certificado para assinatura do JWS

ATENÇÃO: Não crie issue para questões relativas ao ambiente de produção !

Descreva sua dúvida ou problema
Qual é a modalidade exata do certificado para assinatura do payload JWS (QR Codes dinâmicos) ?

Sistema ou Área
QR Code

Identificador do Problema
Manual de Segurança (Anexo II, pág. 26) consta apenas o certificado deve ser emitido por AC amplamente conhecida, e Key Usage=Digital Signature, mas não especifica qual Modalidade Exata do tipo de certificado.

Mensagens Enviadas / Recebidas
Não se aplica

URL de conexão
Não se aplica

Dados adicionais
Manual de Segurança do Pix versão 3.0 (12/08/2020) (pdf)
https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Manual%20de%20Seguranca%20do%20PIX%20v3.0.pdf

Endpoint PSP Recebedor e Autenticação

Boa tarde Srs!
Duas perguntas:

1. A chamada para a API de Cobrança (/cob) será para o endpoint do PSP Recebedor? Ou a chamada deverá ser feita para o endpoint do Bacen, que ficará responsável por rotear para o PSP correspondente?

2. Como será a dinâmica dos tokens para autenticação? Haverá um token por chave do DICT? No caso dos Gateways e TEF, haverá uma forma de transacionar em nome do varejista?

Abcs.

[Dúvida] na [API PIX] - Documentação

Caros,

Gostaria de tirar uma sobre os endpoints de cobrança:

Para a funcionalidade de criar uma cobrança, utilizando o QRCode dinâmico, em qual etapa do processo, o EMV para renderização do QRCode seria retornado? Ou o consumidor da API deverá montar o QRCode a partir do Response do endpoint de cobrança? Ou existe previsto um endpoint para as próximas versões da API que retorna o EMV?

Obrigado.

PACS.008: infoAdicionais

Bom dia.
Por favor, solicitamos auxilio com os pontos abaixo:

1. QR Estático campo infoAdicionais será trafegado pela PACS.008, assim como no QR Dinâmico? Ou seja, o PSP Pagador é obrigado a exibir a informação no momento do pagamento, ao concluir a ordem de pagamento (qr estático), teremos que devolver o campo intacto ao PSP recebedor?

2. No caso QR Dinâmico é facultativo entrada em 16/11 para PSP Recebedor realizar a emissão do QR, porém o PSP enquanto PSP Pagador, deverá estar disponível em 16/11, correto? Caso contrário, os usuários não conseguirão efetuar pagamentos nas instituições que não aderiram ao QR Dinâmico.

Pagamento único ou múltiplo

Gostaria de validar o entendimento abaixo:

1 - A cobrança através de QRcode dinâmico terá o padrão de múltiplos pagamentos;
2 - Não está previsto para versão 2 da API a opção de pagamento único.

Exemplificando:

• Pagamento único seria conforme é o boleto atualmente e caso alguém for fazer um segundo pagamento este seria recusado;
• Múltiplos pagamentos. Todo mês seria pago a conta de energia através do mesmo QRcode, porém com dados atualizados relativos ao mês atual.

[Dúvidas] na [API Pix] - Webhook

**Descrição das dúvidas

1. A API 2.0.0 tem agora webhook (método /webhook), mas não especifica o formato desse callback assíncrono: formato da mensagem, se apenas um TxID pode ser informado por vez ou mais, se a informação só deve ser de TxID que teve alteração para o EC fazer get ou pode contar a nova situação etc. Esse formato será especificado ainda para o Go Live, ou ele pode ser diferente entre PSPs ?

2. Um QR-Code estático que tenha TxID (que não é mandatório mas é possível) pode ser informado pelo PSP se webhook estiver ativado, tem que ser informado pelo PSP se webhook estiver ativado ou não pode gerar chamadas de webhook, que só podem ser usadas para QR-Code dinâmico ?

Sistema ou Área
API PIx

URL de conexão
/webhook

[Dúvida] no [QR Code] - Campo Identificador nos Requisitos Mínimos para Experiência do Usuário

Boa tarde,

O campo "Identificador" (da transação) apresentado no documento de Requisitos Mínimos na criação de um QR Code (página 19) é passível de inclusão pelo usuário. Este campo informado pelo usuário recebedor deve ser transmitido no QR Code Estático dentro do campo "TxId"? Ou o campo "TxId" é gerado automaticamente pelo sistema?

Sistema ou Área
QR Code

Grata.

[Dúvida] - Motivo de devolução

Prezados, a API de devolucao não está prevendo motivo de devolucao porém, em mensageria esse é um dado obrigatorio

[Dúvida] na [API Pix] - Devedor x Pagador

Descrição da Dúvida
Na API 2.0.0, alguns campos mudaram de Pagador para Devedor, mas outros se mantiveram. Isso significa que no caso de Pagador que a informação será a do efetivo pagador e não a de contra quem a cobrança foi emitida ? Essa informação virá em inteiro teor ou parcialmente mascarada ?

Sistema ou Área
API PIx

Identificador do Problema
Exemplo de inconsistência local em /cob/

devedor

Pessoa Física (object) or Pessoa Jurídica (object)Os campos aninhados sob o objeto devedor são opcionais e identificam o devedor, ou seja, a pessoa ou a instituição a quem a cobrança está endereçada. Não identifica, necessariamente, quem irá efetivamente realizar o pagamento. Um CPF pode ser o devedor de uma cobrança, mas pode acontecer de outro CPF realizar, efetivamente, o pagamento do documento. Não é permitido que o campo pagador.cpf e campo pagador.cnpj estejam preenchidos ao mesmo tempo. Se o campo pagador.cnpj está preenchido, então o campo pagador.cpf não pode estar preenchido, e vice-versa. Se o campo pagador.nome está preenchido, então deve existir ou um pagador.cpf ou um campo pagador.cnpj preenchido.

Exemplo de inconsitência cruzada em /pix/

"endToEndId": "E12345678202009091221abcdef12345",
"txid": "cd1fe328-c875-4812-85a6-f233ae41b662",
"valor": "100.00",
"horario": "2020-09-10T13:03:33.902Z",
"pagador": {
"cnpj": "12345678000195",
"nome": "Empresa de Serviços SA"
},
"infoPagador": "Reforma da casa",
"devolucoes": [
{}
]

TxID nulo em /pix

Uma query com txid= (ou seja, em branco) em GET /pix deveria retornar os Pix recebidos sem TxID ou retornar erro ?

Dúvida no QRCode - Lista dos domínios autorizados a gerarem QR Codes no âmbito do SFN

Descreva sua dúvida ou problema
No documento de especificações versão 6.2, página 36, nota de rodapé 12, tem a seguinte citação:

A URL/URI está hospedada no domínio do PSP do Recebedor. As validações de segurança incluem
a verificação da validade do certificado apresentado no domínio e a verificação da presença do
domínio na lista dos domínios autorizados a gerarem QR Codes no âmbito do SFN. Caso as
validações sejam positivas, o aplicativo também recupera a chave pública do PSP/domínio em
questão.

Nada foi especificado sobre essa lista dos domínios autorizados a gerarem QR Codes no âmbito do SFN.

• Onde estará hospedado?
• Como recuperar/consultar?
• Como cadastrar um domínio do PSP no âmbito do SFN?

Sistema ou Área
QR Code

API Pix - QR Code Dinâmico no Aplicativo

Entendemos que o usuário final vai poder criar no próprio aplicativo do PSP, um QR Code Dinâmico e também o QR Code Estático.

Na documentação dix:

O QR Code dinâmico no Pix deve ser gerado por meio da API Pix. A API Pix é uma API padronizada pelo
BCB com o objetivo de facilitar o processo de integração com soluções de automação, ampliar a
concorrência no setor e possibilitar menores custos aos usuários finais

No caso da criação de um QR Code pelo usuário recebedor no aplicativo também deve ser utilizado essa a api?

Minha dúvida seria mais na documentação abaixo:

O txid é criado exclusivamente pelo usuário recebedor e está sob sua responsabilidade. O txid, no
contexto de representação de uma cobrança, é único por CPF/CNPJ do usuário recebedor. Cabe ao PSP
recebedor validar essa regra na API Pix.

Se o txid é o usuário recebedor que informa, então no aplicativo tem que ser adicionado um campo para informar o identificador(txid) na criação do QR Code Dinâmico?

Esse txid no caso dos QR Codes gerados pelo usuário no aplicativo não deveria ser um TXID do PSP?

Documento: https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/III.ManualdeFluxosdoProcessodeEfetivacaodoPix-versao1.1.pdf

[Dúvida] na [API Pix] - Endpoint Criar Cobrança – txId informado pelo cliente na requisição

/cob/{txid} Criar Cobrança

Entendemos que o campo TxId fica a cargo do PSP do recebedor. Então esse campo não deveria ser passado pelo cliente na API do PSP, certo?

II_ManualdePadroesparaIniciacaodoPix-versao1.pdf
“1.6.11.O campo 6: txid
....
Quanto ao seu conteúdo, a maneira específica que será empregada pelo PSP do recebedor para implementar a funcionalidade de conciliação de pagamentos por meio da utilização do txid transcende o escopo deste Manual. De outra maneira, estando habilitado o recebedor a conciliar pagamentos conforme especificados no âmbito do Pix, o preenchimento do txid fica a cargo do PSP do recebedor. “

Salientamos que esse campo é o único elo entre o Pix (pagamento) e a cobrança (qr-code). Entendemos que é uma chave forte e deveria ser gerada pelo PSP.

Auth Scopes

Poderiam colocar na spec o retorno dos endpoints de geração e refresh token, acredito que não deve ser diferente de

{
    "access_token": "....",
    "refresh_token": "...."
}

Podem só afirmar como será o retorno dos escopos de autenticação.

[Dúvida] Sobre a migração de contas de recebimentos

Em discussão a respeito da migração de conta de recebimentos, nos deparamos com um ponto de questionamento que julgamos pertinente. A API Pix é estruturada buscando dar autonomia ao usuário, de forma que ele consiga alterar o PSP fornecedor da sua API sem impactar seu negócio.

Sendo assim, temos o seguinte caso:
Migração do PSP A para PSP B

• Altera-se a URL base da API Pix para o PSP B
• Define-se novo webhook no PSP B
• Efetua-se a portabilidade das chaves para conta transacional do PSP B

Após a conclusão da migração, as confirmações de cobranças emitidas no PSP A passarão a ser entregues ao PSP B, que nesse caso não possui tais títulos salvos em sua base de dados, logo, como o PSP B deve prosseguir? Ele simplesmente aceita e cadastra as informações em sua base? E se o integrador precisar listar as cobranças ativas? Como está sendo pensada a migração de cobranças em um cenário de troca de PSP?

[Dúvida] API PIX - Padronização

Descreva sua dúvida ou problema

1. Vocês já nos responderam que não é possível o envio de campos adicionais na API. Gostaria de entender se tivermos todas as APIs padronizadas no portfólio (exatamente iguais), se poderemos ter outras APIs com objetivos diferentes das padrões (exemplo API para geração de QR Code Estático ou consultas com visões distintas).

No mesmo cenário (onde o PSP possui a APi padrão), poderia oferecer outra API para complementar serviços adicionais oferecidos pel participante?
Exemplo: Emissão de QR Code com disparo da fatura para lista de emails indicado

Sistema ou Área
APi Pix, QR code

[Dúvida] APi Pix 2.0 - Indiretos

Descreva sua dúvida ou problema
A API Pix padronizada é obrigatória para os Indiretos?

Sistema ou Área
Api Pix, Qr Code

[Dúvida] no [QRCode] - Como identificar que um recebimento é de um QRCode?

Descreva sua dúvida ou problema
Já fiz uma ponderação aqui de que o campo txid do QRCode estático não deveria ser preenchido pelo usuário, mas sim pelo PSP e deveria ser único, desta forma seria possível correlacionar diversos recebimentos a um único QRCode estático. Isto traria uma experiência de usuário muito mais fluida para o usuário final. Ex.:

1. Usuário A gera um QRCode para dividir a conta de um bar e envia para os amigos;
2. Amigos escaneam e pagam este QRCode;
3. Usuário A consegue ver todos os pagamentos recebidos a partir daquele QRCode específico, gerado para esta ocasião.

Meu primeiro ponto é: É realmente a palavra final do BACEN este ponto a respeito do txid? Porque deixar o identificador aberto (e não único) só torna a experiência mais complicada para o usuário final. Ele terá que ficar vendo várias entradas soltas no extrato e procurando pelo identificador que ele mesmo criou (e que pode ser repetido, o que torna as coisas mais confusas ainda).

Bem, tirando o ponto acima, o manual de experiência do usuário diz que no extrato eu devo diferenciar visualmente quando uma transação recebida é referente a um QRCode gerado. A despeito de tudo o que eu falei acima, qual é a melhor forma de identificar isso? Procurar pela presença do txid? A presença dele garante que aquele Pix partiu de um QRCode?

Outra dúvida: É vedado o envio do txid quando uma transação não partir de um QRCode?

Mais uma dúvida: O QRCode dinâmico também possui um txid. Assumindo a natureza transacional dele, posso assumir que, no caso do dinâmico, este txid é fornecido pelo PSP e é único e não é fornecido pelo usuário final, correto? Até porque, pela api de recebimento o txid é a chave principal utilizada. Meu entendimento está correto?

Webhook mTLS authentication

Na spec informa que a forma de autenticação entre o PSP Recebedor e o gateway deverá ser realizado utilizando mTLS, mas não está claro quem irá prover a chave e o certificado para realizar está autenticação. Essa autenticação deverá ser definida pelo PSP Recebedor?

[SEGURANÇA] Endpoint Criar Cobrança – Nome do devedor divergente da SRF

Aqui em nosso PSP, sempre validamos os campos de CPF/CNPJ na SRF. A dúvida seria se o cliente colocar um nome diferente do cadastrado na SRF qual manteremos na base para apresentar ao PSP do pagador?

Exemplo: na API chegou Dentran-DF, mas na SRF está João Antonio.

[Dúvida] no [Pix Api] - Api Recebimentos (V1) é considerada obsoleta?

Com o release da API PIX v2, podemos considerar a API v1 como obsoleta e que não deve ser utilizada por nenhum participante?

Sistema ou Área
Iniciação de Pagamentos

[Dúvida] - Segurança e Certificados

Estamos com algumas dúvidas relacionadas ao item 5 (Segurança) descrito no documento "II_ManualdepadroesparainiciacaodoPix-versao1.1.pdf"

a. Os certificados digitais dos clientes da API poderão ser emitidos pelo próprio PSP ou
por ACs externas, conforme definido por cada PSP. Não deverão ser aceitos
certificados auto-assinados pelo cliente.

e

8. A credencial de acesso utilizada na autenticação (Client_ID) deve ser vinculada ao CNPJ ou CPF
   do usuário recebedor e deve permitir acesso a recursos apenas de contas transacionais de
   titularidade do CNPJ ou CPF associado

1 - O certificado será gerado pelo PSP para utilização das empresas de automação comercial ou será gerado em nome do EC?

2 - Referente aos termos "cliente" e "usuário recebedor", trata-se do EC (Estabelecimento Comercial) ou empresa no ramo de automação (Tef House, Software House, etc..)?

3 - Vamos precisar gerar 1 credencial (clientId + certificado) por EC (Dependendo da Adquirente, podem existir centenas de milhares) ou vamos precisar gerar 1 credencial por empresa de automação?

4 - Em caso de precisarmos gerar 1 credencial por EC e levando em consideração que podemos ter mais de 100.000 ECs, os próprios ECs terão que enviar suas credenciais (Certificado + ClientID) para as empresas de automação comercial em nome do EC?

5 - Em caso de precisarmos gerar 1 credencial por empresa de automação, como vai funcionar o fluxo de concessão? Antes eu havia lido na documentação que vocês sugeriram a utilização de FAPI + CIBA mas não sei se fecharam nele, outro caminho válido também poderia ser com Oauth2 Authorization Code Flow, sabem me informar?

[Dúvida] na API PIX 2.0 - Expiração

Por favor, pode esclarecer se devemos utilizar o default 86400 (24h) caso esse campo não seja informado na API Pix 2.0?

Na documentação da api esse campo é opcional , mas não indica default. Já na documentação Padrão de iniciação esse default é especificado.

Além disso, gostaria de esclarecer se o campo expiração pode ou não ser utilizado em conjunto com o vencimento (em outros canais). No padrão de iniciação as descrições dos campos calendário.expiração e calendario.vencimento estão divergentes.

Obrigada.

Sistema ou Área
QR Code

[Dúvida] no [PIX] - Motivos de devolução

No documento de Requisitos Mínimos para experiência do usuário, informa a obrigatoriedade de o usuário selecionar, entre a lista de motivos padronizados, o motivo da devolução.

Contudo, não está na documentação nem na API quais são os motivos padronizados.

Sistema ou Área
Iniciação de Pagamentos

[Correção] Formato do txid (cobrança)

Limitar campo txid a qualquer combinação de:
. letras: a-z A-Z
. dígitos decimais: 0-9
. entre 1 e 35 caracteres
O padrão é 'url-friendly' e compatível com o uso de 'uuid's sem traço (32 posições).
O id de devolução tem formato similar.

Múltiplos Webhooks

Um determinado usuário recebedor pode utilizar sistemas de mais de um fornecedor, integrados a API de Recebimento do mesmo PSP, para receber Pix (por exemplo, um sistema utilizado para os frentes de caixa, de loja física; e outro utilizado para e-commerce).
Assim, os 2 sistemas podem configurar diferentes URLs para receber as notificações de Pix realizados via Webhook.

Considerando que os 2 sistemas autentifiquem-se perante o PSP com credenciais diferentes, porém ambas associadas à mesma conta transacional, como deve ser o comportamento do envio dos Webhooks?

1 - Cada URL de Webhook estará associada a uma credencial, de modo que cada sistema receberá apenas os Pix associados à cobranças iniciadas por ele mesmo.

2 - Ambos os sistemas receberão todos os Pix realizados, nos 2 sistemas.

Entendo que será o cenário 2, já que o primeiro cenário tem várias limitações. Por exemplo, não seria possível identificar para qual URL deveriam ser enviados Pix não associados a cobranças.

[Dúvida] APi Pix - Padronização

A API poderá possuir campos adicionais (opcionais) aos padronizados ou deverá ser exatamente igual a API divulgada?

Sistema ou Área
QR Code

Data de expiração - campo calendario.expiracao

Gostaria de confirmar se o campo calendario.expiração pode ser superior a 86400 segundos. No informe 048/2020 faz referência que o pagamento será apenas imediato em 16/11/2020.