Base-24 pos SDPH parser

[tzetter]

Hi,

I am in the process of setting up a jPOS server to act as a IP/SSL
Gateway beetwen my TCP/IP POS Terminals and the Base24 Host.

Today I have dial_up terminals that connects directly to a third
party processor that runs a BASE24 host, our POS use the BASE24-pos
SDPH message format to send and receive message from the third party
processor.

We are currently in the process of doing a project to offer our
merchant a TCP/IP POS Terminal. In our talks with the third party
processor we were told that they are not going to offer us an IP/SSL
solution, so we had to come up with another solution.

In the talks with the third party processor, we found out from them
that they offer a connection for Internet Payment Gateways, in which
Internet Payment Gateways can connect to their host over a frame
relay connection using TCP/IP using the BASE24-pos SPDH message
format.

In collaboration with the third party processor we have decided to
creat an IP/SSL Gateway that will send the message "straight
through" to the host leverage this Internet Payment Gateway
connection. It is very similar to how our dial_terminals send and
receive a message from the host.

Now there are many ways we could go about setting up an IP/SSL
Gateway. One is to use the openSSL package and send the pass through
message to the host. But we dicovered in out talks that there is one
reversal condition that we need to manage, so we can't use the
openSSL package.

So we decide we are going to use the jPOS framework to handle the
IP/SSL Gateway task. In the standard jPOS-EE package there is no
SPDH adaptor, and we would need one as we have to do parsing to
handle the reversal condition.

As jPOS is an open community, I wanted to check with you the jPOS
users/developers if anyone of you have had a similar project or have
developed a parser for Base24-pos SPDH.

Let me know, as I would be interested to learn from your experience
and find out if you would be interested in providing us with your
solution.

Have a great day
Torbjorn Zetterlund
For the latest ePayments Industry News visit www.epnn.com

[newsinnewsout]

hello Torbjorn ,

I have been investigating using jPOS as a means of decoding and
encoding SPDH format message. I got help from Alejandro Revilla at
jPOS. He suggested I look at the FSDMsg class and examples in
src/examples/fsdmsg

Having investigated this, I was able to create a set of a SPDH
message definition files and in principal it works quite well, but I
immediately hit a problem because of the nature of SPDH messages.

As you are aware SPDH messages have a fixed header followed by
optional variable length fields, these fields are identified by
field ids (fids).

The fid fields are identified in the definiton files as 'key' fields,
and the fid values (e.g. a, b, g etc) form part of the name of the
corresponding message field definition file. The problem is that
SPDH messages define both upper and lower case letter fids (e.g. b
and B). This causes an immediate issue on windows platforms where
the file system is not case sensitive.

The FSDMsg class takes a URI as a path to the location of the
definition so we considered the idea of getting the definition from
a web service. But this can also suffer from upper/lower case issues
on some web servers, and is a lot slower.

In the end we extended the FSDMsg class pack() and unpack() methods
to handle the 'key' fields by including an 'l' character for lower
case and a 'u' character for upper case fids in the filename. This
is a bit of a hack so I am currently investigating a better approach
to this issue.

further to these issues it was necessary to
- make changes to remove the last field separator character which is
not required in SPDH messages.
- modified FSDMsg to handle any separator character (not just FS) as
SPDH uses RS as the separator in sub fields.
- modified FSDMsg to do binary to ascii and ascii to binary
conversions for PIN and MAC fields, did this by adding a B option to
the <field> element type attribute.
- modified FSDMsg to add field type and length checking based on the
defintion <field> element values.

All of this work is still very much in the prototype stage and not
thoroughly tested.

Does anyone else have any suggestions or been through a similar set
of experiences :-)

John Anderson

[Alejandro Revilla]

Post by newsinnewsout
In the end we extended the FSDMsg class pack() and unpack() methods
to handle the 'key' fields by including an 'l' character for lower
case and a 'u' character for upper case fids in the filename. This
is a bit of a hack so I am currently investigating a better approach
to this issue.

The schemas are lazy loaded and cached in the Space, I guess we
could eager load them and use the schema's 'id' attribute (which
supports lower/upper cases) as the key. So, if you have a set
of files cfg/xxx-*.xml, we could just go ahead and load them all
into the Space at FSDMsg static initialization.

Post by newsinnewsout
further to these issues it was necessary to
- make changes to remove the last field separator character which is
not required in SPDH messages.
- modified FSDMsg to handle any separator character (not just FS) as
SPDH uses RS as the separator in sub fields.
- modified FSDMsg to do binary to ascii and ascii to binary
conversions for PIN and MAC fields, did this by adding a B option to
the <field> element type attribute.
- modified FSDMsg to add field type and length checking based on the
defintion <field> element values.

Good additions!

--Alejandro