Histórico de mensagens em sugestões

Acho que a única coisa já conhecida que se qualifica nisso é a inclusão no campo 54 (valor) no EMV, com formato "x{1-9].xx", que faz diferença em alguns PSPs para não ter que fazer o cliente digitar o valor.

Pessoal, existe alguma doc para mostrar qual a melhor maneira de gerir as requisições para pagamento de forma que o cliente sinta fluidez na hora de pagar?

👍

<@!440035527127990273>, fizemos essa alteração que você sugeriu

E sobre esse tema, confirmação do Banco Central:
https://github.com/bacen/pix-api/issues/232

Entendi <@!780500321994539068>, vou verificar com a equipe responsável e assim que eu tiver uma posição eu falo com vocês.

Um comentário disso <@!775350441965649951> é que a recusa de pagamentos duplicados não pode depender do payload. Ela precisa ser feita na ligação com o SPI/PIG.

<@!440035527127990273> Mais uma vez, obrigado por nos reportar. Iremos analisar e com certeza elas serão levadas em consideração para melhorar cada vez mais nosso ambiente.

obs: até porque, uma cobrança estar com status CONCLUIDA não é um erro. É um status perfeitamente normal para uma cobrança.

Report de bug:

Os payloads de cobrança pagas estão retornando um JSON contendo erro: "status_cobranca_invalido", mensagem: "A cobrança não está mais com o status ATIVA". Assim, os apps dos PSPs pagadores estão apresentando "erro ao ler o QR".

O payload deveria continuar sendo retornado no padrão JOSE (com certificado e assinatura, igual as cobrança ativas), com o status alterado para CONCLUIDA, para tratamento adequado, conforme status + possível presença do template 01 com valor 12 (qr code de apresentação única).

Agradecemos pelas sugestões <@!440035527127990273>.

-editado-

-editado-

O link para abertura de ticket (para solicitar certificado API Pix) na página https://dev.gerencianet.com.br/docs aponta para https://gerencianet.com.br/fale-conosco/ quando ele poderia apontar para https://sistema.gerencianet.com.br/tickets/criar (os tickets abertos pelo link apontado atualmente não ficam vinculados à conta dentro do sistema).

O horário das mensagens no sistema de tickets está sendo exibido em UTC (sem nenhuma indicação de que este é o fuso horário utilizado).

"a)Fase 1 – até 01/02/2021: Canais de atendimento, produtos e serviços mais relevantes, como contas de depósito à vista e operações de crédito;

b)Fase 2 – até 15/07/2021: Cadastros e transações de clientes relativas aos produtos e serviços da fase 1;

c)Fase 3 – até 30/08/2021: Serviços de iniciação de transação de pagamentos e encaminhamento de proposta de operação de crédito;

d)Fase 4 – até 15/12/2021: Outros produtos, serviços e transações de clientes, como operações de câmbio, investimentos, seguros e contas-salário."

Eu tenho impressão que na fase 1 tem só a tarifa máxima mesmo. Mas um possível pedido seria seguir o mesmo layout do OpenBanking de tarifas públicas disponível via interface autenticada.

huum.. interessante, não tava sabendo não. Obrigado <@!780500321994539068> !

Uma possibilidade seria pegar obrigações que a Gerencianet já vai ter que atender de OpenBanking, que inclusive iriam ser obrigatórias agora e foram adiadas para Fevereiro, e já fazer de forma padrão. A primeira fase é justamente expor tarifas, mas eu não sei se precisa da tarifa específica de uma conta ou da tarifa máxima.

Equipe GN, uma sugestão que acho interessante é vocês fornecerem um endpoint para que seja retornado quais as tarifas relacionadas a conta do cliente (sobre o escopo da API PIX). No webinar falou-se que uma empresa ou outra pode fazer parceiras com o GN e que os valores dessa tarifa podem variar. Isso, para quem fez a integração com a API para vários clientes acaba sendo ruim, pois a alternativa seria o usuário fornecer essas informações em vez do próprio sistema consultar e calcular a despesa gerada pela integração. O sistema podendo recuperar essa info, seria o ouro!

As sugestões agregam muita a Gerencianet, agradecemos a participação e com certeza elas serão levadas em consideração para melhorar cada vez mais nosso ambiente.