Termos mais procurados:
Bom dia, @f1ed7e55d61c2f1af0ae4a2814_43203. A diferença entre eles está no processo de geração do txid (identificador da transação Pix). No método pixCreateDueCharge, sua aplicação é responsável por essa geração, enquanto no método pixCreateImmediateCharge, é a própria API da Efí que se encarrega de gerar a cobrança e o txid.
Oi, @golfibra_17433. Como vai?
Em que podemos ajudar?
Olá, @golfibra_17433. Bom dia! Como vai?
A API não cancela os boletos automaticamente. Qual sistema integrado você utiliza?
Bom não sou a voz da toda verdade, mas acredito de tal forma.
Porquer acredito que se o PSP fazer toda a providencia de segurança e regulamento os demais ultilitario deverão cumprir conformebo mesmo e consideram isso os provedores de serviço de hospedagem tvm deveriam se certificar pois a maioria dos clientes hoje em dia usam algum PSP para transmitir algum tipo de serviço ou algo parecido.
Não é questão de desejo... Estou falando por base no que vc ta falando.
A providência pode ser justamente desabilitar a API para a conta ofensora... então cuidado com o que você deseja. 😉
Esse foi um dos modelos sugeridos para o BACEN, que disse não... o que aliás até se voltou contra a segurança quando se descobriu o ataque do webhook via outra conta.
Não não, concordo, foi só uma opinião, de q o webhook é o menor dos problemas... Kkkk
Cartão teria possíveis normas das bandeiras, mas de fato não tem nada nelas obrigando uso de certificado. Boleto poderia ter norma FEBRABAN, mas de fato as normas da FEBRABAN não exigem certificado. Então aí é discrecionaridade da Efí... Pix não.
Era mais fácil o Bacen colocar para só enviar o id da transação, e o cliente fazia uma Consulta...
A api antiga do PagSeguro, era assim, o webhook, só trazia o código da notificação, não era nem o id da transação, e o cliente consumia um endpoint para saber oq era aquela notificação, e o código de notificação, tinha uma prazo para expirar...
https://github.com/bacen/pix-api/issues tem todas as discussões, algumas com posicionamento do BACEN.
Então o PSP que devem tomar está providência.
O certificado para gerar a transação, criar a cobrança, acho q deveria ter em todos os endpoints... Pix, cartão, boleto...
Mas o webhook, vamos ser sinceros, muda nada...
Esse tipo de argumento foi passado para o BACEN, está no histórico do Github do BACEN. Mas não aceitaram, e o padrão é com mTLS. Notar que o webhook do Pix tem mais informações do que só um transaction ID, então isso pode ter colaborado para essa exigência. Ou por homogeneidade com o OpenFinance.
Não é pq o webhook falhou, q o Pix vai ser desfeito... Se o webhook não chegar na aplicação, nada muda, financeiramente...
Até pq, uma opinião minha agr...
O webhook é o ponto "menos importante" pq a transação já aconteceu...
Uma forma de segurança q eu uso, pq vem da época de webhook q não tinha mtls, q é o caso do cartão e boleto, é quando recebo um webhook, não confiar nele, pego o id da transação e eu faço a consulta a api para validar o status...
Sim, multa é só no PSP. Por isso eu disse que a escolha deles é fácil entre a multa e desligar o uso de API que comprovadamente viole o regulamento.
Não, não verificar não impede de você checar mTLS do seu lado.
Mas se alguém vai ser multado ou punido é o psp e não o cliente...
