Exigência da informação do "id" de devoluções

[jgslima]

Os ambientes dos PSPs podem possuir canais variados, de forma que, um cliente recebedor acabará tendo à sua disposição algum outro canal para comandar uma devolução além da API PIX (app, internet banking, etc). Ocorre que, devoluções comandadas por canais convencionais não terão a informação do "id".

Alguns serviços de consultas da API PIX especificam que, se o PIX relativo a uma cobrança tiver tido devoluções, os dados destas devoluções devem ser retornados. E dentre eles, o campo "id" que é declarado como required.

Se o cliente recebedor tiver, por alguma razão qualquer, comandado uma devolução por um canal convencional, o PSP terá ciência de que a devolução relativa àquele PIX ocorreu, mas não terá como reportar a informação do "id" (também questionável se a informação do "status" é pertinente neste caso).

Como o PSP deve proceder?

[rubenskuhl]

Me parece que o campo "id" deveria ser opcional no GET /pix e no webhook, porém apenas caso ele não exista. Ou seja, se existir ele deve ser informado. Já no PUT de devolução continuaria obrigatório e idempotente (vide #277).

[ninrod]

bom dia @jgslima

Se o cliente recebedor tiver, por alguma razão qualquer, comandado uma devolução por um canal convencional, o PSP terá ciência de que a devolução relativa àquele PIX ocorreu, mas não terá como reportar a informação do "id" (também questionável se a informação do "status" é pertinente neste caso).

Ressalto que esse id da devolução é único por e2eid. Além disso, apresenta tamanho máximo de 35 caracteres no pattern [A-Za-z0-9]{1,35}.

Como o PSP deve proceder?

O PSP escolhe um id para representar esse id que não foi escolhido pelo usuário recebedor. Sem pensar muito eu usaria um UUIDv4 (32 chars hexa).