EMV Application Selection: AIDs, PSE/PPSE and Candidate Lists

A single chip card can carry several applications: a debit and a credit application, a domestic and an international one, or a payment application next to a transit or identity applet. Before anything else can happen, the terminal and the card have to agree which application to use. That step is application selection. This guide explains how it works at the conceptual level: what an application identifier is, how a terminal discovers which applications a card holds, how the list of candidates is built, and who decides. For working code, APDU traces and a troubleshooting table, see the companion article Implementing and troubleshooting application selection.

Scope. This is an explanation for developers, based on openly published standards, industry guidance and research (listed at the end). It is not a normative specification. The detailed rules for payment terminals are set in specifications published by EMVCo under its own terms of use, which are not reproduced or paraphrased here.

Application identifiers (AIDs)

Each application on a card is named by an application identifier, a byte string of up to 16 bytes with two parts:

A0 00 00 03 08 | 00 00 10 00 01 00
|----- RID ----|------ PIX ------|
  5 bytes         0 to 11 bytes

The RID (registered application provider identifier) is five bytes registered to an organisation under ISO/IEC 7816-5. A0 00 00 03 08, for example, is NIST’s RID, used for the US PIV card application above.
The PIX (proprietary application identifier extension) is chosen by that organisation and distinguishes its applications, versions or products.

Because the RID is registered, two organisations cannot accidentally choose the same AID. That is why Android’s documentation, for example, recommends that developers building new reader infrastructure register their own AID rather than inventing one. Our AID list collects identifiers from published sources.

Selecting an application with an APDU

The terminal makes an application current with the SELECT command, naming it by its AID (in the command it is called the DF name):

00 A4 04 00 | 07 | A0 00 00 00 04 10 10 | 00
CLA INS P1 P2  Lc   AID (7 bytes)          Le

Three details shape everything that follows:

The answer. 90 00 means the application is now selected, and the response data usually describes it. 6A 82 means the card has no matching application. Both are normal outcomes when a terminal probes several AIDs.
Partial names. A card can accept a right-truncated AID, just its first bytes, and select the first application whose AID starts with them.
More than one match. When several applications start with the same bytes, P2 asks for the first or the next occurrence, so the terminal can step through all of them.

The APDU reference covers the command format, status words and length encoding in detail.

Two ways to discover what a card holds

1. Ask the card for its directory

A payment card can publish a directory of its applications under a well-known name. On the contactless interface the directory is called 2PAY.SYS.DDF01 (the proximity payment system environment, PPSE); on the contact interface it is 1PAY.SYS.DDF01 (the payment system environment, PSE). Selecting it by name returns a list of entries, each with an application’s AID and usually a label and a priority indicator. US industry guidance notes that a contactless payment transaction always starts with the PPSE, while on the contact interface the PSE is optional for both card and terminal.

2. Try every application the terminal supports

Without a directory, the terminal uses explicit selection: it sends one SELECT for each AID in its own list and notes which ones succeed. A terminal that supports ten AIDs sends ten SELECT commands. A card without a contact directory answers the directory SELECT with “file not found”, and the terminal falls back to this method. Industry guidance strongly recommends allowing partial AID matching here, because it is the only way to find several occurrences of an application whose AIDs share a prefix.

The candidate list

Whichever method was used, the result is a candidate list: the applications that both the card and the terminal support, each with whatever priority information the card provided. Building it is a simple intersection, but three decisions make it non-trivial:

Decision	Options	Why it matters
How the terminal’s AIDs are matched	Exact match, or prefix (partial) match	Prefix matching finds variants of an application with longer AIDs; exact matching does not
Which interface	Contact or contactless	Directory names, and whether a directory must exist, differ by interface
Who chooses	Automatically by priority, or the cardholder from the displayed labels	The rules for when the cardholder must be asked come from the payment schemes

Once an application is chosen, the terminal selects it again by its full AID and continues the transaction with that application’s own commands.

Data objects you meet during selection

Several BER-TLV data objects appear in directory entries and SELECT responses. The names below are those used in publicly available payment processor and network documentation; see our tag reference for sources.

Tag	Name	Where you see it
`4F`	Application Identifier (AID), card	Inside each directory entry; the AID of an application on the card
`84`	Dedicated File (DF) Name	In the response to SELECT; the name of what was selected (the AID, or the directory name)
`50`	Application Label	Directory entries; a short name a terminal can display
`87`	Application Priority Indicator	Directory entries; the card’s preference information
`9F12`	Application Preferred Name	Card data; an alternative display name
`9F06`	Application Identifier (AID), terminal	Terminal data: the AID as held in the terminal’s configuration
`61`	Directory Entry (application template)	One per application in a directory response

Note the two AIDs: 4F comes from the card, 9F06 from the terminal. Keep them apart when you log or compare them.

Who does what

Card	Terminal
Holds the applications and their AIDs	Holds the list of AIDs it is configured to accept
Optionally publishes a directory	Reads the directory, or falls back to explicit selection
Answers SELECT: selected, not found, or next occurrence	Builds the candidate list and applies the selection rules
Provides labels and priority information	Chooses automatically or asks the cardholder

The same mechanism on phones

When an Android phone emulates a card with host-based card emulation, the reader’s first command is typically a SELECT AID, and Android routes it to the app that registered that AID. Apps register AIDs in groups with a category, payment or other, and only one payment-category group is active at a time. When two apps register the same AID, Android’s documented order is the default wallet app, then the single app that registered it, then the user’s choice. Android does not support partial-AID matching from the reader side, so a reader talking to a phone should select full AIDs.

The flow in pseudocode

The outline below is pseudocode, not runnable code. A tested JavaScript implementation, with a card simulator and an APDU trace, is in the companion implementation guide.

function selectApplication(card, terminalAids, interface):
    directory = (interface == CONTACTLESS) ? "2PAY.SYS.DDF01" : "1PAY.SYS.DDF01"
    response = card.select(name = directory)
    if response.status == 90 00:
        entries = all directory entries (tag 61) in response.data
        candidates = entries whose AID (tag 4F) matches an AID in terminalAids
    else:
        candidates = []
        for aid in terminalAids:
            response = card.select(aid, occurrence = FIRST)
            while response.status == 90 00:
                add the selected application (tag 84) to candidates, once
                response = card.select(aid, occurrence = NEXT)
    if candidates is empty: application selection failed
    chosen = choose by the scheme rules (priority, or ask the cardholder)
    card.select(chosen.aid)        // select the final application by its full AID

When selection goes wrong

No application found. Every SELECT returns 6A 82: check the AID bytes, the interface, and whether the card is the kind of card you expect.
Only one of two applications appears. The terminal matches exact AIDs, but the second application’s AID is longer and shares a prefix. Enable partial matching with next-occurrence selection.
The same application appears twice. Results from the directory and from explicit selection were merged without de-duplication.
The reader answers 61 XX or 6C XX. These are transport-level signals that your code or library must follow, not selection errors.

The implementation guide has the full troubleshooting table.

Frequently asked questions

What is the difference between an AID and a RID?

The RID is the first five bytes of an AID and identifies the registered organisation. The full AID adds the PIX, which identifies one application of that organisation.

What is 1PAY.SYS.DDF01?

The name of the payment system environment, the directory a contact payment card can publish to list its applications. Its contactless counterpart is 2PAY.SYS.DDF01.

Why does a terminal select the same application twice?

Discovery leaves the directory, or whichever application was probed last, as the current selection. After choosing, the terminal therefore SELECTs the chosen application by its full AID before it sends that application’s commands.

What does the AID on a card receipt mean?

Receipts often print the AID of the application that was used. Look it up in our AID list to see which scheme or application it belongs to.

Sources

ETSI TS 101 220 V19.0.0, ETSI numbering system for telecommunication application providers, §4 (AID = RID of 5 bytes + PIX of up to 11 bytes; RID registration): etsi.org
ETSI TS 102 221 V18.4.0, §11.1.1 SELECT (selection by DF name/AID, first/next occurrence, right-truncated AID): etsi.org
NIST SP 800-73pt1-5 and pt2-5 (2024) – PIV AID with the NIST RID, SELECT with full or right-truncated AID: Part 1, Part 2
U.S. Payments Forum, EMV Troubleshooting Guide for ATM Owners and Operators (2017), §5 (candidate list, PSE, explicit selection, partial AID matching): uspaymentsforum.org
U.S. Payments Forum, U.S. Debit EMV Technical Solution v1.4 (2018), §6.1 (automatic or consumer selection) and §8.2 (contactless transactions start with the PPSE): uspaymentsforum.org
M. Roland, J. Langer, Cloning Credit Cards: A combined pre-play and downgrade attack on EMV Contactless, USENIX WOOT 2013 (PPSE response listing AIDs): usenix.org; S. J. Murdoch et al., Chip and PIN is Broken, IEEE S&P 2010 (contact trace with 1PAY.SYS.DDF01): cl.cam.ac.uk
Android Developers, Host-based card emulation overview (SELECT AID routing, AID groups and categories, conflict resolution, no partial matching, AID registration advice): developer.android.com
Tag names: public processor documentation, e.g. Global Payments (Heartland) Portico EMV Request Tags: heartlandportico.com; Elavon EMV API fields: developer.elavon.com (full per-tag sources in our tag reference)

Written by the Ambimat engineering team.

Application Selection on Chip Cards: How Terminals Choose an Application