Richard Bucker

jPOS and the next generation

Posted at — May 30, 2012

Having worked in the POS and payments market for many years I’ve evaluated, worked with and recommended the jPOS toolset. On it’s own it provides a codec-like API for encoding and decoding ISO8583 messages. The API are generic enough and support all of the important variations and it’s user extensible when it does not.The best part, however, is that they also have an EE-ish version that provides an almost complete solution for implementing your merchant gateway, acquiring processor or issuing processor. Don’t get me wrong, you still need to be an expert to implement one of these systems but the jPOS stack is going to give you a java-leg up.In truth however, @apr is probably the best part of the offering. He has a keen eye for where he sees the project going and what features need to be added as it expands. He also knows what features¬†should be left to the user to implement. And he knows how to communicate the system design as well as educate the user in how and where to implement the user’s code without effecting any sort of upgrade path.I’m so fond of this system I which I had a language agnostic version that might be more like a meta programming or code generated version so that I could plug-in the target language ad-hoc. And if that was too much to ask, then I’d want a python version so I could operate in the same space and maybe get a little more productivity.