[jpos-users] Problem identifying the source of iso8583

[kelvin-19]

Hi all,

I am just using jPOS to implement my company's payment system which
need to unpack iso8583 messages from different banks. However, all
different messages would be come from the same connection(say, same
socket). So I just wonder if there is any simple way to identify which
bank the message come from so that I can apply the corresponding bank
packager for unpacking. I am new to iso8583 and payment system. Hope
you can share your experience. Thanks.

Kelvin

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Mark Salter-5]

kelvin wrote:

> I am just using jPOS to implement my company's payment system which
> need to unpack iso8583 messages from different banks. However, all
> different messages would be come from the same connection(say, same
> socket).
Is this fixed?  A dedicated port per bank would be less complicated and
would allow you greater control over access and monitoring activity?  A
*much* cleaner solution.

> So I just wonder if there is any simple way to identify which
> bank the message come from so that I can apply the corresponding bank
> packager for unpacking.

If you cannot adjust the port setup, you will need to identify the
source from indicators in the stream - at the channel level, perhaps
length formats or header content.  If some banks share the same message
structure, then the message field contents will be used.

You have the detail of the different message structures?

I think you could also get the socket from the channel and base your
packager decision upon the socket.getInetAddress().getHostAddress() value.

If possible I would tend to go for a port per connection, it allows much
greater control and independent processing for each client.

PS, make sure you take care of any commercial license obligations.


--
Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[chhil]

Is this a single connection persistent or multiple (per bank)  connections to your server or  a connection is received per request (connect disconnect model)?

Based on your model if each bank connection or you may be able to differentiate the messages based on the local port where the connection originates (as Mark has mentioned).

-chhil

On Wed, Nov 4, 2009 at 2:57 PM, Mark Salter <marksalter@...> wrote:

kelvin wrote:

> I am just using jPOS to implement my company's payment system which
> need to unpack iso8583 messages from different banks. However, all
> different messages would be come from the same connection(say, same
> socket).

Is this fixed?  A dedicated port per bank would be less complicated and
would allow you greater control over access and monitoring activity?  A
*much* cleaner solution.

> So I just wonder if there is any simple way to identify which
> bank the message come from so that I can apply the corresponding bank
> packager for unpacking.

If you cannot adjust the port setup, you will need to identify the
source from indicators in the stream - at the channel level, perhaps
length formats or header content.  If some banks share the same message
structure, then the message field contents will be used.

You have the detail of the different message structures?

I think you could also get the socket from the channel and base your
packager decision upon the socket.getInetAddress().getHostAddress() value.

If possible I would tend to go for a port per connection, it allows much
greater control and independent processing for each client.

PS, make sure you take care of any commercial license obligations.


--
Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[kelvin-19]

> Is this fixed?  A dedicated port per bank would be less complicated and
> would allow you greater control over access and monitoring activity?  A
> *much* cleaner solution.

Mark, thanks for your reply~!
I know that your solution is the simplest way to solve my problem.
However, our company's system is not directly connected to different
banks. We get the different banks' iso8583 messages from a third party
vendor through a single persistent connection(i.e all messages come
from single port) so port per connection approach would not work for
me.


> If you cannot adjust the port setup, you will need to identify the
> source from indicators in the stream - at the channel level, perhaps
> length formats or header content.  If some banks share the same message
> structure, then the message field contents will be used.

Yeah, using indicators is our current approach. However, the drawback
of this approach is that the indicators format is vendor specific. We
don't really want to rely on one single vendor.

> You have the detail of the different message structures?
Actually, identifying the source directly from iso8583 message is our
prefered approach(if it is feasible) but I am not sure if there is any
field in the iso8583 message that would be used to identify the source
of message(actually, I got 2 banks message structure only). Please
share your experience for this.


> Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[kelvin-19]

On Nov 4, 8:53 pm, chhil <chil...@...> wrote:

> Is this a single connection persistent or multiple (per bank)  connections
> to your server or  a connection is received per request (connect disconnect
> model)?
>
> Based on your model if each bank connection or you may be able to
> differentiate the messages based on the local port where the connection
> originates (as Mark has mentioned).
>
> -chhil
>
>

Hi chhil,

Thanks for your reply! My reply to Mark's message can also  answer
your question. Please help to give your opinion again.

Kelvin

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Mark Salter-5]

kelvin wrote:
>> If you cannot adjust the port setup, you will need to identify the
>> source from indicators in the stream - at the channel level, perhaps
>> length formats or header content.  If some banks share the same message
>> structure, then the message field contents will be used.
>
> Yeah, using indicators is our current approach. However, the drawback
> of this approach is that the indicators format is vendor specific. We
> don't really want to rely on one single vendor.
So the markers position (field?) and other details should be easily
changed, place them in a configuration file.  It seems you are assuming
that another 'vendor' would pass you messages in the same exact format
as your current vendor?  This is quite possibly *not* the case.

>
>> You have the detail of the different message structures?
> Actually, identifying the source directly from iso8583 message is our
> prefered approach(if it is feasible) but I am not sure if there is any
> field in the iso8583 message that would be used to identify the source
> of message(actually, I got 2 banks message structure only). Please
> share your experience for this.
The fields within your ISO8583 structured messages can vary from bank to
bank.  Thus your packagers *and* the field(s) you need to check for
presence or perhaps for content may also vary.

ISO8583 for bank 1 !(necessarily)= ISO8583 for bank 2

Which is where you started:-

"
So I just wonder if there is any simple way to identify which
bank the message come from so that I can apply the corresponding bank
packager for unpacking.
"

The detail of the message content and possible indicators you will
already have, we do not.

--
Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Alan Honczar-2]

I had the same situation once and I've had to rely on the TPDU.

The NII information told me whose message it was.

2009/11/5 Mark Salter <marksalter@...>

kelvin wrote:
>> If you cannot adjust the port setup, you will need to identify the
>> source from indicators in the stream - at the channel level, perhaps
>> length formats or header content.  If some banks share the same message
>> structure, then the message field contents will be used.
>
> Yeah, using indicators is our current approach. However, the drawback
> of this approach is that the indicators format is vendor specific. We
> don't really want to rely on one single vendor.

So the markers position (field?) and other details should be easily
changed, place them in a configuration file.  It seems you are assuming
that another 'vendor' would pass you messages in the same exact format
as your current vendor?  This is quite possibly *not* the case.

>
>> You have the detail of the different message structures?
> Actually, identifying the source directly from iso8583 message is our
> prefered approach(if it is feasible) but I am not sure if there is any
> field in the iso8583 message that would be used to identify the source
> of message(actually, I got 2 banks message structure only). Please
> share your experience for this.

The fields within your ISO8583 structured messages can vary from bank to
bank.  Thus your packagers *and* the field(s) you need to check for
presence or perhaps for content may also vary.

ISO8583 for bank 1 !(necessarily)= ISO8583 for bank 2

Which is where you started:-

"
So I just wonder if there is any simple way to identify which
bank the message come from so that I can apply the corresponding bank
packager for unpacking.
"

The detail of the message content and possible indicators you will
already have, we do not.

--

Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Brunhera]

On 4 Nov, 00:42, kelvin <kelvinwork...@...> wrote:

> Hi all,
>
> I am just using jPOS to implement my company's payment system which
> need to unpack iso8583 messages from different banks. However, all
> different messages would be come from the same connection(say, same
> socket). So I just wonder if there is any simple way to identify which
> bank the message come from so that I can apply the corresponding bank
> packager for unpacking. I am new to iso8583 and payment system. Hope
> you can share your experience. Thanks.
>
> Kelvin

According to the ISO8583 standard, bit 32 must be the bank ID

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Alan Honczar-2]

In order to discover the bit 32, you have to unpack the message.

Different banks MAY have different packagers...

2009/11/5 Brunhera <jcbrunhera@...>

On 4 Nov, 00:42, kelvin <kelvinwork...@...> wrote:
> Hi all,
>
> I am just using jPOS to implement my company's payment system which
> need to unpack iso8583 messages from different banks. However, all
> different messages would be come from the same connection(say, same
> socket). So I just wonder if there is any simple way to identify which
> bank the message come from so that I can apply the corresponding bank
> packager for unpacking. I am new to iso8583 and payment system. Hope
> you can share your experience. Thanks.
>
> Kelvin

According to the ISO8583 standard, bit 32 must be the bank ID

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Mark Salter-5]

Alan Honczar wrote:
> In order to discover the bit 32, you have to unpack the message.
> Different banks MAY have different packagers...

'We' may find both kelvin's banks don't use field 32 either.

8)

--
Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[kelvin-19]

On Nov 6, 2:27 am, Mark Salter <marksal...@...> wrote:

> Alan Honczar wrote:
> > In order to discover the bit 32, you have to unpack the message.
> > Different banks MAY have different packagers...
>
> 'We' may find both kelvin's banks don't use field 32 either.
>
> 8)
>
> --
> Mark

Hi all,

Thanks you all!
Mark's reply is what I am concerning: whether ALL banks would use
field 32?
If anybody who had seen a bank that did not use field 32, please tell
us.

Kelvin


--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[kelvin-19]

Hi Alan,


On Nov 6, 2:02 am, Alan Honczar <ahonc...@...> wrote:
> In order to discover the bit 32, you have to unpack the message.
> Different banks MAY have different packagers...

According to ISO8583 standard, field 1 to field 31 are all fixed
length fields, so I think we may get the content of field 32 only by
just skipping the first 31 fields' total byte length of the iso
message.(Of course, the premise is that all banks would use field 32)


Kelvin

> 2009/11/5 Brunhera <jcbrunh...@...>
>
>
>
>
>
> > On 4 Nov, 00:42, kelvin <kelvinwork...@...> wrote:
> > > Hi all,
>
> > > I am just using jPOS to implement my company's payment system which
> > > need to unpack iso8583 messages from different banks. However, all
> > > different messages would be come from the same connection(say, same
> > > socket). So I just wonder if there is any simple way to identify which
> > > bank the message come from so that I can apply the corresponding bank
> > > packager for unpacking. I am new to iso8583 and payment system. Hope
> > > you can share your experience. Thanks.
>
> > > Kelvin
>
> > According to the ISO8583 standard, bit 32 must be the bank ID- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[David Bergert-2]

> According to ISO8583 standard, field 1 to field 31 are all fixed
> length fields, so I think we may get the content of field 32 only by
> just skipping the first 31 fields' total byte length of the iso
> message.(Of course, the premise is that all banks would use field 32)

ISO8583 is not a fixed length format it is bitmapped - that bitmap  
indicated what fields are or are not present -- then individual fields  
can hold different lengths of values -- look at DE 2 or Field 2 for  
PAN -- this typically indicates the length of the pan and then then  
pan - up to 19 digits -- then there are the different methods of using  
different character sets to display this information -- BCD, ASCII,  
HEX, EBDIDC, etc.

I don't see how your approach will work.

Regards,

David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com

On Nov 5, 2009, at 8:37 PM, kelvin wrote:

>
>
> Hi Alan,
>
>
> On Nov 6, 2:02 am, Alan Honczar <ahonc...@...> wrote:
>> In order to discover the bit 32, you have to unpack the message.
>> Different banks MAY have different packagers...
>
>
>
> Kelvin
>
>> 2009/11/5 Brunhera <jcbrunh...@...>
>>
>>
>>
>>
>>
>>> On 4 Nov, 00:42, kelvin <kelvinwork...@...> wrote:
>>>> Hi all,
>>
>>>> I am just using jPOS to implement my company's payment system which
>>>> need to unpack iso8583 messages from different banks. However, all
>>>> different messages would be come from the same connection(say, same
>>>> socket). So I just wonder if there is any simple way to identify  
>>>> which
>>>> bank the message come from so that I can apply the corresponding  
>>>> bank
>>>> packager for unpacking. I am new to iso8583 and payment system.  
>>>> Hope
>>>> you can share your experience. Thanks.
>>
>>>> Kelvin
>>
>>> According to the ISO8583 standard, bit 32 must be the bank ID-  
>>> Hide quoted text -
>>
>> - Show quoted text -
> >

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Mark Salter-5]

kelvin wrote:

> Mark's reply is what I am concerning: whether ALL banks would use
> field 32?
All interfaces and message structures vary in format and content, often
there are similarities; they are rarely the same, especially at the
interface level.

> If anybody who had seen a bank that did not use field 32, please tell
> us.
Why not check both your banks message specification to test this?

At this stage I 'hear' you do believe that ISO8583 defines the field
content and field use.  I would humbly suggest ISO8583 defines the
message structure and possible field structures.  The field *use* is
often decided by the interface owner.

Please check your two bank's message specifications for field 32, and
work from there.
Just remember to check all future additions (of bank *and* vendor)
conform to this position.

--
Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Mark Salter-5]

kelvin wrote:
> On Nov 6, 2:02 am, Alan Honczar <ahonc...@...> wrote:
>> In order to discover the bit 32, you have to unpack the message.
>> Different banks MAY have different packagers...
>
> According to ISO8583 standard, field 1 to field 31 are all fixed
> length fields,
Can I ask you start quoting ISO8583 source and versions and variants
please?

Field 2 - often used for PAN - is also usually variable length.  So your
statement is wrong I'm afraid.

> so I think we may get the content of field 32 only by
> just skipping the first 31 fields' total byte length of the iso
> message.(Of course, the premise is that all banks would use field 32)
As David indicates this is not a universal approach - many things will
stop it working.  Having said that, it might work for your vendor's
interface, especially if the document you are 'quoting' from is from
your vendor (or bank(s)) and not a version from iso.org.

--
Mark

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[chhil]

As we all know the thousands of  variations between various 8583  
implementations. To make it scalable you should probably look into
look into getting some sort of custom header prepended by the  
middleman that is forwarding the messages to you after acquiring  
transactions from the banks.
Or look into getting a connection per bank message.
I know this is  easier said than done :-)

-Chhil



--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[Brunhera]

I totally agree with you guys. The first step is understand the ISO
format
for both 2 banks. If they indicate field 32 as a bank ID, the problem
is solved.
If not, the only way is making some header information.





On 6 nov, 06:35, Chhil <chil...@...> wrote:
> As we all know the thousands of  variations between various 8583  
> implementations. To make it scalable you should probably look into
> look into getting some sort of custom header prepended by the  
> middleman that is forwarding the messages to you after acquiring  
> transactions from the banks.
> Or look into getting a connection per bank message.
> I know this is  easier said than done :-)
>
> -Chhil
--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---

[kelvin-19]

Hi all,

This is my first post in the group. I really appreciate your reply!
Thanks for sharing~!

Kelvin

On Nov 7, 9:14 am, Brunhera <jcbrunh...@...> wrote:

> I totally agree with you guys. The first step is understand the ISO
> format
> for both 2 banks. If they indicate field 32 as a bank ID, the problem
> is solved.
> If not, the only way is making some header information.
>
> On 6 nov, 06:35, Chhil <chil...@...> wrote:
>
>
>
> > As we all know the thousands of  variations between various 8583  
> > implementations. To make it scalable you should probably look into
> > look into getting some sort of custom header prepended by the  
> > middleman that is forwarding the messages to you after acquiring  
> > transactions from the banks.
> > Or look into getting a connection per bank message.
> > I know this is  easier said than done :-)
>
> > -Chhil- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
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-users@...
To unsubscribe, send email to jpos-users+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users
-~----------~----~----~----~------~----~------~--~---