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 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.
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).
On Wed, Nov 4, 2009 at 2:57 PM, Mark Salter <marksal...@talktalk.net> 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.
> 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.
On Nov 4, 8:53 pm, chhil <chil...@gmail.com> 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 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.
> 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.
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
According to the ISO8583 standard, bit 32 must be the bank ID
> 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
> According to the ISO8583 standard, bit 32 must be the bank ID
On Nov 6, 2:27 am, Mark Salter <marksal...@talktalk.net> 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.
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, 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)
> > 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
> > According to the ISO8583 standard, bit 32 must be the bank ID- Hide quoted text -
> 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.
> 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...
>>> 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
>>> According to the ISO8583 standard, bit 32 must be the bank ID-
>>> Hide quoted text -
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.
kelvin wrote: > 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,
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.
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 :-)
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.
> 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 :-)
> 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...@gmail.com> 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 :-)
|
