Ingenico ARC Series

Ingenico manufactures a number of PCI 6.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 Axium Retail Core (ARC). ARC 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 ARC payloads for processing on Decryptx. As ARC is standardised across the following Ingenico devices, the steps outlined below should work on all ARC devices. At Bluefin, we have integrated and verified the following Ingenico ARC series devices:

• AXIUM DX8000 PTS 6.x
• AXIUM EX8000 PTS 6.x
• AXIUM EX6000 PTS 6.x
• AXIUM RX7000 PTS 6.x

Obtaining the Payload

Typically, ARC 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 ARC 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 ARC commands to connected device. To capture P2PE data you need two ARC 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.0013[FS]00[FS]00[FS]00[FS]00[FS]23[FS]DX8000[FS][FS]10[FS]22.01.01.01-0004[FS]01.07.11.00008[FS]0000000[FS]0000[FS]0000[FS]2140508[FS]25533776[FS]0000-0-0[FS]0[FS][FS]AXIUM Retail Core[FS]ingenico[FS]0000[FS]226THD829641[FS]0.0.0.00.00.00.00-0000[FS]YES[FS]0002[FS] [ETX][LRC]

This data is parsed as follows:

Swiped Payloads

The next step is to send a capture swipe command.

Request

[STX]23.312[FS][FS][FS]CMS[ETX][LRC]

Response

[STX]47617300111612412201026UAT USA/TEST CARD 011BFF0000055200000000050114372425471535238865=9509469375646702407300000[ETX][LRC]

This data is parsed as follows.

📘

How does ARC encrypt card data?

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

1. The device reads the Track 2 data, e.g., (;4761730000000011=2412101123456789?)
2. It then removes the leading ‘;4’, the ‘=’, and ‘?’ characters (7617300000000112412101123456789).
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: (42547153523886595094693756467024073).
5. The ARC software adds a leading digit to make output to pass MOD 10 check('2') and adds an '=' after 16 digits to make encrypted data to look like Track 2, e.g., (2425471535238865=95094693756467024073).

Processing swiped data

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

425471535238865=95094693756467024073

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

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

FF000005520000000005

You will get the following decrypted value in the response:

3736313733303030303030303031313234313232303131333033313330363030303030

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

76173000000001124122011303130600000

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 ARCARC payload.

[STX]87.312[FS]4761730011161241200001BFF000005520000000004011425M7384121620705769=3667134

This data is parsed as follows:

📘

How does ARC encrypt keyed card data?

UPP does the following when encrypting card data:

1. It submits the manually entered PAN, expiry, and CVV data (4761730000000011, 2412, 201) to the device crypto processor.
2. The crypto processor runs the BPS Encipher and returns the cypher text (73841216207057693667134).
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 (M7384121620705769=3667134).

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:

33383431323136323037303537363933363637313334

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

You will get the following decrypted value in the response:

37363137333030303030303030313132343132323031

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

7617300000000112412201

This data is parsed as follows:

EMV Payloads

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

33.05.0000[FS]T4F:07:hA0000000031010[FS]T50:0B:aVISA CREDIT[FS]T57:13:h4761730000000011D24122010000000000000F[FS]T82:02:h2000[FS]T84:07:hA0000000031010[FS]T89:00:h[FS]T95:05:h0000000000[FS]T9A:03:h230502[FS]T9B:02:h0000[FS]T9C:01:h00[FS]T5F24:03:h241231[FS]T5F2A:02:h0840[FS]T5F2D:02:aen[FS]T5F34:01:h01[FS]T9F02:06:h000000000100[FS]T9F03:06:h000000000000[FS]T9F06:07:hA0000000031010[FS]T9F09:02:h0096[FS]T9F10:07:h06010A03A00000[FS]T9F1A:02:h0840[FS]T9F1B:04:h00002710[FS]T9F1E:08:aHD829641[FS]T9F21:03:h144744[FS]T9F26:08:h7E8A27207F7F4878[FS]T9F27:01:h80[FS]T9F33:03:hE0F8C8[FS]T9F34:03:h1F0302[FS]T9F35:01:h22[FS]T9F36:02:h0050[FS]T9F37:04:h6CA33EC8[FS]T9F39:01:h07[FS]T9F40:05:hF800F0A001[FS]T9F41:04:h00000003[FS]T9F6E:04:h20700000[FS]TDF03:05:hDC4000A800[FS]TDF04:05:h0010000000[FS]TDF05:05:hDC4004F800[FS]D1002:01:a0[FS]D1003:01:aD[FS]D1005:02:a00[FS]D100E:02:aen[FS]D100F:01:a0[FS]D1012:02:a03[FS]D1013:01:aE[FS]D101B:01:a0[FS]D101C:01:a1[FS]D101D:01:a0[FS]D9000:01:aB[FS]D9001:01:aD[FS]DFF1F:5D:a476173001116124122010001BFF0000055200000000020114376357227958483179D1988942137303017523400000[FS]DFF25:02:a02[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 ARC Device TLV Tags

After an Ingenico ARC 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 ARC 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 5D hexadecimal or 93 in decimal. Once you discard the a marker, grab the next 93 characters and use that in your API call to the Parser. The TFF1F value from our example:

The Track 2 FF1F encrypted data example:

476173001116124122010001BFF0000055200000000090114373635264059659101D3982837520375416790800000

[STX]87.0[FS]476173001116124122010000 1BFF0000055200000000090114373635264059659101D39828375203754167908[ETX][LRC]

This data is parsed as follows: