Histórico de mensagens sobre an

estou com problema para fianalizar no meu projeto ao clicar para gerar um boleto vem essa mensagem de erro: Erro código:3500034
Erro:validation_error
Erro descrição:Array

Ok, qualquer outra dúvida, pode contar com a gente!

Entendi. Para essa situação, você pode usar a opção de envio de Pix através do endpoint PUT /v2/gn/pix/:idEnvio. Com este recurso, você pode enviar valores para a chave Pix ou os dados bancários do destinatário. No entanto, ao usar essa função, todo o controle de split deve ser realizado em sua própria aplicação.

A simulação de cobranças de cartão em ambiente de Homologação funciona com base na análise imediata de acordo com o último dígito do número do cartão de crédito utilizado.

ah tipo. eu to usando o plugin do efi, pro wordpress. entao em tese, nao preciso fazer nada, ne?

Ah legal. Muito Obrigado Guilherme.
No sandbox retorna sempre o pagamento aprovado? Ou preciso enviar algum parâmetro?

Olá, @lucianah. As credenciais que você enviar para a autenticação não mudará. A alteração será no access_token retornado na autenticação.

bom dia. recebi um email dizendo que o token da api de cobrança foi alterado. mas quando eu vou na API pra ver o client_id e client_secret eles parecem os mesmos. Este token que foi alterado é de outro lugar no site?

Boa tarde.
Qual o número de cartão usado para testes no ambiente sandbox?
Que seja válido para a API.

Olá, @diogo.f.m.7 e @rubenskuhl. Bom dia!

Gostaríamos de esclarecer que, conforme as normas do Banco Central, as notificações enviadas do PSP recebedor (no caso, a Efí) para o usuário recebedor trafegam utilizando o canal mTLS. Como parte desse protocolo, sempre enviamos o certificado nos webhooks, seja no cadastro ou na notificação de Pix.

Entendemos que em alguns cenários, como hospedagem em servidores compartilhados, pode haver restrições em relação à inserção de certificados. Por isso, disponibilizamos a opção skip mTLS, que permite o cadastro do webhook sem a necessidade do hand shake mTLS por parte do integrador. É importante destacar que, ao optar por utilizar o atributo skip mTLS, o integrador fica responsável por validar o nosso certificado, conforme as orientações que fornecemos.

Ressaltamos que sempre seguimos as diretrizes do Banco Central para garantir a segurança e conformidade de nossos serviços. 🧡

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.

Olá, @golfibra_17433. Bom dia! Como vai?
A API não cancela os boletos automaticamente. Qual sistema integrado você utiliza?

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.

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.

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...

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...