Se você receber uma transferência para a sua chave de um outro PSP, o webhook não vai ser acionado, pois, não é considerado uma cobrança Pix. Mas será notificado do recebimento pelo aplicativo Gerencianet
Termos mais procurados:
Histórico de mensagens sobre PSP
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Conceito de Payload Locations no PIX
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Autenticação com Certificado em NextJS
- Consulta de Chave PIX na API de Envio
- Acionamento de Webhooks em Pagamentos e Devoluções
- Configuração de URLs para Recebimento de Status
- Implementação da SDK do Pix em Next.js ou React
- Cobrança em Período de Teste Grátis de 7 dias
- Especificação da URL do Webhook no Exemplo Pix
- Repetição do Processo de Criação com txid
- Recebimento de Pagamentos via QR Code e Arduino
- Implementação do Módulo Gerencianet no Perfex CRM
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Teste de Status de Pagamento em Ambiente de Homologação
- Integrações com o Laravel e SDK de PHP da EFI
- Problemas com Token em Ambiente de Homologação
- Funcionamento do Webhook em Ambiente de Homologação
- Geração de Link de Pagamento e Reembolso
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Retenção de Pagamento no PIX em Marketplace
- Cancelamento de Boleto e Remoção do DDA
- Integração de Pix no Bubble (Plataforma No-Code)
- Notificações de Pagamento de Boleto e Pix
- Utilização de Endpoints e Payload no Pix
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
EXIBINDO CONVERSAS RECENTES:
Texto: PSP
Por isto o E2EID não estava em nosso banco de dados, mas é uma questão financeiro entre os PSPs e não uma falha de API.
Portabilidade e reivindicação não são problema pq a chave continua existindo. O problema é se for feita uma remoção no outro PSP.
Pois é, teria que ser um cache do próprio PSP que faz o rateio pra garantir o destino do split. Só que aí vêm questões de portabilidade/reinvindicação que podem invalidar o cache.
você pode adiantar os PSP que vocês já testaram e exibem corretamente ou não?
e você saberia me dizer qual a fonte da GN para esse TradeName? é informado manualmente pelo cliente à GN na abertura da conta PJ? se é automático, a fonte é atualizada (como o site da Receita Federal) ou vem de APIs de terceiros (que levam meses a publicar atualizações)?
mas o qr code pode ter txid e a notificação trazendo o txid + valor pago, derruba a necessidade de client_id + client_secret + certificado de consumo da API (se for possível cadastrar a URL direto na interface do PSP)
Vejo como a culpa de não pegar no comércio talvez dos PSPs?
Diminui carga útil para você e para o PSP, além de não atingir limites impostos pelo PSP caso você tenha uma quantidade grande de volume da dos.
Na verdade o parâmetro ignora o teste de mTLS... o mTLS ainda é requerido. Já a informação de pagador foi sim suprimida pela Gerencianet em alinhamento com a versão nova da API do BACEN, e você pode se juntar à legião que sente falta dela. Instituição pagadora você tem pelo E2EID, que começa com o ISPB do PSP pagador. CPF do pagador você tem como checar se quem pagou é um CPF que você imaginava, mas para isso você precisa passar o CPF que você acha que pagou como parâmetro.
Sim, melhor fazer um loop. Inclusive por sobrevivência a mudanças quer seja de código na Gerencianet, quer seja de mudança de PSP.
Não. Imagine que você tenha emitido duas cobranças para duas pessoas diferentes que tenham conta no mesmo PSP e façam o pagamento ao mesmo tempo. O formato de envio do BACEN para os PSPs permite agregar mais de uma transação em uma mensagem (chamada PACS.008), então pode acontecer das duas virem para você numa única notificação.
<@!780500321994539068> , mestre, qual outro PSP que possa enviar o dado de pagador, vc conhece outro alem do GN ?
É função do número de transação efetivamente realizadas. Se ficar consultando e não realizar transação, o PSP fica limitado e não consegue consultar o DICT.
pq se os outros PSPs possuem
O BACEN tirou isso da API e a GN tirou também. Mas outros PSPs disponibilizam.
O cobv é uma cobrança única com vencimento. O lotecobv é em lote, diversas cobranças com vencimento uma para cada cliente diferente. Notar que o BACEN instruiu os PSPs pagadores a suportarem isso até o dia 15 de Março, e os recebedores a só ofertarem depois do dia 15 de Março.
mas "não seguir" mTLS seria não enviar o certificado. se é o EC que valida, qual a responsabilidade do PSP? qual o critério pra saber que o EC não tá validando?
Não é só o mTLS que o PSP precisa avaliar do EC, é toda a postura de segurança.
Assegurar a segurança do desenvolvimento do software cliente85 da API, mesmo que
desenvolvido por terceiros. Sugere-se que o PSP institua e mantenha processo de
homologação dos softwares clientes, estabelecendo critérios mínimos de segurança para que
eles sejam autorizados a interagir com a API. Nesse caso, a API deve negar tentativas de
comunicação de clientes não homologados.
5. Os usuários recebedores, como clientes da API, são um elo importante na segurança do
sistema, e, portanto, recomenda-se que o PSP tome ações para mitigar os riscos do ambiente
computacional dos seus usuários, uma vez que caso um risco se materialize em um incidente,
o próprio PSP poderá ser afetado. Ações recomendadas (sem prejuízo para outras ações que
o PSP julgar importantes):
a. Instituir e acompanhar programa de melhoria contínua da segurança dos usuários
recebedores que utilizam a API;
b. Realizar campanhas de conscientização e compartilhamento de informações de
segurança junto aos usuários;
c. Definir uma política de troca periódica do certificado, senha e outras credenciais
utilizadas no acesso à API;
d. Validar a segurança do ambiente computacional dos usuários nos aspectos de
infraestrutura, implementação e configuração do software cliente da API.
e. Exigir que as empresas e instituições que utilizem a API tenham uma Política de
Segurança da Informação formalmente instituída.
desenvolvido por terceiros. Sugere-se que o PSP institua e mantenha processo de
homologação dos softwares clientes, estabelecendo critérios mínimos de segurança para que
eles sejam autorizados a interagir com a API. Nesse caso, a API deve negar tentativas de
comunicação de clientes não homologados.
5. Os usuários recebedores, como clientes da API, são um elo importante na segurança do
sistema, e, portanto, recomenda-se que o PSP tome ações para mitigar os riscos do ambiente
computacional dos seus usuários, uma vez que caso um risco se materialize em um incidente,
o próprio PSP poderá ser afetado. Ações recomendadas (sem prejuízo para outras ações que
o PSP julgar importantes):
a. Instituir e acompanhar programa de melhoria contínua da segurança dos usuários
recebedores que utilizam a API;
b. Realizar campanhas de conscientização e compartilhamento de informações de
segurança junto aos usuários;
c. Definir uma política de troca periódica do certificado, senha e outras credenciais
utilizadas no acesso à API;
d. Validar a segurança do ambiente computacional dos usuários nos aspectos de
infraestrutura, implementação e configuração do software cliente da API.
e. Exigir que as empresas e instituições que utilizem a API tenham uma Política de
Segurança da Informação formalmente instituída.
e a pergunta oposta: quem disse que o PSP deve mandar request pra URL do webhook no momento do PUT? isso não tá previsto. eu poderia configurar o webhook com o PUT sem a URL estar sequer alcancável