pix-api
pix-api copied to clipboard
bacen
Idéias para QR-Code do pagador
Seguem alguns pensamentos meus e do @SeanWykes sobre como poderia ser a API Pix para suporte a QR-Code do pagador
Rubens Kuhl — Que mudanças na API vocês imaginam para usar o QR-Code do pagador ?
Sean Wykes — Rubens, pelo lado pagador, penso de imediato que será preciso uma forma de subir o QR recebido para encaminhamento para o pagador pelo SPI. Pode ser tão simples quando um PUT o POST /qrcode. Daí, a confirmação do pagamento poderia vir pela notificação do webhook. O que ainda não vi é a questão de TXID, pois se for gerado pelo pagador, como identificar o pagamento na notificação?
Já para atender o lado pagador, a coisa complica devida às diferentes regras e funcionalidades propostas
Rubens Kuhl — Possivelmente o POST do /qrcode retorne o txid. O problema é garantir idempotência. O que me ocorre é o QR-Code ter um PaymentID do pagador cujo objetivo seja apenas esse de idempotência, não de conciliação. Então se fizer o POST do mesmo QR-Code duas vezes, retorna o mesmo TXID.
Sean Wykes — Aí fica bacana. Como o QR pagador é completamente diferente do QR PIX atual, não precisa nem ter um TXID, então este pode ser gerado pelo recebedor ou seu PSP, e o PSP recebedor manter a relação entre os dois (PaymentID, TXID). Ao chegar no PSP pagador, será disparado o pagamento com o TXID do recebedor normalmente, assim funcionando o webhook e as consultas, inclusive um GET /qrcode/{txid} etc
Entendo que o caminho tem que ser igual a cobrança imediata atual, apenas com um campo adicional que é o "qrcode pagador". Ou seja, o rebecedor define valor, txid, etc, mantendo a conciliação como é atualmente.
Ao receber o qrcode pagador no payload, o PSP do recebedor vai enviar a pain013 para solicitar o pagamento ao PSP do pagador, que, em caso de sucesso, vai seguir na compensação normal com o fluxo atual.
Em caso de insucesso, chegará uma resposta através da pain014, que deve alterar a cobrança para "rejeitada" e avisar pelo webhook mesmo webhook.
@rubenskuhl e @mliberato (e demais) bom dia.
Vou aproveitar a oportunidade e fazer algo diferente aqui: procurar receber um pouco mais de feedback da comunidade no design dos endpoints do QrP. Então trabalhando aqui apenas no campo das ideias (e.g. não assumam, de nenhuma forma, como a versão final), tomo aqui a liberdade de compartilhar o design atual, que, entendo eu, não está muito diferente do que o @rubenskuhl e o @SeanWykes conversaram. Está assim:
body da request exemplo:
{
"qr": "hQVDUFYwMWGBz08QRjAwMDAwMDAwMDAwMDAwMVoKMDAwMDAwMDAwMGOBrtAQMDAwMDAwMDAwMDAwMDAwMdEIMDAxMzIuOTPgOdUIMDAwMDAwMDDWBDExMTHXFDExMTExMTExMTExMTExMTExMTEx2ARDQUND2QsxMTEwMDAxMTEwMNITMjAyMTEyM3QwMjM1OTU5MTExWtNANDEyMjZmOTkyZjRmNDg2ZGI1MTViMGJlNzMwOGNhZDE0MTIyNmY5OTJmNGY0ODZkYjUxNWIwYmU3MzA4Y2FkMQ==",
"valor": "132.93",
"chave": "123e4567-e89b-12d3-a456-426655440000"
}
response exemplo:
{
"qr": "hQVDUFYwMWGBz08QRjAwMDAwMDAwMDAwMDAwMVoKMDAwMDAwMDAwMGOBrtAQMDAwMDAwMDAwMDAwMDAwMdEIMDAxMzIuOTPgOdUIMDAwMDAwMDDWBDExMTHXFDExMTExMTExMTExMTExMTExMTEx2ARDQUND2QsxMTEwMDAxMTEwMNITMjAyMTEyM3QwMjM1OTU5MTExWtNANDEyMjZmOTkyZjRmNDg2ZGI1MTViMGJlNzMwOGNhZDE0MTIyNmY5OTJmNGY0ODZkYjUxNWIwYmU3MzA4Y2FkMQ==",
"valor": "132.93",
"chave": "123e4567-e89b-12d3-a456-426655440000",
"calendario": {
"criacao": "2020-08-14T17:19:00.358Z"
},
"txid": "7978c0c97ea847e78e8849634473c1f1",
"endToEndId": "E18236120202108141719s11145264E2",
"status": "EM_PROCESSAMENTO"
}
Possibilidades para o campo status no response:
Uma vez criado o qrp, não há possibilidade de modificá-lo. É "tudo ou nada".
GET /qrp/{txid}: restorna um qrp e uma lista de pix associados, se aplicável.
Webhook funciona normalmente, assim como funciona para cob e cobv.
Pensamentos, críticas e sugestões são bem-vindos, lembrando que estamos, no momento, nos "early stages" de desenvolvimento da feature.
@ninrod bom dia.
Conceitualmente, eu entendo que há uma cobrança da mesma forma que há na cobrança imediata (cob). O que muda é o estímulo para o pagamento que agora poderá ser feito a partir de um QR code pagador (pull payment).
Além disso, temos possibilidade de resposta negativa agora, o que poderia muito bem ser acomodado com um status da COB.
Acho interessante também usar o modelo da COB, já que seria possível também, aos PSP recebedores, rejeitar pagamentos fora do prazo de expiração por exemplo. Junto com isso já vem também toda a estrutura de dados de recebimento de pix e devoluções, que já estaria "pronto".
Daria até pra suportar "pagar" uma COB existente ao fazer um PATCH enviando o qrcode pagador para aquela COB. Mas para evitar 2 requests, o ideal seria em um único request ser possível criar a cobrança e informar como ela será paga (qr pagador).
Independente do cenário que formos seguir, acho que quem tem que ficar no controle do txid é o recebedor, e não o PSP do recebedor, ou seja, suportar receber o txid como parâmetro.
@mliberato , na COB não tem como encaixar o QrP inclusive por causa do Pix Saque e Pix Troco como vocês terão a oportunidade de conferir nos próximos dias. Além disso tem location, reuso de location, expiração definida pelo usuário recebedor, remoção pelo PSP, etc... Nada disso "encaixa" no produto QrP.
@mliberato , na COB não tem como encaixar o QrP inclusive por causa do Pix Saque e Pix Troco como vocês terão a oportunidade de conferir nos próximos dias. Além disso tem location, reuso de location, expiração definida pelo usuário recebedor, remoção pelo PSP, etc... Nada disso "encaixa" no produto QrP.
Eu também acho que não casa muito bem com a COB não. Mas eu estava pensando se o método deveria ser QrP ou algo mais genérico, já que estão também no roadmap NFC e outros métodos de iniciação.
@ninrod Não sei se estou totalmente convencido de que não encaixa, ao meu ver ele só entra em um estado "mais próximo" da liquidação, mas eu entendo as ponderações.
Sobre o txid, faz sentido deixar o recebedor (que faz interface com a API pix do PSP do recebedor) ter a possibilidade de definir essa informação, que servirá para ele mesmo fazer a conciliação, da mesma forma que ocorre no COB, certo?
Inclusive esse txid deveria ser global (para aquela conta), já que o webhook para notificação da compensação será o mesmo de COB.
@rubenskuhl
Eu também acho que não casa muito bem com a COB não. Mas eu estava pensando se o método deveria ser QrP ou algo mais genérico, já que estão também no roadmap NFC e outros métodos de iniciação.
Consideramos esse caminho, mas o NFC está muito, muito no começo então fica difícil encaixar qualquer tipo de generalização. O mesmo se aplica aos outros tipos de iniciação futuros. Como já tínhamos Cob e CobV, dois produtos, duas tags, e como o QrP é um novo produto, pareceu que criar uma nova tag com novos endpoints era o caminho mais natural.
@mliberato ,
@ninrod Não sei se estou totalmente convencido de que não encaixa, ao meu ver ele só entra em um estado "mais próximo" da liquidação, mas eu entendo as ponderações.
Você teria que encaixar o QrP sem quebrar a API e sem criar possibilidades inconsistentes. Em nosso entendimento, ficou inviável. Vamos pegar apenas o ponto que levantei acima sobre o status: a cob já tem um campo status e um dos status desse campo é o "Removido pelo PSP recebedor". Esse status não se aplica ao QrP e você não pode remover esse status da COB; caso contrário, haveria quebra de API. Só aí você já tem um sério entrave.
Sobre o txid, faz sentido deixar o recebedor (que faz interface com a API pix do PSP do recebedor) ter a possibilidade de definir essa informação, que servirá para ele mesmo fazer a conciliação, da mesma forma que ocorre no COB, certo?
Exatamente, faz todo o sentido, tanto é que o {txid} é informado assim como na cob e na cobv.
Inclusive esse txid deveria ser global (para aquela conta), já que o webhook para notificação da compensação será o mesmo de COB.
O txid é sempre global para aquele CPF/CNPJ tanto para cob quando para cobv quanto para QrP. Ele já era global antes do QrP.
@ninrod "O txid é sempre global para aquele ClientID ("conta"), tanto para cob quando para cobv quanto para QrP. Ele já era global antes do QrP."
Talvez você esteja apenas exemplificando, mas entendo que o txid é global para um CPF/CNPJ, e não ClientId (OAUTH2), conta em PSP ou chave DICT? Procede?
Entendo que uma pessoa (PF/PJ) poderá ter múltiplos client_ids (até para ter escopos limitados).
@SeanWykes
Talvez você esteja apenas exemplificando, mas entendo que o txid é global para um CPF/CNPJ, e não ClientId (OAUTH2), conta em PSP ou chave DICT? Procede?
Exatamente isso mesmo, obrigado.
@ninrod , qual seria a prévia atual de informação que apareceria no QR-Code do pagador ? Além de ser EMV customer-presented, claro.
@rubenskuhl a princípio, o QR Code Pagador contém:
- id do QR Code
- valor (opcional para configuração avançada)
- dados da conta do pagador (ispb, agência, conta, tipo, cpf/cnpj)
- timestamp da geração
- assinatura
- tipo do QR Code (utilizado para configuração avançada)
- dados do recebedor (opcional para configuração avançada)
BER-TLV encodado como binário.
Olá amigos, estou com um projeto de TCC (Trabalho de conclusão de curso), é uma plataforma digital para ONGs receberem doações, dessa forma, o usuário que entrar na plataforma poderá realizar uma doação para a ONG que desejar, a minha ideia inicial é gerar um QRCODE com as informações da ONG e o usuário ler o QRCODE e fazer a doação, é possível gerar o QRCODE com esta API ?
Olá amigos, estou com um projeto de TCC (Trabalho de conclusão de curso), é uma plataforma digital para ONGs receberem doações, dessa forma, o usuário que entrar na plataforma poderá realizar uma doação para a ONG que desejar, a minha ideia inicial é gerar um QRCODE com as informações da ONG e o usuário ler o QRCODE e fazer a doação, é possível gerar o QRCODE com esta API ?
@GusMartins499 , sim, é possível, basta integrar seu software com a implementação da API Pix, normalmente provida por um PSP. Recomendo criar uma discussão específica para abordar este tema e assim não desviar a presente thread do assunto principal.
Olá amigos, estou com um projeto de TCC (Trabalho de conclusão de curso), é uma plataforma digital para ONGs receberem doações, dessa forma, o usuário que entrar na plataforma poderá realizar uma doação para a ONG que desejar, a minha ideia inicial é gerar um QRCODE com as informações da ONG e o usuário ler o QRCODE e fazer a doação, é possível gerar o QRCODE com esta API ?
@GusMartins499 , sim, é possível, basta integrar seu software com a implementação da API Pix, normalmente provida por um PSP. Recomendo criar uma discussão específica para abordar este tema e assim não desviar a presente thread do assunto principal.
Tudo bem, assim farei quando começar a integração, muito obrigado e desculpe por qualquer coisa
BOa t
@rubenskuhl e @mliberato (e demais) bom dia.
Vou aproveitar a oportunidade e fazer algo diferente aqui: procurar receber um pouco mais de feedback da comunidade no design dos endpoints do QrP. Então trabalhando aqui apenas no campo das ideias (e.g. não assumam, de nenhuma forma, como a versão final), tomo aqui a liberdade de compartilhar o design atual, que, entendo eu, não está muito diferente do que o @rubenskuhl e o @SeanWykes conversaram. Está assim:
body da request exemplo:
{ "qr": "hQVDUFYwMWGBz08QRjAwMDAwMDAwMDAwMDAwMVoKMDAwMDAwMDAwMGOBrtAQMDAwMDAwMDAwMDAwMDAwMdEIMDAxMzIuOTPgOdUIMDAwMDAwMDDWBDExMTHXFDExMTExMTExMTExMTExMTExMTEx2ARDQUND2QsxMTEwMDAxMTEwMNITMjAyMTEyM3QwMjM1OTU5MTExWtNANDEyMjZmOTkyZjRmNDg2ZGI1MTViMGJlNzMwOGNhZDE0MTIyNmY5OTJmNGY0ODZkYjUxNWIwYmU3MzA4Y2FkMQ==", "valor": "132.93", "chave": "123e4567-e89b-12d3-a456-426655440000" }response exemplo:
{ "qr": "hQVDUFYwMWGBz08QRjAwMDAwMDAwMDAwMDAwMVoKMDAwMDAwMDAwMGOBrtAQMDAwMDAwMDAwMDAwMDAwMdEIMDAxMzIuOTPgOdUIMDAwMDAwMDDWBDExMTHXFDExMTExMTExMTExMTExMTExMTEx2ARDQUND2QsxMTEwMDAxMTEwMNITMjAyMTEyM3QwMjM1OTU5MTExWtNANDEyMjZmOTkyZjRmNDg2ZGI1MTViMGJlNzMwOGNhZDE0MTIyNmY5OTJmNGY0ODZkYjUxNWIwYmU3MzA4Y2FkMQ==", "valor": "132.93", "chave": "123e4567-e89b-12d3-a456-426655440000", "calendario": { "criacao": "2020-08-14T17:19:00.358Z" }, "txid": "7978c0c97ea847e78e8849634473c1f1", "endToEndId": "E18236120202108141719s11145264E2", "status": "EM_PROCESSAMENTO" }Possibilidades para o campo
statusno response:
Uma vez criado o qrp, não há possibilidade de modificá-lo. É "tudo ou nada".
GET /qrp/{txid}: restorna um qrp e uma lista de pix associados, se aplicável.Webhook funciona normalmente, assim como funciona para cob e cobv.
Pensamentos, críticas e sugestões são bem-vindos, lembrando que estamos, no momento, nos "early stages" de desenvolvimento da feature.
Fala @ninrod, beleza? Em que pé está essa feature?
Esse atributo do request QR seria o payload de informações do QRCODE?
Pelo que eu entendi, esses endpoints seriam direcionados ao request de um pagamento de uma cobrança já gerada, utilizando as informações do payload?
@leoelias023 , bom dia, tudo bem.
A feature ainda está "em desenvolvimento". O QR do pagador já foi apresentado ao mercado que forneceu feedbacks ao BC e conversas estão em andamento.
Pelo que eu entendi, esses endpoints seriam direcionados ao request de um pagamento de uma cobrança já gerada, utilizando as informações do payload?
Não entendi exatamente qual é a pergunta, mas acho que vale uma breve explicação sobre o QR do pagador:
O QR do pagador você poderia entender como se fosse um "cheque". Ou então um valor "ao portador". Ou uma "autorização" que o usuário pagador fornece ao recebedor para que este retire uma quantia específica daquele. O usuário recebedor, então, de posse do payload do QR, usa a API pix de seu PSP recebedor para que este utilize o BCB como roteador via pix. O QR Code do pagador, juntamente com outras informações, eventualmente, chega ao PSP do pagador que poderá conferir se o QR do pagador em questão é realmente válido e bate com as informações de requisição de pagamento. A partir daí, segue-se o fluxo normal.