o cliente vai precisar criar a chave pix pelo celular
Termos mais procurados:
Histórico de mensagens sobre pix 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
- Problemas com Token em Ambiente de Homologação
- Implementação da SDK do Pix em Next.js ou React
- Recebimento de Pagamentos via QR Code e Arduino
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
- Atualização de informações no Retentiva de Cobrança
- Teste de Status de Pagamento em Ambiente de Homologação
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Autenticação com Certificado em NextJS
- Utilização de Endpoints e Payload no Pix
- Integrações com o Laravel e SDK de PHP da EFI
- 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:
Texto: pix
Canal: sugestões
{
"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": {}
}
}]
}
}
{
"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": {
"txidNulo": true,
"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": {
"txidNulo": true,
"txidRegex" "^pix", // necessário mais estudos
}
"viaChave": {}
}
}]
}
}
> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
Estou gostando disso.
> Ah, e sempre com a exceção - nem configurável - de que se a titularidade de origem é a mesma do recebedor, a transação é aprovada.
Perfeito!
Pensando na implementação lógica, o fluxo seria mais ou menos esse:
-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).
se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).
e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).
e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.
É isso mesmo. Eu só descreveria de outra forma pq sem txid e sem a informação do método de iniciação de pagamento, saber se era um QR dinâmico, um QR estático ou um Pix via chave é impossível... ao menos até que isso venha na PACS.008 como está planejando o BACEN. Acho que só o Pix manual vem diferente.
Importantes essas considerações de vocês sobre o que trará mais valor no momento.
Vejam se estamos falando disso:
- QR Dinâmico: valida-se se possui cobrança atrelada e o valor está correto
- QR Estático: permite ao EC aceitar ou não TxId nulo
- Pix via Chave: permite ao EC recusar ou não
- Pix Manual: permite ao EC recusar ou não
Em um segundo passo, para QR Code Estático:
- Validações de padrão do TxId
<@!440035527127990273> <@!780500321994539068>
bom dia. voltando à questão do regex para aceitar/não os recebimentos com base no txid. alguém da GN pode me esclarecer quais os cenários específicos onde vocês visualizaram uma necessidade de aceitação com base em regex? que eu me lembre, essa ideia apareceu como como uma evolução da necessidade de barrar recebimentos com txid vazio. porém:
- para recebimentos de cobranças (QR dinâmico) o txid precisa ser correspondente a uma cobrança existente na GN ou ela já poderia ser descartada (independente de qualquer crivo por parte do EC); e
- para recebimentos de QR estático, é perfeitamente compreensível que a GN não tenha ciência prévia dos txid dos recebimentos mas não vislumbro problemas maiores que exijam uma validação do txid com base em critérios definidos pelo EC (somente o problema conhecido de pagamentos entrando sem txid).
então, eu pergunto:
1. já foi implementada a possibilidade de bloqueio de recebimentos de Pix sem txid (seja a nível de chave Pix ou de conta transacional)?
2. se não foi, a evolução dessa funcionalidade para algo baseado em regex (ou outras regras) não está atrasando desnecessariamente a implantação da função de bloqueio de recebimento sem txid?
Lembrando que esse bloqueio é essencial para os EC que precisam de 100% de assertividade na conciliação automática.
8ª - A página com o QR Code para pagamento poderia ser atualizada automaticamente quando o Pix é pago, assim facilitaria para o usuário identificar que o pagamento dele deu certo, sem ter que fazer o envio de comprovante ou qualquer outra coisa
6º - Quando apenas o módulo de Pix está ativo no plugin, uma mensagem dizendo que é necessário ativar uma forma de recebimento fica aparecendo
3º - Incompatibilidade com alguns bancos. Cadastrei uma chave de e-mail, configurei tudo no WooCommerce, na hora de pagar recebo o QR Code, mas nem todos bancos conseguem ler a image, como no caso do PicPay, o erro apresentado é que o Pix ainda não está disponível para este código... mas se tento ler com o Nubank por exemplo, funciona
Este pode ser um problema de não ter o Nome do Recebedor no QRCode, o PicPay não aceita se não tiver.
boa tarde, estou testando o plugin do WooCommerce e gostaria de enviar algumas sugestões:
1º - Puxar o CPF/CNPJ do cliente no momento do Checkout automaticamente em vez de ficar perguntando toda vez qual o CPF
2º - Adicionar um código Copia e Cola abaixo da imagem do QR Code gerado, nem todos clientes fazem o pedido pelo computador
3º - Incompatibilidade com alguns bancos. Cadastrei uma chave de e-mail, configurei tudo no WooCommerce, na hora de pagar recebo o QR Code, mas nem todos bancos conseguem ler a image, como no caso do PicPay, o erro apresentado é que o Pix ainda não está disponível para este código... mas se tento ler com o Nubank por exemplo, funciona
4º - O identificador do Pix poderia ser o número do pedido gerado no site, complementar ao "Nome da fatura" configurado no plugin. Assim ficaria muito mais fácil de identificar o pagamento no painel GN
Tipo assim:
"recebimento": {
"txid": {
"comecaCom": ["gnPix", "pix", "prod"], // aplica-se OR para os arrays, entre comecaCom e terminaCom, aplica-se AND
"terminaCom": ["BACEN", "pix"],
"aceitarVazio": false
}
}
"txid": {
"comecaCom": ["gnPix", "pix", "prod"], // aplica-se OR para os arrays, entre comecaCom e terminaCom, aplica-se AND
"terminaCom": ["BACEN", "pix"],
"aceitarVazio": false
}
}
Os comecaCom/terminaCom/contem são múltiplos ? Ou seja, poderia ser:
"recebimento": {
"txid": {
"comecaCom": "gnPix",
"comecaCom": "BACEN",
"aceitarVazio": false
}
}
?
Eu acredito que resolveríamos com outra flag, <@!780500321994539068> , algo nesse sentido:
"recebimento": {
"txid": {
"contem": "gnPix",
"aceitarVazio": true
}
}
"txid": {
"contem": "gnPix",
"aceitarVazio": true
}
}
Boa tarde @everyone !
Retomando o assunto endpoint de configurações (https://www.notion.so/Endpoint-de-configura-es-0a97faee68f845ab96ec21551862fe6c).
Nosso time de engenharia observou que existem possíveis situações em que o match do regex com a string do txid pode demorar muitos segundos ou até minutos. Existem situações inclusive de crash da aplicação. Em outras palavras: não é seguro recebermos via input qualquer regex.
Um exemplo que vocês podem testar no browser:
let regexp = /^(\d+)$/;
let str = "012345678901234567890123456789z";
alert( regexp.test(str) );
let str = "012345678901234567890123456789z";
alert( regexp.test(str) );
O alert acima levará um longo tempo até que apareça. Imaginem isso no ato de recebimento de um Pix, no qual cada milisegundo é um fator determinante para um timeout inesperado.
A conclusão é que precisamos controlar melhor quais regex serão aceitas.
A proposta é, ao invés de receber um txidRegex, receber algo mais limitado que também atenda da mesma forma:
"recebimento": {
"txid": {
"comecaCom": "gnPix"
}
}
"recebimento": {
"txid": {
"terminaCom": "gnPix"
}
}
"recebimento": {
"txid": {
"contem": "gnPix"
}
}
"txid": {
"comecaCom": "gnPix"
}
}
"recebimento": {
"txid": {
"terminaCom": "gnPix"
}
}
"recebimento": {
"txid": {
"contem": "gnPix"
}
}
comecaCom/terminaCom/contem: a-zA-Z0-9{0,15} //caracteres aceitos
Gostaria de opinião de vocês em relação a essa nova proposta, bem como sugestões dentro dessa nova abordagem.
Para quem interessar, uma referência sobre o assunto regexp-catastophic-backtracking com mais detalhes.
https://javascript.info/regexp-catastrophic-backtracking
Esse primeiro deploy traz uma versão mais simples, na qual a Gerencianet resolve tudo. Isso atenderá a alguns perfis de clientes. Lembrando que nós não armazenamos a chave privada.
Mas a sugestão de aceitar um CSR é tão boa que já tá até no Roadmap, neste card: https://www.notion.so/Gera-o-de-certificados-API-Pix-a-partir-de-um-CSR-de6f5650a5d44ed092af81d6b830ed66