Histórico de mensagens sobre PSP em sugestões

Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.

E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.

O BACEN parece bem propenso a continuar com mTLS no webhook na v2. Porém, parece haver espaço para na v3 simplificar as webhook para notificação apenas, e aí em algo que só tenha notificação, se quem mandou o aviso foi o PSP ou o Gasparzinho, dá na mesma.

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.

Benefício esse principalmente para o PSP que terá menos carga...

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.

<@!522899003663450113> acredito que podemos assumir que, se webhook.notificar.envio for habilitado, a notificação do envio de Pix será enviada com a informação se foi sucesso ou falha. Em caso de falha, irá constar o motivo, que pode ser uma recusa ou timeout do PSP recebedor.

tem PSP implementando isso muuuuuito mal.. e ainda tem as opções do tipo "lembrar recebedor" guardam os dados da conta na lista de recebedor e os clientes pagam por ali em vez de ler QR code (não se dão conta de que precisamos do txid para identificar as cobranças)

Em relação a isso já que implementaram também o envio do Pix e ele é async, seria interessante criar um webhook também pra recusa do PSP recebedor...

seria para quando a Gerencianet recusar um Pix vindo de outro PSP para a sua conta GN

Uma dúvida que me deu agora é: "recusa" é quando um PSP que você enviou um PIX recusou, quando você recebeu um Pix e foi recusado ou os dois?

<@!793123559874494465> txId nas comunicações PSP/Bacen tem essa capitalização (com I maiúsculo) mas entre PSP e EC é sempre todo minúsculo txid na API então acho que ficaria melhor seguir a mesma linha aqui

É necessário que o Pix se comporte de forma alinhada aos recursos que temos no boleto, para que o modelo hibrido seja coeso, como; desconto por pagamento antecipado, vencimento (considerando feriados locais), juros e multas...

Essa coesão já está desenhada pelo Bacen, a questão que precisamos que todos os PSP's leiam as informações corretamente. A Experiência do Pix mostrou que muitos PSP's levam algum tempo para fazerem suas partes. O Bacen sinalizou que em março todos os PSP's devem ter feito seus deveres de casa, momento que a Gerencianet sentirá confortável em disponibilizar a opção de pagamento por Pix em seus boletos.

não esclarece o que é o PSP, tem um monte informações sobre PACS (adicionou mais confusão em vez de esclarecer, sendo que o cliente GN não precisa nem saber que uma PACS existe. é algo entre PSPs e BACEN), inclui um regex na explicação para algo que poderia ser resumido com uma explicação simples: "(...) contendo letras maiúsculas, letras minúsculas e números, em um total de 26 a 35 caracteres"

o cliente que lê, fica sem entender nada a respeito do que é PSP. e ao clicar no link de detalhes, se depara com isso:

A primeira referência ao termo "PSP" é essa:

<@!781134406680838216> : minha sugestão é retirar as menções às "PACS" da documentação de vocês. é totalmente irrelevante para os clientes. É detalhe de comunicação entre PSPs e BACEN. melhor ainda seria a documentação do BACEN ser referenciada, por mais que a de vocês seja boa, e deixar apenas menção ao que ainda não está 100% aderente ao BACEN. assim evitaria a necessidade de ficar represando modificações, quando elas tiverem por objetivo se adequar ao BACEN.

poderia constar nas regras que os projetos apresentados no <#💻devs> devem fazer uso dos serviços da GN ou serem complementares a eles (um e-commerce que aceite Pix mas use um PSP concorrente para transacionar, por exemplo, acho que não faria sentido ter espaço publicitário no servidor)

Acho que a única coisa já conhecida que se qualifica nisso é a inclusão no campo 54 (valor) no EMV, com formato "x{1-9].xx", que faz diferença em alguns PSPs para não ter que fazer o cliente digitar o valor.

Report de bug:

Os payloads de cobrança pagas estão retornando um JSON contendo erro: "status_cobranca_invalido", mensagem: "A cobrança não está mais com o status ATIVA". Assim, os apps dos PSPs pagadores estão apresentando "erro ao ler o QR".

O payload deveria continuar sendo retornado no padrão JOSE (com certificado e assinatura, igual as cobrança ativas), com o status alterado para CONCLUIDA, para tratamento adequado, conforme status + possível presença do template 01 com valor 12 (qr code de apresentação única).