Open mvallim opened 3 years ago
renatofrota
commented
3 years ago O evento em t=2 (Pagador paga) está ligado ao Banco B no seu gráfico mas o Banco A (do recebedor) está envolvido nesse processo. Este evento será completado com a conivência do Banco A.
No momento t=3, o Banco A vai recusar a remoção da cobrança pois ela já estará com status CONCLUIDA devido ao pagamento recebido em t=2.
mvallim
commented
3 years ago @renatofrota,
Mas veja que em t=3 o "Banco A" ainda não recebeu a transferência do "Banco B", não teria como colocar uma cobrança como CONCLUIDA, se ainda não recebi, como seria esse caso?
A conclusão de uma cobrança só finaliza quando efetivamente recebo a transferência interbancária, correto?
renatofrota
commented
3 years ago @renatofrota,
Mas veja que em t=3 o "Banco A" ainda não recebeu a transferência do "Banco B", não teria como colocar uma cobrança como
CONCLUIDA, se ainda não recebi, como seria esse caso?
Dentro do evento em t=2, existem "sub-eventos" onde os 2 bancos se comunicam e o pagamento se concretiza. Se todo o processo acontecer, o Banco A já terá o dinheiro. Se o recebedor pedir ao Banco A a remoção da cobrança antes da última mensagem do Banco A ao Banco B informando "OK, transferência acatada, já creditamos a conta do recebedor, pode debitar a conta do pagador aí do seu lado e emitir o comprovante para ele", a remoção da cobrança é que será o t=2 (e o t=3 será a recusa do pagamento pelo Banco B devido à cobrança ter sido removida).
renatofrota
commented
3 years ago O t=4 do seu gráfico, na verdade, é um evento que acontece em consequência do evento de pagamento em t=2 (e faz parte do processo de pagamento). Se ele acontece antes ou após a tentativa de remoção da cobrança em t=3, é indiferente. O evento de remoção da cobrança é que depende da transação já ter sido acatada ou não. Se já foi acatado o pagamento e o pagador tem um comprovante, a tentativa de remoção da cobrança no t=3 será recusada [e o t=4 vai acontecer de qualquer forma].
mvallim
commented
3 years ago Dentro do evento em t=2, existem "sub-eventos" onde os 2 bancos se comunicam e o pagamento se concretiza.
A questão está nesse ponto se isso demora, e isso eventualmente pode e irá acontecer, como ficaria essa situação?
renatofrota
commented
3 years ago Dentro do evento em t=2, existem "sub-eventos" onde os 2 bancos se comunicam e o pagamento se concretiza.
A questão está nesse ponto se isso demora, e isso eventualmente pode e irá acontecer, como ficaria essa situação?
O processo todo de t=2 deve ser concluído para poder gerar o evento t=4 (transferência efetiva dos recursos entre os bancos).
Se não acontecer o processo todo de pagamento em t=2 (ex: o cliente ainda está na tela de digitação da senha pra confirmar a transação e o recebedor remove a cobrança - ainda que milisegundos antes) a remoção é que será o t=2, e a tentativa de pagamento será o t=3 (que vai falhar, com recusa do Banco A, informando que a cobrança foi removida, e o Banco B informa o pagador a impossibilidade de pagamento).
mvallim
commented
3 years ago O processo todo de t=2 deve ser concluído para poder gerar o evento t=4 (transferência efetiva dos recursos entre os bancos).
Se não acontecer o processo todo de pagamento em t=2 (ex: o cliente ainda está na tela de digitação da senha pra confirmar a transação e o recebedor remove a cobrança - ainda que milisegundos antes) a remoção é que será o t=2, e a tentativa de pagamento será o t=3 (que vai falhar, com recusa do Banco A, informando que a cobrança foi removida, e o Banco B informa o pagador a impossibilidade de pagamento).
@renatofrota,
Então sempre devo assumir isso como uma verdade, tornando a transação como um todo atômica?
+--------> transfere (atomic) >-------+
| |
Banco A Banco B Banco A negado
^ ^ ^ ^
| | | |
t = 0 [1]-------------------------[2]-----------------------------------[3]---------------------[4]
Recebedor emite cobrança Pagador Paga Cobranca paga Recebedor remove a cobrançaOu
+--------> transfere (atomic) >-------+
| |
Banco A Banco B Banco A Banco A
^ ^ ^ ^
| | | |
t = 0 [1]-------------------------[2]----------------[3]----------------[4]
Recebedor emite cobrança Pagador Paga Recebedor remove Pagamento negadoA sua preocupação é do ponto de vista do EC (Estabelecimento Comercial que faz o consumo da API Pix como cliente - e que enviaria a solicitação da remoção da cobrança)? Se o seu PSP respondeu afirmativamente à sua solicitação de remoção, é porque ele não recebeu nenhum pagamento ainda e quaisquer tentativas de pagamento para aquela cobrança (ainda que venha 1ms depois), o seu PSP deverá rejeitar. Então, sim, há uma atomicidade entre a efetivação do Pix e a efetiva transferência dos recursos entre os PSPs (e o crédito na conta do EC).
Pelo menos é o que eu entendo interpretando a documentação. Não encontro viabilidade ou previsibilidade de qualquer comportamento diferente para esse processo em particular. Não sei se o @ninrod tem informações a respeito do "enforcement" dessa atomicidade na homologação da API dos PSPs. Aguardemos a manifestação dele.
mvallim
commented
3 years ago A sua preocupação é do ponto de vista do EC (Estabelecimento Comercial que faz o consumo da API Pix como cliente - e que enviaria a solicitação da remoção da cobrança)? Se o seu PSP respondeu afirmativamente à sua solicitação de remoção, é porque ele não recebeu nenhum pagamento ainda e quaisquer tentativas de pagamento para aquela cobrança (ainda que venha 1ms depois), o seu PSP deverá rejeitar. Então, sim, há uma atomicidade entre a efetivação do Pix e a efetiva transferência dos recursos entre os PSPs (e o crédito na conta do EC).
@renatofrota é exatamente esse ponto.
Pelo menos é o que eu entendo interpretando a documentação. Não encontro viabilidade ou previsibilidade de qualquer comportamento diferente para esse processo em particular. Não sei se o @ninrod tem informações a respeito do "enforcement" dessa atomicidade na homologação da API dos PSPs. Aguardemos a manifestação dele.
Vamos aguardar a resposta.
Obrigado pela discussão.
renatofrota
commented
3 years ago @renatofrota é exatamente esse ponto.
Vamos aguardar a resposta.
Obrigado pela discussão.
Disponha.
"Processando" mentalmente com mais calma a comunicação que ocorre entre os PSPs durante o processo de pagamento, entendo que aquele intervalo de até 10 segundos para o envio do Pix se concretizar é basicamente uma consulta do PSP pagador ao PSP recebedor a respeito dos parâmetros de pagamentos, pra saber se serão aceitos (o PSP recebedor já consultou a cobrança pra obter informações a respeito dela antes do pagador confirmar o pagamento, digitar a senha, etc). O PSP recebedor vai, justamente ler os dados enviados pelo PSP pagador e:
CONCLUIDA.Para garantir a atomicidade entendo que o PSP poderia abrir uma transaction com o BD de cobranças imediatamente antes de enviar o OK para o PSP pagador e, se receber um OK de volta, marca CONCLUIDA e commit (do contrário, só fecha a transação, sem alterações).
Mas isso pode ser um problema devido ao paralelismo/concorrência, pois a transaction aberta não pode "travar" o BD enquanto se espera uma resposta do request enviado pro banco do pagador (que pode levar alguns segundos) - o SGBD deve ter "write ahead" ou seria quase impraticável acatar várias transações em paralelo. E aí o comportamento é meio inesperado se ocorrer a solicitação de remoção da cobrança nesse intervalo, mesmo. Agora entendo a sua preocupação!
Mas em relação ao pagamento, você está ressalvado: se o PSP do pagador debitou a conta dele, o PSP recebedor terá o dinheiro (assim como você, EC recebedor).
É um intervalo de poucos milisegundos esse "gap" pra uma solicitação de remoção da cobrança por parte do EC recebedor ser acatada enquanto o processo de recebimento ainda está rodando (no lado do PSP recebedor). E, na prática, talvez os PSPs recebedores respondam o OK e, somente depois do request respondido pelo PSP pagador, alterem no BD o status da transação para CONCLUIDA. Aí esse gap seria até um pouco maior (apesar de ainda na casa dos milisegundos).
Entendo que o processo seria mais ou menos assim:
CONCLUIDA);CONCLUIDA); e, na sequênciaCONCLUIDA (pelo processo de recebimento do Pix que estava em execução em paralelo).Em última instância, se o seu sistema for notificado do pagamento recebido para uma cobrança que você acabou de solicitar a remoção - por mais que tenha recebido uma confirmação da remoção - seu sistema pode estar preparado para considerar o pagamento como recebido (como se não tivesse solicitado a remoção ainda). Você também pode fazer uma consulta por Pix recebidos para aquela cobrança logo após pedir a remoção (se não usar webhooks, principalmente).
Mas, agora, fiquei ainda mais curioso pela resposta do ninrod 😁 pois eu não sei muito sobre os detalhes técnicos da comunicação entre os PSPs durante o processo de efetivação do Pix e posso estar falando besteira.
mvallim
commented
3 years ago @renatofrota,
Por se tratar de transações bancarias em sistemas totalmente independentes com dois atores nesse meio que pode efetuar ações esses milissegundos pode invalidar uma transação financeira ou qualquer coisa do gênero, e ocorrer inconsistências eventuais.
O processo todo é regulamentado em 10s mas entre desses 10s muitas coisas podem acontecer e invalidar a operação.
Mas estou na mesma linha que você, estou curioso pela resposta do @ninrod, e posso estar falando besteira e me preocupando por algo que não faça nenhum sentindo.
renatofrota
commented
3 years ago O processo todo é regulamentado em 10s mas entro desses 10s muitas coisas podem acontecer e invalidar a operação.
O prazo ser 10s, 10m, 10h, 10d... não faz diferença. O gap (potencial) é apenas entre o momento que o PSP recebedor confirma pro PSP pagador que a transação foi "acatada" e o momento que ele efetivamente troca o status da cobrança.
Mas não há risco de "invalidar a transação". Se o PSP recebedor confirmar que os dados recebidos do PSP pagador estão nos conformes, a transação vai acontecer, invariavelmente. A questão é meramente a possível inconsistência em relação ao status da cobrança, do lado do PSP recebedor (por alguns [mili]segundos) e do seu lado (EC) até você consultar de novo e/ou ser informado que entrou um Pix para aquela cobrança.
mvallim
commented
3 years ago O prazo ser 10s, 10m, 10h, 10d... não faz diferença. O gap (potencial) é apenas entre o momento que o PSP recebedor confirma pro PSP pagador que a transação foi "acatada" e o momento que ele efetivamente troca o status da cobrança.
Sobre esse ponto OK os PSP's envolvidos acabam se resolvendo pelas N validações antes de dar o OK ou NOK.
Mas não há risco de "invalidar a transação". Se o PSP recebedor confirmar que os dados recebidos do PSP pagador estão nos conformes, a transação vai acontecer, invariavelmente. A questão é meramente a possível inconsistência em relação ao status da cobrança, do lado do PSP recebedor (por alguns [mili]segundos) e do seu lado (EC) até você consultar de novo e/ou ser informado que entrou um Pix para aquela cobrança.
Esse é o ponto, esses ms me me chamam atenção e lembrando que podem ocorrer, pois se tratarem de "atores" independentes e as coisas podem acontecer no mesmo instante, podem ser mínimas, mas quando ocorrem o que fazer... :warning:?
renatofrota
commented
3 years ago O prazo ser 10s, 10m, 10h, 10d... não faz diferença. O gap (potencial) é apenas entre o momento que o PSP recebedor confirma pro PSP pagador que a transação foi "acatada" e o momento que ele efetivamente troca o status da cobrança.
Sobre esse ponto OK os PSP's envolvidos acabam se resolvendo pelas N validações antes de dar o OK ou NOK.
Mas não há risco de "invalidar a transação". Se o PSP recebedor confirmar que os dados recebidos do PSP pagador estão nos conformes, a transação vai acontecer, invariavelmente. A questão é meramente a possível inconsistência em relação ao status da cobrança, do lado do PSP recebedor (por alguns [mili]segundos) e do seu lado (EC) até você consultar de novo e/ou ser informado que entrou um Pix para aquela cobrança.
Esse é o ponto, esses
msme me chamam atenção e lembrando que podem ocorrer, pois se tratarem de "atores" independentes e as coisas podem acontecer no mesmo instante, podem ser mínimas, mas quando ocorrem o que fazer... warning?
Se você é o EC e removeu uma cobrança (e recebeu "OK" do seu PSP) mas 1ms depois entrou um Pix para aquela cobrança, quais as implicações disso (não pode simplesmente tratar o caso como se não tivesse removido a cobrança ainda)? 🤔
E você não pode consultar a cobrança em seguida pra se certificar que o status é REMOVIDA_PELO_USUARIO_RECEBEDOR e sem Pix associado?
mvallim
commented
3 years ago Se você é o EC e removeu uma cobrança (e recebeu "OK" do seu PSP) mas 1ms depois entrou um Pix para aquela cobrança, quais as implicações disso (não pode simplesmente tratar o caso como se não tivesse removido a cobrança ainda)? 🤔
Nenhum problema, mas isso é regulamentado?
Porque eu removi REMOVIDA_PELO_USUARIO_RECEBEDOR, e recebi um PIX 1ms depois, o status passa para CONCLUIDA?
Lembrando que eu como PSP, entendo que não posso mudar uma informação que foi alterada pelo EC, a não ser que isso esteja regulamentado ou faça parte do fluxo PIX.
E você não pode consultar a cobrança em seguida pra se certificar que o status é REMOVIDA_PELO_USUARIO_RECEBEDOR e sem Pix associado?
Se o cenário acima for verdade não sei responder e como proceder...
renatofrota
commented
3 years ago Nenhum problema, mas isso é regulamentado?
Não é. Mas é uma boa prática o seu sistema estar preparado pra saber lidar com erros cometidos pelos seus interlocutores.
Porque eu removi
REMOVIDA_PELO_USUARIO_RECEBEDOR, e recebi um PIX 1ms depois, o status passa paraCONCLUIDA?
É o que deveria acontecer, num cenário problemático (resposta "OK" para a solicitação de remoção da cobrança durante o gap). Se além de responder OK para a remoção o status ainda permanecer como REMOVIDA_PELO_USUARIO_PAGADOR, seria ainda pior (mas, de qualquer forma, não sendo especificamente ATIVA e, ainda por cima, por já ter um Pix associado, o PSP não vai receber outro pagamento para a cobrança, de qualquer forma).
Lembrando que eu como PSP, entendo que não posso mudar uma informação que foi alterada pelo EC, a não ser que isso esteja regulamentado ou faça parte do fluxo PIX.
Concordo. Mas vale aqui, também, a reposta acima (boas práticas).
E você não pode consultar a cobrança em seguida pra se certificar que o status é REMOVIDA_PELO_USUARIO_RECEBEDOR e sem Pix associado?
Se o cenário acima for verdade não sei responder, como proceder.
Essa pergunta foi para o caso de você responder a pergunta anterior afirmativamente.
mvallim
commented
3 years ago Não é. Mas é uma boa prática o seu sistema estar preparado pra saber lidar com erros cometidos pelos seus interlocutores.
Sim, com relação as boas práticas, mas se não está regulamentado dentro da spec, não posso assumir isso como uma verdade.
É o que deveria acontecer, num cenário problemático (resposta "OK" para a solicitação de remoção da cobrança durante o gap). Se além de responder OK para a remoção o status ainda permanecer como REMOVIDA_PELO_USUARIO_PAGADOR, seria ainda pior (mas, de qualquer forma, não sendo especificamente ATIVA e, ainda por cima, por já ter um Pix associado, o PSP não vai receber outro pagamento para a cobrança, de qualquer forma).
E mesma resposta acima.
Se existe uma "tolerância" (aka gap) qual é o valor (ns, ms, s, m, h, d, y).
Entendo que a experiência é ruim para todos os atores envolvidos, se a regra não deixa isso claro para todos.
Mas como falei, meu entendimento pode estar errado.
ninrod
commented
3 years ago Olá @ninrod ,
Estou com uma dúvida com relação ao seguinte cenário:
Imaginando uma linha do tempo onde estão envolvidos os atores, iremos chama-los de "Banco A", "Banco B" , "Recebedor" e "Pagador".
Segue uma time-line.
Banco A Banco B Banco A Banco B transfere para Banco A ^ ^ ^ ^ | | | | t = 0 [1]-------------------------[2]-------------------------[3]-------------------------[4] Recebedor emite cobrança Pagador Paga Recebedor remove a cobrançaO cenário é que as transferências entre bancos deveriam ser imediatas, porem problemas podem ocorrer e irão ocorrer, e hipoteticamente ocorra um delay entre o pagamento do "Pagador" no seu "Banco B" transferindo o pagamento para o "Banco A" onde a cobrança foi criada pelo "Recebedor".
Com esse cenário, o "Recebedor" desiste de esperar o pagamento, pois ele gostaria que o pagamento fosse efetuado imediatamente, e cancela essa cobrança, mas o pagamento do "Pagador" ainda está "transito" e no instante 4 a transferência chega ao "Banco A" onde a cobrança foi devidamente criada no instante 1 e removida no instante 3.
Como devemos proceder nesse caso? Acata ao pagamento e despreza a remoção do "Recebedor", ou o "Banco A" recusa a transferência, dado que a cobrança foi removida pelo "Recebedor" no "Banco A"?
Essa dúvida é direcionado a experiência do "Recebedor" que tem interesse na venda e do "Pagador' na compra e dos Bancos envolvidos., além de ser um falta do meu entendimento,
Obrigado,
Boa tarde @mvallim , você acabou de chegar perto do conceito de "finality", que é o momento exato depois do qual torna-se irreversível a efetivação do Pix. Atingido o finality, o Pix será liquidado e não há nada que se possa fazer a respeito. E aí você tem que entender o fluxo de liquidação em detalhes.
Para entender porque esse problema não acontecerá no Pix, temos que explodir o passo "2", em que o banco B "paga". O que, exatamente, é esse "Banco B paga"? Funciona assim:
nota: até aqui, nada foi pago e o Banco A não sabe de nada. Então a cobrança pode ser removida com tranquilidade.
-> (basicamente é a mesma PACS enviada do banco B para o BCB).
importante: Esse é o principal passo no contexto da sua dúvida. Até aqui, nada foi "pago" ainda. Não há, portanto, "finality". Porém, note que o recebedor já tem ciência, neste momento, ao receber esta PACS.008, de que aquela cobrança pode ser paga, e provavalemente, com 99,99% de certeza, será paga. Já é um indicativo muito importante de que essa cobrança deveria ser marcada como "temporariamente travada", ou algo assim, até que venha a pacs.002 do banco central informando que o finality foi atingido (mais sobre isso adiante).
Então a decisão que vai se tomar em relação à solicitação de remoção da cobrança depende exclusivamente do momento infinitesimal em que você, o recebedor, recebe tal solicitação de remoção da cobrança. O Recebedor, neste momento aqui em que ele recebe a PACS.008 do BCB, tem que responder, em tempo bastante curto, se aceita ou não o crédito. Então "das duas uma":
a) ou o Recebedor aceita o crédito e determina, portanto, que a partir deste momento, a cobrança não pode ser removida, pois está "on hold" aguardando a chegada da PACS.002 que informa o finality (mais sobre isso adiante).
b) ou o Recebedor rejeita o crédito, e pode continuar a aceitar remoções da cobrança.
-> nos dois casos, a) ou b), o recebedor do crédito deve comunicar sua decisão via uma PACS.002 para o BCB.
Se o recebedor optar por a), então, a partir deste momento infinitesimal, a cobrança não pode ser removida pelo menos até que a pacs.002 do BCB para o recebedor chegue do banco central, porque há a chance de 0,0001% de que algum problema ocorra na liquidação. (um exemplo, para fins de entendimento, seria a entrada de um pix de 1 bilhão de reais contra o banco B, deixando o banco B sem saldo)
Por tanto, até aqui, você não tem finality, mas tem uma indicação fortíssima de que a finality deste pix se aproxima a passos galopantes.
nota: O Banco central nesse momento fará uma série de checks para poder efetivar "a troca dos saldos" entre as instituições. Tudo isso é muito rápido, mas feitos os checks, trocados os saldos, a finality é atingida ou não.
a) se a finality for atingida, o Pix está pago e isso é irreversível.
b) se algum problema ocorrer, o Pix não será liquidado.
nota: Nesse momento, o banco A tem condições de efetivamente alterar a cobrança para "CONCLUÍDA" e fazer os demais ajustes e registros necessários.
Resumindo, esse é o "negócio" envolvido no fluxo de liquidação. Entrentanto, recomendo não ficar apenas com a minha resposta e dedicar algum tempo em leitura detida do documento "Manual de Fluxos do Processo de Efetivação do Pix".
renatofrota
commented
3 years ago Eu resumiria assim:
P. Há chance de receber um pagamento milisegundos após remover uma cobrança? R. Sim. 1 chance em milhões de tentativas de se conseguir esse resultado específico (realizando a remoção da cobrança e o pagamento em tempos sincronizados).
P. Há chance de acontecer uma inconsistência no status da cobrança (ela ficar com status diferente de CONCLUIDA depois de recebido o pagamento)?
R. Sim. Também muito improvável (ou zero, se o PSP ignorar o status atual da cobrança ao fazer o update para CONCLUIDA diante da efetivação do pagamento).
P. Há chance de o dinheiro não ser recebido pelo EC, diante de um envio do pagador? R. Não.
P. Como tratar? R. Se eu recebo um pagamento para uma cobrança que internamente já tinha status de removida, posso optar em processar o recebimento (como se ainda estivesse ativa) ou simplesmente devolver esse pagamento imediatamente.
mvallim
commented
3 years ago @renatofrota
P. Há chance de receber um pagamento milisegundos após remover uma cobrança? R. Sim. 1 chance em milhões de tentativas de se conseguir esse resultado específico (realizando a remoç> ão da cobrança e o > pagamento em tempos sincronizados).
Sim existe, e se existe ela vai acontecer, que é a única premissa que podemos assumir
P. Há chance de acontecer uma inconsistência no status da cobrança (ela ficar com status diferente de CONCLUIDA depois de recebido o pagamento)? R. Sim. Também muito improvável (ou zero, se o PSP ignorar o status atual da cobrança ao fazer o update para CONCLUIDA diante da efetivação do pagamento).
Sim existe, e se existe e não está regulamentada, não podemos assumir isso como uma verdade.
P. Há chance de o dinheiro não ser recebido pelo EC, diante de um envio do pagador? R. Não.
Isso nem entramos no mérito dessa questão, pois é sabido que isso não tem chance de acontecer.
P. Como tratar? R. Se eu recebo um pagamento para uma cobrança que internamente já tinha status de removida, posso optar em processar o recebimento (como se ainda estivesse ativa) ou simplesmente devolver esse pagamento imediatamente.
Sim existe, e se existe e não está regulamentada, não podemos assumir isso como uma verdade.
@ninrod, consegue nos ajudar aqui?
Abraços,
rubenskuhl
commented
3 years ago @ninrod, consegue nos ajudar aqui?
Eu acho que ele já esclareceu, vide https://github.com/bacen/pix-api/issues/324#issuecomment-782162537 .
renatofrota
commented
3 years ago @ninrod, consegue nos ajudar aqui?
Eu acho que ele já esclareceu, vide #324 (comment) .
Eu acho que ele esmiuçou o processo "pagador realiza o pagamento a partir do PSP B" em detalhes, mas ainda não ficou claro se há ou não qualquer regulamentação a respeito da forma que o PSP A (emissor da cobrança) deve tratar, especificamente, a concorrência de processos (pagamento da cobrança acontecendo ao mesmo tempo que recebe um request de remoção da cobrança pelo EC recebedor).
Entendo que o PSP A pode travar a cobrança até a finalização do processo de pagamento (colocando em hold qualquer request de remoção/alteração da cobrança que chegar durante o processo de pagamento, por exemplo - entre as PACS.008 e PACS.002 vindas do BC - até a PACS.002 chegar ou, opcionalmente, respondendo com 503), como o próprio ninrod disse. Mas, isso é obrigatório? Ou a possível (apesar de improvável) inconsistência da cobrança não será regulamentada?
Do ponto de vista de EC, acho um problema muito pequeno pra se preocupar, pois é bem fácil tratar se porventura vier a acontecer. Para os mais preocupados (mvallim) a resposta do ninrod foi sugerir que leia o manual de fluxos. Talvez lá tenha alguma resposta mais precisa, dizendo se isso pode mesmo acontecer ou não ou alguma regulamentação/orientação para os PSPs de como tratar o caso. Ainda não tive tempo de ver.
mvallim
commented
3 years ago Eu acho que ele esmiuçou o processo "pagador realiza o pagamento a partir do PSP B" em detalhes, mas ainda não ficou claro se há ou não qualquer regulamentação a respeito da forma que o PSP A (emissor da cobrança) deve tratar, especificamente, a concorrência de processos (pagamento da cobrança acontecendo ao mesmo tempo que recebe um request de remoção da cobrança pelo EC recebedor).
Entendo que o PSP A pode travar a cobrança até a finalização do processo de pagamento (colocando em hold qualquer request de remoção/alteração da cobrança que chegar durante o processo de pagamento, por exemplo - entre as PACS.008 e PACS.002 vindas do BC - até a PACS.002 chegar ou, opcionalmente, respondendo com 503), como o próprio ninrod disse. Mas, isso é obrigatório? Ou a possível (apesar de improvável) inconsistência da cobrança não será regulamentada?
Do ponto de vista de EC, acho um problema muito pequeno pra se preocupar, pois é bem fácil tratar se porventura vier a acontecer. Para os mais preocupados (mvallim) a resposta do ninrod foi sugerir que leia o manual de fluxos. Talvez lá tenha alguma resposta mais precisa, dizendo se isso pode mesmo acontecer ou não ou alguma regulamentação/orientação para os PSPs de como tratar o caso. Ainda não tive tempo de ver.
Exatamente @renatofrota .
@ninrod e @rubenskuhl já havia lido a documentação e não encontrei evidencias claras sobre esse assunto, ou posso ter não entendido com a devida clareza, por isso levantei esse questionamento.
No entanto se o racional é o que foi relatado aqui https://github.com/bacen/pix-api/issues/324#issuecomment-782162537, entendo que sempre que um pagamento estiver em "transito" não seria possível alterar o status de uma cobrança, para evitar o cenário exemplificado aqui.
Obrigado pelos esclarecimento de todos (@renatofrota, @ninrod e @rubenskuhl)
ninrod
commented
3 years ago não qualquer regulamentação a respeito da forma que o PSP A (emissor da cobrança) deve tratar, especificamente, a concorrência de processos (pagamento da cobrança acontecendo ao mesmo tempo que recebe um request de remoção da cobrança pelo EC recebedor).
É uma liberalidade do PSP recebedor, em termos de estratégia de implementação, definir como exatamente tratar a situação.
Olá @ninrod ,
Estou com uma dúvida com relação ao seguinte cenário:
Imaginando uma linha do tempo onde estão envolvidos os atores, iremos chama-los de "Banco A", "Banco B" , "Recebedor" e "Pagador".
Segue uma time-line.
O cenário é que as transferências entre bancos deveriam ser imediatas, porem problemas podem ocorrer e irão ocorrer, e hipoteticamente ocorra um delay entre o pagamento do "Pagador" no seu "Banco B" transferindo o pagamento para o "Banco A" onde a cobrança foi criada pelo "Recebedor".
Com esse cenário, o "Recebedor" desiste de esperar o pagamento, pois ele gostaria que o pagamento fosse efetuado imediatamente, e cancela essa cobrança, mas o pagamento do "Pagador" ainda está "transito" e no instante 4 a transferência chega ao "Banco A" onde a cobrança foi devidamente criada no instante 1 e removida no instante 3.
Como devemos proceder nesse caso? Acata ao pagamento e despreza a remoção do "Recebedor", ou o "Banco A" recusa a transferência, dado que a cobrança foi removida pelo "Recebedor" no "Banco A"?
Essa dúvida é direcionado a experiência do "Recebedor" que tem interesse na venda e do "Pagador' na compra e dos Bancos envolvidos, além de ser um falta do meu entendimento,
Obrigado,