Credit Card Service Code Chart

A card’s service code is the three-digit number stored right after the expiry date in its magnetic-stripe track data. Each digit answers one question: the first says where the card may be used and whether it has a chip, the second says how transactions must be authorised, and the third says which services are allowed and when to ask for a PIN. For example, 201 reads as “international card with a chip, normal authorisation, no restrictions”.

This page gives a chart for each digit position, a decoded list of the codes people search for most (101, 120, 201, 206, 221, 226 and others), and explains where the code lives, why chip terminals care about it, and what the PCI DSS rules say about storing it.

Scope: The service code is defined in ISO/IEC 7813, a paid standard that we have not used. Every digit meaning below comes from openly published documents: Visa’s public Transaction Acceptance Device Guide, Mastercard’s public Security Rules and Procedures – Merchant Edition, and Nepal Clearing House’s public NEPALPAY card specification. A value is marked confirmed when at least two of these independent publishers state it, and qualified when only one does. We leave out values that none of them define. We keep the per-row evidence (source, section and retrieval date for every value) in a dataset, and the decoder further down embeds the same table.

How to read a service code

Read the three digits from left to right. Each one is looked up on its own, and the full code is simply the three answers together:

  2        0        1
  |        |        |
  |        |        +-- digit 3: which services are allowed, and the PIN rule
  |        +----------- digit 2: how the transaction must be authorised
  +-------------------- digit 1: where the card may be used, and chip present?

Two cautions apply before you use the charts. First, both Visa and Mastercard say that not every combination of valid digits is a valid code, and that only certain codes are allowed on a given card programme. A code you can build from the charts is not necessarily one that any issuer actually puts on a card. Second, the digits only govern transactions read from the magnetic stripe. When a chip is read, the terminal follows rules stored on the chip instead (more on this below).

Digit 1: where the card may be used, and whether it has a chip

The “2 or 6 means a chip” rule matters most in practice. Mastercard’s rules say a 2 or 6 in the first position tells the terminal that the card has a chip carrying the same Mastercard application as the stripe. Visa’s guide requires every Visa chip card to start its service code with 2 or 6, on the stripe and on the chip alike. The reverse does not hold: a first digit of 1 or 5 only means the stripe does not signal a chip, and Mastercard even requires a 1 for some chip cards that carry only a stand-alone stored-value application. The values 0, 3, 4 and 8 are not defined for payment use by any of our sources: Visa lists them as invalid and NCHL lists them as reserved.

Digit 2: how the transaction must be authorised

Visa’s guide is clear about what a 2 here means for a stripe read: the transaction must go online even when the amount is below the floor limit. An offline-only terminal, or one that is temporarily offline, cannot approve it, although the merchant may still get a voice authorisation. Mastercard’s rules add a regional case: in its Europe region, a stripe-reading terminal must get authorisation before completing a Mastercard transaction whose second digit is 2.

Digit 3: which services are allowed, and the PIN rule

In this digit, “PIN” means an online PIN. Visa’s guide says a PIN pad that can only do offline PIN (as used for chip transactions) counts as “no PIN pad” when the terminal applies the service code. Mastercard adds that issuers may only use the PIN-related values on programmes where Mastercard has approved PIN use.

Quick lookup: common service codes decoded (101, 120, 121, 201, 206, 221, 226, 501, 601)

The table below is derived. Each row is just the three digit meanings above put together. It is not a list of codes that a particular network allows on a particular product. The last column marks the codes that also appear in a published example: Visa’s track-encoding examples use 101, 120 and 201, and NCHL requires 226 on NEPALPAY EMV cards.

Mastercard’s rules also give 506 as an example of a PIN-related code on a national-use-only card. Read with the charts, it means domestic only, normal authorisation, and ask for a PIN if a PIN pad is present.

Where the service code sits in the track data

A payment card’s stripe has two tracks that matter here. Track 1 is alphanumeric, can be up to 79 characters, and also holds the cardholder name. Track 2 holds digits only and can be up to 40 characters. On both tracks, the service code comes straight after the four-digit expiry date (YYMM). Mastercard describes it as a three-digit number that complies with ISO/IEC 7813, requires the same code on Track 1 and Track 2, and allows only one code per card. The layouts below follow the field tables in Visa’s guide. The PAN is a synthetic, Luhn-valid number we made up for this page. It does not belong to any real card.

Track 2 (stripe, numeric, max 40 characters)

 ;  9999990000000014  =  3012  201  [ PIN verification data ]  [ discretionary data ]  ?  LRC
 |  PAN, 12-19 digits |  YYMM  |      0 or 5 digits             issuer-defined        |
 start sentinel     separator  service code                                        end sentinel

Track 1 (stripe, alphanumeric, max 79 characters)

 %  B  PAN  ^  CARDHOLDER NAME  ^  YYMM  SSS  [ PIN verification ]  [ discretionary ]  ?  LRC
    format code B                       service code

Track 2 Equivalent Data on the chip (EMV tag 57, shown as hex digits)

 9999990000000014 D 3012 201 ...discretionary data... F
                  separator is the hex digit D; no sentinels or LRC; F pads to a whole byte

Chip cards also carry the service code. The chip holds a copy of the Track 2 data, called Track 2 Equivalent Data (tag 57). Visa’s guide says that on a chip card, the service code in this copy and the one on the stripe must both start with 2 or 6. If you are parsing tag 57, our BER-TLV parser walkthrough shows how to pull the field out of a card response.

EMV service code: why 2xx and 6xx mean “use the chip”

The first digit is what makes chip acceptance hold together on terminals that also have a stripe reader. When a card is swiped, Visa’s guide requires a chip-capable terminal to read the service code. If the code starts with 2 or 6, the terminal must ask for the card to be inserted, unless fallback conditions apply. Mastercard’s rules say the same thing for hybrid terminals: try the chip first. Without that 2 or 6, a terminal reading a swipe would have no way of knowing that a chip was there.

Fallback is the exception. If the chip or the chip reader genuinely fails, Visa lets the terminal complete the sale from the stripe after retrying the chip, and requires every fallback transaction to be authorised online. The issuer works out whether a transaction was a fallback by looking at three fields together: the POS entry mode (stripe read), the service code (chip card) and the terminal’s entry capability (chip-capable). Visa’s US acquirer guide lists exactly this combination. The EMV Migration Forum’s 2015 fallback guidance warns that a terminal which is chip-capable in hardware, but not yet enabled for chip, will wrongly flag ordinary swipes as fallback if it reports itself as a chip terminal.

Chargeback rules use the code too. Visa’s public rules treat a counterfeit-fraud dispute under the EMV liability shift as invalid when the authorisation shows a stripe read (POS entry mode 90) and the stripe’s service code does not indicate a chip. Our liability shift and fallback guide covers that side in more depth.

On a chip transaction, the service code steps aside

Both networks limit the service code to stripe-read transactions. Visa says that on a chip transaction the terminal uses controls stored on the chip instead, such as the Cardholder Verification Method (CVM) List and the Application Usage Control. Mastercard says a hybrid terminal completes a chip transaction using the data on the chip. So a 201 card that is inserted and read successfully does not get its PIN policy from the final “1”. The chip’s own data decides. To see what the chip offers before that point, start with EMV application selection and the EMV tag reference.

Not a secret, and not a security check on its own

The service code is not secret. It is an instruction from the issuer that sits in plain view in the track data, and PCI SSC lists it as an element of cardholder data, alongside the cardholder’s name and expiry date. It does not prove the card is genuine. The stripe’s card verification value (CVV or CVC1) is a separate value that the issuer computes with a secure cryptographic process, and a chip transaction is protected by the chip’s own cryptogram. Neither of these is the “security code” that online checkouts ask for: Visa defines that printed value (CVV2) separately.

The code also does not tell you whether a card is credit or debit. Visa’s digit table describes a first digit of 2 as “EMV chip, debit or credit”.

What merchants and developers actually do with it

• Prompt for the chip. On a swipe, if the first digit is 2 or 6, ask for the card to be inserted, and only fall back to the stripe after a real chip failure.
• Force online authorisation. If the second digit is 2, send the transaction online whatever the floor limit. An offline-only device must not approve it.
• Decide on a PIN prompt. Visa’s guide says a device with an online PIN pad should ask for a PIN for third digits 0 and 6. If it then cannot go online, it continues normally for a code like x06 but declines for x20.
• Respect “ATM only”. Visa asks POS devices that approve below the floor limit to check that the third digit is not 3.
• Do not hard-decline on an unknown code. Visa says a device that does not recognise the code should send the transaction online if it can, and reject it only if it is offline. Mastercard tells acquirers that hybrid terminals must not refuse a transaction just because of the service code.
• Do not invent meanings. If a digit is not in your rule set, report it as unknown rather than guessing. The decoder below does exactly that.

Visa’s guide also notes that a stripe-read transaction cleared without online authorisation can be charged back for a service-code violation if the code was ignored. That is a reason to get these checks right, not legal advice. Your acquirer’s rules decide what applies to you.

PCI DSS: the service code may be stored, but not the track it came from

PCI SSC’s glossary treats the service code in two ways, depending on where it sits. On its own, it is one of the elements of cardholder data that may appear together with the PAN. Inside a full track, it is part of track data: the stripe contents or the stripe image on the chip. Full track data counts as sensitive authentication data, which is processed but not stored. PCI SSC’s data-storage fact sheet says the same in practical terms. Never keep the full contents of any track after authorisation, even encrypted. If the business needs them, you may keep the name, PAN, expiry date and service code, provided they are protected under PCI DSS. That fact sheet dates from 2008, so check the current PCI DSS version for the exact requirement numbers.

For developers, the rule is simple. Parse the service code out of the track at authorisation time. If you need it later, store only that field. Do not log or keep the raw track or the tag 57 contents.

A small decoder you can test

The module below is self-contained: its digit table is a copy of the sourced dataset behind the charts on this page, and our tests check that copy against the dataset row by row. It rejects anything that is not exactly three ASCII digits. It reports digits that are not in the dataset as “not defined in sources used” rather than guessing. It can also pull the service code out of stripe-format Track 2 data or out of tag 57 data in hex.

// Decode a 3-digit magnetic-stripe service code. Self-contained: no file access.

export const UNDEFINED = 'not defined in sources used';

// Digit meanings, one entry per position=digit, generated from the article's sourced dataset
// (every row has a public source; see the Sources section). Digits absent here are not
// defined by the sources used and are reported as such rather than guessed.
export const DIGITS = Object.freeze({
  'd1=1': { meaning: "International use; the stripe does not signal a chip", status: 'confirmed', sources: 3 },
  'd1=2': { meaning: "International use; card carries a chip that must be used when the terminal can read it", status: 'confirmed', sources: 3 },
  'd1=5': { meaning: "National (domestic) use only", status: 'confirmed', sources: 3 },
  'd1=6': { meaning: "National (domestic) use only; card carries a chip that must be used when the terminal can read it", status: 'confirmed', sources: 3 },
  'd1=7': { meaning: "Private-label or proprietary card; not for general interchange", status: 'confirmed', sources: 2 },
  'd1=9': { meaning: "Test card", status: 'qualified', sources: 1 },
  'd2=0': { meaning: "Normal authorisation: the usual rules and floor limits apply", status: 'confirmed', sources: 3 },
  'd2=2': { meaning: "Online authorisation by the issuer is required for every transaction, regardless of floor limit", status: 'confirmed', sources: 3 },
  'd2=4': { meaning: "Authorised by the issuer and should be online, except under bilateral agreement", status: 'qualified', sources: 1 },
  'd3=0': { meaning: "PIN required; no restriction on the type of service", status: 'confirmed', sources: 3 },
  'd3=1': { meaning: "No restrictions; normal cardholder verification", status: 'confirmed', sources: 3 },
  'd3=2': { meaning: "Goods and services only (no cash)", status: 'confirmed', sources: 3 },
  'd3=3': { meaning: "ATM only; PIN required", status: 'confirmed', sources: 3 },
  'd3=4': { meaning: "Cash only", status: 'qualified', sources: 1 },
  'd3=5': { meaning: "Goods and services only (no cash); PIN required", status: 'confirmed', sources: 2 },
  'd3=6': { meaning: "No restrictions; prompt for PIN if a PIN pad is present", status: 'confirmed', sources: 3 },
  'd3=7': { meaning: "Goods and services only (no cash); prompt for PIN if a PIN pad is present", status: 'confirmed', sources: 2 },
});


export function serviceCode(code) {
  if (typeof code !== 'string' || !/^[0-9]{3}$/.test(code)) {
    throw new TypeError('service code must be a string of exactly three digits');
  }
  const digits = [...code].map((digit, i) => {
    const e = DIGITS[`d${i + 1}=${digit}`];
    return {
      position: i + 1,
      digit,
      meaning: e ? e.meaning : UNDEFINED,
      status: e ? e.status : 'undefined',
      sources: e ? e.sources : 0,
    };
  });
  // A first digit of 2 or 6 tells a magnetic-stripe reader the card has a chip.
  return { code, chip: code[0] === '2' || code[0] === '6', digits };
}

// Pull the service code out of Track 2 data: either the stripe form
// ";PAN=YYMMSSS...?" or the chip's Track 2 Equivalent Data as hex, "PANDYYMMSSS...F".
export function serviceCodeFromTrack2(track2) {
  const m = /^;?([0-9]{12,19})[=D]([0-9]{4})([0-9]{3})/i.exec(String(track2).trim());
  if (!m) throw new TypeError('not recognisable Track 2 data');
  return m[3];
}

Running the example on a synthetic tag 57 value, plus 226 and an undefined 301, prints:

201  chip=true
  digit 1 = 2: International use; card carries a chip that must be used when the terminal can read it [confirmed, 3 source(s)]
  digit 2 = 0: Normal authorisation: the usual rules and floor limits apply [confirmed, 3 source(s)]
  digit 3 = 1: No restrictions; normal cardholder verification [confirmed, 3 source(s)]
226  chip=true
  digit 1 = 2: International use; card carries a chip that must be used when the terminal can read it [confirmed, 3 source(s)]
  digit 2 = 2: Online authorisation by the issuer is required for every transaction, regardless of floor limit [confirmed, 3 source(s)]
  digit 3 = 6: No restrictions; prompt for PIN if a PIN pad is present [confirmed, 3 source(s)]
301  chip=false
  digit 1 = 3: not defined in sources used [undefined, 0 source(s)]
  digit 2 = 0: Normal authorisation: the usual rules and floor limits apply [confirmed, 3 source(s)]
  digit 3 = 1: No restrictions; normal cardholder verification [confirmed, 3 source(s)]

Our node --test suite (not reproduced here) checks that every dataset row decodes word for word, that every “confirmed” row has at least two independent sources, that every digit missing from the dataset is reported as undefined, and that malformed input is rejected. That includes numbers, strings with spaces, and full-width digits.

Frequently asked questions

What does service code 201 mean?

201 means an international card with a chip (2), normal authorisation (0), and no restrictions with normal cardholder verification (1). A chip-capable terminal that swipes a 201 card should ask for the card to be inserted.

What does service code 101 mean?

101 means an international card whose stripe does not indicate a chip, with normal authorisation and no restrictions. It is one of the codes Visa uses in its track-encoding examples.

What does service code 121 mean?

121 means an international card whose stripe does not indicate a chip (1), which must always be authorised online by the issuer (2), with no restrictions and normal cardholder verification (1). This is a derived reading from the three digit charts.

What does service code 120 mean?

120 means an international card with no chip indicated, online authorisation required, and a PIN required. Visa uses 120 in one of its track-encoding examples.

What does service code 206 mean?

206 means an international chip card, normal authorisation, no restrictions, and a PIN prompt if a PIN pad is present (derived from the digit charts).

What do service codes 501 and 601 mean?

Both mean a domestic-use-only card with normal authorisation and no restrictions. 601 also tells the terminal that the card has a chip, while 501 does not (derived from the digit charts).

What is the difference between service code 221 and 226?

Both mean an international chip card that must always be authorised online. The difference is the last digit: 221 uses normal cardholder verification, while 226 asks for a PIN if a PIN pad is present. NCHL requires 226 on NEPALPAY EMV cards.

Is the service code the same as the CVV or security code?

No. The service code is an issuer instruction stored in the track data. The CVV (or CVC1) is a separate value computed by the issuer. The security code printed on the card (CVV2) is a third, separate value used for card-not-present payments.

What is the difference between track 1 and track 2 data?

Track 1 is alphanumeric (up to 79 characters) and includes the cardholder name. Track 2 is numeric only (up to 40 characters). Both carry the PAN, expiry date and the same service code. Chip cards hold a copy of Track 2 as Track 2 Equivalent Data (tag 57).

Where is the service code on a credit card?

It is not printed on the card. It is stored on the magnetic stripe, immediately after the expiry date on both Track 1 and Track 2, and chip cards also keep a copy in the Track 2 Equivalent Data on the chip.

What does a first digit of 2 or 6 mean on a track 2 service code?

It means the card has a chip. 2 means international use and 6 means domestic use only. Terminals that can read chips should use the chip rather than the stripe unless the chip cannot be read.

Can I store the service code?

Per PCI SSC guidance, the service code may be stored as cardholder data if it is protected under PCI DSS. The full track data it was read from must not be stored after authorisation.

Related reading on Ambimat

• EMV liability shifts and fallback transactions
• Step by step: how an EMV contact card payment works
• EMV application selection
• EMV and NFC tag reference
• How to parse TLVs in JavaScript
• The Luhn algorithm for card numbers

Sources

• Visa, Transaction Acceptance Device Guide (TADG), version 3.1, November 2016 (Visa Public). Section 3.2 (chip read and fallback), Section 5.3 (service codes), Appendix A Tables A-1 and A-11, Appendix B Tables B-1, B-3, B-6, B-8 and B-9. usa.visa.com
• Mastercard, Security Rules and Procedures – Merchant Edition, 4 August 2026. Section 3.13 (Service Codes), Table 3.2 and Section 3.13.4, pp. 46–49. mastercard.com (read via Wayback capture of 19 Sep 2026)
• Nepal Clearing House Ltd (NCHL), NEPALPAY Card Specification, NCHL API documentation, section 4 (service code tables for Track 1 and Track 2; required value 226). doc.connectips.com
• Visa, Visa Core Rules and Visa Product and Service Rules, 18 April 2026. Rule 4.1.17.21; Table 11-10 (Dispute Condition 10.1 invalid disputes); Glossary entries “Service Code”, “Card Verification Value”, “Card Verification Value 2”, “Authorization Request Cryptogram”, “Fallback Transaction”. usa.visa.com
• Visa, VSDC Contact & Contactless U.S. Acquirer Implementation Guide, version 3.0, effective June 2020. Section 2.1.1 and Table 5-2 (magnetic-stripe fallback data elements); Glossary “Application Usage Control”. usa.visa.com
• EMV Migration Forum, EMV Implementation Guidance: Fallback Transactions, version 1.0, November 2015. Pages 1–2. web.archive.org (emv-connection.com)
• PCI Security Standards Council, Glossary: “Service Code”, “Cardholder Data”, “Track Data”, “Sensitive Authentication Data”. Retrieved 10 October 2026. pcisecuritystandards.org
• PCI Security Standards Council, PCI Data Storage Do’s and Don’ts (fact sheet), 2008. Page 2, “Technical Guidelines for Stored Payment Card Data”. pcisecuritystandards.org

Written by the Ambimat engineering team. Code tested on Node.js 25.8.2.