If you’ve worked with payment systems long enough, you’ve probably heard people say that an issuer simply “approves” or “declines” a transaction. While that is technically true, there is actually much more happening behind the scenes.
An issuer does not only decide whether a transaction should be approved. It can also send instructions back to the card or the payment terminal while the transaction is still in progress. These instructions may update security settings, block a compromised card, reset counters, or even change how the card behaves in future transactions.
Understanding this communication helps developers appreciate why EMV transactions are more than just exchanging amounts and approval codes. It also explains why payment systems are designed around cryptography instead of trust.
In this article, we’ll look at how issuers authenticate cards, how they know a card is genuine, and how they securely send commands back to the card.
The Problem That Needed to Be Solved
Imagine that every payment card only contained a visible card number.
Anyone could copy that number, print it onto another card, and use it to make purchases. The payment network would have no reliable way to distinguish the genuine card from a copied one.
This is exactly the problem EMV was designed to solve.
Instead of relying only on information printed on the card, every EMV chip contains cryptographic keys that never leave the chip. Those keys allow the card to prove its identity during every transaction.
Even if someone copies the visible information, they cannot reproduce the cryptographic secrets stored inside the secure chip.
The Participants
Before looking at the authentication process, let’s identify who participates in an EMV transaction.
- Card, contains secure cryptographic keys.
- Terminal, communicates with the card and forwards transaction data.
- Acquirer, receives transactions from the merchant.
- Payment Network, routes messages between banks.
- Issuer, owns the card account and validates the transaction.
A simplified flow looks like this:
Each participant has a different responsibility, but only the issuer knows the secret information required to verify that the card is authentic.
How the Card Proves It Is Genuine
One of the most important pieces of data generated during an EMV transaction is the Application Cryptogram.
Think of it as a digital signature created specifically for one transaction.
The card generates this cryptogram using information such as:
- Transaction amount
- Transaction date
- Terminal information
- Application Transaction Counter (ATC)
- Random numbers generated during the transaction
- Secret cryptographic keys stored inside the chip
Because the secret key never leaves the card, nobody else can generate the same cryptogram.
A simplified illustration looks like this.
The cryptogram changes for every transaction.
Even purchasing the same amount twice produces a different result because fresh transaction data and counters are involved.
What Happens at the Issuer
When the authorization request reaches the issuer, the issuer receives the cryptogram along with the transaction information.
The issuer has enough information to independently calculate what the expected cryptogram should be.
If both values match, the issuer has strong evidence that:
- the card is genuine
- the transaction data was not modified
- the cryptographic process completed correctly
If they do not match, the issuer may decline the transaction because the card cannot be trusted.
This verification happens within milliseconds.
Dynamic Data Is the Key
One question many developers ask is why the cryptogram changes every time.
The answer is replay protection.
Suppose an attacker records an authorization request from yesterday.
Without dynamic values, they could simply replay the same request later.
EMV avoids this by including changing values such as:
- Application Transaction Counter
- Unpredictable Number generated by the terminal
- Transaction details
- Cryptographic session data
Since every transaction produces a different cryptogram, replaying an old request will fail verification.
More Than Approval or Decline
Here’s something that surprises many developers.
The issuer does not only respond with “approved” or “declined.”
It can also send secure commands back to the card.
These commands are called Issuer Scripts.
Issuer scripts allow the bank to update information stored inside the chip without asking the customer to visit a branch or replace the card.
This makes EMV much more flexible than magnetic stripe cards.
What Can Issuer Scripts Do?
Issuer scripts are securely protected commands that the card executes after verifying they really came from the issuer.
Depending on the card profile, scripts can perform operations such as:
- Blocking the card
- Unblocking certain functions
- Resetting offline counters
- Updating risk management parameters
- Changing application settings
- Managing offline PIN information
- Updating issuer controlled data stored on the chip
The exact commands supported depend on the card application and issuer configuration.
Not every card supports the same operations.
A Simplified Example
Suppose a customer reports that their card was temporarily lost.
Later, they find it again.
Instead of immediately replacing the card, the issuer might decide to temporarily disable offline transactions until the customer confirms everything is safe.
The flow could look like this.
The customer usually doesn’t notice this process happening.
It occurs as part of a normal payment transaction.
How Does the Card Trust the Issuer?
Just as the issuer authenticates the card, the card must also authenticate the issuer.
Otherwise, anyone could send commands to disable or modify cards.
Issuer scripts are protected using cryptographic techniques defined by the EMV specifications.
Before executing a script, the card verifies that:
- the command came from the legitimate issuer
- the command has not been modified
- the security checks pass
If validation fails, the card ignores the command.
This mutual trust is one of the reasons EMV has remained effective against many types of fraud.
Why This Matters for Developers
Many application developers never directly implement EMV cryptography.
That work is usually handled by payment kernels, HSMs, card personalization systems, or issuer authorization platforms.
Still, understanding the flow is valuable.
For example, if you’re building payment software, transaction gateways, or issuer systems, you’ll eventually encounter fields such as:
- ARQC
- ARPC
- Issuer Scripts
- ATC
- Cryptograms
- Authorization Response Codes
Knowing what these values represent makes debugging much easier.
Instead of treating them as mysterious hexadecimal data, you’ll understand how they fit into the overall authorization process.
A Simple Analogy
Imagine entering a secure office building.
You present your employee ID.
The security desk verifies that the ID is genuine.
Once verified, security not only allows you to enter but also updates your access permissions based on your current role.
The next time you enter, your badge behaves differently because it has already been updated.
EMV works in a similar way.
The card proves its identity, the issuer verifies it, and if necessary, securely updates the card before the transaction finishes.
Common Misunderstandings
One common misconception is that the card number alone proves the card is genuine.
It does not. The real proof comes from the cryptographic operations performed inside the secure chip.
Another misunderstanding is that issuer scripts are sent during every transaction. In reality, they are only included when the issuer has something that needs to be updated on the card.
It’s also easy to assume that any payment terminal can modify card data. That is not the case. The terminal only transports the issuer’s commands. The card executes them only after validating their authenticity.
Conclusion
EMV transactions involve much more than checking an account balance and returning an approval code.
Every transaction includes cryptographic operations that allow the issuer to verify the authenticity of the card. At the same time, the issuer has the ability to securely send commands back to the card whenever updates are needed.
This two way trust model is one of the reasons chip cards are significantly more secure than traditional magnetic stripe cards. It helps prevent card cloning, protects against replay attacks, and allows issuers to manage cards throughout their lifecycle without requiring physical replacement.
As developers, we don’t always need to implement the cryptography ourselves, but understanding how these pieces fit together makes payment systems far less mysterious. Once you know what happens between the card and the issuer, many of the fields you see in EMV logs and authorization messages start to make much more sense.
