How to Pack F55 into a BCD format to Host Processor

[Chinwendu Ochonma]

I've been struggling with this now, I want to transmit ICC Data below to the host in BCD format, but I keep getting "F55 has invalid value" from the host, could someone help me out

The host says it expects in this format    b..255 (LLLVAR)

Received ICC data from POS device

9F2608E86510AD990250489F2701809F10120110A080002A0000138600000000000000FF9F3704597656F69F36021118950500802488009A032207089C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100

Here is what am doing currently

String F55=incomingMsg.getString(55);
tic.set(55, ISOUtil.hex2byte(F55));

<isofield id="55" length="255" name="RESERVED ISO" class="org.jpos.iso.IFA_LLLBINARY" />

The host documentation is stated below
Field format is identical to that of the field 55 in Master Card.
See documentation
EMV2000
Interrated Circuit Card Specification for Payment System
Book 3
Application Specification
Annex C
Coding of Data Elements used in the Transaction Processing.
Tag 9F36 (Application Transaction Counter) is an exception. Its value is transmitted in the BCD format for the protocol version 07 and previous versions.
Tags 95, 9F10, 9F5B can be transferred in the 420 message.

I have also attached my xml packager, please what could I be doing wrongly.

[Alejandro Revilla]

You can’t transmit binary data in BCD fields. 

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/60d2c9ca-2e9e-4149-9406-9b71d6c0eb21n%40googlegroups.com.

--

--

@apr

[Chinwendu Ochonma]

Hi Alejandro,

If you don't mind, please could you explain further, at the moment,  I need sufficient information to help me navigate out of this challenge?

[Mark Salter]

Hi.

You need to read that spec more carefully as to what values are in BCD.

Your target admins or support staff will be able to tell you what they think is wrong with your F55 to them, we can't with the detail shared, ask them.is the length format even right for them, or is it the content they reject at what tag?

Does your data hold the special tag 9f36 when you send it to them? Is the message you are send long version 7 or less?

--
Mark




Sent from ProtonMail mobile



-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/c975775e-638f-4771-9183-c8427b230533n%40googlegroups.com.

[Rakesh Shetty]

Hi, 

Ideally ICC data represents in HEX format ,since BCD representation is different format itself . As per your statement the F55 didn't read because data representation (format ) was mismatched itseems.

Pack the data in hex format and send it your switch , later as per their specs it has to send to end host.

Thanks,

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/k1Tb3laa91UWVULQrM7z_6EYFW1WW3jB-uahHU5DGX4OqH8nyQDJCveJAjLYiRnMwwHwCqea-HPwhL9d5E43HxaIi_k7Z0Uh-CR6uQzXZvw%3D%40pm.me.

[igor skljar]

Hi

If you talk about TIC try to use tic.set(55, F55);

ISOUtil.hex2byte(F55) you will need with TITP...

суббота, 9 июля 2022 г. в 14:51:21 UTC+3, chinwend...@gmail.com:

[igor skljar]

although not, ISOUtil.hex2byte() need to be used with TIC also

суббота, 9 июля 2022 г. в 20:32:35 UTC+3, igor skljar:

[igor skljar]

msg.set(55, ISOUtil.hex2byte("9F2608E86510AD990250489F2701809F10120110A080002A0000138600000000000000FF9F3704597656F69F36021118950500802488009A032207089C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100"));

with

<isofield
id="55"
length="255"

name="ICC SYSTEM RELATED DATA"

class="org.jpos.iso.IFA_LLLBINARY"/>

was correctly identified by host interface

F55.9f26)E86510AD99025048�F55.9f27)128�F55.9f10)0110A080002A0000138600000000000000FF�F55.9f37)597656F6�F55.9f36)1118�F55.95)0080248800�F55.9a)220708�F55.9c)00�F55.9f02)000000001000�F55.5f2a)0566�F55.82)14336�F55.9f1a)0566�F55.9f34)420300�F55.9f33)14743752�F55.9f35)22�F55.9f1e)00000001�F55.84)A0000000041010�F55.9f09)0004�F55.9f03)000000000000�F55.5f34)00��

суббота, 9 июля 2022 г. в 20:58:12 UTC+3, igor skljar:

[Chinwendu Ochonma]

Hello Igor,

Thanks for the feedback, I executed as advised, however the request was rejected with the response below, any idea what this suggest, my colleague on the switch are not available at this time ?

A4M041039200F238468128A0920000000000020200A0165395860157801837001000000000000050007092131052131052131050709599905100000006545361375395860157801837=22102211124075800000220709213105082UP10255UNIFIED PAYMENTS SER          LA                            000566SO                            SO                            SO                            00220220709null2UP12UP1LA000000159          0000000000000000      566EEC66C4F15465CD1140Ÿ& �Šuð9£• Ÿ' €Ÿ  €À€*À€À€q À€À€À€À€À€À€À€Ã¿Å¸7 8_— Ÿ6 )• À€â‚¬$ˆÀ€Å¡ "    Å“ À€Å¸ À€À€À€À€ À€_* f‚ 8À€Å¸ fŸ4 B À€Å¸3 àøÈŸ5 "Ÿ 00000001„  À€À€À€ Ÿ     À€ Ÿ À€À€À€À€À€À€_4 À€088700150116Acct=0905587572222070921310606900000000000000000000000000000000008FN2=VALU

[igor skljar]

A4M04103 tells you that something wrong with 103 field.

суббота, 9 июля 2022 г. в 23:53:48 UTC+3, chinwend...@gmail.com:

[Mark Salter]

Perhaps read the documentation whilst you wait for them to start working.

--
Mark


Sent from ProtonMail mobile



-------- Original Message --------

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/06e7ad81-3c98-4c09-b92f-ba1471a46018n%40googlegroups.com.

[igor skljar]

BTW
<isofield id="0" length="12" name="MESSAGE TYPE INDICATOR" class="org.jpos.iso.IFA_NUMERIC"/> from your tranzware.xml.
i believe length must be 4

воскресенье, 10 июля 2022 г. в 00:25:06 UTC+3, igor skljar:

[Mark Salter]

I would guess a header is being included in the mti instead of as a header.
Unfortunately I suspect a user is urgently rushing and not reading much documentation.

Sent from ProtonMail mobile



-------- Original Message --------

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/1a14ab85-7737-4f83-828f-338e9bab7d83n%40googlegroups.com.

[Chinwendu Ochonma]

Thank you all for the feedback so far, I contacted my back-office team.

At the moment, the message is not rejected, I got response, but TIC interface complain of "Field 55 has invalid value", any idea on what it is could be done further ?

Here is my request to TIC

A4M0800002007238468128A09200165395860157801837001000000000000100007101612081612081612080710599905100000006545361375395860157801837=22102211124075800000220710161208082UP10255UNIFIED PAYMENTS SER          LA                            000566SO                            SO                            SO                            00220220710null2UP12UP1LA000000159          0000000000000000      566EEC66C4F15465CD1140Ÿ& å»Ùïìܾ0Ÿ' €Ÿ  € *  „x       ÿŸ7 I?&ôŸ6 6• €$ˆ š " œ Ÿ     _* f‚ 8 Ÿ fŸ4 B Ÿ3 àøÈŸ5 "Ÿ 00000001„     Ÿ     Ÿ      _4

ICCDATA

9F2608E5BBD9EFECDCBE309F2701809F10120110A080002A0000847800000000000000FF9F3704498126F49F36021136950500802488009A032207109C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100

TIC LOG

16:12:10.664 >In A4M0800002007238468128A0920016539586******183700100000000000010000710161208161208161208071059990510000000654536137539586******1837=2210221*************220710161208082UP10255UNIFIED PAYMENTS SER          LA                            000566SO                            SO                            SO                            00220220710null2UP12UP1LA000000159          0000000000000000      566FFFFFFFFFFFFFFFF140┼*******************************************************************************************************************************************

16:12:10.782 <Out A4M040000210B22002012A9080080000000010400000001000000000000100007101612081612080000654536137539586******1837=2210221*************22071016120800074082UP10255  566VALUValuCard  064243670000000000000000000000000000000000000000000000

TRACE

16:12:10.664 inp>> 200: H1)A4M▌H2)08▌H3)000▌F2)539586******1837▌F3.1)001│F3.2)00│F3.3)00│▌F4)000000001000▌F7)0710161208▌F11)161208▌F12)161208▌F13)0710▌F18)5999▌F22)051▌F23)000▌F25)000▌F32)545361▌F35)539586******1837=2210221*************▌F37)220710161208▌F41)2UP10255▌F43.1)UNIFIED PAYMENTS SER          │F43.2)LA                            │F43.3)000│F43.4)566│F43.5)SO                            │F43.6)SO                            │F43.7)SO                            │F43.8)002│F43.9)20220710│F43.10)null2UP12U│F43.11)P1LA│F43.12)000000159          000000│F43.13)000│F43.14)0000000  │F43.15)    │▌F49)566▌F52)FFFFFFFFFFFFFFFF▌F55)313430C52A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A▌
# 16:12:10.665 Field 55 has invalid value

  16:12:10.666 Authorisation request received, RRN=220710161208
  16:12:10.703 Checking Acquiring Transaction Control rules.
  16:12:10.704 Rule #18 (any acquirer object and any issuer object).
  16:12:10.705 Calling external host incoming message control functions, tran. id=4434615
  16:12:10.706 Function #428349 was completed in 0.000 sec
  16:12:10.716 Transaction #4434615 is sent to authorizer host #957
  16:12:10.783 out<< 210: H1)A4M▌H2)04▌H3)000▌F3.1)001│F3.2)00│F3.3)00│▌F4)000000001000▌F7)0710161208▌F11)161208▌F23)000▌F32)545361▌F35)539586******1837=2210221*************▌F37)220710161208▌F39)00074▌F41)2UP10255▌F44.1) │F44.2) │▌F49)566▌F61.1)VALU│F61.2)ValuCard  │▌F100)424367▌F106.1)000│F106.2)000│F106.3)000000000000│F106.4)000000000000│F106.5)00000000│F106.6)00000000│▌
  16:12:10.787 Response to inbound request sent, tran. id=220710161208

[Mark Salter]

In the trace you provided I can see :-

tF55)313430C52A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A

Doesn't look like right does it.

How did that value get to the system logging it? Is it from another field?
Have you checked all fields are defined correctly on your side to fully match the target specification?

I would check your setup against what they specify the fields should look field by field carefully up to and including f55 which yo should have done already, but check again.

They might be able to help also, but you are not sharing enough explicit and specific detail for us to help you.

Sent from ProtonMail mobile

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/17dcc46a-11b0-47ea-bd5a-84ed52a7f879n%40googlegroups.com.

[igor skljar]

main question is how

9F2608E5BBD9EFECDCBE309F2701809F10120110A080002A0000847800000000000000FF9F3704498126F49F36021136950500802488009A032207109C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100

became

C52A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A

?

воскресенье, 10 июля 2022 г. в 20:59:43 UTC+3, marks...@pm.me:

[Mark Salter]

The OP is not reading the manual cleanly, and passing on confusion I fear.  As BCD looks to only be applicable to ATC tag 9F36 - in that extract - if it is even relevant or accurate for the target system here though.

OP seems to need someone to help them, but no #smartquestion yet :-(

--

Mark

On 09/07/2022 13:18, Alejandro Revilla wrote:

You can’t transmit binary data in BCD fields. 

On Sat, 9 Jul 2022 at 07:51, Chinwendu Ochonma <chinwend...@gmail.com> wrote:

[snip]

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3DnHnNDh0kwAqhFAaV7hXAQkcaQzaNWPiLr3eKsaAGfiig%40mail.gmail.com.

[Mark Salter]

On 10/07/2022 20:48, igor skljar wrote:

main question is how

9F2608E5BBD9EFECDCBE309F2701809F10120110A080002A0000847800000000000000FF9F3704498126F49F36021136950500802488009A032207109C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100

became

C52A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A

?

I don't see it can have, I suspect something is misaligned badly or perhaps an incorrect length format and basic setup checking has not been done to ensure the target specification is being followed for all fields (since perhaps 52 is a PIN block and is being obscured with F's to hide it in the trace, even though It is clearly shared in the OP shared message!  Test data and keys and PAN I am sure!!)

(shrug)

Only Chinwendu has all the details need to solve this in front of him, but is rushing and not asking a smart question :-

( http://www.catb.org/~esr/faqs/smart-questions.html#translations )

with all that detail shared in it so we can see it.

--

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/58be305c-5e37-4be7-add6-6ff59e8b8459n%40googlegroups.com.

[igor skljar]

i can reproduce this

msg.set(55, ISOUtil.str2bcd("9F2608E5BBD9EFECDCBE309F2701809F10120110A080002A0000847800000000000000FF9F3704498126F49F36021136950500802488009A032207109C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100",true));

and then

<isofield
id="55"
length="255"

name="ICC SYSTEM RELATED DATA"

class="org.jpos.iso.IFA_LLLBINARY"/>

will give us

313430C52A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A▌

воскресенье, 10 июля 2022 г. в 23:03:49 UTC+3, marks...@pm.me:

[Mark Salter]

Nice, you are possible spending more time on this than the OP actually is ;-).

On 10/07/2022 21:16, igor skljar wrote:

i can reproduce this

msg.set(55, ISOUtil.str2bcd("9F2608E5BBD9EFECDCBE309F2701809F10120110A080002A0000847800000000000000FF9F3704498126F49F36021136950500802488009A032207109C01009F02060000000010005F2A020566820238009F1A0205669F34034203009F3303E0F8C89F3501229F1E0830303030303030318407A00000000410109F090200049F03060000000000005F340100",true));

will give us

313430C52A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A▌

OP never indicated this was being coded that I can see; OP is making it hard for everyone.

(Shrug again)

--

Mark

[Chinwendu Ochonma]

Thank you Mark, Igor, Alajendro, Rakesh and everyone for the support.

My issue was Resolved, and below is what I did to resolve the issue, however I needed to work with the operations team on the switch side (Tranzware), to really look into the trace to see how the ISO message is appearing on the other end in order to give a clue of what next to do.

Note: I had to go through this guide below to see how the packagers for binary packages the data before sending.. ISO8583ConfigGuide for knowledge sake

1. The packager used is <isofield id="55" length="999" name="RESERVED ISO" class="org.jpos.iso.IFA_LLLBINARY" />

2. Then the code goes  tic.set(55, ISOUtil.hex2byte(fiftyfive)); //IFA_LLLBINARY

My advice to developers is to work with the OP team to make life easy for you, because you might not know when you may have resolved the issue, because other things may make a transaction fail and not necessarily looking out for an approved transaction.

Regards

[Mark Salter]

Just to add...

On 18/07/2022 12:17, Chinwendu Ochonma wrote:

My issue was Resolved, and below is what I did to resolve the issue, however I needed to work with the operations team on the switch side (Tranzware), to really look into the trace to see how the ISO message is appearing on the other end in order to give a clue of what next to do.

You could do a network trace on your machine to see what is leaving to compare to the specification or examples.

Best though (if you can't or are not sure) is to ask the owners of the system that is requesting your request (or response if the roles are reversed) for their view.

 --

Marl