Ingenico UPP Series

Ingenico manufactures 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 devices ship with on-board software called Unified Payment Platform (UPP). UPP supports Derived Unique Key Per Transaction (DUKPT) BPS encryption of track data, referred to as OnGuard by Ingenico. Note that for legacy reasons Ingenico's documentation refers OnGuard mode as E2EE encryption and not P2PE.

The following guide outlines how to 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 UPP series 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, Ingenico'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:

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:

📘

How does UPP encrypt card data?

To help you understand how to prepare 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 Track 2 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 Track 2, e.g., (1089645004140780=5213838004040678).

Processing swiped data

To prepare the encrypted payload for decryption, you must reverse UPP's Track 2 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 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. The following is the ASCII version:

1249399999999902212101123456789

This data is parsed as follows:

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 Track 2 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:

📘

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 the device crypto processor.
2. The crypto processor runs the BPS Encipher and returns 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 the data look like Track 2 (M2615003155099705=0402551).

Processing Keyed Data

To prepare the encrypted payload for decryption, 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:

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 FF1F in the device payload parameter or simply pass the whole payload as the device payload parameter.

The following sample Ingenico UPP EMV payload:

Extracting the Decryptx Parameters

The encrypted data is stored in the FF1F 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 you discard the a marker, grab the next 221 characters and use that in your API call to the Parser. The TFF1F value from our example:

The Track 2 FF1F encrypted data example:

541333411116125122019001B000228000000008001640114371237079866102780=49100761840377394733328C6F41A7AD6220CB4158F93B459FD79F965F58E62D6A69E8A3E3479AACEC82B26EC85E5B81E9E33D9BD2637451509D7BEBE4B4F7DEB98C9A8DF6FC1620B6EFCB0F2

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

This data is parsed as follows: