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
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Conceito de Payload Locations no PIX
- Repetição do Processo de Criação com txid
- Configuração de URLs para Recebimento de Status
- Implementação do Módulo Gerencianet no Perfex CRM
- Consulta de Chave PIX na API de Envio
- Endpoint para Recuperar Saldo
- Implementação da SDK do Pix em Next.js ou React
- Problemas com Token em Ambiente de Homologação
- Recebimento de Pagamentos via QR Code e Arduino
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
- Teste de Status de Pagamento em Ambiente de Homologação
- Atualização de informações no Retentiva de Cobrança
- Autenticação com Certificado em NextJS
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Integrações com o Laravel e SDK de PHP da EFI
- Utilização de Endpoints e Payload no Pix
- Cobrança em Período de Teste Grátis de 7 dias
- Geração de payment_token pelo Postman e teste em homologação
- Especificação da URL do Webhook no Exemplo Pix
- Retenção de Pagamento no PIX em Marketplace
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Cancelamento de Boleto e Remoção do DDA
- Integração da API do Pix em Sistema Próprio
- Acionamento de Webhooks em Pagamentos e Devoluções
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).