Histórico de mensagens sobre pix em sugestões

Sobre o pagamento/transferência via POST em /pix, eu acho que ele devia ser mudado para PUT. O POST hoje não tem idempotência, e está sujeita a duplicações... a idempotência seria garantida com um parâmetro id (similar ao id de devolução), diferente do eventual txid (que é do recebedor). Para não ter que criar muitos métodos distintos, acho que poderia ser um único... se não tiver txid ou código, a ação é de transferência. Se tiver txid ou código, é pagamento... mas são mutuamente exclusivos. Ou tem o txid, ou tem o código do Pix Copia e Cola.
No geral fica:
chave mutuamente exclusivo com banco/tipo/agência/conta/cpf , mas um deles é requerido
txid mutuamente exclusivo com código, mas é opcional.
idenvio obrigatório, e garante idempotência. Se receber duplicado, só dá erro se for diferente. <@!793123559874494465>

Eu tinha pensado em algo para confirmar existência de chave em situações de split e envio de Pix, mas aí não funcionaria para CPF/CNPJ/chave aleatória. 😦

Mas o que está no manual do BACEN sobre mostrar LegalName ou TradeName do Pix recebido ?

https://github.com/renatofrota/pix-pendencias/labels/Gerencianet

Olá, <@!742492546198143151>! Sabe me dizer se já estamos conseguindo usar o TradeName aparecendo no extrato do destinatário, ao enviar PIX via API?

Sugestão: alinhar melhor com a equipe as informações a respeito dos [novos] recursos e exigências [removidas] para consumo da API Pix. Por ex: as informações a respeito da necessidade ou não de mTLS no PUT /webhook, bem como no recebimento dos callbacks, estão desencontradas lá no canal <#❖pix>. Tem membros da equipe GN dizendo A e outros membros dizendo B.

Podia por os 2. As vantagens do pix.ae:

1. mais fácil usar (muitas mídias não tornam clicáveis - ou sequer aceitam - links que não sejam http(s))
2. é acessível para todos os clientes Pix universalmente, inclusive os clientes de PSPs que ainda não suportam a integração "automática" pelo header x-pix-brcode (abre no navegador e escaneia/copia o brcode)
3. se propagará mais rápido devido às vantagens 1 e 2 😁

O app da GN poderia suportar links https://pix.ae nativamente: https://github.com/bacen/pix-api/issues/251#issuecomment-761594651

Para o regulamento somos pragmáticos 🙂 Faz parte de nosso entusiasmo com o Pix

Na verdade, .webhook.pix.ae. Precisa do servername para decidir qual certificado apresentar.

webhook.pix.ae

Na verdade, chave Pix e txid, para evitar o problema do webhook pilantra. 😉

Eu tenho a sensação de que o POST em v2/pix para envio de Pix e em v2/cob para criação de cobrança com txid gerado pelo PSP estariam melhor posicionados numa rota proprietária da GN, como /gn/pix e /gn/cob. Como está agora, pode acabar colidindo com alguma implementação futura do BACEN.

Bom dia Nageni, mande a sua dúvida no canal <#❖pix> por favor, vamos auxilia-lo em suas dúvidas.

Isso (o que tentei explicar), mas de qualquer forma é manual. A questão é que isso seria algo legal a ser utilizado, rejeitar qualquer pix que não seja gerado a partir do /cob

Discordo disso. Um teste que fiz com o Paghiper foi o seguinte:

O Paghiper não é PSP e está usando a chave "[email protected]", então peguei o txid de uma transação e tentei enviar um QRCode Estático com o txid (porque ai eu poderia tentar enviar com valor menor da cobrança). O Itaú recusou o Pix porque estava efetuando uma transação manual e não por causa do regex do txid, por exemplo.

As vezes o usuário pode enviar um Pix para uma chave sua sem que você queira.

Por Pix Manual podemos entender que são aqueles nos quais o usuário inputa dados bancários (ag, conta, banco..)

O ponto que tô levantando é: Você tem um sistema que gera a cobrança com a chave [email protected] e ai um cliente (isso já aconteceu inclusive) não paga a cobrança e depois envia a grana para a chave, sem ser pela cobrança...

Não seria melhor usar "aceitarPixManual": true" e aceitar que seja configurado pra cada chave?