Posted on 20th Oct 2018 2378 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.
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.
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.
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.
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.
Run the neaPay ISO8583 simulator 9544 views
Log Files in BASE24 classic 3831 views
BASE24 classic interview questions 3409 views
BASE24 documentation to read 3374 views
BASE24 classic vs BASE24-eps 3334 views
BASE24 classic screens examples explained 2605 views
Enabling traces in the payments simulator 2306 views
EMV explained for programmers 2305 views
BASE24-eps interview questions 2255 views
Cards and Banks Training 2084 views
Working with Base24-eps vs BASE24 Classic 1298 views
BASE24 classic routing in IDF 1139 views
First steps with BASE24 Classic 965 views
Ready to start your next project with us? Give us a call or send us an email and we will get back to you as soon as possible!