credit card processing on unix with fp

[Fairlight]

On Fri, Nov 16, 2007 at 11:20:48AM -0500, after drawing runes in goat's blood,
GCC Consulting cast forth these immortal, mystical words:
>  
> 
> > This has to be a slow solution.  Does the application support TCP/IP. 
> > Then you could do this with sockets.
> > 
> > Nancy
> 
> My processing take about 3 seconds a card that includes writing out the xml,
> reading it back, and updating the results to the transaction being
> processed.

It's actually very fast.  Especially when you consider that includes the
perl instance load and precompile. :) I've run into slower transactions at
kiosks in stores or the registers at Wal*Mart where it's all in firmware on
a dedicated network.

> The windows program we are interfacing to is "YourPay".  One problem we had
> is they demanded xml but are returning pseudo xml.  Don't ask.

Definitely DON'T ask.  If I had a choice, I would -run-, not walk away
from YourPay.  Their spec is just horrible, their software worse.  It was
as stringent as you'd expect (actually, moreso if I remember one alpha
testing issue) from an XML parser, and they demand valid XML coming in.
But coming back they didn't even give you valid XML that would pass any
parser's even cursory checks.  If memory serves, the main issue that throws
you for a loop is that they have -no- top-level element enclosing their
other elements in the response.  Hence, invalid XML.  That was just one of
their shortfalls.  Their spec was just plain painful to read--especially
stacked up against the reality of their operating code; it was obvious to
me that the people writing this stuff had no concept of what they were
supposed to be doing in reality.  They used the big words and acronyms like
a big house should, but didn't get the implementation entirely right on any
side, IMHO.

That said, I now know how it works, so I can deal with it easily.  :)  But
beware to the YourPay Virgins out there...

mark->