Comparing Chip Card and Magnetic Stripe Card Transaction Flows

As you begin to learn about chip card (A.K.A. smart card or EMV™ 1) transactions, sometimes it is helpful to start with what you know: the familiar magnetic stripe card transaction. In this introduction to chip card processing, this article examines the similarities and differences in the magnetic stripe card transaction flow and the chip card transaction flow.

The Basics: EMV and Chip Cards

Frequently, you'll hear the terms EMV, chip, and smart cards used interchangeably. You may be surprised to learn that patents were first filed for "smart cards" in France, Germany, and Japan in the 1970s. The concept started as a way to store bank account information securely on a card. Over time, people realized that this technology provided a way to store more data on the card than is possible to store on a magnetic stripe. The technology also provided a way to make decisions and handle dynamic data from the card (that is, without requiring communication with the host).

Standards were needed to ensure interoperability between cards and devices, so that any chip card could communicate with any chip device. EMVCo LLC, currently operated by American Express, JCB International, MasterCard International, Visa International, Discover and Union Pay was formed in February 1999 "to manage, maintain and enhance the EMV Integrated Circuit Card Specifications for Payment Systems." EMVCo members worked together over several years to establish standards for chip-enabled devices and chip cards. Just as there are rules for the location and contents of a magnetic stripe on a card, there are strict guidelines for the location of the chip on a contact chip card, because certain areas of the chip must come into physical contact with certain points on the device. The various payment systems and networks have worked within the standards established by EMVCo to define their own formats for certain EMV data fields.

What is a chip card, and how does it work? Think of the chip on the card as a miniature computer. It has its own operating system, memory, communications interface, security features, and the ability to encrypt and decrypt data. As you might expect, this technology comes with its own terminology, acronyms, data formats, and several types of keys and cryptograms.

Some of the important benefits of a chip card include the ability to securely store information in chip on the card, and the ability to send and receive sensitive financial data in a secure manner. (Interested in more information on chip cards and EMV? See Chip Cards 101: The What and Why of EMV.)

Let's take a quick look at a transaction flow for a magnetic stripe card and a chip card. (There are many possible variations of transaction flows, but rather than launch into an indepth analysis of financial transaction messaging, we'll simply focus on a high-level overview of one possible transaction flow.)

Magnetic Stripe Card Transaction Flow at a Magnetic Stripe Device

Magnetic Stripe Card Transaction Flow at a Magnetic Stripe Device

To begin our comparison of magnetic stripe transaction flow and chip card transaction flow, let's review the familiar transaction flow that occurs when a magnetic stripe card is used at a device which employs a magnetic stripe reader.

  1. Let's imagine we are using our trusty magnetic stripe card to make a purchase at a POS device. The magnetic stripe contains data in "tracks"; for example, Track 2 contains data such as the card number and the card expiration date. When the card is swiped through the device, data from the magnetic stripe is captured and included in the transaction request.
  2. The request, with the captured data, goes from the device to the acquirer.
  3. The request then goes to the issuer.
  4. The issuer uses the data from the card, as well as information such as the transaction amount, to make an authorization decision.
  5. The response is then sent back to the acquirer.
  6. The response then goes to the device.

There is no further interaction between the device and the card after the card is swiped. Many cardholders in the US are accustomed to swiping the card and immediately putting it back in their wallet or purse. Sometimes the store clerk may ask the cardholder for the last 4 digits of the card number, but there is no further interaction between the terminal and the card after the card is initially swiped.

Of course, we could also use our magnetic stripe card at an ATM. Even though the ATM may hold the card for the duration of the transaction, the data that is read from the card and the transaction path we presented for the POS transaction are virtually the same for an ATM transaction.

Now, let's look at a chip card transaction flow. (Again, this is simply a high-level overview of one possible transaction flow.)

Chip Card Transaction Flow at a Chip-Capable Device

Chip Card Transaction Flow at a Chip-Capable Device

Now we will look at what happens when we use our chip card to make a purchase at a chip-capable POS device. Even though this example shows a contact chip card at a contact POS chip device, the same principles apply if we used a chip card at a chip-capable ATM, or if we used a contactless chip card.

  • From the beginning of the transaction, there is communication between the chip card and the device in both directions. There's quite a lot going on in this step, but we'll focus on three major functions.
    • First, the terminal has to determine whether the card is a magnetic stripe card or a chip card.

      Typically, the terminal begins by reading the magnetic stripe (because the assumption today is that all cards have a magnetic stripe). By interrogating the service code in the magnetic stripe data, the terminal determines whether the card is a magnetic stripe card or a chip card. If it's a chip card, the terminal then has to try to read the chip. If the terminal can't read the chip, the terminal follows the applicable rules and regulations to determine how to proceed at this point: either to "fall back" and generate a magnetic stripe transaction, or to stop the transaction. For our example, we'll assume the terminal was able to successfully read the chip.

    • Next, the card and the terminal must determine if they have at least one Application ID in common.

      The chip card will be programmed with one or more Application IDs, which indicate the particular networks, programs, or applications the card supports (for example, PLUS®2 or Cirrus®2). Similarly, each chip-capable device must be configured to support one or more Application IDs, depending on the acquirer agreements. If they don't, there are usually rules that must be followed to determine if the transaction can proceed or not.

    • Assuming there is a match with at least one Application ID, the chip card creates a request cryptogram.

      The cryptogram is a collection of several pieces of data related to the card and the transaction that is encrypted under a special key stored in the card.

  • This request cryptogram, along with other EMV-related information from the card and the terminal, is sent to the acquirer.
  • Then, the request cryptogram is sent to the issuer.
  • The issuer verifies the request cryptogram and optionally generates a response cryptogram.

    By verifying the cryptogram, the issuer is assured that the transaction came from the chip card (and was not fraudulently introduced into the transaction request path).

    If the request cryptogram is verified successfully, the issuer may optionally generate a response cryptogram.

    (The issuer can also send a command back to the chip card as part of the transaction response that will update some specific fields within the chip.)

  • The response cryptogram is passed in the response that goes back to the acquirer.
  • Then, the response cryptogram is passed in the response to the device.
  • At this point, the device has to once again communicate with the chip card, because the card will try to verify the response cryptogram. By doing so, the chip card can be assured that the response came from the issuer, and was not fraudulently introduced into the transaction response path.
  • There are other steps involved in the card-device interaction, but the previous steps illustrate the basic transaction flow. (Interested in a more technical discussion of chip card transaction flow? See Beyond Cards and Terminals: Considerations for Testing Host-to-Host EMV Processing.)

    The acquirer and the transaction authorizer will require chip-enabled hardware and software to handle the additional information and processing required for chip transactions, and each segment of the transaction path must be able to support this additional information and processing.

    What About PIN Verification in Chip Card Transactions?

    Often, when one is first learning about EMV, there is concern that PIN verification (as currently performed by the host) will need to change, but this is generally not the case. If the transaction requires a PIN, and the PIN is sent online to the host for verification, PIN encryption and PIN verification are handled in the same way in a chip transaction as in a magnetic stripe transaction.

    You can think of these as verifying different aspects of the transaction.

    • By verifying the PIN, the issuer is authenticating the cardholder who performed the transaction. In other words, assuming the cardholder is the only one who knows the PIN, we can be assured that the cardholder actually performed this transaction.
    • By verifying the request cryptogram in the chip transaction, the issuer is authenticating the card that performed the transaction. In our example, it indicates whether or not a legitimate chip card was actually used for the transaction.

    Summarizing the Differences Between Magnetic Stripe and Chip Card Transactions

    The major differences between a magnetic stripe transaction flow and a chip card transaction flow are summarized in the following table.

    Magnetic Stripe Card at Magnetic Stripe Device Chip Card at Chip-Enabled Device
    Initial terminal-card interaction Initial terminal-card interaction
    • Terminal gets static data from card
    • Terminal identifies card type (chip, non-chip)
    • Terminal and card agree on Application ID
    • Card generates request cryptogram
    Request includes data from magnetic stripe Request includes new EMV data elements
     

    Authorization processing must include EMV

    • Validate request cryptogram
    • Optionally generate response cryptogram
    • Optionally generate a command for the card

    Response may include new EMV data elements

    Terminal and card do not interact when response is received Final terminal-card interaction
     
    • Card validates response cryptogram if sent by issuer
    • Card executes command if sent by issuer

     

    About Paragon Application Systems

    Since 1994, Paragon Application Systems has provided ePayment simulation, configuration and testing software solutions to the financial industry. More than 600 financial institutions in over 90 countries use Paragon tools to improve quality and reduce time-to-market. Paragon has helped customers around the globe with their EMV implementations. We start with training to help customers understand what EMV is and all of the terminology associated with it. Then we help customers to develop the right plan for EMV implementation including providing the right set of test tools to validate EMV migration. Visit Paragon Application Systems at www.paragonedge.com, follow our blog at www.emv411.com, follow us on LinkedIn, Twitter @ParagonEdge, @testpayments, Facebook, or email info@paragonedge.com.

    About the Author

    Deborah Spidle has over 20 years of experience in the IT industry, focusing on banking and financial applications. During her career, she has served in many roles, including business analyst, software engineer, and project manager. Deborah spent seven years working with a major national network in Canada, where she performed business and technical analysis for the network’s EMV migration project. She also designed EMV upgrades for multiple highly customized online transaction processing systems, and provided technical guidance to several Canadian banks and credit unions during their EMV migrations.

    Deborah is one of a select group of industry professionals who have earned the Certified Smart Card Industry Professional Certification (CSCIP) and the CSCIP/Payments Certification (CSCIP/P) from the Smart Card Alliance, demonstrating her expertise in Smart Card technology.

    In her current role as Director of EMV Solutions with Paragon Application Systems in Holly Springs, North Carolina, Deborah is responsible for professional services related to EMV, including training and consulting. She has developed over 17 online training presentations covering general payments industry topics and EMV. Deborah’s blog, www.EMV411.com, also addresses topics of interest related to EMV.

    Deborah is very active in the EMV Migration Forum, where she serves on the ATM Working Committee and the Communication and Education Working Committee. Deborah was one of the primary authors of the white paper “Implementing EMV at the ATM: Requirements and Recommendations for the U.S. ATM Community” which was recently published by the EMV Migration Forum.

     


    1EMV™ is a trademark owned by EMVCo LLC.

    2PLUS Network is a registered trademark of Visa International. Cirrus is a registered trademark of MasterCard Worldwide.