Andy Orrock | Payment Systems

Conversion(s) Complete

For payment systems managers wondering if the jPOS project is a good choice for your enterprise, we’ve got an update from our flagship OLS.Switch client as a consideration in your decision-making process. 

At that client, we reached a gratifying dual milestone last week.  First, they’ve just finished on-boarding the last of about 1,800 acquired stores, bringing the total to around 5,020 locations across the four US continental time zones.  Second, we’ve just converted the last of the payment acceptance types off of the legacy platform.  That's a Check Authorization application.  As a result, as of Friday the legacy application is processing a big fat zero transactions per day, while the jPOS-fueled OLS.Switch clocked in a week in which the daily average was just a gnat's hair shy of 1 million (991,588 to be exact). 

I had said here recently that the 'New Normal' after we reached these milestones was going to be one where we reached a million customers interactions a day the 'natural' way, i.e., without the a holiday-fueled consumer buying bulge.  We're not quite there yet.  Thursday, Friday and Saturday all clocked in comfortably over the one million threshold but were no doubt fueled by a sizable Father's Day run-up.

We do all this on $28,000 of core server hardware - replicated application nodes + a two-server MS SQL Server virtual cluster.  Refer to my 'Can jPOS Handle It?' series for further details.

Replicating your issuer-side jPOS implementation in Country #2

I blog here mostly about all the development, operational and new initiative activity going on on the acquirer-side of OLS.Switch (our jPOS-based payment switch), but we've got an issuer side solution we created as well.  You don't hear about that much here because, by nature, there are not as many new initiatives, volume is lower (just a quirk of our client set mix) and there's only a single payment gateway in play in the solution environment.  Compare that last point with a typical acquirer-side solution.  At our flagship client, for example, we've got 32 endpoints in play. 

The reason I bring this up is that an issuer client of ours has approached us about replicating our in-place solution for an operation they want to bring online in another country.  I was asked to put together a list of items that would need analysis and probable change.  I made the assumption (confirmed, in this case) that the payment gateway we're using  here in the US instance won't be a viable option for Country #2 and beyond.  With that fact in hand, here's the list of touchpoints I had tallied:

1. We need copies of all related specifications describing the interface that will perform the role that the current gateway provider now plays in conjunction with the US implementation.
2. In particular, we need four pieces of information: the authorization message set and field descriptions; the telecommunications guide; the encryption guide; and the certification script.  Optimally, these documents should be provided to us in English.
3. After we have time to review the documents, we need a formal walkthrough in the form of a teleconference with the gateway provider.
4. We need to know details about the reversal model; specifically, how does the reversal get matched-up to the original?  (each gateway provider has a distinct match-up methodology).
5. Similarly, we need to know details about the pre-auth/completion; specifically, how the completion get matched to the pre-auth? (similarly, each gateway provider has a distinct match-up methodology)
6. We need to understand the testing facilities that will be made available to us, how to coordinate testing and what will be required for certification.
7. We need to know if we need to have any specific language capabilities on our side to perform testing and certification.
8. We also need to know whether any currency conversion issues will be in play.

Items 4 and 5 - how to match the reversal to the original; how to match the completion to the pre-auth - are worthy of a closer look.  I mention above that "each gateway provider has a distinct match-up methodology."  I have a write-up in my files that delves into the way that one such gateway provider does it.  What we, in turn, have to do is described here.  I think is pretty good one-page summary of things. 

Good switch, bad switch

A reader asks:

----------------
Do you think jPOS could do 400tps? I need a stable and reliant ISO switch that can do 400tps at peak.
----------------

Well, this is a highly qualified 'yes'.  Given the right team, you can surely conceive, design, engineer and perfect a top-notch jPOS solution that turns in some eye-popping TPS results.  The Gladiators - definitely the 'A Team' - have achieved 900 TPS.  I've got an application that I've tested unofficially at 330 TPS on a very modest architecture.  Alejandro gets reports all the time from the field of really impressive (but unpublishable) results .

But here's the thing:  You can use jPOS to build a good switch...or a bad one.  There's nothing preventing you from taking jPOS and building a craptastic switch...nothing to prevent that at all.  Simply put together an ill-suited team that doesn't understand payment systems or don't pay attention to details, and odds are good you'll bomb.  It all factors into the Buy vs. Build argument - do you have the time and expertise to pull off the build?

One example from memory:  that instance I reference above where mention 330 TPS.  We were maxing out at 30 TPS in early tests, but it turns out we hadn't yet put the optimal index on one of the key files.  So forget about jPOS - we were lopping greater than 90% off our TPS capacity simply because I overlooked something on the DB side.

I'm also reminded of Bill Gates' comments about good programmers and bad programmers.  He said that the public believes that a good programmer must be twice as effective as a bad programmer.  In reality, a good programmer is some crazy multiple better - i think he mentioned eight times better.  Think about those dynamics when you're putting together a team.

One comment about 400 TPS and perspective for readers:  One of our jPOS applications processes all the payments for one of the leading retailers in the United States:  $17.5 billion in yearly revenues; 5,000 locations in four US time zones; each location with up to a dozen lanes.  Their 30-minute sustained holiday season peak is 35 TPS.  [We engineer for sustained peaks.]

Relationship between POS devices and jPOS Acquirers

A partner posed the following question to me:

Andy -

What info do we need from our clients regarding their POS or PC-based transaction environment? Manufacturer, model #, software program or version etc.?

-------------
My answer follows (it's a good question because it allows me to talk about a very important concept in terms of how you can be successful with your jPOS Acquirer-side payment systems solutions):

------------
Well, we need to know some important things about a client's transaction environment, but it's definitely not manufacturer, model #, software program or version.  We do not care - nor do we want any knowledge of - that type of thing.  It's an important point about the boundaries of OLS.Switch (NOTE:  OLS.Switch is our jPOS-fueled financial payment switch):  it's a host switching program and, as such, there is a very solid line in which we are protected from things like manufacturer and model and SW version decisions and vagaries. 

For example, our biggest client has a mixture of technology in the field.  We have no knowledge of their vendor selections, hardware configurations, program versions, etc.  What we *do* know from this customer - or any client like it - is the specified manner in which the POS population interacts with the host.  That means knowing:

• The message set
• The message types
• The fields within the messages

As an example, take a look at the OLS.Switch Debit/EBT spec (see redacted version of the relevant sections of my spec here).  You'll see that despite the wide range of hardware the customer has in the field, all Debit requests look the same, and all EBT requests look the same.  It's that uniformity that allows us to pull off projects of this magnitude. 

I've worked on many big installations over the years, and this is what the POS-Host interaction has in common on every one:

• An enterprise-wide POS specification
• A program in which POS vendors and their various configurations are certified in accordance to their adherence to that specification
• Sticking to that specification as new terminal vendors are brought into the mix, i.e, the terminal is always brought in line with the host, not vice versa

A bad, non-scalable and expensive (for you) scenario would be one where each terminal manufacturer interacted with OLS.Switch using its own proprietary format.  That terminal-to-host interaction is always a tough, grind-it-out process to work through, even when you're getting alignment on one enterprise format.  Doing that exercise for a series of proprietary interfaces would make any project untenable cost-wise.

The Evolution of jPOS: Your Complete Solution Framework

During a recent payment systems proposal, I challenged myself - as part of our RFP response - to come up with a list of the "unique 'value added' augmentations that distinguish our products and services."  For the purposes of this post, I want to 're-purpose' that answer.  In previous posts, I've noted that the original challenge Alejandro set out to conquer was the industry-wide drudgery involved with creating and implementing an ISO8583-based solution.  Now, he's expanded the vision and capability of the jPOS project such that a savvy team can implement the full breadth and depth of a payment systems solution using jPOS...to the extent that proactive leaders ought to now start looking at jPOS-centric solutions to take the step of replacing legacy payment systems.  [If you're not considering this shift already, you're falling behind.  That's fact, not opinion.  Your peers are already making these moves and are aggressively cutting their cost structure in the process.]

So, here I present my original list now re-purposed as documentation of what jPOS can do for you.  Each one of the following solution points uses jPOS as its backbone:

1. Debit/EBT Gateway implementation including logon manager and custom channel definition
2. MasterCard, Visa, AMEX and Discover Credit Card Gateway implementations including logon manager and custom channel definition
3. SVS, GreenDot, inComm and Verizon Stored Value interface implementations
4. Working jPOS packagers for each interface, featuring various models – EBCDIC display model, ASCII model, BCD model, BCD lengths, Hex lengths
5. Simulators to auto-respond to specific gateways
6. Debit/EBT Gateway Dynamic key exchange implementation [In-place model:  OLS.Switch requests new key with 0800 Network Message; Debit/EBT gateway responds with key in 0810; Key – ‘updated ZPK’ – maintained in ‘system’ table for use by all application nodes]
7. Specific PIN translation implementation [DUKPT at Device --> Triple DES Master Session for Debit/EBT Gateway; In-place model: CI/CJ command to Thales (formerly Racal) 8000 HSM for Single DES BDK and G0/GI command for Triple DES BDK.]
8. HSM Adapter ‘pool’ implementation which provides ability to balance HSM requests over multiple connections made to multiple devices
9. Terminal request parse and response ‘build’ models [In-place model is implemented via jPOS’ FSDMsg facility; model is set-up in a manner that facilitates transition to ISO8583 or Visa Gen2-based approach.]
10. Java New Input/Output (‘NIO’) -based terminal server will support massive number of simultaneous terminal connections (OpenSource version uses a Thread-based model).
11. PCI/CISP compliance model
12. Four TransactionManager instances featuring a series of useful, deployed, reusable transaction participants [Implemented TransactionManager participants include: transaction route path ‘switch’; transaction forwarding; transaction (request) parsing; tran log creation; tran log populate (by Application – Debit/EBT, Credit, SV, etc.), transaction request validation; duplicate check; Manager Override handling; reversal match-up; merchant/store/terminal validation; mapping to MTI and processing code for specific endpoint; force approval; result-code setting; select endpoint (Group Selector participant); set endpoint; ‘hasEntry’ (participant to determine if specific Context value is present)]
13. ‘Decrypt’ participant built in support of client’s custom implementation to encrypt ‘in flight’ PANs and Tracks [‘In flight’ here meaning: path between transaction origination point to host where OLS.Switch resides; client created encryption approach to comply with PCI/CISP; participant makes JNI call to ‘decrypt’ routine provided by client.] 
14. Complete reversal implementation including reversal/original cross-referencing
15. Specific tran log implementation which meets four needs: (a) provides internal troubleshooting transaction visibility via UI; (b) facilitates reversal and duplicate processing (contains data fields to determine reversal and duplicate status – and to build switched-out reversals to external authorizer; (c) allows creation of third-party extracts; (d) facilitates tallying of transaction statistics (transaction ‘duration’ and ‘outstanding’ figures logged as column entries on tranLog).
16. Extract/Report Engine [‘Handler’ framework facilitates ability to define and add new third-party extracts and/or internal reports; layouts implemented via jPOS ‘FSDMsg’ provide dozens of working examples; extracts and reports can be executed manually or scheduled via ‘90_extract’ deploy member]
17. Specific third-party Extracts, each of which has passed certification [FDR (Debit, EBT, Visa Credit, MC Credit); Discover; American Express; Stored Value Systems (‘SVS’), etc]
18. OLS.Switch User Interface [Enterprise-strength implementation of the jPOS UI Framework including:  System Status; Transaction list (with Application type filter); transaction ‘show’; transactions by store location; store/terminal view and real-time input facility; card type and BIN range definitions; manual execution of Extract]
19. Specific implementations of channel and SAF monitors, which updates the “status monitoring subsystem” and can be reflected in ‘System Status’ UI screen.
20. Card Type and BIN Range model that IDs card brand and selects proper endpoint
21. Working Store and Forward (‘SAF’) implementations [FDR North, SVS, GreenDot, inComm, etc.]
22. Host-based reversals
23. Threshold timeouts [Deny transaction internally if unable to switch-out prior to threshold timer value]
24. Terminal-based reversals and Voids [Includes match-up mechanics, reversal/original cross-linking; and placing of 0400 (or 0420) into endpoint-specific SAF queue.]
25. Duplicate check implementation
26. Five-part origination point definition model:  Merchant; store; terminal; External Merchant Info (‘EMI’) at Store level (MID, TID); or – optionally – at Terminal level
27. “OLS Audit” facility – ‘Last step’ on every transaction; allows implementer to scrutinize all context values and define rules for placing items into audit log
28. Complete result code model facilitating Remote Response Code (‘rrc’) --> Internal Result Code (‘irc’) --> Device Response translation [Library of codes has been built up over a series of projects and successful endpoint implementations.]
29. Complete internal tran code (‘itc’) model  [Creates level of internal standardization across various ISO and/or FSDMsg implementations; facilitates Extract/Report model.]
30. Specific ‘captureDate’ implementation [Defines point of day at which to roll/log transactions to ‘next’ day; allows business to implement their specific extract/reporting model; Extract/Report Handler uses captureDate to determine which transactions to extract.]
31. Specific implementation of jPOS’ ‘DirPollAdapter’ [Import employee file; update cardholder (employee by SSN)) and card (Employee ID number) files.]

Of course, beyond the design, coding and implementation of all that, there's even more hard work.  In our RFP, I noted that "[our] extensive tests, quick identification and reaction to production problems, dedication to continuous improvement and practice of ‘controllable change’ have produced a stable, enterprise-class , jPOS-enabled solution in which numerous complex components function in a cohesive, well-defined arena, addressing today’s payment systems challenges. We have a viable Fortune 500-class working model – developed over a three-year period – that really works: there are no leaks, no odd, unexplained behaviors."

Five Challenges (Issuer Side Implementation)

I wrote recently of the Five Biggest Challenges on an Acquirer side financial payments system implementation.  That would seem to call for a similar piece about challenges on an Issuer-side implementation.  So, here it is.  In both cases, these are not 'academic' lists.  They're based on real experiences on successful projects with enterprise-class customers.  Hopefully, these comments and insights can help you plan and better manage a similar project.

1. Card/Account Decision-Making - I'm not sure how to best entitle this one...I've worded it here in the widest way possible.  I'm referring to the complex of code that needs to determine Approve/Reject/Refer on a card and/or related account based on balances, transaction amounts, limits in force, fees applied, card status and profile, override flags, etc.  That's one bullet on my list of five, but easily 70% of your pain if you don't have a ready-made transaction processing engine to handle all that.  [For those of you looking for options in this regard, make sure you take a look at Alejandro's MiniGL project, which is designed to encompass many of these issues and to give it a strict accounting take that is sure to interest your finance an auditing teams.]  To measure the pain, let's compare to an Acquirer system - the challenge there is to accept the transaction, translate the PIN and get it to the proper authorizer.  And, you've got reversal implications aplenty on Debit/EBT.  But you're not the decision-maker on the transaction (I'm comparing only purely switched-out transactions here).  The issuer takes care of that for you.  On an issuer-based implementation, you're the system receiving that request.  The bar is set high for you to make conistent, accurate and timely decisions. 

2. Prevent Defense -  In an Acquirer-side system, you can control much of your own destiny because you the originator of the transactions.  On the Issuer-side, it's a different story entirely: you're at the mercy of the Acquirer and the gateway.  What I mean by that is that the proper functioning of your in-place issuer application is really - in large part - in the hands of how well acquirers adhere to specs (and common sense, frankly) and how well your gateways prevent illogical occurrences and sequences from sneaking through and biting you.  I talk about this at length in an earlier post.  I've seen entire issuer-side business models blown up because of loose adherence to specifications by acquirers (the example foremost in my mind is one in which it was super-critical for the issuer to know precisely how much of each purchase request was cashback...and, in practice, we found out that many acquirers can't be bothered to split out that portion).  While Prevent Defense is an exercise in continuous improvement, I suggest you make your best efforts to get as much in place upfront as possible.  One simple lesson to pass along:  always respond with an ISO-level approval to any and all store-and-forward (typically, reversals and completions) requests from the gateway/acquirer. You can figure out how you want to handle illogical requests behind the scenes (an "Approval" to an SAF request doesn't mean you'll necessarily apply it to the account...you need to make a systematic judgment call on each SAF request you receive), but ALWAYS respond in the affirmative to the gateway/acquirer if at all possible (something will need to be seriously wrong with your application to go back with anything but an approval of an SAF).  SAF requests queue to you in strict sequential fashion, so until you successfully process that item currently in play, everything else will queue behind it.  That can become a bad scene very quickly for you.  Play prevent defense.

3. The Pre-Auth / Completion Model - Yeah, this one is going to seem very narrow in scope and I'm sure you're wondering why I bring it up as one of the biggest challenges.  There are three reasons.  First, the match-up models provided by gateways tend to be, well, esoteric.  For example, in one gateway that provides transactions to one of our customers, there are two competing models in play.  We can't trust or predict a specific network to use one way vs. another, so in approving and storing the pre-auth, we need to account for the possibility of either of the following match-up methods being used:

The Authorization ID Response Code (ISO Field 38) created by our transaction authorization engine and returned in the pre-auth response to the Network is contained in the corresponding Field 38 of the subsequent completion request.

The Retrieval Reference Number (ISO Field 37) provided by our transaction-authorization engine and returned in the pre-auth response to the Network is contained in the corresponding Field 37 of the subsequent completion request.

To facilitate both of these methods, our engine caches the contents of Fields 37 and 38 along with the card number when logging the results of an approved pre-auth.

Reason number two is that the pre-auth and completion sit at the heart of determining an account's available balance.  And it's this balance - not the current or 'ledger' balance - that gets used to make your authorization decisions.  So, you don't want to be 'close' on pre-auth / completion mechanics...you want to be right.

Reason number three is that you need to put a methodology in place to handle pre-auths where a completion is never received.  This is a perfectly legimate sequence of events.  Ever go to gas station, put your card in the pump, then not pump any gas (for whatever reason)?  You just initiated a pre-auth without a corresponding completion.  In our authorization engine we have a parameter that answers the question "when do you want to expire the effect (on available balance) of this pre-auth if a completion is never received?" Typically, we use 1440 minutes (24 hours).

4. Extract/Settlement Cycle - I don't mean to trivialize Acquirer extract processes, because they have their own special challenges (especially when it comes to  discerning the weirdness of some gateway specifications), but it's a more delicate dance on the Issuer side because of balance re-calculating (for recovery purposes, we never allow the transaction engine to update the card balances directly; that task is left to the batch cycle) and the interaction with other balance-affecting systems in the enterprise (if they're in play).  Our typical batch sequence undertakes the following pieces of work:

• Selects and ‘extracts’ transaction data from the online transaction database and prepares a reconciliation (‘recon’) file from it.

• Performs (based upon an option selected by the client) either:

A “Self DB Refresh” (i.e., updating the card database directly from the recon file created in the first step.

An DB Refresh from an external source (“External DB Refresh”) by means of a input file provided by the client.  In this option, the recon file created in the first step is used by the client as one input (of many) to an enterprise-wide account reconciliation process.  In the last step of that process, the enterprise system must create an External DB Refresh file (format specified herein) which will allow then be used as input to update the balances maintained on the card file. 

Needless to say, it'll take a while to make sure you've got that all working and updating everything properly.  It's super-critical this be right, not close to right.

5. Ongoing Maintenance - Okay, an odd fit here because it's not part of your 'project' per se, but something I'm sticking in here as my "fifth challenge" because I want to make a point.  On our Issuer-side implementations, we work really hard to get them "just so."  Then, invariably, what happens is that the system gets into production and proves its mettle, and then the marketing people start generating all sorts of good ideas: hey, let's change this, add that, modify this calculation to help the customer, etc.  All good and welcome stuff, but: your "just so" app will be tested...can it stand up to repetitive change cycles and increasingly expansive enhancement requests?  Unless it has a solid foundation, it won't.  That's the premise of Alejandro's MiniGL project: it is designed to provide the user with a solid transactional- and accounting-based backbone upon which you can build your authorization engine.

Five Challenges (Acquirer Side Implementation)

As a manager of a payment systems project, you'll want to know the challenges that your predecessors have underestimated so that you can plan your project accordingly.  These typically aren’t 20% underestimates…they’re along the lines of 5x underestimates.  So, I hope I can pass along the benefit of some of our experiences so you’re not caught unaware.

Here’s my current (and ever-evolving) “Five Biggest Challenges” list for acquirer-side payment systems implementations:

1. PIN Encryption – A typical acquirer-side encryption implementation brings the following concepts into play:

•    Key ceremonies
•    DUKPT and its constituent parts (KSN, BDK, PAN)
•    PIN Translation (DUKPT to Triple DES Master Session)
•    Dynamic Key Exchange
•    ZMKs and ZPKs
•    The hardware-specific commands required to implement each of these concepts
•    Multi-threading adapters

In short, it’s a complicated, extremely esoteric, hardware-dependent exercise.  Most of the hits on my blog come from people around the world in our same shoes looking for a breakthrough on an encryption issue.  It’s not because of their lack of knowledge of capabilities.  Rather, it’s because the hardware manuals seem almost purposefully obscure; or, because the terminal vendor can’t fully articulate how they implemented DUKPT on their side so it’s up to you to guess; or, because the Debit/EBT gateway partner isn’t really clear which key encryption scheme it used to generate the ZPK…you get the idea.  Just assume you’ll be working with less than perfect knowledge.  You should plan on crawling your way through this task inch by inch.

2. Terminal Message Format – Acquirers will say “we use the ISO8583 standard” (or ANSI X9.15, or Visa Gen 2 or whatever).  The point is, terminal message formats are always theoretically standards-based in their original incarnation.  However, adherence to that standard tends to slowly erode over time.  An acquirer will, rightfully and expectedly so, slowly adapt that standard to their specific business model and market needs over the years.  So, by the time you come along with your project, yeah, the standard is there…under the covers if you look hard enough.  But, for all intents and purposes, it’s a proprietary interface.  Save yourself a lot of pain by just admitting to this fact upfront.  Treat the terminal interface as customer-specific and you won’t be disappointed or surprised by the quirks and oddities you’ll find along the way.  I once did a full-blown acquirer conversion project of a major gasoline marketer.  My advice to the outsourcer was “focus like a laser beam on the terminal message formats (these were flat-out proprietary) and transaction set.  If you can get those under control, you’ll succeed.”  They later said my advice was well-founded. 

3. Extract/settlement/reporting – Any Acquirer-side project worth its salt is going to have significant extract, settlement and reporting requirements.  The bar is particularly high on a credit extract because this acts as the billing source (by contrast, an Debit online transaction doubles as its own billing source, and any related file is only advisory in nature).  In terms of the mechanics of these efforts, you can read elsewhere on my blog why Real Systems Do Extracts (Part 1, Part 2, Part 3).  In this space, I simply will pass along the warning not to underestimate the task.  Given the right levels of staffing, you shouldn’t say “we’ll attack the extract after we get the auth model working.”  Optimally, you’ll have another individual working alongside the OLTP team.  This person would be digesting the settlement specs from the issuers (delightfully obscure and maddening!), working out FTP/delivery mechanics, figuring out how to intersect with the transaction log…all stuff you shouldn’t leave for the last week.  I like the visual picture of “driving the golden spike” (two sides working to join a railroad): one area of focus on the OLTP engine; another area of focus on the extracts; and meet up at the tranlog.  [I drone on more extensively about the mechanics of that effort in my Real Systems Do Extracts posts.]

4. Reversal model – I have a post about this elsewhere.  Let me reiterate:  Reversals matter.  They matter.  This is a huge thing.  And, they need to be implemented exactly right.  Not, “well, that will cover most cases,” but 100% on-the-money right.  So, let me save you a lot of work: don’t make an assumption about reversal models.  Have the discussion upfront with customer (if you’re a vendor) or your business owner (if implementing internally) about how to match a reversal to its original.  Don’t just make an assumption where you say something like “well, we’ll match on store, amount and card and that should find the original.”  The only thing that matters here is the point-of-sale business model.  A recent client has a model where the amount and card on a reversal could be different than the original.  [Not worth getting into the details here, but it suffices to say that it is a legitimate set of steps that could lead to this circumstance and that it’s an outgrowth of this company’s customer policies.]  So, we needed to change our matching model to reflect the in-place business model.  That was a painful for us, but we learned from it!  I hope I can prevent you from going through the same experience.

5. Database – This is a curious one.  With the advent of JDBC-style connectivity and Object Relational Mapping (‘ORM’) tools like Hibernate, we’re accustomed to minimizing (or explaining away) database requirements and complexity.  In the sales cycle, certainly, the point is always made “hey, we can use your preferred enterprise RDBMS.”  The fact is, though, that how the OLTP authorization engine interacts with the database is only one facet of how a database is employed.  Beyond that, you’ve got the question of how to address the list of ad-hoc queries and reports that will spring up.  And – one of my hot-button issues – you’ve got the really critical task of database maintenance.  It’s of utmost important to cull the tranlog and keep indices as defragmented as possible.  Speaking from a very painful personal experience (on another application), if you don’t defragment, you will wake up one morning and the application will pretty much cease to function.  Let me tell you, it’s a miserable experience recovering from that.  And it’s probably an even worse experience trying to explain why you let it happen.  So, get your arms around those database needs right from the start by involving the right people.  We’re fortunate to have great DBAs at our client sites.  You should make that experience an integral part of your team.  It’s a critical success factor.

Some reading on the jPOS site

If you like the writings on this blog, I can direct your attention to some things of interest that Alejandro has been kind enough to post on the jPOS site:

• Here's a piece called 'What is jPOS?'  The key line is this one: "jPOS can help you act as acquirer or issuer, can be strict one-to-one or one-to-many, can do passthrough processing or act as host. Not inherently, mind you. You and your team would need to build that capability on top of the jPOS framework, which does not inhibit you in anyway from any of those directions. The 'zing' you get from jPOS is that it eliminates...the grunt work associated with complex ISO8583 messaging implementations and its corresponding security requirements, thus allowing you and your team to focus on more 'value added' activities."
• In a second piece called 'Buy vs. Build' I attempted to answer the question "when does it make sense to look at a jPOS-based implementation already built by someone else vs. building one from scratch by myself?"  I came up with these four factors for you to consider in making that judgment:
  1. The number of network interfaces
  2. Your familiarity with encryption processing
  3. The complexity of your authorization needs
  4. Your inter-system responsibilities
• While you're there, take a look at Alejandro's 'Who Is Using' jPOS page.  The global spread of jPOS-based implementations is impressive.  [Please add your implementation if you've not already done so.  Your addition is important to all of us, especially those of us called upon to present a business case for a jPOS approach to management.]
• You should also add Alejandro's blog to your reader.