When I first started working with EMV transactions, I used to wonder: what really happens the moment you tap or insert your card? On the surface it looks so simple, the card is near the terminal, something blinks, and then the screen shows “Processing”. But inside, a lot of things are happening between the card and the terminal.
In this post I want to share with you my personal journey in understanding two very important parts of this process: the GPO (Get Processing Options) and the AFL (Application File Locator). These are fancy names you’ll see a lot in EMV specs, but if you’re like me before, they sound abstract. Let’s break them down in plain language and with examples from my own projects.
The first moments after card insertion or tap
When the card is inserted or tapped, the terminal already has some information from the ATR (Answer to Reset) and from the Application Selection step. Basically, the terminal knows which application on the card it wants to talk to Visa, Mastercard, etc.
At this point, the terminal needs to ask the card: How should I process this transaction? What files should I read? That’s where GPO comes in.
Think of GPO as the terminal saying to the card: “Hey, I picked your application. Please tell me how to continue and what files I should look at.”
What is GPO (Get Processing Options)?
The GPO is one of the first commands the terminal sends after selecting the application. In technical terms, the terminal builds an APDU command called “Get Processing Options” and sends it to the card.
From my project experience, building this APDU is not so complicated once you get used to TLVs (Tag-Length-Value). For example, in one of our POS terminal projects, I had to debug why some cards were failing at this step. The issue was actually in the way the terminal was sending the PDOL data.
A quick example of GPO command
80 A8 00 00 0E 83 0C 9F 66 04 9F 02 06 9F 37 04 00Let me explain a bit:
- 80 A8 00 00 is the header for the GPO command.
- 0E is the length.
- 83 means this is a PDOL-related data object.
- Then you see tags like 9F66 (Terminal Transaction Qualifiers), 9F02 (Amount), 9F37 (Unpredictable Number).
When the card receives this, it replies with a response that contains something called AIP (Application Interchange Profile) and the AFL (Application File Locator).
AIP and AFL: What the card gives back
The response of GPO usually looks something like this:
77 0E 82 02 38 00 94 08 08 01 01 00 10 01 01 00Breaking this down:
- 82 02 38 00: This is the AIP. It tells what the card supports. For example, does it allow offline PIN, does it support SDA/DDA (static or dynamic data authentication), etc.
- 94 08 08 01 01 00 10 01 01 00: This is the AFL. This is where the real work starts.
Understanding AFL (Application File Locator)
The AFL basically tells the terminal: These are the files you need to read, and here’s where to find them.
When I first saw AFL, it looked like random bytes. But once you understand the format, it makes sense. Each record in AFL is 4 bytes long:
- SFI (Short File Identifier) which file to read.
- Start record.
- End record.
- Number of records included in offline data authentication.
For example:
08 01 01 00This means:
- File SFI 08
- Start record 1
- End record 1
- 0 records for offline data authentication
So the terminal will now send READ RECORD commands to fetch the data from SFI 08, record 1.
Why is this important?
If GPO and AFL don’t work properly, the transaction can’t continue. In one of my projects, we had a terminal integration where a certain bank’s cards always failed right after tap. We traced it and saw that the terminal was ignoring the AFL response and trying to read the wrong records. The card kept rejecting the commands.
Fixing this was not about changing the card, it was about correcting how our terminal parsed the AFL. Once we fixed it, everything flowed smoothly.
Real project lesson
In real life, understanding GPO and AFL helps a lot when troubleshooting. For example, if a card transaction fails early (before even asking for PIN), there’s a good chance something went wrong with GPO or reading the AFL.
I remember one test session with an acquirer where we had to show that our POS can correctly handle multiple AFL entries. Some cards give you more than one set of AFL data. If your terminal only reads the first one, you’ll miss important data like Track 2 Equivalent or cardholder name.
Sample flow
Here’s how the sequence usually looks (you can imagine this as a diagram):
- Terminal selects the application (AID).
- Terminal sends GPO command with PDOL data.
- Card responds with AIP and AFL.
- Terminal parses AFL.
- Terminal sends READ RECORD commands according to AFL.
- Card responds with the actual data (Track 2, PAN, Expiry, etc).
Example of AFL with multiple records
94 10
08 01 02 01
10 01 03 02This means:
- First entry: SFI 08, records 1 to 2, one record for offline auth.
- Second entry: SFI 10, records 1 to 3, two records for offline auth.
The terminal must loop through each entry and read the records accordingly.
Conclusion
When you tap or insert your card, a lot of invisible steps happen before the screen shows “Processing”. GPO and AFL are like the bridge between selecting the application and actually reading the card data.
For me, the biggest lesson was: never ignore the small details in the AFL. If the terminal reads the wrong file or skips one, the transaction will fail. Debugging this can save you hours during certification or field deployment.
I hope this post gave you a clearer picture of what’s happening inside the card and terminal during those first seconds of a transaction.
Sources
- EMVCo Book 3: Application Specification
- EMVCo Book 4: Cardholder, Terminal, and Acquirer Interface Requirements
- Various test logs and integration experience from my past projects
