Cadastro de dispositivo Pix
O módulopix_device transforma o cadastro de dispositivo de acesso que o Regulamento do Pix (art. 89, §6º a §9º, incluídos pela Resolução BCB nº 403/2024) obriga o PSP a manter num cadastro verificado por biometria. No ato de cadastrar um aparelho novo, o titular passa pelo face match e pela prova de vida do mesmo fluxo, que são o segundo fator que a Instrução Normativa BCB nº 491/2024 aceita, e o aparelho só é vinculado ao titular quando a verificação inteira aprova.
O módulo exige liveness e um 1:1 do rosto contra uma referência do titular no mesmo flow, e a exigência vem da norma, não de preferência nossa: sem eles, o vínculo seria com quem digitou, e não com quem é. O 1:1 tem duas formas. A preferida é face_reauth, que compara a selfie com a matrícula daquela conta, sem pedir documento; ela pede que o titular tenha passado uma vez pelo onboarding com matrícula, e em produção a sessão sem matrícula é recusada com enrollment_not_found (o sandbox não confere matrícula). A outra é face, que compara com o documento apresentado no mesmo flow (cpf_ocr ou doc_global); nessa forma, confira o CPF lido do documento contra o do seu correntista, porque quem está na câmera pode apresentar o próprio documento. A identidade do aparelho chega pelo seu servidor, com a chave secreta, nunca pelo navegador do titular: quem está do outro lado da câmera é o adversário do produto e não pode escolher o próprio identificador de dispositivo.
limits_advisory carrega os limites da IN BCB nº 491/2024, art. 9º, para dispositivo não cadastrado (duzentos reais por transação e mil reais por dia), em centavos. Ele é informativo por contrato: quem aplica limite é o seu motor, nunca o nosso. O campo existe para o seu motor carregar os números certos sem alguém ter que reescrevê-los à mão a cada mudança de norma.
No resumo checks o módulo sai como "pix_device": "active" (o vínculo nasceu), "review" (há uma pergunta esperando gente) ou "pending" (ainda sem desfecho do aparelho). Nunca leia pending como “cadastrado”.
O que nunca sai no payload: a impressão digital do aparelho (você já tem o valor que enviou, e devolver o nosso derivado dele só serviria para alguém testar palpites contra ele) e o apelido do aparelho, que é dado do usuário final, guardado cifrado em repouso e nunca devolvido em resposta de API.
Revogação. Quando um aparelho é revogado, no bloqueio reversível ou na exclusão definitiva da IN BCB nº 491/2024 (art. 7º, com o recadastro obrigatório da IN BCB nº 594/2025), o seu backend recebe no mesmo endpoint de webhook de sempre, com a mesma assinatura, um evento pix_device.revoked. É por ele que o seu motor de limites fica sabendo que um aparelho roubado saiu do cadastro. A exclusão é terminal: recadastrar exige uma sessão de verificação nova. Quem revoga é o painel, em Dispositivos PIX: é lá que se bloqueia, desbloqueia ou exclui um aparelho, e o evento acima sai desse ato.