Problem identifying the source of iso8583
kelvin
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
Mark Salter
> 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
chhil
kelvin
> would allow you greater control over access and monitoring activity? A
> *much* cleaner solution.
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.
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?
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
kelvin
> 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
>
>
Thanks for your reply! My reply to Mark's message can also answer
your question. Please help to give your opinion again.
Kelvin
Mark Salter
>> 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.
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
Alan Honczar
Brunhera
Alan Honczar
Mark Salter
> 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
kelvin
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
kelvin
Hi Alan,
On Nov 6, 2:02 am, Alan Honczar <ahonc...@gmail.com> wrote:
> In order to discover the bit 32, you have to unpack the message.
> Different banks MAY have different packagers...
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...@gmail.com>
>
>
>
>
> > On 4 Nov, 00:42, kelvin <kelvinwork...@gmail.com> 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
>
>
> - Show quoted text -
David Bergert
> 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)
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...@gmail.com> wrote:
>> In order to discover the bit 32, you have to unpack the message.
>> Different banks MAY have different packagers...
>
>
>
Mark Salter
> 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
Mark Salter
> On Nov 6, 2:02 am, Alan Honczar <ahonc...@gmail.com> 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,
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
Chhil
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
Brunhera
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.
kelvin
This is my first post in the group. I really appreciate your reply!
Thanks for sharing~!
Kelvin