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.39k stars 269 forks source link

[Dúvida] na [API PIX] - Varios assuntos #8

Closed jocimarcan closed 4 years ago

jocimarcan commented 4 years ago

Caros,

A flag de aceite após vencimento foi retirada na versão 2.0.0 da API PIX, bem como juros, multas e descontos. No entanto, ainda consta do manual de experiência do usuário, pag 46, atualizado após publicação da API PIX. Isso dado:

(1) Os campos retirados (juros, descontos e multas) serão incluídos numa versão futura? Alguma previsão?

(2) Poderá o PSP, respeitando o padrão BR Code, criar arranjo próprio no ID 27, diferente do Pix, para atender essa necessidade (aceitar pagamento após data de vencimento com cobrança de juros) e servir por meio de outra API privada?

(3) Todo PSP terá que recusar o pagamento por uma cobrança após a data de expiração?

Considere o seguinte caso: Uma empresa gera uma cobrança de luz (QR code dinâmico com txId1) pelo PSP1 para Fulano pagar; Fulano possui duas contas cadastradas no Pix no PSP1; Fulano gera um QR code estático, de forma independente, com o mesmo txId1, mas trocando apenas a chave Pix – a chave do payload da cobrança era cobranca.luz.xyz764@empresa.com, já a chave do QR code estático é preenchida com fulano.764z@contadofulano.com, que está ligada a uma das contas do Fulano. Em seguida, Fulano realiza um pagamento por meio do QR code estático, ou seja, a si próprio (transferência entre contas):

(4) Como o PSP1 vai reconhecer que esse pagamento não se trata de uma quitação da cobrança, sendo que eles possuem o mesmo TxId? Qual a outra informação que estou esquecendo de considerar?

Outras questões relativas a API PIX:

(5) O retorno do método PUT /cob/{txid} (criar cobrança) está com revisão igual a 1. Não deveria ser 0, uma vez que se trata da criação da cobrança, e conforme a descrição ela se iniciaria em 0?

(6) A API PIX poderá ser usada pelo PSP para a funcionalidade de extrato (transações Pix)? Ou seja, ela exibirá todas as transações Pix (manual, por chave, por QR estático e por QR dinâmico)?

(7) GET cob/ lista uma devolução de 10, relativa a um pagamento de 110 de uma cobrança cujo valor original é 100. Como o usuário conseguiu pagar 110, se ele não poderia mudar o valor original da cobrança que é de 100?

(8) Quando uma cobrança assume o status de CONCLUÍDA? Uma vez concluída ela pode voltar para o status de ATIVA? As regras de mudança de status talvez precise ser melhor documentadas. Embora elas possam ser inferidas, isso pode levar a diferentes tratativas pelos PSPs.

Obrigado

rubenskuhl commented 4 years ago

No QR Code estático o TxID é opcional. E como seu uso é dependente do estabelecimento, apesar do PSP poder recusar TxID duplicado de QR-estático (https://github.com/bacen/pix-perguntas-e-respostas/issues/222), isso só poderia ser feito por instrução do estabelecimento já que o TxID pode não estar sendo usado como identificador único (ex: um supermercado que coloca a linha de caixa como TxID).

Me parece uma má idéia do estabelecimento usar um mesmo TxID num QR-Code estático e num dinâmico.

dmkamers commented 4 years ago

Caros, 1) Os referidos atributos estão em análise, mas estarão sim em versão posterior da API. 2) (nos permitam responder esse ponto à parte - daremos retorno brevemente) 3) O campo 'calendario.expiracao' não é mais um 'timestamp' (data-hora, ou calendário). É uma 'duração' (em segundos). A interpretação do campo é como 'tempo de vida' da cobrança. Assim, ela não deve ser executada após a expiração definida pelo recebedor que gerou a cobrança. Essa duração é relativa ao (a partir do) 'tempo de criação', OU a partir do 'vencimento' (quando presente). 4) O txId é por recebedor, e não por pagador. Assim, é único por cpf/cnpj de recebedor em um PSPx. Um pagamento para outra 'conta' (uma chave de 'terceiro' alheio à cobrança) no mesmo PSPx, é sempre diferente, independente do txId. Assim, os txId´s do recebedor nunca se confundem com os do Fulano (no papel de pagador, com qualquer chave). 5) De fato, na criação deve começar em 0. Na 'revisão' (método patch) se esperam revisões subsequentes. Vamos corrigir, obrigado. 6) Sim. O endpoint 'Consultar Pix recebidos' retorna todos o recebimentos via Pix para um dado recebedor (cpf/cnpj) em um dado PSP, qualquer que seja o 'método de iniciação'. Cada recebimento tem seu próprio identificador único ("endToEndId"). 7) Ele poderia 'criar' um BRCode estático para o mesmo recebedor (chave) e mesmo txId, em cenário semelhante ao descrito no questionamento (4). 8) De fato, precisamos esclarecer as transições de estado. Não se espera que uma cobrança 'concluída' seja reativada.

dmkamers commented 4 years ago

No QR Code estático o TxID é opcional. E como seu uso é dependente do estabelecimento, apesar do PSP poder recusar TxID duplicado de QR-estático (bacen/pix-perguntas-e-respostas#222), isso só poderia ser feito por instrução do estabelecimento já que o TxID pode não estar sendo usado como identificador único (ex: um supermercado que coloca a linha de caixa como TxID).

Me parece uma má idéia do estabelecimento usar um mesmo TxID num QR-Code estático e num dinâmico.

De fato. Note-se que todos os recebimentos via Pix, para um dado cpf/cnpj em um PSP, são 'listados' via Pix API através do endpoint "Consultar Pix Recebidos" (GET /pix).

dmkamers commented 4 years ago

Prezados, Há documentação relevante nos novos anexos "Anexo I - API Pix: Conceitos de Negócio" e "Anexo II - API Pix: Especificação Técnica" que fazem parte do "Manual de Padrões para Iniciação do Pix" revisado disponível na Página do Pix. - quadro "Regulamentação relacionada ao Pix" (à direita).

jocimarcan commented 4 years ago

@ninrod @dmkamers De certa forma, o usuário pagador poderia fraudar (ou acidentalmente gerar) uma cobrança com txId1, gerando um QR code estático com o mesmo txId1. a) Ele poderia gerar um QR estático com valor inferior ao da cobrança; b) Ele poderia fazer um pagamento após a data de expiração da cobrança por meio desse QR estático. 1) Em ambos os casos, como o PSP deverá proceder para resolver esse "conflito", caso ocorra? 2) O PSP deverá obrigatoriamente, mesmo nesses casos, notificar o usuário recebedor desses pixs?

[Sugestão] Analisar padronizar o txId para permitir a distinção de um txId de um QR dinâmico e de um txId de um QR estático. Lembrando que o QR estático estará já disponível em novembro, podendo ter txId quaisquer espalhados por aí. É uma discussão que me parece urgente, que vai além da escolha de case-sensitive e de caracteres. Envolve experiência do usuário e conciliação de pagamento.

ninrod commented 4 years ago

Em ambos os casos, como o PSP deverá proceder para resolver esse "conflito", caso ocorra?

@jocimarcan , o PSP recebedor tem em mãos os elementos para recusar o Pix no ato do Recebimento da PACS008.

O PSP deverá obrigatoriamente, mesmo nesses casos, notificar o usuário recebedor desses pixs?

Não há notificação se a cobrança for recusada.

ninrod commented 4 years ago

@jocimarcan , vou tomar a liberdade de fechar a presente issue.

Pode abrir outra contendo apenas o(s) pontos não tratados aqui? Aproveito para ressaltar que issues com o escopo de dúvida mais restrito ficam mais fáceis de serem encontradas por outros desenvolvedores que eventualmente tenham a mesma dúvida.

jocimarcan commented 4 years ago

Obrigado @ninrod. Posso sim, apenas a questão (2) que ficou sem retorno.