Histórico de mensagens sobre PIX em sugestões

Sugestão: incluir na parte de tarifas do Pix que não há tarifa adicional para devolução de Pix recebido, além das já incorridas para o recebimento que originou a devolução.

Bom dia <@!317088998415925248> ! Em nossa Api Pix, temos um endpoint para consulta de saldo, GET /v2/gn/saldo . Para mais detalhes, acesse nossa documentação https://dev.gerencianet.com.br/docs#section-buscar-o-saldo-da-conta

aceitar apenas PIX PELO COPIE E COLA / qr code

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

<@!236380478955978753>
https://dev.gerencianet.com.br/v1/docs/api-pix#section-criar-modificar-configura-es-da-conta

ja é possivel não autorizar recebimentos de pix, pela chave fixa?

Pessoal poderiam ver a possibilidade de ter um menu para desligar as notificações de pix recebido no app GN, pois no caso de empresa todo tempo chega um notificação. Caso já exista por favor me avisem.

a gerencianet tá de parabéns mesmo com a questão de implantar o PIX pro Brasil

Bom dia! Alguns pontos a serem pensados:
1. Busca por txid ou e2eid
2. Filtrar devoluções (Existe a opção de filtrar por crédito ou débito) mas não por crédito devolvidos.
3. Devolver pix via interface web (A devolução só é possível de ser feita via APP GN, então temos que identificar na interface web a transação por data e hora e ir no APP para devolver)

Pessoal, vocês tem um "não antes de" para a quitação de cobrança da API-Pix em ambiente de homologação ?

É eu vi, agora ficou bom, já removi do meu código a correção que tinha, fui pego de surpresa pela correção hoje de manhã, fiquei uma meia hora sem emitir pix kk

Se houver alguma coisa no arranjo Pix e/ou no comportamento dos demais PSPs que impeça isso, pq não regride para algo extremamente simples que atenda a necessidade primária da maioria?

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

Então, Pessoal, o Pix é algo que veio para ficar. É nítido o crescente uso da modalidade, seja por Pessoa Física ou por Pessoa Jurídica, e na troca entre os dois. É muito animador tudo que está ocorrendo, e não aderir ao Pix é uma inocência gerencial.

Observamos que a funcionalidade de recusa de txids, desenhada dentro das variáveis do fluxo oficial do Pix, tem tido problemas devido a implementações precárias por parte de alguns PSP's, que estão tecnicamente aquém do que se espera das especificações do Bacen.

Em conversas internas, e diante de nossas responsabilidades, não seria justo, seja com a comunidade ou com o próprio ecossistema do Pix, deixarmos de ofertar possibilidades em decorrência de problemas básicos de aplicação/interpretação da documentação oficial do Bacen por outros PSP's.

Por isso, iremos liberar, ainda hoje, o recurso de recusa de Pix, PARA TODOS, cabendo a nós "puxarmos a orelha" dos outros PSPs e buscarmos que eles sejam tecnicamente mais assertivos sobre a correta implementação do Pix.

Com o apoio de vocês, seguimos fortes na nossa responsabilidade e nossa contribuição com a inovação de Meios de Pagamentos no Brasil.

Manda para o DECEM e para o pix-pendencias também. Shame and blame. 😉

Se enviar a chave num Pix manual, mesmo assim não vai ter txid... cai na outra regra. De txid inválido o espaço de endereçamento é o limite, mas se for do tamanho do txid de um estático, também vai pra chón. Se enviar um txid de dinâmico que não tem match em cobrança, idem.

Pessoal, bom dia.

Passamos os últimos três dias testando massivamente a nova funcionalidade, porém acreditamos que ainda podemos ter surpresas com PSP's que fazem uma "abordagem própria", algo que já estamos calejados 🙄 , por exemplo alguns enviam as chaves mesmo nos Pix manuais, ou podem enviar um outro padrão de txid inválido que ainda não pegamos, etc.

Portanto, não iremos liberar a atribuição autônoma de escopos no nosso sistema ainda. Peço aos interessados que informem ao <@!652136709982781470> o Client Id das credenciais de vocês, ele vai atribuir os novos escopos pontualmente. Vamos seguir o entendimento de uma funcionalidade em beta, portanto sugiro que criem uma nova chave evp exclusiva para a utilização das novas configurações, para não atrapalhar a operação de vocês.

relevante: https://github.com/bacen/pix-api/issues/209#issuecomment-797197299

Pessoal, boa tarde.

Sobre o lançamento desses novos recursos que negociamos, quero pedir aos envolvidos mais um pouquinho de paciência. As funcionalidades já estão em produção porém seguramos a atribuição externa dos novos escopos.

Todos sabem que ambiente de testes é uma maravilha 👀, mas como a alteração está em um ponto crítico do nosso sistema (diretamente na confirmação/recusa de Pix) achamos prudente finalizar nossas baterias de testes em produção e deixar o sistema amadurecer com esses novos recursos.

Se tudo ocorrer dentro do esperado, estamos projetando a liberação ainda amanhã, pela manhã.

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.