# Cadastro de dispositivo Pix

<https://unifokal.com/docs/modulos/pix-device>

## Cadastro de dispositivo Pix

O módulo `pix_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.

! **Somos fornecedor da tecnologia do cadastro, não participante do Pix.** O registro regulatório do dispositivo, o motor de limites e a resposta ao Banco Central continuam sendo do PSP. O que entregamos são três coisas: o fator biométrico do cadastro, o vínculo verificado entre aparelho e titular com a verificação que o aprovou como evidência, e o aviso assinado quando um aparelho é revogado.

! **Em breve.** A venda deste módulo está pausada: ele aparece na [tabela de preços](https://unifokal.com/precos) com preço e com o selo "Em breve", e o `create` de flow o recusa até a abertura. O campo de identidade do aparelho na criação de sessão também ainda não está publicado. O contrato de resposta abaixo é o que o backend já emite, para você planejar a integração.

O módulo exige `face` e `liveness` 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 **é**. 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.

```
// pix_device no check_details: o cadastro verificado do aparelho
{ "module": "pix_device", "passed": true, "outcome": "approved", "score": 92,
  "data": { "device_id": "pxd_01H…",              // id estável do aparelho, e a chave da revogação
            "status": "active",                   // active | pending_verification | verification_failed
            "platform": "ios",                    // o que você declarou na criação da sessão
            "activated_at": "2026-06-17T14:31:52.114Z",  // só quando ativou
            "limits_advisory": { "unregistered_max_per_tx_cents": 20000,
                                 "unregistered_max_daily_cents": 100000 } } }
```

O `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".

! **Aparelho compartilhado nunca reprova sozinho.** Um celular já ativo para outro titular vira `review` com a evidência, e não recusa automática: família dividindo um aparelho é comum e legítimo, e a decisão dura sobre o dispositivo é sempre do PSP. O titular, na tela, vê apenas "revisão manual", nunca "este aparelho já pertence a outra pessoa".

**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.

```
// evento pix_device.revoked no seu endpoint de webhook
{ "id": "evt_pxd_01H…_pix_device_revoked_1",
  "schema_version": 1,
  "event": "pix_device.revoked",
  "livemode": true,
  "created": "2026-06-18T09:02:44.120Z",
  "data": { "object": "pix_device",
            "device_id": "pxd_01H…",
            "verification_id": "ver_01H…",   // pode ser null: revogado antes de a verificação decidir
            "reference_id": "usr_1207",
            "status": "blocked",             // blocked (reversível) | removed (terminal)
            "reason": "stolen",              // stolen | compromised | user_request | admin
            "revoked_at": "2026-06-18T09:02:43.900Z" } }
```