Achei apenas no aplicativo móvel
Termos mais procurados:
Histórico de mensagens em sugestões
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
- Implementação da SDK do Pix em Next.js ou React
- Configuração de URLs para Recebimento de Status
- Acionamento de Webhooks em Pagamentos e Devoluções
- Cobrança em Período de Teste Grátis de 7 dias
- Especificação da URL do Webhook no Exemplo Pix
- Implementação do Módulo Gerencianet no Perfex CRM
- Recebimento de Pagamentos via QR Code e Arduino
- Repetição do Processo de Criação com txid
- 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:
Canal: sugestões
A função de autorização é muito bacana mesmo. Na prática, não sei como funcionaria. Existe um desafio de infraestrutura aí. Quase que precisaríamos homologar o EC que nem o Bacen fez com a gente, para validarmos se ele é capaz de responder em 200ms cada request, por exemplo.
Mas seria de já recusar todos os QR estáticos baseado apenas no tamanho do txid... antes mesmo da PACS.008 conter a informação de método de iniciação.
Eu posso dizer do meu caso de uso inicial, de que o recusarTodos no qrEstatico resolve. E tenho dúvida de se o melhor jeito depois é o Regex ou a função de autorização... estou mais para a 2a.
Pode ser interessante manter tudo, quem quer recusar tudo usa o recusarTodos, quem quer personalizar pra recusar só em alguns parâmetros usa eles, e sempre que o recusarTodos estiver como true os outros são ignorados.
Você quem vão dizer se precisamos então de todos esses campos dentro do qrEstatico (para uma maior versatilidade), ou se neste momento bastaria o recusarTodos
{
"pix": {
// configuração da conta
"receberSemChave": true, // permite ao EC recusar Pix Manual de titularidade diferente
"chaves": [{
"chave": "[email protected]",
"recebimento": {
// se false, implica em recusar qualquer txid vazio ou com "", não importando
// qual a forma de iniciação
"txidNulo": false,
// no futuro, quando a forma de iniciação vier na PACS.008,
// será possível outras customizações
// não precisamos entrar nesse mérito agora, mas um esboço poderia ser:
"qrEstatico": {
"recusarTodos": true,
"txidTamMin": 10, // obviamente só entra em cena caso o anterior seja false
"txidNulo": true, // idem
"txidRegex" "^pix", // necessário mais estudos
}
"viaChave": {}
}
}]
}
}
"pix": {
// configuração da conta
"receberSemChave": true, // permite ao EC recusar Pix Manual de titularidade diferente
"chaves": [{
"chave": "[email protected]",
"recebimento": {
// se false, implica em recusar qualquer txid vazio ou com "", não importando
// qual a forma de iniciação
"txidNulo": false,
// no futuro, quando a forma de iniciação vier na PACS.008,
// será possível outras customizações
// não precisamos entrar nesse mérito agora, mas um esboço poderia ser:
"qrEstatico": {
"recusarTodos": true,
"txidTamMin": 10, // obviamente só entra em cena caso o anterior seja false
"txidNulo": true, // idem
"txidRegex" "^pix", // necessário mais estudos
}
"viaChave": {}
}
}]
}
}
Eu estava tentando seguir a idéia original de maior versatilidade... para mim o desabilitar QR-Code estático por chave já resolve.
não seria mais didático para esse fim uma opção para recusar estático (assim como a opção de recusar txid vazio)? pq não serviria pra nada definir um tamanho mínimo de 10, por exemplo.. "ataques" continuariam acontecendo com txid de tamanhos 11-25. se tornaria uma função inútil...
<@!793123559874494465> Acho que alguns campos das comunicações entre PSPs e BACEN admitem/adotam a grafia "txId" (com I maiúsculo) mas na comunicação PSP <-> EC o termo "txid" foi padronizado para minúsculas em todo o material e API padrão do BACEN (já há algum tempo). Então acho que seria mais consistente para os ECs tratar assim (txid).