we have in our case an ATM switch that is connected to Payment network (e.g, VISA) on one hand and Issuer on another hand. while firing a transaction(transaction flow :acquirer bank-->Payment network-->ATM switch-->Issuer),the transaction failed with error "PIN block translation failed" at switch side. What could be a reason for such error, noting that the check value of ZPK at both sides(Payment network and ATM switch) is found to be the same ?
3 Answers
There may be several reasons when ZPK is the same and there is encryption issue:
- Different PINblock format
Although it is not that common, but still, you might want to verify that on both ends you have same format (some are padded with 'F', some are xored with PAN).
- You may have incorrect PAN
Account number is necessary for many PINblock formats, translation may not succeed when account number is different, you may check if there are PAN mapping/translations/tokenizations in place.
- Account number format
i.e. when you use ISO9564 format 0 PINblock you don't use the whole PAN for PIN Block generation, but only 12 rightmost digits without the Luhn check digit - with some cards you may have a surprise is the check digit included or not.
- Some other issue, but it's hard to say without any test data.

- 1,197
- 8
- 16
-
i checked and it is the same block format used at both sides of the switch and payment network – Bassem Abd Elmaksoud Feb 05 '19 at 09:25
Is it just with Visa you have this issue ? By this I mean to ask, for other payment schemes it is working ? If it is working then you can rule out the chance of terminal PIN key mismatch with switch.
Now you you can start looking at PIN block generation part. During FIT download, you mention for each bin range how it has to be. Compare it with expected values. Mostly used is format 0, but double confirm your case.
Lastly, during translation you specify source pin block format and destination PIN block format. Verify that is as expected.

- 2,133
- 1
- 13
- 18
-
the acquirer bank in our case is different from the switch bank. – Bassem Abd Elmaksoud Feb 02 '19 at 12:07
-
the acquirer bank in our case is different from the switch bank where translation failed. the Flow : ATM--> Acquirer bank switch --> Payment network--> our bank switch --> issuer. In this case, i guess there is no issue with TPK as pin block is translated normally at acquirer bank side and forwarded towards Payment network,but the translation failed at our bank switch side; as we are unable to forward it to the issuer. – Bassem Abd Elmaksoud Feb 02 '19 at 12:32
-
-
Are you able to simulate it in your test environment. If so can you update the logs from both the switches and update your original question. Try to use a test card so that you can upload unmasked logs. – Adarsh Nanu Feb 02 '19 at 15:31
-
the transaction is forwarded successfully towards issuer in test environment, the issue occurs when we move to production environment – Bassem Abd Elmaksoud Feb 05 '19 at 09:23
-
Quite honestly, when the issue does not appear in test and can be reproduced in production, the issue is almost every time that one side is using different key than they think they are using (maybe it was imported incorrectly on one side?). Are you sure that both source and destination ZPK are encrypted under the right LMK? – Michal Gluchowski Feb 05 '19 at 18:01
-
can you clarify what do you mean with "the right LMK", do you mean that the keys is imported on an HSM rather than production HSM ? – Bassem Abd Elmaksoud Feb 06 '19 at 08:19
If you have the clear ZPK(zonal pin key) decrypt the pinblock using TripleDES algorithm. If the decrypted pinblock does not start with character '0' or '1' then you are using wrong key for translation. If you give more details like HSM response code of failure, more specific reason can be found out.
If you don't want to try manually use https://www.eftlab.com/bp-tools/

- 425
- 4
- 14