/by apr/ We regularly receive requests from PEP members willing to engage jPOS-savvy consultants. From small consulting gigs to full time on-site and remote positions, there are always great opportunities here and there. You can send your CV to jobs at jPOS dot org (for utmost confidentiality, you can send it to me using PGP).

/by apr on show business/

Andy and Dave from Online Strategies had a great idea, payment systems related podcasts, and here is Episode #1! In this first episode, they describe how they have migrated a big application from a legacy platform to their jPOS based OLS.Switch.

/by apr on this-is-what-I'm-doing-now/

During my long (I wish I could say short) life as a programmer I've been writing the same kind of applications over and over and over.

Every time a given application goes live, I immediately start writing it again under my budget in what I think could be a more efficient, modular and elegant way.

That's how I've written jPOS, previous versions were written in C, then C++, then back in C, then Java.

During the last 10 years or so most of my projects have been mostly either transaction switches or credit/debit/stored-value/gift-card/loyalty system.

We have some pretty impressive production grade systems, from small acquirers and card issuers in small countries to large financial institutions as well as Fortune 500 and Fortune 100 companies processing massive transaction loads.

Almost all the projects enjoy the jPOS-EE modular architecture, but in most situations we end up implementing what the customers have in place in terms of protocols involved.

There are usually inbound protocol specs in place, sometimes outbound specs, customer-specific routing and reporting/extract requirements and business logic, and that's what we have to implement.

In order to reuse code as much as possible, we have the jPOS TransactionManager that is a great general purpose component that fosters the reuse of a lot code (the so called transaction 'participants'), but we still get to implement large chunks of customer-specific code, we still need to read tons of specs. We read specs and we implement those specs, but there's no such a thing as the jPOS specs.

In order to change that and in an attempt to move ourselves to the center of the boxing ring (so to speak), we have now our own specs. And by not reinventing the wheel, our effort has been very small as the new ISO-8583 version 2003 spec is really nice and well thought.

Most things that were previously done using esoteric private fields are now very well specified as part of the standard, so there's not too much to think (no think is good), one just have to follow the experts. But we don't live in a perfect world, so we need to support legacy protocol versions (both inbound and outbound).

Our approach is to use what we call "Stations" that speak the jPOS Transaction Switch (jPTS) internal message format (jPTS IMF) based on ISO-8583 version 2003 and to whatever external protocol is involved.

We currently have five stations types:

• Source Stations (SS) are typically POS/ATM drivers or multi-lane POS servers receiving transactions using ISO-8583 variants or proprietary protocols and converting them to jPTS' Internal Message Format.
• Destination Stations (DS) are used to convert jPTS IMF based transactions into messages suitable for a given destination endpoint. Those can be either a different variant of the ISO-8583 protocol or any other proprietary protocol.
• Monitoring Stations (MS) can be configured to receive copies of messages sent from and to SSs and DSs either as part of the transaction (synchronous mode) or via store and forward (asynchronous mode). MSs can be used to monitor system health, feed in-house reporting/settlement subsystems as well as active and passive fraud prevention subsystems.
• Control Stations (CS) can use jPTS IMF to initiate several system jobs such as setting the current capture date, forcing a cutover, modifying system configuration parameters, reporting a hot card or hot bin range, etc.
• HSM Stations (HSMS) provide an abstraction layer that enables the communication with different hardware-based (and software-based) security modules brands and models.

So we basically have two tightly coupled projects, jPTS (the switch) and jCard (the CMS that implements a native jPTS IMF and can act as a jPTS Destination Station).

Both take advantage of miniGL and we are currently working in the user interface where we have some good news too, we have now the jPOS Presentation Manager (I'll talk about it soon - think dynamic scaffolding to provide CRUDL support for most commonly managed entities).

While we still have a lot of work to do and a lot of features to add before we can release this projects, we believe these applications could be extremely helpful, even as a reference implementation, to teams working on their own jPOS and jPOS-EE projects. In the same way a picture is worth a thousand words, studying a working application (specially a good one) is worth a thousand programmer's guides. We are currently working in a sneak preview program that will allow you to embrace this technology now and use it as part of your projects, either as a reference or as its core engine. Interested parties can register here.

/by apr/ Ditto. See the ChangeLog for details. The new development version is now 1.6.3.

/by apr on kudos/ The jPOS team @ CS has certified the new VISA Business Enhancements April 2008 at one of our jPOS sites today and is working on a second site. This is not a big deal and not worth a blog post, but we got word that this is the second site in Latam to be ready to go. Congratulations!! The CS guys have a solution that works even for non jPOS customers (simple jPOS based bridge between the customer's main system and VISA's VAP to handle the required message format changes). Feel free to contact them if you want further information.

/by apr/ Reading the Payment Systems blog I came accross this other excellent PCI answers blog. After reading Trust but verify your POS system I got to re-read the list of validated payment applications. The PABP requirement #1 clearly says: Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data. I'm working on several jPOS systems that connect to some of the systems listed there and it's nice to see incoming 220s and 420s with lovely data elements 35 and 45 from time to time. Those are SAF-ed messages and I wonder how the hell they manage to not store sensitive data on disk, not even in encrypted form, but they are still able to send it over in store and forward messages that sometimes arrive at our end a couple of days later when our test platform is not active.

I think the PABP list is nice, but it will take a lot of time to get customer sites upgraded to PABP compliant versions of the products mentioned there. The customer have a false sense of security because their provider is listed there, but the version they are running is not that good. Bottom line, Trust but verify your POS system but also verify your acquirer's software version number.

/by apr on recommendations/ My friend and jPOS developer Dave (CISSP, CISA) has a new blog: Payment Systems Blog We are working with him, Andy and the OLS team in some changes to jPOS-EE and their OLS.Switch required for PABP certification (actually they are doing most of the work, which is great, I will just take care of merging the results back to the jPOS-EE codebase). I guess users reading this blog may have tangential interest in it.

/by apr/ For those of you thinking that your special application needs an extremely high performance engine, and you are not sure if jPOS can handle it, here is a nice post that basically says in a polite way that probably YAGNI!. When you ask if jPOS can handle your load you actually need to ask yourself if the business logic and database access strategy that you are going to put in place on top of jPOS can really handle it.

/by apr/ The Free Software Foundation has released the GNU Affero General Public License (AGPL v3.0), a license we've been waiting for a long time that will allow us to open source more code such as the jCard (our Card Management System) and jPTS (an ISO-8583/2003 based jPOS Transaction Switch) projects. We plan to upgrade all our licenses to AGPL v3.0. What does this mean to you?

• If you use jPOS as part of an open source project, you can check this Compatibility Matrix.
• If you are an existing sponsor or contributor, nothing changes, you'll be entitled to get a waiver
• If you use jPOS commercially and you are neither a contributor nor a sponsor, you should raise the issue to your managers and have them contact us

/by apr on propaganda jPOS speed/ While reading about how Open Source is essencial to Paypal's success I was impressed to see Paypal processes about U$S 1500 every second of every day and that's only 10 times bigger than some of our jPOS sites running in a couple of Intel boxes and probably only 5 times bigger than The Gladiators' upcoming system. BTW, I recently got word that a large financial institution (really really large) was using jPOS to test their own legacy systems and (with some changes to the ISOMsg class in order to pre-allocate fields) they managed to get 330k pack/unpack operations per second on a Sun 32-WAY system. Not bad, huh?