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.32k stars 262 forks source link

[Dúvida] Data de Pagamento Pretendida (DPP) e Código do município (codMun) #203

Closed jocimarcan closed 3 years ago

jocimarcan commented 3 years ago

Caros,

1) A DPP é uma data que o usuário pagador deverá informar ao PSP pagador no momento do pagamento, que corresponde a data em que ele deseja que sua conta seja debitada e a cobrança liquidada. Certo? 2) Caso o item 1 seja verdadeiro, o PSP pagador deverá programar uma rotina para liquidação de cobranças e garantir que o usuário tenha saldo na DPP para a liquidação da cobrança. Certo? 3) Como foi planejada a experiência de usuário nesse caso? O manual de experiência do usuário parece estar bem defasado da realidade. Em que momento o aplicativo do PSP pagador deverá solicitar a DPP ao usuário pagador, uma vez que a recuperação e os dados do payload da cobrança dependem da DPP? Imagine a jornada do cliente e todas as chamadas de API para exibição dos dados ao usuário pagador (telas). 4) Referente ao codMun, considere que Fulano e Ciclano residam em municípios diferentes. Fulano decide pagar uma cobrança de Ciclano. Dado pela manual que o codMun refere-se ao município de residência do usuário pagador, o valor da cobrança irá variar dependendo do pagador. Isso pode implicar em cobranças sendo negadas pelos PSPs por estarem sendo pagas por usuários diferentes ou cobranças sendo aceitas pelos PSPs com valores diferentes dependendo do pagador. O que eu não estou vendo ou isso é algo pretendido?

rubenskuhl commented 3 years ago

O @ninrod comentou bastante disso no #199 .

rubenskuhl commented 3 years ago

Acho que o único ponto adicional é o 2, mas eu entendo que o Pix Agendado atual não seja garantido em nenhum caso, baseado nos diversos vídeos do BACEN. O recurso de Pix garantido, se é que vai se chamar assim mesmo, é da agenda evolutiva.

ninrod commented 3 years ago

A DPP é uma data que o usuário pagador deverá informar ao PSP pagador no momento do pagamento, que corresponde a data em que ele deseja que sua conta seja debitada e a cobrança liquidada. Certo?

Correto.

Caso o item 1 seja verdadeiro, o PSP pagador deverá programar uma rotina para liquidação de cobranças e garantir que o usuário tenha saldo na DPP para a liquidação da cobrança. Certo?

Seria uma opção, dentro da liberalidade do PSP pagador. Por exemplo, em o correntista não tendo saldo, a cobrança falharia.

Como foi planejada a experiência de usuário nesse caso? O manual de experiência do usuário parece estar bem defasado da realidade. Em que momento o aplicativo do PSP pagador deverá solicitar a DPP ao usuário pagador, uma vez que a recuperação e os dados do payload da cobrança dependem da DPP? Imagine a jornada do cliente e todas as chamadas de API para exibição dos dados ao usuário pagador (telas).

A jornada de QR Dinâmico não está detalhada no manual de UX, no momento e sabemos que há esse "distanciamento". Uma nova versão do manual de UX está sendo desenvolvida.

Referente ao codMun, considere que Fulano e Ciclano residam em municípios diferentes. Fulano decide pagar uma cobrança de Ciclano. Dado pela manual que o codMun refere-se ao município de residência do usuário pagador, o valor da cobrança irá variar dependendo do pagador. Isso pode implicar em cobranças sendo negadas pelos PSPs por estarem sendo pagas por usuários diferentes ou cobranças sendo aceitas pelos PSPs com valores diferentes dependendo do pagador. O que eu não estou vendo ou isso é algo pretendido?

Aqui recomendo ler minha resposta na issue #199: https://github.com/bacen/pix-api/issues/199#issuecomment-733066883