Ingenico UPP Series

Ingenico manufacture a number of PCI 3.X certified payment terminals. Their terminals allow manual card data entry, magnetic card swipes and contactless card data entry. Their device is shipped with on-board software called Unified Payment Platform (UPP). UPP supports DUKPT BPS encryption of track data, referred to as OnGuard by Ingenico. It should be noted that for legacy reasons Ingenico's documentation refers OnGuard mode as E2EE encryption and not P2PE.

The following guide outlines how you can extract the P2PE data from UPP payloads for processing on Decryptx. As UPP is standardised across the following Ingenico devices, the steps outlined below should work on all UPP devices. At Bluefin, we have integrated and verified the following Ingenico devices:

  • Lane/3000 PTS 5.x
  • Lane/5000 Only PTS 4.x Supported by UPP
  • Lane/7000 PTS 5.x
  • Lane/8000 PTS 5.x
  • Move/5000 Only PTS 4.x Supported by UPP
  • Link/2500 Only PTS 4.x Supported by UPP

Obtaining the Payload

Typically, UPP terminals are connected to host computers that run special software referred to as Point of Sale (POS) applications. POS applications obtain payment data from a paired terminal and sends the data to a card payment processing gateway. Conveniently, the vendor's developer portal has a number of UPP software development kits for a wide variety of operating systems and development languages. They make it easy for POS applications to obtain data from payment terminals.

In order to obtain data from the terminal, the POS sends UPP commands to connected device. To capture P2PE data you need two UPP commands, the syntax and output of which are detailed below. In our guide, the text [STX], [ETX], [FC] and [LRC] represent one byte characters for the following: start of transmission, end of transmission, field separator and longitude redundancy check (LRC) check sum.

Sample

The first step is to identify the device's serial number by sending a Health Check (08) command to the terminal.

Request

[STX]08.0[ETX][LRC]

Response

[STX]08.6547[FS]248[FS]309[FS]6259[FS]0000[FS]0109[FS]iPP350[FS]2214106PT010989[FS]3806[FS]1202[FS]0401[FS]1001[FS]0000[FS]0000[FS]14516[FS]12912[FS]2014-04-16[FS]0[FS]UNSUPPORTED_DEVICE[FS]Retail Base[FS]INGNAR[FS]0000[FS]80688474[ETX][LRC]

This data is parsed as follows:

CharsValueDescription
1-223[STX]0...00[FS]UPP payload containing terminal specific information.
224-23180688474The device's serial number.
232-241[ETX][LRC]Remainder of payload.

Swiped Payloads

The next step is to send a capture swipe command.

Request

[STX]87.Please Slide Card[ETX][LRC]

Response

[STX]87.0[FS]41249399901612212101912TEST/BLUEFIN1BFFFF99999900F660000B0114331089645004140780=52138380040406783299B50C91A3B8A8302DB5B68F36AAE851960E91C78B1AA699A986957236BB6FAD69F7047F06FF046FF61B1A020BD2016814A2E402305C089BABA1214883E15FB1698[ETX][LRC]

This data is parsed as follows:

CharsValueDescription
1-6412493Clear value of first 6 digits of PAN (card number)
7-109990Clear value of last 4 digit of PAN
11-1216Decimal length of PAN
13-131MOD 10 check flag: 0=PAN failed MOD 10 check;1=PAN passed MOD 10
14-172212Clear value of PAN expiration date (YYMM)
18-20101Clear value of track2 service code
21-219Track2 language indicator
22-2312Decimal length of cardholder name
24-35TEST/BLUEFINClear value of cardholder name
36-361Card data encrypted flag: 0=clear ASCII data; 1=encrypted ASCII data
37-37BEncrypted format type: B=OnGuard (or IngeCrypt)
38-57FFFF99...60000B10 bytes of Key Sequence Number in hex.
58-610114Custom field of KSN
62-6333Decimal length of encrypted card data
64-641UPP adds this leading digit to make output to pass MOD 10 check.
65-96089645...040678The track2 encrypted card data.

📘

How does UPP encrypt card data?

To help you understand how to prepare an Ingenico payload data for processing on Decryptx, you need to know how UPP manipulates the card data when encrypting it:

  1. The device reads the track2 data. e.g. (;4124939999999990=2212101123456789?)
  2. It then removes the leading ‘;4’, the ‘=’, and ‘?’ characters (1249399999999902212101123456789).
  3. It submits the reduced track data to the device's Crypto processor
  4. The Crypto processor runs BPS Encipher and returns the following encrypted text: (0896450041407805213838004040678).
  5. The UPP software adds a leading digit to make output to pass MOD 10 check('1') and adds an '=' after 16 digits to make encrypted data to look like track2. i.e. (1089645004140780=5213838004040678).

Processing swiped data

To prepare the encrypted payload for decryption, you must reverse UPP's track2 data manipulation. To do this, remove the leading digit and the '=' character from the payload and base64 encode it. In this example, the encrypted data is:

1089645004140780=5213838004040678

Before sending it to Decryptx it should be converted to the following: >30383936343530303431343037383035323133383338303034303430363738

After making the API call to the Decryptx with the converted data and the KSN:

FFFF99999900F660000B

You will get the following decrypted value in the response:

31323439333939393939393939393032323132313031313233343536373839

Before extracting the payment data from the decrypted value, it must be converted to ASCII first. The following is the ASCII version:

1249399999999902212101123456789

This data is parsed as follows:

CharsValueDescription
1-15124939...999990This is the PAN, minus the first digit. The full PAN can be reconstructed by prepending this value with the first character in the original UPP payload.
16-192212The expiry date in YYMM format. The data does not contain a separator to deliminate the PAN and expiry values, however, the length of the PAN can be found in chars 11-12 of the original payload. In this example the PAN length is 16.
20-22101Service Code
23-31123456789 Card specific data.

Keyed Payloads

📘

How do you differentiate keyed payloads from swiped?

Payloads that contain keyed data will always have a Service Code of 000, followed by a language indicator of 0. The track2 data is also prepended with a M marker.

The following outlines how to extract the P2PE data from a Keyed UPP payload.

[STX]87.0[FS]4124939990161221200001BFFFF99999900F660000A011425M2615003155099705=04025513293F5249D4B0B1BAAD4DFA43528271D4164B3F1532E3FDA2271FB52CA770C5068FD196D644CB1604054AF45E995CA58149F0[ETX][LRC]

This data is parsed as follows:

CharsValueDescription

📘

How does UPP encrypt keyed card data?

UPP does the following when encrypting card data:

  1. It submits the manually entered PAN, expiry, and CVV data (4124939999999990, 2212, 123) to device crypto processor.
  2. The crypto processor runs the BPS Encipher and returns back the cypher text (6150031550997050402551).
  3. UPP then prepends the indicator of manual entry ‘M’ and a leading digit to make the fake PAN to pass MOD 10 check(‘2’), it also adds ‘=’ after 16 digits to make data to look like track2 (M2615003155099705=0402551).

Processing Keyed Data

To prepare the encrypted payload for decryption, you must remove the '=', the 'M' marker and the leading digit. In this example you will end up with the following payload:

36313530303331353530393937303530343032353531

After making the API call to the Decryptx with the converted data and the KSN >FFFF99999900F660000B

You will get the following decrypted value in the response:

31323439333939393939393939393032323132313233

Before extracting the payment data from the decrypted value, it must first be converted to ASCII. The following is the ASCII data:

1249399999999902212123

This data is parsed as follows:

CharsValueDescription
1-15124939...999990This is the PAN, minus the first digit. The full PAN can be reconstructed by prepending this value with the first character in the original UPP payload.
16-192212The expiry date in YYMM format. The data does not contain a separator to deliminate the PAN and expiry values, however, the length of the PAN can be found in chars 11-12 of the original payload. In this example the PAN length is 16.
20-22123The CVV.

EMV Payloads

To enable EMV you must send a 33.x command.

33.02.0000[FS]T4F:07:hA0000000041010[FS]T50:0A:aMasterCard[FS]T57:13:h5413330000004111D2512010000000000000F[FS]T5A:08:h5413330000004111[FS]T84:07:hA0000000041010[FS]T5F20:1A:aDITest/Card06[FS]T5F24:03:h251231[FS]T5F28:02:h0840[FS]T5F2D:02:aen[FS]T5F30:02:h0201[FS]T5F34:01:h01[FS]T9F06:07:hA0000000041010[FS]T9F07:02:hFF00[FS]T9F11:01:h01[FS]T9F12:10:h4D617374657243617264437265646974[FS]T9F1A:02:h0840[FS]T9F1B:04:h00002710[FS]T9F1E:08:a81307672[FS]T9F1F:18:a[FS]T9F42:02:h0840[FS]T9F6E:20:h0840000030300000000000000000000000000000000000000000000000000000[FS]DFF1D:10:a5413330000004111[FS]DFF1F:DD:a541333411116125122019001B000228000000008001640114371237079866102780=49100761840377394733328C6F41A7AD6220CB4158F93B459FD79F965F58E62D6A69E8A3E3479AACEC82B26EC85E5B81E9E33D9BD2637451509D7BEBE4B4F7DEB98C9A8DF6FC1620B6EFCB0F2[FS]

Transaction data from EMV chip-card is returned primarily as Tag, Length, Value (TLV).

📘

What is TLV?

Tag-length-value (TLV) is a data encoding scheme. Values are appended to a string in triplets. The first field in the triplet is the "type" of data being processed, the second field specifies the "length" of the value, the third field contains a "length" amount of data representing the value for the "type". Typically, the type and length fields are fixed in size (typically 1-4 bytes).

Multiple pieces of data can be transmitted in the same string by appending more triplets to a previously existing string.

Ingenico UPP Device TLV Tags

After an Ingenico UPP device has processed an EMV transaction it will output a payload containing the EMV tag names, the value length and tag values. This payload is similar to the standard EMV TLV string. However, it has additional markers to denote if the value is hexadecimal (h) or ASCII (a), it separates the tag name, length and value with a colon (:) character and it precedes the tag name with a T. To process the transaction with the Parser you can either parse the payload and pass the FFIF in the device Payload parameter or simply pass the whole payload as the devicePayload parameter.

The following sample Ingenico UPP EMV payload:

TagFormatLengthValueDescription
4FHexAscii7A0000000041010Application Dedicated File (ADF) Name
50Ascii10MasterCardApplication Label
57HexAscii195413330000004111D251201…Track 2 Equivalent Data
5AHexAscii85413330000004111Primary Account Number (PAN)
84HexAscii7A0000000041010Dedicated File (DF) Name
5F20Ascii26DITest/Card06Cardholder Name
5F24HexAscii3251231Application Expiration Date (YYMMDD)
5F28HexAscii20840Issuer Country Code
5F2DAscii2enPreferred Languages
5F30HexAscii20201Service Code
5F34HexAscii101Application Primary Account Number (PAN) Sequence Number
9F06HexAscii7A0000000041010Application Identifier (AID) - Terminal
9F07HexAscii2FF00Application Usage Control (AUC)
9F11HexAscii101Issuer Code Table Index
9F12HexAscii164D617374657243617264437265646974Application Preferred Name
9F1AHexAscii20840Terminal Country Code (USA)
9F1BHexAscii400002710Terminal Floor Limit
9F1EAscii881307672Interface Device (IFD) Serial Number
9F1FAscii24Track 1 Discretionary Data
9F42HexAscii20840Application Currency Code
9F6EHexAscii3208400000303000000000000…Third Party Data
FF1DAscii165413330000004111Maked or Encrypted PAN
FF1FAscii221541333411116125122019…Encrypted Track 2 Data

Extracting the Decryptx Parameters

The encrypted data is stored in the FFIF TLV tag.

To extract the FF1F value you must search the payload for the TFF1F marker, then parse the length value that follows it (sandwiched between the two :), discard the a marker that precedes the value (denotes that the value is ASCII). In this example the length is DD hexadecimal or 221 in decimal. Once we discard the a marker we grab the next 221 characters and use that in our API call to the Parser. The TFF1F value from our example:

The track 2 FFIF encrypted data example:

541333411116125122019001B000228000000008001640114371237079866102780=49100761840377394733328C6F41A7AD6220CB4158F93B459FD79F965F58E62D6A69E8A3E3479AACEC82B26EC85E5B81E9E33D9BD2637451509D7BEBE4B4F7DEB98C9A8DF6FC1620B6EFCB0F2

[STX]87.0[FS]5413334111161251220190 1B000228000000008001640114371237079866102780=49100761840377394733328C6F41A7AD6220CB4158F93B459FD79F965F58E62D6A69E8A3E3479AACEC82B26EC85E5B81E9E33D9BD2637451509D7BEBE4B4F7DEB98C9A8DF6FC1620B6EFCB0F2[ETX][LRC]

This data is parsed as follows:

CharsValueDescription
1-6541333PAN, first 6
7-104111PAN, last 4 digits
11-1216PAN length
13-131PAN Mod-10 check flag|
14-172512Expiry date
18-20201Service code
21-219Language code
22-220Cardholder name length
23-23 Empty value | Cardholder name
24-241Card data encrypted flag
25-25BEncrypted format type
26-49000228...640114IC KSN
50-5137IC card data length
52-88123707...394733IC card data field
89-9032AES PAN length
91-1228C6F41...9FD79FAES PAN field
123-12496LS card data length
125-2205F58E6...EFCB0FLS Card data field
221-2212Extended language code

Did this page help you?