Need help to use JPOS for ISO 8583

[shashi...@gmail.com]

Hi,

As part of e-commerce application development, we are using latest JPOS in order to pack and unpack ISO 8583 message to communicate with third party system  to use e-gift card as payment.

We used Data Elements(DE) 2,3,4,11 and the sample data is as follows.

----ISO MESSAGE-----

  MTI : 0300

    Field-2 : 123456789

    Field-3 : 910000

    Field-4 : 185.15

    Field-11 : 091212

--------------------

Packed Message:

0300702000000000000009123456789910000000000185.15091212

Red Font -- Bit Map

1. We understand that Bit Map is in Hexadecimal format and the portion out of bit map- 702000000000   when it gets converted to Binary (011100000010000000000000000000000000000000000000) indicates that DE 2,3,4,11 are used in the packed message. But we are not able to understand the Bit map portion which is in red color with yellow background- 000009 .
   
2. JPOS has functionality to pad zeros(In the above packed message we have not seen zero padding). We are not sure how to use this functionality. Any Example would be great.
   
3. We are using basic.xml  with schema found in  http://jimmod.com/blog/2011/07/jimmys-blog-iso-8583-tutorial-build-and-parse-iso-message-using-jpos-library/  as a sample xml which has all the 128 elements defined in it.  Please let us know if this is sufficient or do we need have our own xml with schema.

Thanks & Regards,

Shashi.

[Sumeet Phadnis]

Hi,

The bitmap is 7020000000000000, 8 bytes in ASCII. 09 is the length of field 2 (IFA_LLNUM => 2 bytes length indicator).

As you see, padding is there for field 4. Fields 3 and 11 already have data that fills up the defined width, 6 each.

Field 0 = 0300
BITMAP = 7020000000000000
Field 2 = 09123456789
Field 3 = 910000
Field 4 = 000000185.15
Field 11 = 091212

Usually amount in ISO8583 is sent in minor currency, without the decimal point. You may want to check your specs for that.

Regards

--
--
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 "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Salter]

On Tuesday, September 10, 2013 8:33:55 AM UTC+1, shashi...@gmail.com wrote:

We used Data Elements(DE) 2,3,4,11 and the sample data is as follows.

----ISO MESSAGE-----

  MTI : 0300

    Field-2 : 123456789

    Field-3 : 910000

    Field-4 : 185.15

    Field-11 : 091212

--------------------

Packed Message:

0300702000000000000009123456789910000000000185.15091212

Red Font -- Bit Map

1. We understand that Bit Map is in Hexadecimal format and the portion out of bit map- 702000000000   when it gets converted to Binary (011100000010000000000000000000000000000000000000) indicates that DE 2,3,4,11 are used in the packed message. But we are not able to understand the Bit map portion which is in red color with yellow background- 000009 .
   

No, not really, the bitmap is more likely  7020000000000000, with the 09 that follows this being the length of the data in the first field.

1. JPOS has functionality to pad zeros(In the above packed message we have not seen zero padding). We are not sure how to use this functionality. Any Example would be great.
   

Just define a fixed length field with padding on and put less that the max length into the field - padding will ensue (at pack time).

1. We are using basic.xml  with schema found in  http://jimmod.com/blog/2011/07/jimmys-blog-iso-8583-tutorial-build-and-parse-iso-message-using-jpos-library/  as a sample xml which has all the 128 elements defined in it.  Please let us know if this is sufficient or do we need have our own xml with schema.

You will probably need your own, *unless* this example is for the same system/interface you want to communicate with.

Sorry for breaking the numbering of your items, this browser based editor is broken.

Also check your license needs for what appears to be a commercial use of jPOS.

--
Mark

[Mark Salter]

PS, you possibly have your own example of a field being padded - how are you setting/using field 4?

[shashi...@gmail.com]

Thank you so much for your kind response.Its very informative. 

I still have doubt on padding. I do agree that Field-4 has zero padding. But when i tested for Field-2 , its not getting padded with zero.

Requirement says that : Primary Account Number    V1/1B+…19, 4-bit BCD/11B. 

That mean Field-2 has max length of 19  and if its less than 19, it should be  zero padded.

In the example i specified,   Field-2 : 123456789   had the data of length 7 and the result would be Field 2 = 09123456789( as per the info provided by you) . 

There is no zero padding for this field. Do we need to customize it ?

Thanks,

Shashi

[Mark Salter]

On Tuesday, September 10, 2013 12:57:38 PM UTC+1, shashi...@gmail.com wrote:

Thank you so much for your kind response.Its very informative. 

I still have doubt on padding. I do agree that Field-4 has zero padding. But when i tested for Field-2 , its not getting padded with zero.

Field 2 has a component that gives the length of the value present?  This sort of does away with padding, although the recipient could align and pad as they need.

Requirement says that : Primary Account Number    V1/1B+…19, 4-bit BCD/11B. 

That mean Field-2 has max length of 19  and if its less than 19, it should be  zero padded.

Not as a variable length field.
 

In the example i specified,   Field-2 : 123456789   had the data of length 7

I count 9?
 

and the result would be Field 2 = 09123456789( as per the info provided by you) . 

Yep, 9 it is.

Perhaps you are thinking that the length include the length of the length?

There is no zero padding for this field. Do we need to customize it ?

If you want a fixed field, that is padded, then you will need to change the field definition to another one IFA_CHAR perhaps (just guessing as you have not shared your need just yet)

--
Mark

[shashi...@gmail.com]

On Tuesday, September 10, 2013 5:36:51 PM UTC+5:30, Mark Salter wrote:

On Tuesday, September 10, 2013 12:57:38 PM UTC+1, shashi...@gmail.com wrote:

Thank you so much for your kind response.Its very informative. 

I still have doubt on padding. I do agree that Field-4 has zero padding. But when i tested for Field-2 , its not getting padded with zero.

Field 2 has a component that gives the length of the value present?  This sort of does away with padding, although the recipient could align and pad as they need.

Requirement says that : Primary Account Number    V1/1B+…19, 4-bit BCD/11B. 

That mean Field-2 has max length of 19  and if its less than 19, it should be  zero padded.

Not as a variable length field.
 

In the example i specified,   Field-2 : 123456789   had the data of length 7

I count 9?
 

and the result would be Field 2 = 09123456789( as per the info provided by you) . 

Yep, 9 it is.

Perhaps you are thinking that the length include the length of the length?  

No. I just considered the raw data excluding the length of Field-2.  Its 1B+19 BCD.

 

There is no zero padding for this field. Do we need to customize it ?

If you want a fixed field, that is padded, then you will need to change the field definition to another one IFA_CHAR perhaps (just guessing as you have not shared your need just yet)

     you mean padding is for Fixed field only?  The requirement says that,

Field Type :Numeric V1 (variable length)

Data Format :1B, binary + up to 19 N, 4-bit BCD (unsigned packed)

Field Padding :Pad to the left (left-zero-filled)

--
Mark

[Sumeet Phadnis]

Padding will be applied only when the field is defined as a fixed length field. If you need padding for field 2, you will need to change the packager definition like below:

Current definition:

<isofield id="2" length="19" name="PAN - PRIMARY ACCOUNT NUMBER" class="org.jpos.iso.IFA_LLNUM"/>

Change it to:

<isofield id="2" length="19" name="PAN - PRIMARY ACCOUNT NUMBER" class="org.jpos.iso.IFA_NUMERIC"/>

This will drop the 2 byte length indicator and left pad the field with zeros. Also, if you need BCD packaging you should use IFB_NUMERIC.

It is bit weird for PAN to be zero padded, unless the field is used for some other purpose. Switch would typically decide the authorization end point based on card number and the left padding will distort it.

Regards

[shashi...@gmail.com]

By every reply i'm got to know few more extra points. I wasn't even aware of that we should be using IFB_NUMERIC for BCD packaging. Our project is still in analysis phase  hence we have no document on JPOS to understand what to be used.

Thanks a lot..

Shashi

[Mark Salter]

On Thursday, September 12, 2013 8:34:02 AM UTC+1, shashi...@gmail.com wrote:

 hence we have no document on JPOS to understand what to be used.

Sorry - can you explain why that is?

http://jpos.org/

Would be an excellent place to start in your documentation search.

Although it is much easier to ask than purchase and read.

:-(

--
Mark

[chhil]

There are 3 options as I see it

1. This mailing list has a lot of answers. Including pointers to the free PDFs that will surely help you.
2. The source code and test cases are available, get busy.
3. Buy the programmers guide, its money well spent to get you up and running quickly.

I am not aware of any other open framework out their that I would choose for production releases (even the closed source expensive ones are below par) :-)

-chhil

[Andy Orrock]

"Our project is still in analysis phase hence we have no document on JPOS to understand what to be used."

So many punchlines.

Andy

--

[shashi...@gmail.com]

Yes. I do agree that mailing list helps a lot and we are using the available source code  to pack and unpack the data to understand the basics.

We have packed request and response message with us. We are trying to use it as is with JPOS. Please help me to work around this.

Issuing card 6006491286999941570 for $25.00 with PIN 4884 and sending track 2 data also.

Assumptions:2 byte header

Complete request message in hex:  (This sample msg is sent by our client for our understanding)

005c03007038000120C0900013060064912869999415709100000000000025001008521008520807060612862306006491286999941000D181211048628335303030313233343539393939393939393939393939393908403030303034383834

005c - Header, length of message not including length of header

We understand MTI and BIT Map and also Data Elements(DE). The last 3 DE are encoded (These are ANS with Fixed field length) .Say for example PIN 4884 ==>00004884 encoded as 3030303034383834.

Also the above message has length indicator in Hexa and  If the DE has odd number of digits, a leading zero is  padded the first unused half-byte of data.

But when i used the raw data with JPOS  to pack the message, it appeared little different.

03007038000120C090001960064912869999415709100000000000025001008521008520807060612863606006491286999941000D1812110486283350001234599999999999999984000004884

Here are my observations:

 - Length indicator is not getting converted to Hexa

 -  leading zero is not padded to first unused half-byte of data when DE has odd number of digits

 - Encoding is not happening

How can we achieve this with JPOS. 

Thanks

Shashi

[Sumeet Phadnis]

Yes. I do agree that mailing list helps a lot and we are using the available source code  to pack and unpack the data to understand the basics.

Please buy the programmer's guide if you plan to use jPOS. As Chhil said, it is more than worth it. You will save lot of time (time == money).

We have packed request and response message with us. We are trying to use it as is with JPOS. Please help me to work around this.

Issuing card 6006491286999941570 for $25.00 with PIN 4884 and sending track 2 data also.

Assumptions:2 byte header

Assumptions?? Pls don't. They are the cause of most problems. Also please do not share any real card data here (or anywhere). It is taken extremely seriously in payments industry.

Complete request message in hex:  (This sample msg is sent by our client for our understanding)

005c03007038000120C0900013060064912869999415709100000000000025001008521008520807060612862306006491286999941000D181211048628335303030313233343539393939393939393939393939393908403030303034383834

More importantly you need to have the message specification from the client. Based on that you can choose / configure your channel and packager. Then the sample message should be used to test it, first by unpacking. It will tell you if you are able to see all the fields exactly as the client wanted you to. Then you can simply build an ISOMsg, set its fields and send over the channel you tested. You can enable packager-logger to get detailed log of packing/unpacking operations. 

 

005c - Header, length of message not including length of header

We understand MTI and BIT Map and also Data Elements(DE). The last 3 DE are encoded (These are ANS with Fixed field length) .Say for example PIN 4884 ==>00004884 encoded as 3030303034383834.

Also the above message has length indicator in Hexa and  If the DE has odd number of digits, a leading zero is  padded the first unused half-byte of data.

God save your client if they expect the PIN to be sent in clear. How about some googling for pinblock formation and encryption?

 

Regards

[Mark Salter]

On Friday, September 13, 2013 7:56:50 AM UTC+1, shashi...@gmail.com wrote:

Complete request message in hex:  (This sample msg is sent by our client for our understanding)

005c03007038000120C0900013060064912869999415709100000000000025001008521008520807060612862306006491286999941000D181211048628335303030313233343539393939393939393939393939393908403030303034383834

As this is provided in hex, you need to bear in mind that this representation of their test message indicates that some fields are binary and some are character (ASCII)

005c - Header, length of message not including length of header

We understand MTI and BIT Map and also Data Elements(DE). The last 3 DE are encoded (These are ANS with Fixed field length) .Say for example PIN 4884 ==>00004884 encoded as 3030303034383834.

As Sumeet says, good luck with a clear PIN, that just isn't acceptable anywhere other than the cardholders mind :-)

Also the above message has length indicator in Hexa and  If the DE has odd number of digits, a leading zero is  padded the first unused half-byte of data.

But when i used the raw data with JPOS  to pack the message, it appeared little different.

03007038000120C090001960064912869999415709100000000000025001008521008520807060612863606006491286999941000D1812110486283350001234599999999999999984000004884

The 'raw' data - how captured?  By printing out the result of a ISOMsg.pack()?

If so, then your fields are all character and you need to acurratly match the Packager you are using to the specification first.

Do this now, don;t do anything else - other than as the client for their specification.

 

Here are my observations:

 - Length indicator is not getting converted to Hexa

More it is not present.  This is because a jPOS Channel adds the length for the trip across the network, which suggests it is yet to be added and your capture of the 'raw' it not really.

 -  leading zero is not padded to first unused half-byte of data when DE has odd number of digits

My hint about binary above is key here ...

... which DE are you talking about?

If it is one of the binary ones, then of course unless your field is packing to binary, then it won't need to make sure whole bytes are filled?
I think you are using character fields throughout, but this will depend on your answer of which DE.

If it is a ASCII one, then you can add as many padding characters to you data as you like - even in a variable length field :-)

 - Encoding is not happening

As above, the capture points are probably not equivalent, the presentation is different too, you are comparing apples to wingnuts.

Get the message or interface specification, carefully select a Packager and make sure the two items match;  this is a one off exercise if done carefully and correctly (until the specification changes at least).

How can we achieve this with JPOS. 

Can you also please start a new thread for each 'problem' please?

Oh and whilst your company considers using jPOS, check the license under which you plan to operate too.

--
Mark

[chhil]

I would start of as follows

String hex="005c03007038000120C0900013060064912869999415709100000000000025001008521008520807060612862306006491286999941000D181211048628335303030313233343539393939393939393939393939393908403030303034383834";


byte[] dump= ISOUtil.hex2byte(hex);
System.out.println(ISOUtil.hexdump(dump));


0000  00 5C 03 00 70 38 00 01  20 C0 90 00 13 06 00 64  .\..p8.. ......d
0010  91 28 69 99 94 15 70 91  00 00 00 00 00 00 25 00  .(i...p.......%.
0020  10 08 52 10 08 52 08 07  06 06 12 86 23 06 00 64  ..R..R......#..d
0030  91 28 69 99 94 10 00 D1  81 21 10 48 62 83 35 30  .(i......!.Hb.50
0040  30 30 31 32 33 34 35 39  39 39 39 39 39 39 39 39  0012345999999999
0050  39 39 39 39 39 39 08 40  30 30 30 30 34 38 38 34  999999.@00004884

I would use the byte array and pass it to a ISOMsg for unpacking (assuming you have tweaked a packager to your needs and added loggers to get you a detailed output).

Search for examples in the group for setting up packager and loggers.

-chhil

--

[Mark Salter]

On Friday, September 13, 2013 11:32:12 AM UTC+1, chhil wrote:

I would use the byte array and pass it to a ISOMsg for unpacking (assuming you have tweaked a packager to your needs and added loggers to get you a detailed output).

Don't forget to drop the length bytes before unpack'ing, since in jPOS the Channel will have taken care of these two bytes ( x'005c').

:-)

[Troas Lutterodt]

Hi,
My name is Fredrick. I have checked Pablo's blog found in  http://jimmod.com/blog/2011/07/jimmys-blog-iso-8583-tutorial-build-and-parse-iso-message-using-jpos-library/. I have successfully implemented the project as a java application.

Right now, I want to convert the system into a web service that can take a string input and parse it. Can someone kindly help me. Am using netbeans 7.4.

Thank you.

[vijay kumar]

If you want an webseervice to be deployed then you simply expose an interface and annotate with @webmethod and can create an implementatin class which annotates as @webervice and write your parsing logic there

--

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

Join us in IRC at http://webchat.freenode.net/?channels=jpos

 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
---
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/2b0911c0-0d28-4966-94b6-d75dc742a5d6%40googlegroups.com.