search

bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.36k stars 268 forks source link

Padronização de HTTP Status Code em caso de QRCode expirado #169

Closed rafaelchagasb closed 3 years ago

rafaelchagasb commented 3 years ago

No Manual de Padrões para Iniciação do Pix 2.0 foi descrito a nova semântica do campo calendario.expiracao, porém não foi detalhado o seu funcionamento em casos de qrcodes expirados.

Seria interessante que o Bacen definisse um HTTP Status Code padrão para que os PSPs retornassem no caso de qrcodes expirados.

Como o conteúdo do brcode não possui o detalhe de expiração é dificil informar ao usuário final que o pagamento não pode ser realizado devido a isso.

A falta de padrão dificulta o tratamento de erros e por consequência piora a experiência do usuário.

ninrod commented 3 years ago

Seria interessante que o Bacen definisse um HTTP Status Code padrão para que os PSPs retornassem no caso de qrcodes expirados.

Ok @rafaelchagasb , vamos nos debruçar sobre a questão de padronização de erros na versão 2.2.0. Não vamos padronizar todos os possíveis erros, mas alguns, como é o caso do erro que você cita, podem ser interessantes de serem padronizados.

rafaelchagasb commented 3 years ago

Obrigado, @ninrod.

rubenskuhl commented 3 years ago

Me parece que "410 Gone" seria o código HTTP apropriado para um QR-Code expirado.

ninrod commented 3 years ago

Me parece que "410 Gone" seria o código HTTP apropriado para um QR-Code expirado.

Justo. Mas tem uma questão de UX que não foi explorada em detalhe: será que não seria interessante acessar as informações do QR para que o usuário possa ter a chance de ver "do que se trata"?

Talvez no lugar de 410, retornar um código de sucesso mesmo, mas agregar um status para que o PSP pagador possa mostrar o teor do QR, mas não permitir seu pagamento. Que acham?

cryptographix commented 3 years ago

Me parece que "410 Gone" seria o código HTTP apropriado para um QR-Code expirado.

Justo. Mas tem uma questão de UX que não foi explorada em detalhe: será que não seria interessante acessar as informações do QR para que o usuário possa ter a chance de ver "do que se trata"?

Talvez no lugar de 410, retornar um código de sucesso mesmo, mas agregar um status para que o PSP pagador possa mostrar o teor do QR, mas não permitir seu pagamento. Que acham?

Boa. O pagador já precisa tratar os demais valores de status (ativa/concluída/removida). Seria interessante, no entanto, ter alguma recomendação sobre o tempo em que um QR deve ser disponibilizado após vencimento .. pois envolve questões de limpeza de banco de dados etc. Por exemplo, tem que guardar os PIXs recebidos por 90 dias, para poder fazer a devolução, talvez 90 dias tbm para os QR vencidos?

E para as cobranças pagas (concluídas) .. quanto tempo devem estar disponíveis após pagamento?

rubenskuhl commented 3 years ago

Eu acho que um flag não é necessário, pois já há no QR a informação de que está expirado (cobrança imediata) ou vencido (cobrança com vencimento após data limite). Mas sim, poderia ser especificado um ciclo de vida com as seguintes fases: Até expiração/limite + x : 200 e o payload é mostrado Após anterior até +y: 410 Gone Após anterior: 404 Not Found

cryptographix commented 3 years ago

Eu acho que um flag não é necessário, pois já há no QR a informação de que está expirado (cobrança imediata) ou vencido (cobrança com vencimento após data limite). Mas sim, poderia ser especificado um ciclo de vida com as seguintes fases: Até expiração/limite + x : 200 e o payload é mostrado Após anterior até +y: 410 Gone Após anterior: 404 Not Found

é uma opção. No caso, estamos com uma implementação do backend "PSP pagador" que atende a vários wallets e acabamos criando um status de "Vencida" justamente para precisar ter essa verificação duplicada nos wallets. Aí, pensei que isso bem poderia ser feito pelo PSP recebedor, já que ele precisa fazer os cálculos de juros .. ", e assim facilitar a vida dos PSP pagadores.

Talvez o problema aí seria o delay entre a recuperação do payload e o efetivo pagamento .. mesmo o PSP recebedor não considerando a cobrança como vencida, terá sempre de ser validada pelo PSP pagador antes do envio, né? exemplo, payload recuperado às 23:59:00?

rubenskuhl commented 3 years ago

Retomando este tema, já há na API e manuais especificação de resposta do payload a um QR-Code dinâmico já pago ? Imaginem por exemplo uma cobrança imediata, que foi paga mas ainda está dentro da expiração original da cobrança. O que o serviço de disponibilização do payload deve mostrar ?

ninrod commented 3 years ago

@rubenskuhl, espero que fique claro na 2.2.0, que sai em instantes.