Histórico de mensagens sobre regras em sugestões

E agora tenho medo de lançar outra cobrança mesmo tendo mais 2 clientes esperando, com pagamentos acima de 2.000, porque se um cliente que eu conheço a muito tempo e sei que tem total capacidade de pagar aconteceu isso, não posso esperar menos para outros. E eu não posso gerar carnes para todos ou eu terei que pagar o material de todos o que consome um capital muito alto e rápido.

Minha sugestão é precisamos de mais transparência nesse processo, todos os motivos para negação de um recebimento no cartão precisam ser apresentados previamente para que o lojista possa analisar o cliente para poder fechar negócios de acordo com o perfil do seu cliente, como eu vou propor meios de pagamento e condições de pagamento se as regras de recebimento são ocultas?

Olá, @blackmind5164 [Mensagem Removida]

Percebemos que você não seguiu as regras estabelecidas em nossa plataforma, o que pode ter causado problemas para outros usuários e para a integridade da comunidade. Gostaríamos de lembrá-lo de que é importante seguir as regras para garantir um ambiente seguro e respeitoso para todos.

Caso continue a não seguir as regras, sua conta será banida. Por favor, leia atentamente as regras e as políticas da plataforma e assegure-se de segui-las. Se tiver alguma dúvida ou precisar de mais esclarecimentos, não hesite em entrar em contato conosco.

Agradecemos sua compreensão.

Atenciosamente,

Equipe Efí

Uma opção que você poderia considerar seria usar a API de envio de Pix ao invés do app mobile. Aí o que pode ser feito de transferência está sujeito às suas regras de negócio.

mas enfim, estamos desvirtuando a minha intenção ao me intrometer no assunto: a reclamação era quanto a demora na análise anti-fraude da GN. isso é algo que a GN pode (ou não) ajustar e eu só queria salientar que a reclamação do cliente é válida e ele não é obrigado a saber antecipadamente se a demora é resultado de decisão do modelo de negócios da GN (que buscar minimizar ao máximo a incidência de chargebacks) ou um problema técnico (e "pesquisar" e "ler contratos" não esclarece isso, convenhamos). se a GN não oferece personalização e não tem interesse em afrouxar a análise de forma geral, é uma pena, a saída para o cliente que quer regras mais frouxas é trocar de solução de pagamento. porém, essa informação poderia ter sido passada antes de alcançar respostas que até são óbvias mas soam grosseria (quando não acompanhadas das demais informações), como: "tem reclamação? tem. cost of doing business" e comparações forçadas com outro merchant (você mesmo) sem levar em conta que o produto/situação é totalmente diferente.

Se as regras são as mesmas, o que justifica a demora ser maior na GN?

As adversidades existem em todas as soluções de pagamento por cartão de crédito, das quais já tivemos experiência com as mais usadas do mercado. Essas características vem de como as bandeiras estruturam os arranjos, e os arranjos são os mesmos para todos os lojistas e adquirentes. As regras são as mesmas.

Notar que eu citei merchant, ou em Português estabelecimento comercial, que no caso é você. Há regras dos arranjos de cartão aplicáveis a todos os membros do arranjo: bancos emissores, adquirentes, sub-adquirentes, estabelecimentos. Eu não sugiro assinar contratos sem ler e não sugiro operar num sistema sem entender como ele funciona e quais suas regras, mas cada um, cada um.

Oi <@!177276428675448832> tudo bem? 🙂
O campo aceita ambos os valores, true e false.
Adição do header x-skip-mtls-checking no endpoint PUT /v2/webhook/:chave para permitir o cadastro de servidores webhooks sem validação de mTLS durante o consumo.
Regras explicadas:

Se o parâmetro não for enviado, iremos validar mTLS;
Se o parâmetro for enviado e valor igual à true, não validaremos mTLS ;
Se o parâmetro for enviado e valor diferente de true, validaremos mTLS;

Salientamos que a Gerencianet continuara a fornecer a comunicação com mTLS, ou seja, na comunicação da notificação nada mudou. O POST entre Gerencianet e EC continua enviando o certificado.

Para mais detalhes verifique o roadmap no link https://gnetbr.com/rke4baDVyd

Não, pois de certa forma estaríamos impedindo o recebimento de Pix, os casos onde ser quer bloquear os recebimentos são bastante específicos, oque justifica a configuração padrão de aceitar todos e opcionalmente criar regras de recusa

Confesso que não entendi o problema. Se algum PSP comete a atrocidade de enviar uma chave Pix em uma transação manual (com ag. e conta definidos pelo pagador), a GN tem duas opções:

1. tratar com base nas regras da chave enviada (segue a regra de aceite definida pra essa chave); ou
2. trata como manual (e a opção "receberSemChave" vai barrar, se o EC quiser).

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.

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.

e provavelmente daria até menos trab para conciliar tantas regras de "comecaCom", "terminaCom" "E" "OU", etc

Sim. Então algo a documentar, caso seja único, é que pode-se usar a possibilidade de ter chaves distintas para ter regras distintas, caso necessário.

A separação por chaves continua existindo, cada chave pode possuir as suas regras específicas.

Como é um match de txid nulo nessa versão restrita ? Pq os casos de txid com regras de formação que tínhamos pensado se enquadram nas regras mais restritas (ou seja, atendem).

E não só o BACEN faz isso, Visa e Mastercard tem regras extensas para proteção do arranjo como um todo, não só de bancos emissores, merchants ou titulares de cartão.

Bom dia Renato! Faz sentido sim, mas estamos deixando os integradores colocarem seus projetos relacionados ao Pix para que o canal possa crescer e a comunidade interagir cada vez mais. Qualquer mudança nas regras relativas a este tema vamos avisar a todos. Muito obrigado pelos seus feedbacks, eles auxiliam na melhoria da nossa plataforma e neste servidor.

poderia constar nas regras que os projetos apresentados no <#💻devs> devem fazer uso dos serviços da GN ou serem complementares a eles (um e-commerce que aceite Pix mas use um PSP concorrente para transacionar, por exemplo, acho que não faria sentido ter espaço publicitário no servidor)

Pessoal, como a comunidade está crescendo, elaboramos algumas regras para deixar o ambiente ainda mais produtivo e agradável para todos. Pedimos que visitem o canal <#📋regras> e se atentem às boas práticas! 😊