Open rubenskuhl opened 3 years ago
@rubenskuhl , pode expandir a explicação do que seria "um pix sinalizado via API por ter txid"?
@rubenskuhl , pode expandir a explicação do que seria "um pix sinalizado via API por ter txid"?
Pode ser um Pix de pagamento por um QR-Code estático com txid ou um Pix de pagamento de um QR-Code dinâmico.
Então a pergunta não se aplica a Pix recebido por dados bancários nem a Pix recebido por chave apenas.
Funciona mais como uma devolução normal, mas há duas diferenças:
1) É o próprio PSP que cria uma devolução e "inventa" o id da devolução, e não o usuário recebedor.
2) O evento de "congelamento" de recurso não está mapeado na API. Mas o status "final", sim: toda devolução é avisada via webhook e aparece no array de devoluções de um pix.
Funciona mais como uma devolução normal, mas há duas diferenças:
- É o próprio PSP que cria uma devolução e "inventa" o id da devolução, e não o usuário recebedor.
- O evento de "congelamento" de recurso não está mapeado na API. Mas o status "final", sim: toda devolução é avisada via webhook e aparece no array de devoluções de um pix.
Obrigado. E como a infra do EC diferencia essa devolução por mecanismo especial de uma devolução iniciada pelo mobile, por exemplo ?
Outro ponto de interação com a API: se o evento de congelamento de recurso não está mapeado, isso significa que o Pix que está sob análise no mecanismo especial pode ter devoluções do EC, correto ? E aí no final da análise a devolução está limitada pelo valor inicial e devoluções prévias, confere ?
Obrigado. E como a infra do EC diferencia essa devolução por mecanismo especial de uma devolução iniciada pelo mobile, por exemplo ?
@rubenskuhl , o EC não consegue distinguir entre devolução por "mecanismo especial" ou devolução "mobile".
Obrigado. E como a infra do EC diferencia essa devolução por mecanismo especial de uma devolução iniciada pelo mobile, por exemplo ?
@rubenskuhl , o EC não consegue distinguir entre devolução por "mecanismo especial" ou devolução "mobile".
Isso é ruim, pois as ações a tomar nesses casos são muito diferentes.
Outro ponto de interação com a API: se o evento de congelamento de recurso não está mapeado, isso significa que o Pix que está sob análise no mecanismo especial pode ter devoluções do EC, correto ? E aí no final da análise a devolução está limitada pelo valor inicial e devoluções prévias, confere ?
Sim, no final da análise, o valor da devolução deve respeitar o valor original considerando eventuais devoluções prévias.
@rubenskuhl ,
Isso é ruim, pois as ações a tomar nesses casos são muito diferentes.
pode oferecer alguns exemplos?
@rubenskuhl ,
Isso é ruim, pois as ações a tomar nesses casos são muito diferentes.
pode oferecer alguns exemplos?
No caso de mecanismo especial de devolução, o serviço contratado deve ser descontinuado, já que o pagamento foi repudiado. No caso de devolução pelo mobile, o cliente pode ser totalmente inocente e um funcionário do EC com acesso à conta quer por malícia quer por erro fez a devolução, e o cliente não deve ser prejudicado.
@rubenskuhl
No caso de mecanismo especial de devolução, o serviço contratado deve ser descontinuado, já que o pagamento foi repudiado. No caso de devolução pelo mobile, o cliente pode ser totalmente inocente e um funcionário do EC com acesso à conta quer por malícia quer por erro fez a devolução, e o cliente não deve ser prejudicado.
Ok @rubenskuhl , levarei para o decem.
E o não saber quando do congelamento do Pix para análise é ruim também. Em cartões, se recebe notificação de repúdio antes da notificação de chargeback, exatamente para alertar de que há um questionamento a ser analisado.
Digamos que 3 hipóteses se apliquem:
Como fica a sinalização via API, tanto de webhook quanto de GET em /pix, disso ? Lembrando que há casos finais (os de falha sistêmica) e casos de análise (fraude) onde há primeiro um congelamento do recurso e depois uma liberação ou definição.