Máquina de estados EMV
O processamento EMV não é uma única requisição com sua resposta. É uma sequência de passos que sua Manufacturer Service App e a Middleware App percorrem juntas, em ordem fixa. Esta página descreve essa sequência do ponto de vista do seu serviço.
O que é a máquina de estados EMV
A Middleware App se vincula à sua implementação de IEMVInterface por IMainService::getEmv. Antes de qualquer transação, ela chama create com um listener que recebe todos os eventos da sequência abaixo. A partir daí, a transação avança pela máquina de estados um evento por vez. Seu serviço reage a cada um antes de o motor passar ao seguinte.
Duas coisas acontecem antes de uma transação poder começar. Seu serviço recebe seus parâmetros persistentes (AIDs, CAPKs e a configuração relacionada), e a Middleware App instancia o listener que receberá os eventos da transação. Só então a Middleware App chama start para iniciar uma transação específica.
O ciclo de vida da transação
A máquina de estados percorre até onze eventos, em ordem, embora nem toda transação chegue a todos eles.
Começa pela detecção: o motor verifica se já há um cartão no leitor e, se não houver, pede ao seu serviço que sinalize que um cartão é esperado. O que vem depois depende do cartão. Um cartão magnético ou contactless equivalente a tarja é lido diretamente e passa direto para a conclusão. Um cartão EMV de contato ou contactless inicia a seleção de AID: o motor encontra uma ou mais aplicações candidatas e pede à Middleware App que escolha uma, ou que cancele a transação.
Quando a seleção tem sucesso, o motor lê os dados de aplicação do cartão. A reseleção pode ocorrer de novo com menos candidatas se a primeira tentativa não se completar. O motor então reporta todos os valores que leu do cartão; se algum estiver faltando, seu serviço pode solicitá-lo diretamente em vez de encerrar a transação.
O processamento começa assim que a Middleware App confirma que quer continuar. O motor executa a autenticação de dados offline, a verificação do portador e a análise de risco de terminal e de cartão. Ao terminar o processamento, o motor informa se a transação pode ser aprovada offline ou precisa de autorização online, junto do método de verificação do portador utilizado. Em um cartão contactless, quase todo esse trabalho termina aqui, e não é preciso mais comunicação com o chip a menos que a autorização online se aplique.
Se a autorização online for necessária, a Middleware App reporta a resposta do host — ou que a comunicação com o host falhou — e o motor registra a decisão final.
Perto do fim, o motor pode pedir ao portador que retire o cartão ou se afaste dele, quando o estado da transação exige. Em um cartão de contato, o motor aguarda a retirada física antes de continuar e confirma quando ela ocorre. Por fim, a transação chega ao seu estado final. É aí que seu serviço pode avisar o portador, imprimir um recibo ou registrar a transação.
Eventos excepcionais e condicionais
Alguns eventos ficam fora dessa sequência, porque podem ocorrer em mais de um ponto ou apenas sob condições específicas:
- Error — o motor detecta um erro de processamento e reporta um código numérico que identifica a causa. Ainda assim pode disparar depois os eventos de retirada e de fim.
- Message — uma atualização de status genérica que seu serviço pode usar para manter o portador informado.
- Process — sinaliza que uma operação mais longa começou, para que seu serviço possa exibir um indicador de ocupado.
- Show PIN entry — reporta o status da entrada de PIN, para retorno visual durante a verificação do portador.
- Panic — uma falha crítica e irrecuperável do motor. É o único caso em que o evento de fim não vem depois, porque o estado do motor não é mais confiável.
Recursos relacionados
- Arquitetura HAL — como a interface EMV se encaixa no resto da plataforma.
- Referência de interfaces de serviço — as assinaturas completas dos métodos de
IEMVInterface. - Implementar os serviços de hardware — as chamadas de leitura de cartão que precedem o processamento EMV.