[UX] Uso das informações adicionais

[leosn]

Os campos chave e valor do item Informações Adicionais possuem tamanho máximo de 50 e 200 caracteres.

Pelo que entendemos o mobile é o canal principal do Pix definido pelo BC.

Fizemos um exercício de UX no pagamento Pix iniciado por QR-code dinâmicos e percebemos que, quando essa Informação Adicional possui tamanhos de maiores, a experiência do usuário dentro do canal mobile não foi satisfatória.

Vocês entendem isso como um problema?

[ninrod]

@leosn , boa tarde.

se a exp. do usuário não for satisfatoria, isso é um problema para nós sim.

Você pode detalhar melhor o exemplo, anexando possivelmente, por exemplo, screenshots do teste?

[leosn]

Prezados, as nossas telas infelizmente não posso colocar aqui e o tempo está curto. Mas imaginem um celular de 6 polegadas com a informação de 2 registros de item de informações com tamanho máximo definido para cada registro:

chave1:CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC valor1:VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

chave2:CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC valor2:VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

[ninrod]

@leosn, repassei para a equipe seu ponto de atenção. Obrigado.

[franciscotfmc]

Para endossar a preocupação do @leosn , também tivemos o mesmo problema de UX por aqui.

Um pensamento seria tratar, talvez, a exibição como lista de valores, ao invés de listar chave e valor. Digo isso pois chave é algo que remete a programação, e poderemos ter QR Codes onde as chaves são atributos que não fazem sentido para o pagador.

[ninrod]

talvez Item e descrição?

[franciscotfmc]

@ninrod na verdade eu questiono, e talvez nem caiba esse questionamento aqui, até que ponto é importante para o pagador uma lista de até 50 itens e descrições. Não entendo o porquê isso precisa ser mostrado pra ele. Me parece muito mais um campo direcionado a API's do que aos usuários finais.

Eu como pagador não iria conferir isso, ainda mais no mobile.

Provavelmente existe algum caso de uso pra isso, que eu desconheça neste momento.

[ninrod]

a intenção, com esse campo, é oferecer mais elementos para conferência por parte do usuário pagador.

Exemplo:

juros: 1% pró rata die. 
Multa: 100 reais. 
pagamento antecipado: desconto de 10% caso seja pago até 10.10.2021.

Condomínio example.com, seu condomínio online.

[rubenskuhl]

Uma informação adicional importante é o CPF/CNPJ do efetivo devedor do tributo/taxa em um documento do Tesouro Nacional, por exemplo. Talvez limitar as informações adicionais mostradas em UX a um sub-conjunto e tamanho que se encaixem em casos de uso críticos como esse ?

[ninrod]

@rubenskuhl , não sei se entendi. Temos a informação do "devedor", ela já se encontra no payload.

[rubenskuhl]

@rubenskuhl , não sei se entendi. Temos a informação do "devedor", ela já se encontra no payload.

Então eu entendi errado uma menção do GT-SEG a ter uma informação adicional nos Pix do PagTesouro para permitir um melhor match de regras anti-fraude e limites transacionais para pagamentos de impostos federais.

[ninrod]

Então eu entendi errado uma menção do GT-SEG a ter uma informação adicional nos Pix do PagTesouro para permitir um melhor match de regras anti-fraude e limites transacionais para pagamentos de impostos federais.

Deve ser uma "feature nova". Talvez o devedor e o "efetivo devedor" sejam diferentes. Deve ser uma proposta do GT-SEG que entrará para a fila de análise. Informação muito nova. Não tenho certeza.

[HMPannuti]

Um uso para o campo de Informações Adicionais seria informar o 'carrinho' de compras associado à cobrança gerada. Estes são dados de interesse do usuário pagador, onde faria sentido prever até 50 itens.