Histórico de mensagens sobre chave pix | Canal sugestões | Página 1

francisco.carvalho

26/02/2021

{
"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": {}

}
}]
}
}

francisco.carvalho

26/02/2021

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

anoni_mato

26/02/2021

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.

rubenskuhl

26/02/2021

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

francisco.carvalho

26/02/2021

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>

anoni_mato

26/02/2021

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.

wesleyhp

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

joelemanoel

24/02/2021

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.

wesleyhp

24/02/2021

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

francisco.carvalho

23/02/2021

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

rubenskuhl

15/02/2021

API de Cobrança. Daria para conciliar recebimentos, não pagamentos. No caso de envio de Pix se você fizer por banco/conta/CPF já vai saber para quem foi, mas por Chave Pix não. E imagino que seja esse o problema.

rafaelsiqueira8363

02/02/2021

Pessoal, trazendo para cá a discussão sobre devolução por parte do favorecido. Contexto:

Pessoal, uma dúvida sobre devolução de pix.
1. Pix enviado da GN > Chave qualquer. Recebo o webhook com a realização ou não. Tudo certo.
2. A partir da conta "favorecida", faço a devolução do pix.

Essa devolução por parte do "favorecido" deveria ativar o webhook e notificar minha aplicação? Entendo que a devolução esteja atrelada ao e2eid original.
Eu testei esse cenário aqui e não fui notificado. É um comportamento esperado ou temos um gap aí?

rubenskuhl

01/02/2021

Eu tinha pensado em algo para confirmar existência de chave em situações de split e envio de Pix, mas aí não funcionaria para CPF/CNPJ/chave aleatória. 😦

rubenskuhl

15/01/2021

Na verdade, chave Pix e txid, para evitar o problema do webhook pilantra. 😉

joelemanoel

13/01/2021

Discordo disso. Um teste que fiz com o Paghiper foi o seguinte:

O Paghiper não é PSP e está usando a chave "[email protected]", então peguei o txid de uma transação e tentei enviar um QRCode Estático com o txid (porque ai eu poderia tentar enviar com valor menor da cobrança). O Itaú recusou o Pix porque estava efetuando uma transação manual e não por causa do regex do txid, por exemplo.

joelemanoel

12/01/2021

O ponto que tô levantando é: Você tem um sistema que gera a cobrança com a chave [email protected] e ai um cliente (isso já aconteceu inclusive) não paga a cobrança e depois envia a grana para a chave, sem ser pela cobrança...

francisco.carvalho

12/01/2021

## Objetivo

Permitir que o EC defina algumas configurações:

- Quando aceitar um txid;
- Aceitar ou não Pix Manual;
- Quais notificações receber via webhooks;
- Receber ou não a tarifa no webhook;
- Outras configurações podem surgir.

---

# PUT /gn/config

## Input

json
{
"pix": {
"aceitarSemChave": true,
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}

## Output: 200

---

## Definições

Por default:
→ Todas as notificações nascem habilitadas;
→ Não há match de regex: aceita-se qualquer txid;
→ Tarifa não é retornada no webhook;
→ Pix Manual é acatado sempre;

Default em JSON

json

{
"pix": {
"aceitarSemChave": true,
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}

francisco.carvalho

12/01/2021

Hum, teríamos que trocar pra um verbo.
"aceitarPixSemChave": true ou "aceitarPixManual": true"

francisco.carvalho

12/01/2021

{
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}

Definições:

Por default:
- Todas as notificações nascem habilitadas;
- Não há match de regex: aceita-se qualquer txid;
- Tarifa não é retornada;
- Pix Manual é acatado sempre;

Default em JSON

{
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}

Observação
Quando de um envio de Pix: a notificação de webhook, em caso de status NAO_REALIZADO , poderá trazer o motivo da falha (PSP deu timeout, recusou, etc..). Em outro momento falaremos disso.

rubenskuhl

12/01/2021

Só lembrando que nem todo Pix vem com chave identificada. O Pix manual por agência/conta não tem.

rubenskuhl

22/12/2020

É que dessa forma vocês não precisam coordenar uma mudança do tipo "vira a chave"... quem já estiver pronto, já ativa assim.
(E no /pix poderia já ter o ?client_id também)

Histórico de mensagens sobre chave pix em sugestões

CONECTAR AO DISCORD

PROCURE NO HISTÓRICO

CANAIS DE TEXTO

DISCUSSÕES

EXIBINDO CONVERSAS RECENTES:

francisco.carvalho

francisco.carvalho

anoni_mato

rubenskuhl

francisco.carvalho

anoni_mato

joelemanoel

wesleyhp

francisco.carvalho

rubenskuhl

rafaelsiqueira8363

rubenskuhl

rubenskuhl

joelemanoel

joelemanoel

francisco.carvalho

francisco.carvalho

francisco.carvalho

rubenskuhl

rubenskuhl