Payment systems and security

A card transaction can finish in a few seconds. In that window the terminal opens a conversation with the card, runs a sequence of commands and responses, processes application data, performs cryptographic checks and, depending on the authorization flow, may talk to the acquirer and the issuer before deciding whether to approve or decline. What the cardholder experiences as one simple act is an interaction between several systems that do not share a trust domain.

Understanding payment security starts with one distinction. The exchange between an EMV card and a terminal is not an encrypted channel in which everything stays secret. Over contact or NFC it is structured as APDU commands and responses, defined by ISO/IEC 7816 and by the EMV specifications. Confidentiality is not the mechanism EMV relies on for integrity and authenticity. The architecture uses authentication, cryptography, secret keys, certificates, counters and cryptograms to protect particular decisions and particular data.

That distinction matters to anyone doing security research. Being able to observe an APDU trace does not by itself mean being able to modify a transaction usefully, or to exploit it. The question is not only which data can be observed. It is which component produces each field, who can change it, who can verify it, and which decision depends on it.

A transaction has no single point of control either. The cardholder presents the instrument; the merchant supplies the terminal and requests the operation; the acquirer receives and processes the merchant's transactions; the payment network provides the infrastructure and the rules for routing them; and the issuer holds the relationship with the cardholder and takes part in authorization. Each component holds different information and different capabilities, and those differences are exactly what determines where trust sits.

In an EMV transaction the card can produce cryptographic data using keys the terminal does not hold. Depending on the flow, the issuer may later verify a cryptogram the card generated, or validate other cryptographic data tied to the operation. This is why it is wrong to describe EMV as a mechanism in which the terminal verifies the card. The architecture distributes authentication and authorization across the card, the terminal and the systems in the backend.

The situation changes when the terminal has to decide without an online authorization from the issuer. There it can use the mechanisms EMV defines to work out whether the transaction may continue offline, whether because the terminal has no connectivity or because it has been forced offline. That is not the terminal issuing an authorization equivalent to the issuer's. It is the terminal applying the rules and risk mechanisms available locally to decide whether the operation can complete under those conditions.

To analyze a payment system properly, ask the same questions every time. Who generates this data? Who can modify it? Is it authenticated? Who can verify that authenticity? Which component trusts it? What happens if it is wrong, and what does that decision cost the rest of the system? Those questions carry a security investigation much further than memorizing a list of EMV tags in isolation.

A card is also a system that produces data#

The perspective gets clearer with the technologies that came before EMV. A magnetic stripe does not offer the cryptographic properties of an EMV chip. It stores information that a reader recovers through the electromagnetic interaction between the stripe and the magnetic head.

In 2015 Samy Kamkar presented MagSpoof, a device that generates a varying magnetic field a stripe reader can interpret as card data. The project is far more interesting than the device itself, because it demonstrates a principle of hardware security: if a system interprets a physical phenomenon as information, an attacker can study which properties of that phenomenon have to be reproduced for the system to accept the data it is given.

On the stripe, certain fields let the terminal learn characteristics of the application associated with the card. One of them is the service code, whose values can indicate, among other things, that chip processing is available. Be precise here: those stripe fields do not by themselves carry the cryptographic authenticity a chip-based EMV transaction provides. But they are where you can start relating what the stripe says to what the EMV chip holds.

So the problem is not that a magnetic stripe can be emulated. Emulating a signal or a set of data is not very interesting on its own. What matters is identifying which decisions the system takes from that data, and what guarantees exist about its integrity and authenticity.

The pattern repeats throughout modern payment systems. A decision depends on a field; the field arrives from another component; that component may not sit in the same trust domain; and the system finally making the decision may have no independent way to establish whether what it received is correct.

That is why this training does not stop at protocols and data formats. It works on the trust boundaries between card, terminal, firmware, physical interfaces, payment applications, acquirers, networks and issuers. At every one of them the same question applies: what does this component have to believe, what evidence does it have for believing it, and how do you test the implementation?

That question connects things usually studied apart. An observable APDU, a counter, an unexpected firmware response, a CVM decision, an offline authentication mechanism or a contactless interaction can look like separate problems. From a researcher's perspective they all yield to the same model: identify the information, determine where it came from, establish who can modify it, and check what mechanism exists, if any, to detect a modification or an inconsistency.

Four parties, and why it matters#

The PSE directory in Cardpeek

Actual sizeOpen the originalClose

Four technologies, still all in use#

The payment ecosystem today is the result of several generations of technology layering on top of each other rather than replacing each other. One card can support magnetic stripe, EMV over contact and EMV contactless, while the same credential may also be represented by a token in certain payment environments.

Each technology solves different problems and provides different security properties. The magnetic stripe uses data stored physically on the card and, by its nature, produces no new cryptographic value per transaction. EMV introduces an integrated circuit able to run logic and generate cryptographic data tied to the operation. Contactless processing uses EMV mechanisms over an NFC interface, with its own flow differences and timing constraints. Tokenization replaces a credential, or a card number, with an alternative identifier whose use may be limited to a given context.

The most important difference can be put as a question. What information does the payment instrument have to present for a new transaction to be processed?

On a magnetic stripe a significant part of that information stays constant between operations. In EMV the card takes an active part in each transaction and can produce cryptographic values bound to the data of that operation. In contactless those mechanisms run inside a wireless exchange with specific timing and communication requirements. In a tokenized environment the token moving through processing may not be the primary account number originally associated with the instrument.

The channel does not have to be secret#

The captures used in this training contain commands and responses you can inspect directly. That does not mean the system lacks security mechanisms. It means the protection of an EMV transaction does not depend on hiding the whole exchange between the card and the terminal.

APDU traces carry the information needed to run the protocol: application selection, record reads, data processing, authentication and the other operations the payment application defines. Part of that information has to stay interpretable by the terminal for the flow to run at all.

The relevant security property appears when that data later takes part in cryptographic mechanisms, or in decisions governed by specific rules. A capture can reveal the content of a communication without providing the secret keys needed to generate valid cryptographic values.

So a traffic capture has to be analyzed at two levels. First, work out what information the participants exchanged. Then work out what information can be used or altered to produce a new valid transaction.

From bytes to fraud#

Exploiting a payment vulnerability is rarely a single operation. There is a considerable distance between obtaining information from a card and getting that information to produce an economically valid transaction. One useful way to picture it: obtain, then reproduce or modify, then get accepted, then extract value.

The first step can be capturing communications or extracting data. The second can involve emulation, protocol manipulation or replaying information. The third depends on the conditions a transaction has to clear to be accepted. The last belongs to a different stage: turning an approved operation into economic gain, and getting past the controls that come after.

That precision matters when you study published attacks. Some manage to alter a processing condition; others manage to change the behavior of the terminal; and only certain scenarios reach a transaction with a demonstrable financial impact.

The protocol from another angle#

So far this has been technologies and security properties. Now look at what actually happens during a transaction. An APDU capture lets you follow the operation from the first command. In a contactless transaction, one of the first steps the application takes can be selecting a structure the terminal already knows about.

No cryptographic operation is needed to interpret this part of the capture. It is enough to know the APDU structure and to represent the bytes according to their encoding.

The response can contain TLV structures describing the applications available. Tag 4F identifies an AID, tag 50 provides an application label intended mainly for display, and tag 87 can indicate the priority associated with an application during selection.

A few dozen bytes are enough to establish something important. A card does not necessarily represent a single payment application. It can offer several, and hand the terminal information that takes part in choosing which one gets used. That turns an apparently trivial operation into a sequence of observable decisions: the terminal discovers the applications, obtains their identifiers, evaluates the information available, selects one, and only then begins the processing specific to that application. The capture lets you see every one of those steps.

The first skill in the lab#

This is the kind of analysis the rest of the training uses. It does not start from a theory about what should have happened. It starts from the bytes and reconstructs the processing out of them. One command. One response. One tag. One value. One decision. And then the next interaction.

As the course goes on, more complex structures appear: application records, certificates, public keys, authentication data, CVM, Terminal Verification Results, cryptograms and authorization decisions. The difficulty is not in recognizing each individual field. It is in understanding the relationship between them.

Where the field is, as of 2026#

This is not a closed subject with a fixed syllabus. Results land every year, and some of the ones this course is built on are newer than the course. If you are new here, three papers will orient you faster than anything else, and I would read all three before going far into the modules.

The references page lists everything this course stands on, with a line on each saying why it matters here. If a lesson and a source disagree, the source is right and the lesson is a bug. That has happened a few times. Each correction goes into the module instead of being patched quietly.

Read one exchange, before anything else#

You have read the terminal's half. Now read the card's. What follows comes from the Visa capture in this corpus: a real card at a real terminal, sanitized so the account number is a published test number. Nothing else was touched.

The card did not answer with one application. It answered with two, each in its own template, each with a name a person can read and a priority saying which one the terminal should prefer.

What the rest of the course does with that#

This module is the free one and the shortest, and I would rather tell you than let you find out. What you just did, twenty bytes, one response and a real observation at the end of it, is the small version of what the other twenty-one modules do at length.

The tools this course brings with it#

Nearly everything you need is already on this page: the workbench, the decoder you just used and the capture corpus. Beyond that there are three tools this course carries with it, and it is worth knowing they exist from the start, because the modules ahead are built on them. Module 2 goes through all of them, and through the ordinary hardware, in detail.

ATRIUM Mission Control

Actual sizeOpen the originalClose

How to work through this course#

Every module from here refers to a real captured transaction, and you can open any of them whenever you like. Reading about an APDU is worth an hour. Seeing one in the workbench and recognizing the field being described is worth much more. If you want your own hardware, an ACR122U for contactless and an SCR3310 for contact will get you through most of this course; a PN532 board, a Proxmark3 and SIMtrace2 come in later, and module 2 covers the setup. None of it is required to read the captures here.