200,000,000

We passed a significant milestone on one of our production jPOS implementations this past week:  our 200 millionth (200,000,000) transaction processed - see the jPOS UI screen image on the left.  The lucky transaction was a Discover Card credit authorization for USD 22.00.  Total end-to-end processing time (including external auth) was 593 milliseconds. 

I've tracked the daily progression of this jPOS installation for the last couple of months.  This flash-based graph shows you how store count and transaction volume has grown.  This Fortune 200-class acquirer is in the process of adding 1,800 store locations (up to 12 registers per location) as the result of a recently completed acquisition.  You can look at a recent peak day more in depth here - I've broken things down by application (Debit, EBT, Credit, SV, etc.), card type and card brand.   [For more info in understanding that 'day in-depth,' refer to my "Can jPOS Handle It?" series.]  We're running on a four-box MS Windows Advanced Server 2003 configuration:  two replicated app nodes, two DB nodes running as a virtual cluster (see more detail here).

I like the 200,000,000 metric because it raises a point about operations and on-going responsibilities:  it's all well and good to configure a system that can do an eye-popping TPS rating; it's another thing all together to put that application into production, nuture it, continuously improve it and offer 24x7 support for it.  As just one example, you're not getting to 200,000,000 without having prudent database tuning and nightly DB maintenance in place.  Culling and re-indexing are just two of the small pieces of the puzzle you need to have in place.  It takes a series of small, important practices like that to keep your application in shape.  You can take a look at my Five Challenges piece to get some insight on some of the other things to keep in mind when envisioning the implementation of your payment systems application.