Histórico de mensagens sobre dados em sugestões

certo, mas um exemplo do que eu to falando é que na própria documentação os dados que estão lá é do cartão que venceu em maio, e passa normalmente

Olá, <@!517929783753965588>. Boa tarde. Tudo bem?
Em alguns locais da documentação você encontra dados de cartão de crédito de exemplo:
https://dev.gerencianet.com.br/docs/pagamento-com-cartao#section-a-obtendo-um-payment_token-getpaymenttoken-

Mas você pode utilizar qualquer número de cartão que seja válido. Você pode gerar alguns de exemplo no seguinte site: https://www.4devs.com.br/gerador_de_numero_cartao_credito

Oi pessoal, boa tarde!
Estava aqui pensando em algum jeito de testar alguns tipos de erros em transações e acho que tenho uma sugestão para vocês (caso já exista, por favor me sinalize como utilizar).

Eu gostaria que tivesse dados de cartão de crédito para a gente testar em sandbox onde a mensagem daria por exemplo que o digito (cvv) tá incorreto, a validade tá incorreta, numero do cartão ou outra coisa... Se tivessem esses dados na documentação seria ótimo para testarmos isso e poder retornar a informação correta para o usuário.

Boa tarde, <@!266046248103051266>. Tudo bem?
A Gerencianet oferece para você possibilidade de gerar um Botão de Pagamento ou link, que você pode disponibilizar em seu site. Ao clicar no botão, seu cliente será direcionado para a página de pagamentos da Gerencianet, onde poderá preencher os dados e escolher a forma de pagamento.

Veja como é simples gerar um Botão de Pagamento> https://gerencianet.com.br/artigo/oferecer-pagamento-online-em-site/

O sistema de pagamentos por cartão tem muito que melhorar, estou com pagamentos em analise a mais de 1 dia já, muitos clientes reclamando do tempo de analise e de todos os dados estarem corretos e ainda sim a compra ser reprovada. Infelizmente se isso não melhorar vou tem q usar apenas o pix da gn, gosto muito da plataforma mas realmente tá impossivel.

Tenho um website onde vendo meus livros, cursos e consultoria e seria muito bom se o plugin wordpress de vocês pudesse ser compatível com o Woofunnels, plugin que permite criar funis de vendas com order bumps, upsell e downsell. O order bump funciona direitinho, pois é incluído no checkout. O upsell/downsell traria um ganho muito grande, pois permite incluir um produto de maior ou menor valor após o cliente escolher e fornecer os dados de pagamento.

É interessante você criar uma chave aleatória e testar as configurações que mais se ajustam pro seu cenário, uma vez validados replica em sua chave de produção

Olá pessoal, conforme orientado pelo <@!671762828046106646>, faço a sugestão de um endpoint na API PIX que nos informe os dados de um pix enviado para montarmos um comprovante de pagamento do nosso lado.

Entendi. Então você tá apoiando por que é melhor pro EC e por que vai na linha da API do BACEN, apesar da minha sugestão ter sido motivada, principalmente, pela economia de recursos da GN para processar os dados em um formato que tenha as chaves pix como índice. Apenas motivações diferentes.

A minha preocupação foi 0% em relação ao EC. Foi 100% do lado da GN em relação ao desempenho que ela vai ganhar não precisando iterar esse array em todo recebimento. Todo array que depende de um loop que o percorra para que seus elementos internos sejam identificados (e condicionantes sejam aplicadas) é um array "burro". O identificador deve ser a chave do elemento, sempre que possível. Verificar se pix[chaves][123] existe não exige que eu leia todos os elementos em chaves (e muito menos todos os seus valores internos). Ganha-se absurdamente em velocidade e em consumo de memória - e isso mesmo quando só houver 1 elemento no array. Um teste array_key_exists() tem um processamento ínfimo perto de qualquer tipo de loop. Isso pode ser comparado à uma busca em banco de dados em diferentes colunas, uma com índice e a outra sem.

A estrutura de dados do config e a estrutura de dados do atendedor de recebimentos não precisam ser a mesma. Eles podem fazer essa otimização em uma e não na outra... ou podem fazer nas duas. Mas a transação de config ocorre bem raramente, então dá bem na mesma...
.... porém, sua sugestão me parece mais alinhada com a estrutura da API do BACEN. Então por motivos diferentes, eu também apoio.

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.

O cenário atual da GN não permite consultar um pix sem txid, logo não consigo buscar dados de um pix enviado via POST /v2/pix. Dessa forma, não existem maneiras de saber, via aplicação/integração, quando um pix é devolvido por parte do favorecido.

Uma otimização seria só revalidar os callbacks idle. Os de quem transação a cada alguns minutos logo terão dados de retorno gerados pelas próprias notificações.

e do lado de vocês, é possível "exigir o mTLS" pra decidir se os dados devem ser enviados (no momento do callback em si)?

basicamente.. o Itaú tá usando QR estático para um cenário onde deveria estar usando dinâmico. apenas se pouparam de ter que oferecer a leitura de qr codes via payload. deixaram todos os dados da cobrança a cargo do integrador, guardando somente a associação txid <-> valor, e rejeitando o que não coincidir

<@!522899003663450113> mas aí você tá chamando de "manual" só pq foi vc que gerou o qr code estático. Quando falamos "manual" estamos falando de inserção de dados do recebedor (banco, ag, conta, nome, cpf/cnpj), igual no envio de TED

Por Pix Manual podemos entender que são aqueles nos quais o usuário inputa dados bancários (ag, conta, banco..)

tem PSP implementando isso muuuuuito mal.. e ainda tem as opções do tipo "lembrar recebedor" guardam os dados da conta na lista de recebedor e os clientes pagam por ali em vez de ler QR code (não se dão conta de que precisamos do txid para identificar as cobranças)

No extrato, em detalhes da transação, seria interessante exibir a instituição usada para a transação. O app atualmente exibe na notificação, mas no extrato não há essa informação.

É útil pra identificar os problemas, já que não são todos os bancos que estão funcionando 100%. Como o banco Inter, que mesmo o cliente pagando com QR Code, o sistema reconhece como se tivesse sido pago com chave, e os dados acabam não batendo com os da API, precisando fazer a aprovação manual do pagamento.