Casos de uso para o status REMOVIDA_PELO_PSP

[franciscotfmc]

Estamos na dúvida em relação aos casos de uso para que uma cobrança tenha seus status alterado para REMOVIDA_PELO_PSP. @ninrod saberia dizer a motivação desse status e em quais momentos vocês pensaram numa "intervenção" do PSP em determinada cobrança?

[ninrod]

@franciscotfmc , boa tarde.

Um exemplo de uso seria a detecção de uma cobrança fraudadada ou usuário recebedor com suspeita de fraude (caso em que PSP recebedor poderia remover todas as cobranças ativas de tal usuário, por exemplo).

Outro exemplo seria a remoção de cobranças por questão de inadimplência ou inativação do usuário.

De imediato, esses seriam os principais casos de uso.

[rubenskuhl]

Imagino que a remoção da chave, portabilidade da chave para outro PSP e desativação da conta também tivessem esse status como consequência.

[ninrod]

Imagino que a remoção da chave, portabilidade da chave para outro PSP e desativação da conta também tivessem esse status como consequência.

Parece bem adequado.

[rubenskuhl]

@ninrod, hoje as notificações tem apenas objeto pix. No caso de uma cobrança que mude para removida pelo PSP Recebedor, não seria necessário o envio de um objeto cob ?

[joelemanoel]

@rubenskuhl você indicou:

Imagino que a remoção da chave, portabilidade da chave para outro PSP e desativação da conta também tivessem esse status como consequência.

O webhook hoje funciona por chave, a remoção e portabilidade poderia acionar a url da chave que se trata, mas e da desativação de conta por exemplo qual seria a url acionada?

[rubenskuhl]

@rubenskuhl você indicou:

Imagino que a remoção da chave, portabilidade da chave para outro PSP e desativação da conta também tivessem esse status como consequência.

O webhook hoje funciona por chave, a remoção e portabilidade poderia acionar a url da chave que se trata, mas e da desativação de conta por exemplo qual seria a url acionada?

Depende de quais cobranças ativas existirem naquele momento. Se há cobranças das chaves x, y e z, o webhook da chave x seria acionado para comunicar a mudança de status das cobranças x, o da y as da y e assim por diante. Como toda cobrança tem ao menos uma chave e apenas uma chave, o máximo de acionamentos vai ser o limite de chaves, 20 no caso de CNPJ.

[ninrod]

@ninrod, hoje as notificações tem apenas objeto pix. No caso de uma cobrança que mude para removida pelo PSP Recebedor, não seria necessário o envio de um objeto cob ?

Poderia ser o caso sim, eu só não sei se enviar um objeto "cob" e apendar o /cob seria o melhor caminho porque o mercado tem reclamado do append do /pix. Mas sim, enviar outras notificações além do /pix sempre esteve no radar. Em havendo necessidade de negócio é só instar o DECEM a se posicionar porque há diversos itens a serem priorizados na agenda evolutiva.

[rubenskuhl]

@ninrod, hoje as notificações tem apenas objeto pix. No caso de uma cobrança que mude para removida pelo PSP Recebedor, não seria necessário o envio de um objeto cob ?

Poderia ser o caso sim, eu só não sei se enviar um objeto "cob" e apendar o /cob seria o melhor caminho porque o mercado tem reclamado do append do /pix. Mas sim, enviar outras notificações além do /pix sempre esteve no radar. Em havendo necessidade de negócio é só instar o DECEM a se posicionar porque há diversos itens a serem priorizados na agenda evolutiva.

Me pareceu pelo seu comentário em #241 (comment) que esse (ter um cob com schema cob no webhook) seria o caminho sim. O que poderia ser feito no momento é deixar claro que essa transição não deve ser informada no pix/ e portanto sinalizada out-of-band por outro meio (e-mail, SMS), até que seja padronizado como fazer.

[ninrod]

Me pareceu pelo seu comentário em #241 (comment) que esse (ter um cob com schema cob no webhook) seria o caminho sim.

Esse era o caminho sim, a ideia era justamente esta, antes de conhecermos as desvantagens apontadas pelos colaboradores do repo. Agora, com maior conhecimento, precisamos avaliar melhor como seriam agregadas novas notificações, sempre pensando na compatibilidade. Talvez continue desta mesma maneira, mas é muito bom debatermos a questão e pensarmos muito bem nas implicações.

deixar claro que essa transição não deve ser informada no pix/ e portanto sinalizada out-of-band por outro meio (e-mail, SMS), até que seja padronizado como fazer

Eu não vejo como o PSP poderia notificar uma cobrança via o "append do /pix" e ao mesmo tempo respeitar o schema definido. O PSP está livre para implementar "endpoints adicionais", então vejo que poderia ser um caminho.

[HMPannuti]

Alguns PSPs estão alterando o status da cobrança para REMOVIDA_PELO_PSP, quando a mesma expira, ante de ser paga.
Esse comportamento está correto?

[renatofrota]

Alguns PSPs estão alterando o status da cobrança para REMOVIDA_PELO_PSP, quando a mesma expira, ante de ser paga.
Esse comportamento está correto?

Não. Ela deve continuar ATIVA (ainda podendo ter sua validade estendida pelo EC via PATCH, por exemplo).

[ninrod]

Não. Ela deve continuar ATIVA (ainda podendo ter sua validade estendida pelo EC via PATCH, por exemplo).

@renatofrota, perfeita a resposta, não tenho nada a acrescentar.