> For the complete documentation index, see [llms.txt](https://ftcoders.first-tech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ftcoders.first-tech.com/landing-page/modulo-pan/casos-de-uso-cenarios-1-a-3.md).

# Casos de Uso: Cenários 1 a 3

### Cenário 1 - Emissão de PIN para Novo Cartão

O emissor produz um cartão novo e necessita de gerar um PIN aleatório, persisti-lo cifrado na sua base de dados e enviá-lo cifrado à gráfica de personalização para impressão num *PIN mailer* ou exibição num PIN pad seguro ao titular .

#### Sequência de Etapas

1. Solicitação do PIN: O sistema do emissor invoca o endpoint `GeneratePinIssuerKey` passando o `pan` do novo cartão, o `pinLength` desejado e o `keyIdDb` da ZPK do emissor que protegerá o PIN durante o trânsito .
2. Geração do PIN: O HoP gera um PIN aleatório no HSM, cifra-o sob a ZPK do emissor e devolve-o no campo `retMultiValue.generatedPin`. O PIN em claro nunca sai do HSM .
3. Persistência: O sistema do emissor persiste o PIN cifrado vinculado ao PAN na Base de Cartões. O `keyIdDb` utilizado é armazenado em conjunto para suportar futuras rotações de chave .
4. Envio à gráfica: O sistema envia o PIN cifrado para a gráfica/personalização através de um canal seguro (TLS + chave partilhada). A gráfica necessita de ter a ZPK correspondente disponível no seu próprio HSM .
5. Impressão segura: A gráfica decifra o PIN dentro do seu PIN pad seguro e imprime o *PIN mailer* físico (ou exibe-o num canal eletrónico controlado). O PIN nunca é manipulado em claro fora do hardware seguro .

***

### Cenário 2 - Validação de PIN em Compra com Cartão

O titular insere o cartão num POS e digita o PIN para autorizar uma compra. A transação percorre o ecossistema clássico de quatro partes (POS → adquirente → bandeira → emissor) até chegar ao HoP do emissor para validação criptográfica do PIN .

#### Sequência de Etapas

1. Inserção do cartão e PIN: O titular insere o cartão na máquina (POS) e digita o PIN. O POS cifra o PIN imediatamente sob a TPK (chave do terminal) .
2. Envio ao adquirente: O POS envia ao adquirente uma mensagem ISO 8583 com o PIN cifrado e os dados da transação .
3. Encaminhamento à bandeira: O adquirente encaminha a transação (após eventualmente traduzir o PIN para a ZPK partilhada com a bandeira) .
4. Encaminhamento ao emissor: A bandeira encaminha a transação ao emissor do cartão, incluindo o PIN cifrado pela ZPK partilhada entre a bandeira e o emissor.
5. Validação no HoP: O emissor invoca o endpoint `ValidatePinIssuerKey` passando o PIN recebido (`pin` sob `keyId`), o PIN armazenado na sua base (`pinDb` sob `keyIdDb`), e o PAN. O HoP traduz o PIN recebido para a LMK, decifra ambos dentro do HSM e compara os valores .
6. Resultado da validação: O HoP retorna `retValid = true` se o PIN for válido, ou `false` caso contrário. O emissor verifica então as restantes variáveis de negócio (saldo, limite, fraude) para decidir a autorização .
7. Resposta à cadeia: O emissor envia a resposta de autorização (aprovação ou recusa) à bandeira . A bandeira repassa a resposta ao adquirente , que a transmite de volta ao POS .
8. Notificação ao titular: O POS informa o titular sobre a aprovação ou recusa, finalizando a transação .

***

### Cenário 3 - Reset de PIN via Canal Digital

O titular esqueceu o PIN e solicita um novo através da aplicação móvel ou *internet banking*. O emissor gera um PIN novo, persiste o dado e exibe-o ao titular através de um componente seguro (PIN pad virtual na app ou canal homologado) .

#### Sequência de Etapas

1. Solicitação do reset: O cliente, após autenticação multifator, solicita o reset de PIN na aplicação. O backend valida a elegibilidade e dispara o processo .
2. Geração do novo PIN: O backend invoca o endpoint `GeneratePinIssuerKey` passando o PAN e o `keyIdDb` da ZPK do emissor .
3. Retorno do PIN cifrado: O HoP retorna o PIN gerado no campo `retMultiValue.generatedPin`, devidamente cifrado sob a ZPK do emissor .
4. Atualização da base: O backend atualiza o PIN cifrado no cadastro do cartão na Base de PINs. O PIN antigo é invalidado .
5. Tradução para o canal de exibição: O backend invoca o endpoint `PinEmbossing` (ou `TranslatePinLmkToZpk` se o PIN pad for AES) para traduzir o PIN da ZPK do emissor para a ZPK do componente seguro de exibição .
6. Retorno do PIN sob chave do PIN pad: O HoP devolve o PinBlock cifrado sob a chave de destino .
7. Envio ao componente seguro: O backend envia o PinBlock cifrado ao componente, que o decifra dentro do seu próprio enclave seguro (HSM ou *secure element* local) .
8. Exibição ao cliente: O componente exibe o PIN ao cliente em modo de leitura única (sem permissão de *screenshot* e sem persistência local). O cliente memoriza o PIN .


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ftcoders.first-tech.com/landing-page/modulo-pan/casos-de-uso-cenarios-1-a-3.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.