How Does a Batteryless Contactless Card Prove a Payment Is Real?

A contactless bank card has no battery. Nothing inside it is continuously listening for a payment terminal. Yet, during a tap, its chip wakes up, exchanges a sequence of messages, performs a cryptographic calculation, and gives the bank something it can verify.

That is already stranger than the usual explanation.

The intuitive model is that the terminal reads a card number over a very short-range radio link. But if that were the whole mechanism, recording the exchange once would be enough to repeat it. A static number is still a static number, even when it travels only a few centimeters.

The real tap stacks three different systems on top of each other:

1. the terminal powers the card;
2. the terminal and card exchange payment data;
3. the chip produces a fresh cryptographic proof over that data.

Those layers solve different problems. Confusing them is why contactless payment can look either magical or dangerously simple.

The terminal powers the card before it reads it

Inside the plastic is an antenna coil connected to a chip. The terminal has another coil. When the terminal generates its magnetic field, the card’s coil couples to it and extracts enough energy to run the chip.

This is not a side effect. It is part of the contactless interface. An NXP antenna-design guide for ISO/IEC 14443 readers —the International Organization for Standardization and International Electrotechnical Commission standard used by proximity cards—describes the same reader antenna doing three jobs: powering the card, sending data to it, and receiving its response.

The card therefore does not need to store energy between payments. It borrows power for the duration of the conversation.

Near Field Communication (NFC) is the radio technology wrapped around that interaction. Its short range creates the familiar tap gesture and limits the nominal operating area. It does not, by itself, prove that the card is genuine. Radio moves the messages. Authentication gives those messages meaning.

The tap becomes a payment conversation

Once powered, the card does not immediately shout a complete payment into the air. The terminal and card first identify a compatible payment application and agree on how to process it.

This is where the details begin to vary. EMV—the payment specifications originally named for Europay, Mastercard, and Visa—contains different contactless kernels for different payment systems. A Visa transaction is not byte-for-byte identical to a Mastercard transaction. Offline and online authorization also follow different paths.

But a representative online transaction has a stable shape:

Terminal: Which payment application can you run?
Card:     Here is a compatible application.

Terminal: Here is the context for this transaction.
Card:     Here is my cryptographic response.

Terminal → payment network → issuer: Please verify it.
Issuer:   Approved or declined.

The issuer is the bank or financial institution that issued the card. Between the merchant and that issuer there may be a processor, an acquirer, and a card network. Those systems matter commercially, but they do not change the central proof: the issuer receives transaction data plus a result that should only have been produced by the card’s secret key material.

The terminal contributes context such as the amount and a value called an unpredictable number. The card contributes its own changing state, including an Application Transaction Counter (ATC), a counter advanced as transactions are initiated. The exact data list depends on the payment system and card profile, but public Visa and Mastercard protocol traces show both terminal-provided transaction data and card-generated state entering the cryptographic process.

The terminal is not merely reading the card. It is asking the chip to authenticate a transaction context.

The secret never crosses the air

For a common online payment, the card creates an Authorization Request Cryptogram (ARQC). A cryptogram is the card’s cryptographic result for this transaction. In this path, it behaves like a Message Authentication Code (MAC): a short value computed from data and secret-derived key material.

A simplified conceptual input might look like this:

amount:                 EUR 27.40
terminal value:         7A3F91C2
card counter:           0194
other EMV data:         ...

cryptogram:             94C8A7F1...

This is deliberately not the algorithm or universal field list used by a real card. Different payment systems and card profiles construct the input and derive keys differently. The useful property is the relationship:

transaction data + changing card state + secret-derived key
                              ↓
                     transaction cryptogram

The terminal can see the transaction data, the counter, and the resulting cryptogram. It does not receive the long-term secret needed to produce a new valid result. The issuer has the corresponding key infrastructure and can independently verify the relationship.

EMVCo’s description of online cryptograms is explicit about this path: the payment device responds to an unpredictable number from the terminal, uses symmetric cryptography, and produces a cryptogram that the card issuer verifies remotely.

The closest physical analogy is a tamper-evident seal placed over the transaction fields. You may read the label and copy the appearance of the package, but changing what is inside breaks the relationship the issuer checks.

The analogy stops there. There is no physical seal. There is a mathematical authentication code, and the issuer verifies it using data and keys.

What happens if you record the whole tap?

Suppose an attacker captures every message visible between the terminal and the card. They now know the amount, the terminal’s unpredictable value, the card counter, and the cryptogram.

That sounds like everything. It is not the secret.

If the attacker changes the amount from EUR 27.40 to EUR 82.00 while keeping the captured cryptogram, the issuer computes the expected result over different data. The old cryptogram no longer matches.

If the attacker resends the entire original packet unchanged, the cryptogram can still be mathematically consistent with that old packet. This is where the card’s counter and issuer-side history matter. The Application Transaction Counter is also an input to issuer-side Authorization Request Cryptogram verification , giving the host a state value it can compare with earlier transactions. The exact acceptance policy is not identical at every issuer: offline transactions and delayed delivery can make counters arrive out of order. So the counter is better understood as authenticated state and a fraud signal, not a universal “duplicate equals decline” switch.

The model below makes both cases visible. It simulates a representative online flow; it does not implement an EMV kernel or read a real card. Current Web NFC is limited to NFC Data Exchange Format tags , and does not expose the low-level payment interfaces needed for that.

The important result is smaller than the protocol: copying a message does not give you the ability to produce a fresh proof over new data.

A valid cryptogram still does not prove distance

Replay is not the only possible attack.

Instead of recording an old transaction and trying to reuse it, an attacker can forward the current conversation in real time. One device sits near the victim’s genuine card. Another behaves like a card beside the merchant’s terminal. Messages travel between them over a longer network connection.

The merchant terminal sends a fresh challenge. The distant genuine card receives it and computes a fresh valid response. The terminal sees a cryptogram that verifies because the real card did participate—just not where the terminal assumed it was.

This is a relay attack:

merchant terminal ⇄ attacker's proxy ⇄ genuine remote card

Researchers have demonstrated relays with commodity devices, and a 2025 systematization with experimental replication found relay attacks remained reproducible while also documenting protocol- and implementation-specific defenses.

This does not mean every contactless card can always be charged from arbitrary distance. Timing checks, relay-resistance protocols, cardholder verification, issuer risk systems, spending controls, and the details of the card and terminal all change feasibility.

It means the cryptogram proves a narrower statement than people often assume:

A device with the required key material participated in this transaction data.

It does not automatically prove:

That device was physically beside this terminal, or the human cardholder approved the purchase.

That boundary is not a footnote. It tells us what the mechanism actually authenticates.

Cryptographic validity is not payment approval

Even without an attacker, a valid cryptogram is only one input to the issuer’s decision.

The issuer can still decline because the account is blocked, funds or credit are unavailable, the transaction looks risky, or cardholder verification is required. Conversely, a payment system with incomplete checks can mishandle a technically suspicious transaction.

Cryptography answers a specific question: is this authentication code consistent with the card’s key material and the transaction data the issuer received?

Authorization answers a larger one: should this payment be allowed?

A phone can speak the same external language

A phone payment looks similar to the terminal because NFC supports card-emulation mode. The NFC Forum describes this explicitly : a phone or wearable can present itself through the same framework as a contactless card, while the service on the other side only needs it to “look like” one.

What changes is behind that interface. A mobile wallet can use secure hardware or host-based card emulation, plus local cardholder verification such as a face, fingerprint, or device code. It can also replace the card number with a payment token constrained to a particular device or scenario, as described by EMV Payment Tokenisation . The exact design depends on the wallet and device.

That is why the phone belongs at the edge of this explanation rather than at its center. From the terminal’s point of view, it participates in a familiar contactless payment protocol. Internally, it may protect and present a different credential in a different way.

A tap is three mechanisms, not one

The short-range radio link is the most visible part of contactless payment, but it is not the part that makes a copied transcript useless.

The terminal’s field powers the card. The protocol gives the chip a transaction to evaluate. The cryptogram binds selected data and changing card state to secret-derived key material that stays out of the radio exchange.

That is why a batteryless card can do more than reveal an identity. For a few moments, the terminal lends it power, and the card uses that power to produce evidence.

But the evidence has a boundary. It can show that the right cryptographic device participated in the data. It cannot, on its own, prove where that device was or who intended the payment.

The useful question is no longer “is contactless secure?” It is: which claim does each layer actually prove?