How the fingerprint reader works in the ISO8583 payments simulator

Posted on 20th Oct 2018 4064 views

In the simplest form, the fingerprint reader will be called to read a fingerprint when you use the keyword **FINGERREADER** in the field where you want the fingerprint data to be populated.

But let us start from the beginning.

A fingerprint verification is done by checking 2 fingerprints: the capture fingerprint is verified against the enrolled fingerprint. This means that in order to do this, you need to start with enrolling a fingerprint.

1. Enroll fingerprint

The Issuer must have a fingerprint enrolled in order to be able to verify a fingerprint. In the ISO8583 payments simulator this is done by calling function "performFingerPrintVerification()" which will do two things: enroll a finger and verify a finger.

The Enroll will ask you to put your finger 5 times on the reader so it can capture as much information as possible about your fingerprint. The more detailed this is, the more likely it is to get a match when you verify.

The Verify in this step is just to make sure that everything works correctly and in case of a verification, we are successful.

The result of the enrollment is showed in the console as a hashed fingerprint, as a string. This is the Enrollment fingerprint.

2. Save fingerprint

The Issuer must possess the enrolled fingerprint if it needs to be able to perform a verification. In order to do this, in a testing situation, we simply copy the Enrolled fingerprint from the console, and we save it in the card details sheet.

In the Issuer Payments simulator we can simply paste this value next to the card ID/number that we want to have this fingerprint enrolled. In case of an authorization system, we place this in the card record, in the database.

3. Capture fingerprint

The Acquirer must be able to capture a fingerprint in order to send it to the Issuer for verification.

The keyword **FINGERREADER** must be placed the ISO8583 field where we want the fingerprint to be loaded. In this case 113. That is it.

When the simulator will start building the fields, it will find this keyword, will call the core to get a fingerprint from the user, the core will activate the reader, capture a fingerprint (correctly), store it in the field, and continue to build the message.

4. Verify fingerprint

The Issuer has the capability to verify the received fingerprint in DE113.

When the message contains a value in field 113, the Issuer starts to perform the verification. First, it looks up the fingerprint in the card row or record. If the row has **NOVALUE** then it just writes that fingerprint verification cannot be performed. 

If it does find a fingerprint in the card row/record, then it performs a comparison between the received value and the stored value, automatically.