Getnet DocsGetnet Docs

EMV State Machine

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

EMV processing is not a single request and response. It’s a sequence of steps that your Manufacturer Service App and the Middleware App work through together, in a fixed order. This page describes that sequence from your service’s point of view.

What is the EMV state machine

The Middleware App binds to your IEMVInterface implementation through IMainService::getEmv. Before any transaction, it calls create with a listener that receives every event in the sequence below. From that point, the transaction moves through the state machine one event at a time. Your service reacts to each one before the engine moves to the next.

Two things happen before a transaction can start. Your service receives its persistent parameters (AIDs, CAPKs, and related configuration), and the Middleware App instantiates the listener that will receive transaction events. Only then does the Middleware App call start to begin a specific transaction.

The transaction lifecycle

The state machine moves through up to eleven events, in order, though not every transaction reaches every one of them.

It starts with detection: the engine checks for a card already on the reader, and if none is present, asks your service to signal that a card is expected. What happens next depends on the card. A magnetic or contactless-magstripe-equivalent card gets read directly and moves straight to completion. A contact or contactless EMV card starts AID selection instead: the engine finds one or more candidate applications and asks the Middleware App to choose one, or to cancel the transaction.

Once selection succeeds, the engine reads the card’s application data. Reselection can happen again with fewer candidates if the first attempt doesn’t fully succeed. The engine then reports every card value it read; if a value is missing, your service can request it directly instead of ending the transaction.

Processing starts once the Middleware App confirms it wants to continue. The engine runs offline data authentication, cardholder verification, and terminal and card risk analysis. When processing finishes, the engine reports whether the transaction can be approved offline or needs online authorization, along with the cardholder verification method used. For a contactless card, most of this work finishes here, and no further communication with the chip is needed unless online authorization applies.

If online authorization is required, the Middleware App reports the host’s response — or that communication with the host failed — and the engine records the final decision.

Near the end, the engine may ask the cardholder to remove or move away from the card, when the transaction state requires it. For a contact card, the engine waits for physical removal before continuing and confirms once it happens. Finally, the transaction reaches its end state. This is where your service can notify the cardholder, print a receipt, or record the transaction.

Exceptional and conditional events

A few events fall outside that sequence, because they can happen at more than one point or only under specific conditions:

  • Error — the engine detects a processing error and reports a numeric code identifying the cause. It may still trigger the remove and end events afterward.
  • Message — a generic status update your service can use to keep the cardholder informed.
  • Process — signals that a longer operation has started, so your service can show a busy indicator.
  • Show PIN entry — reports PIN entry status, for UI feedback during cardholder verification.
  • Panic — a critical, unrecoverable engine failure. This is the only case where the end event does not follow, because the engine’s state can no longer be trusted.