> 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-emv/fundamentos-e-fluxo-transacional.md). # Fundamentos e Fluxo Transacional ### O que é EMV? EMV é o padrão internacional para transações com cartões chip, originalmente estabelecido por Europay, Mastercard e Visa, e atualmente mantido pelo consórcio EMVCo. O padrão especifica as regras de autenticação entre o cartão e o terminal por meio de criptogramas. ### A Necessidade do HSM O pilar da segurança EMV baseia-se nas Chaves Mestras do Emissor (*Issuer Master Keys*, ou MK), que são armazenadas em hardware criptográfico seguro. Através destas chaves mestras, o emissor deriva chaves únicas por cartão e por transação. Como as chaves mestras jamais devem ser expostas em texto claro, toda operação de validação ou geração de criptograma precisa ser executada rigorosamente dentro do ambiente criptográfico. O módulo Hop V4 expõe essas operações via API REST, garantindo a manutenção da cadeia PCI HSM de ponta a ponta. ### Os Criptogramas do Fluxo EMV Em um fluxo típico de autorização, quatro tipos principais de criptogramas podem interagir: | Sigla | Nome | Significado / Papel no Fluxo | | -------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ARQC** | *Authorization Request Cryptogram* | Gerado pelo cartão. Transportado no campo 55 da ISO 8583 (tag 9F26). Indica que o cartão está solicitando autorização online ao emissor. | | **ARPC** | Authorization Response Cryptogram | Gerado pelo emissor como resposta ao ARQC. Confirma ao cartão que a resposta do emissor é legítima. É justamente o que o endpoint `GenerateARPC4x` produz. | | **TC** | Transaction Certificate | Gerado pelo cartão ao final de uma transação offline aprovada. Garante a integridade da transação para posterior captura. | | **AAC** | *Application Authentication Cryptogram* | Gerado pelo cartão quando a transação é negada (offline ou online). Encerra o fluxo EMV. | ## ARQC e ARPC no Fluxo Transacional Para integrar a API, é necessário compreender onde os endpoints se encaixam em uma autorização típica de crédito ou débito. ### Atores e Sequência de Mensagens * **Cartão (chip):** Gera o ARQC a partir dos dados da transação e da chave derivada da MK do emissor. * **Terminal (POS / maquininha):** Monta o campo 55 com as tags EMV e encaminha a autorização para o adquirente. * **Adquirente e Bandeira:** O adquirente encaminha a autorização para a bandeira, que roteia para o emissor. * **Emissor (backend):** Recebe a autorização, valida o ARQC via Hop, toma a decisão de autorização e gera o ARPC via Hop para retornar ao cartão. * **Hop V4 (Módulo EMV):** Atua como HSM-as-a-service que executa a validação e geração de criptogramas com as chaves mestras do emissor. ### Sequência do Fluxo de Autorização Online O fluxo abaixo apresenta, de forma linear, as trocas entre os atores: 1. O Cartão chip gera o ARQC (tag 9F26) e os dados EMV (campo 55) e envia ao Terminal. 2. O Terminal encaminha a mensagem ISO 8583 com o campo 55 passando pelo Adquirente e pela Bandeira até chegar ao backend do Emissor. 3. O Emissor aciona a Hop V4 (`POST /v4/PayShieldEMV/ValidateARQC4x`) para que o ARQC seja validado contra a chave mestra do cartão . 4. Com a resposta, o Emissor toma a decisão de autorização (aprovar ou negar). 5. O Emissor aciona novamente a Hop V4 (`POST /v4/PayShieldEMV/GenerateARPC4x`) para gerar o ARPC com base no ARC ou CSU. 6. O Emissor devolve a resposta ISO 8583 com o ARPC transportado no campo 55 (tag 91), que trafega pela Bandeira e Adquirente até o Terminal . 7. O Terminal repassa o ARPC e o status ao Cartão, que valida o ARPC e encerra a transação. {% hint style="info" %} **Otimização:** Validar e Gerar em uma Única Chamada É possível combinar as etapas 3 e 5 em uma única chamada ao Hop, utilizando modos de operação que validam o ARQC e já geram o ARPC no mesmo request. Em cenários de alto volume (ex.: autorização de débito em tempo real), combinar validação e geração na mesma chamada (`mode=1,3,5`) tipicamente reduz em aproximadamente metade o tempo total gasto no serviço criptográfico, por evitar o *round-trip* adicional. {% endhint %} --- # 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-emv/fundamentos-e-fluxo-transacional.md?ask=&goal= ``` `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.