Cashless Nomad

Cashless Future: Building Reliable Payment Systems.

,

How Terminals Select the Right Application on an EMV Card

ASSI Avatar
ASSI

When I was building an EMV payment terminal for one of our retail clients a few years ago, one of the things I had to understand deeply was how the terminal figure out what application to use when a card is tapped or inserted. Sounds simple, right? Just pick one and go? Not quite.

If you’ve been puzzled by how a terminal chooses between VISA, Mastercard or a loca debit app on the same card, this is for you.

Let me walk you through what I’ve learned (the hard way) from dealing with real cards, actual POS hardware, and production-level issues you don’t always read about EMV specs.

What Even Is Application Selection?

When a chip card (also called an ICC or Integrated Circuit Card) is inserted, it often contains multiple applications. Each one represents a way of processing payments. For example, one card might have:

  • VISA Credit (AID: A0000000031010)
  • VISA Debit (AID: A0000000032010)
  • A local domestic scheme like Bancnet (AID: A0000002771010)

The terminal must choose one. That’s called “Application Selection”

Getting this wrong leads to failed transactions, cardholder confusion, or in some cases, regulatory issues. So let’s get into how it works.

Step 1: Terminal Declares Supported AIDs

The first thing the terminal does is tell the card what application identifiers (AIDs) it supports.

In the terminal’s EMV configuration, you typically configure a list of AIDs like:

Plaintext
A0000000031010 ; VISA Credit
A0000000041010 ; Mastercard Credit
A0000002771010 ; BancNet Debit

These AIDs are stored in the terminal’s EMV kernel config – either on the file system or injected during parameter download.

Tips from my experience: If the terminal doesn’t have the right configured, even if the card supports it, it won’t be able to select that application. I learned this the hard way when our clients kept complaining that their BancNet cards didn’t work. Turned out we forgot to inject the local AID.

Step 2: Matching Terminal AIDs and Card AIDs

Now the terminal will compare its list with the card’s list.

If there’s a match (based on prefix, full match, or partial match depending on the configuration), the application becomes a candidate for selection.

There are two common modes of matching:

  • Exact match: Terminal AID must match card AID exactly
  • Partial match: Terminal AID can be a prefix of the card AID.

Why this matters? I once had a case where the terminal was configured for partial matching, and it ended up selecting the wrong debit app because the prefix matched multiple AIDs on the card. From then on, we always enforced exact match in production environments, unless a client had specific multi-scheme fallback needs.

Step 4: Prioritizing Among Candidates

Once we have the list of candidate apps, the terminal needs to decide which one to select. There are three ways this happens:

  1. Card Priority. The card includes a priority value each AID. Lower values mean higher priority (0 is the highest). The terminal can use this to automatically pick.
  2. Terminal Priority Rules. Some merchants may prefer Mastercard over VISA or domestic schemes over international. The terminal may have a merchant-specific config to override card priority.
  3. Cardholder Selection. If both card and terminal allow, the user can be shown a menu to choose their preferred app.

Personal Story: We had a merchant in the Philippines who wanted to always push BancNet if it was available, since it’s cheaper for them than processing via VISA or Mastercard. We had to configure the terminal’s EMV kernel to prefer local schemes. This is often done via something called the “Application Preferred Name” and settings terminal logic accordingly.

Step 5: SELECTing the Application (APDU Time!)

Once the final AID is choose, the terminal sends a SELECT command using APDU (Application Protocol Data Unit) format.

Example:

Plaintext
00 A4 04 00 07 A0000000031010 00

This means:

  • CLA: 00
  • INS: A4 (SELECT)
  • P1: 04 (Select by Name)
  • P2L 00
  • Lc: 07 (Length of AID)
  • Data: A0000000031010 (VISA)
  • Le: 00 (Expected length of response)

If the card responds successfully (6Fxx or 9000 status), the application is selected. If not, the terminal will try the next candidate.

Real-life headache:

Sometimes, SELECT command fail because the card expects exact length or specific Le values. Debugging this in a live POS terminal is a pain, especially when logs are limited or encrypted.

Common Issues You Might Encounter

Let me share a few mistakes I’ve seen (or made) that caused issues in real-world terminals:

  • Wrong AID Format: AID configured without terminal-specific preferences like length or prefix rules.
  • Missing AIDs: Forgot to include local AIDs during config
  • Cardholder Menu not shown: Some terminals skip this by default unless explicitly allowed.
  • Mismatch in matching rules: Terminal using partial match when card expected exact match.
  • Priority conflicts: Terminal prefers VISA, but card has BancNet as top priority and the transaction fails.

Sources You Can Reference

To help you go deeper (and give proper credit), here are a few official and public resources:

Wrapping Up: Why This Matters

Application selection is one of those parts of EMV you don’t think about until it breaks. When it works, no one notices. But when it fails, you’ll hear about it from the merchant, from support, from users.

For me, understanding how the terminal and card “talk” to each other, and how priorities are resolved, changed how I build and test EMV terminals. It’s not just about the specs, it’s about making the right choice for the merchant, for the user, and for the network rules you’re operating under.

If you’re working on EMV terminals, I suggest taking the time to test with real cards, log your APDU traffic, and double check your AID priorities.

It’s one of those “small things” that can make or break a deployment.

More Articles & Posts