Ingenico RBA 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 device is shipped with on-board software called Retail Base Application (RBA). RBA versions 12.02 and higher support 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 to extract the P2PE data from RBA payloads for processing on Decryptx. As RBA is standardized across all Ingenico devices, the steps outlined below should work on all RBA devices. At Bluefin, we have integrated and verified the following Ingenico RBA series devices:

  • Ingenico iPP 320
  • Ingenico iPP 350
  • Ingenico iSC 250
  • Ingenico iSC Touch 250
  • Ingenico iSC Touch 480

Obtaining the Payload

Typically, RBA 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 RBA 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 an RBA command to a connected device. To capture P2PE data you need two RBA 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]RBA 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 digits 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 Track 2 service code.
21-219Track 2 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-641RBA adds this leading digit to make output to pass MOD 10 check.
65-96089645...040678The Track 2 encrypted card data.

๐Ÿ“˜

How does RBA encrypt swiped card data?

To help you understand how to prepare Ingenico payload data for processing on Decryptx, you need to know how RBA 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 RBA 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 RBA'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 first. The following is the ASCII version:

1249399999999902212101123456789

This data is parsed as follows:

To help you understand how to prepare an Ingenico payload data for processing on Decryptx, you need to know how RBA 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 RBA 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)`.

Keyed Payloads

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

[STX]87.0[FS]4124939990161221200001BFFFF99999900F660000A011425M2615003155099705=04025513293F5249D4B0B1BAAD4DFA43528271D4164B3F1532E3FDA2271FB52CA770C5068FD196D644CB1604054AF45E995CA58149F0[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 digits 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-20000Clear value of Track 2 service code.
21-210Track 2 language indicator.
22-221Card data encrypted flag: 0=clear ASCII data; 1=encrypted ASCII data.
23-23BEncrypted format type: B=OnGuard (or IngeCrypt).
24-43FFFF99...60000A10 bytes of Key Sequence Number in hex.
44-470114Custom field of KSN.
48-4925Decimal length of encrypted card data.
50-50MIndicator that the payload was manually entered.
51-512RBA adds this leading digit to make output to pass MOD 10 check.
52-74615003...402551The Track 2 encrypted card data.

๐Ÿ“˜

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.

๐Ÿ“˜

How does RBA encrypt keyed card data?

RBA 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. RBA 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 to 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:

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 RBA 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

The following outlines how to extract the P2PE data from an RBA EMV payload.

[STX]87.0[FS]476173001016118122019001BFFFF99999901238000350114341438585185678075=015537112599878533221BEA3C5443CFA32650E51470C051A0E96C88BAF5E59658848430E5DF910E0ED31CE0B46BDC26A5773A0866F85B037F4B3FCCD36D8FBA31C3A5589EB88A3901D688[ETX][LRC]

This data is parsed as follows:

CharsValueDescription
1-6476173Clear value of first 6 digits of PAN (card number).
7-100010Clear value of last 4 digits of PAN.
11-1216Decimal length of PAN.
13-131MOD 10 check flag: 0=PAN failed MOD 10 check;1=PAN passed MOD 10
14-171812Clear value of PAN expiration date (YYMM).
18-20201Clear value of Track 2 service code.
21-219Track 2 language indicator.
22-2300Decimal length of cardholder name.
24-241Card data encrypted flag: 0=clear ASCII data; 1=encrypted ASCII data.
25-25BEncrypted format type: B=OnGuard (or IngeCrypt).
26-45FFFF99...80003510 bytes of Key Sequence Number in hex.
46-490114Custom field of KSN.
50-5134Decimal length of encrypted card data.
52-521RBA adds this leading digit to make output to pass MOD 10 check.
53-85438585...987853The encrypted card data.

๐Ÿ“˜

How do you differentiate EMV payloads from others?

Payloads that contain EMV data will have a cardholder name length of 00.


Did this page help you?