Getnet DocsGetnet Docs

Máquina de estados EMV

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

El procesamiento EMV no es una única petición con su respuesta. Es una secuencia de pasos que tu Manufacturer Service App y la Middleware App recorren juntas, en un orden fijo. Esta página describe esa secuencia desde el punto de vista de tu servicio.

Qué es la máquina de estados EMV

La Middleware App se vincula a tu implementación de IEMVInterface mediante IMainService::getEmv. Antes de cualquier transacción, llama a create con un listener que recibe todos los eventos de la secuencia siguiente. A partir de ahí, la transacción avanza por la máquina de estados un evento a la vez. Tu servicio reacciona a cada uno antes de que el motor pase al siguiente.

Dos cosas ocurren antes de que una transacción pueda empezar. Tu servicio recibe sus parámetros persistentes (AID, CAPK y la configuración relacionada), y la Middleware App instancia el listener que recibirá los eventos de la transacción. Solo entonces la Middleware App llama a start para iniciar una transacción concreta.

El ciclo de vida de la transacción

La máquina de estados recorre hasta once eventos, en orden, aunque no toda transacción llega a todos ellos.

Empieza por la detección: el motor comprueba si ya hay una tarjeta en el lector y, si no la hay, pide a tu servicio que señale que se espera una tarjeta. Lo que ocurre después depende de la tarjeta. Una tarjeta magnética o contactless equivalente a banda se lee directamente y pasa de inmediato a la finalización. Una tarjeta EMV de contacto o contactless inicia en cambio la selección de AID: el motor encuentra una o más aplicaciones candidatas y pide a la Middleware App que elija una, o que cancele la transacción.

Cuando la selección tiene éxito, el motor lee los datos de aplicación de la tarjeta. La reselección puede repetirse con menos candidatas si el primer intento no llega a completarse. El motor informa después de todos los valores que leyó de la tarjeta; si falta alguno, tu servicio puede solicitarlo directamente en lugar de terminar la transacción.

El procesamiento empieza una vez que la Middleware App confirma que quiere continuar. El motor ejecuta la autenticación de datos offline, la verificación del titular y el análisis de riesgo de terminal y tarjeta. Al terminar el procesamiento, el motor informa de si la transacción puede aprobarse offline o necesita autorización online, junto con el método de verificación del titular utilizado. En una tarjeta contactless, casi todo este trabajo termina aquí, y no hace falta más comunicación con el chip salvo que aplique la autorización online.

Si se requiere autorización online, la Middleware App informa de la respuesta del host — o de que la comunicación con el host falló — y el motor registra la decisión final.

Cerca del final, el motor puede pedir al titular que retire la tarjeta o se aleje de ella, cuando el estado de la transacción lo exige. En una tarjeta de contacto, el motor espera la retirada física antes de continuar y lo confirma cuando ocurre. Por último, la transacción alcanza su estado final. Ahí es donde tu servicio puede avisar al titular, imprimir un recibo o registrar la transacción.

Eventos excepcionales y condicionales

Algunos eventos quedan fuera de esa secuencia, porque pueden ocurrir en más de un punto o solo bajo condiciones concretas:

  • Error — el motor detecta un error de procesamiento e informa de un código numérico que identifica la causa. Aun así puede disparar después los eventos de retirada y de fin.
  • Message — una actualización de estado genérica que tu servicio puede usar para mantener informado al titular.
  • Process — señala que ha empezado una operación más larga, para que tu servicio pueda mostrar un indicador de ocupado.
  • Show PIN entry — informa del estado de la entrada de PIN, para dar retroalimentación de interfaz durante la verificación del titular.
  • Panic — un fallo crítico e irrecuperable del motor. Es el único caso en el que el evento de fin no llega, porque ya no se puede confiar en el estado del motor.

Recursos relacionados