BuyVersusBuild

From jPOS.org

http://jpos.org/images/team/orrock_s.jpg /From a post by Andy Orrock in jpos-dev mailing list,

I posted some thoughts to the group regarding a query similar to yours a few months back. List member Dave Bergert was kind enough to post my answer to the jPOS Wiki, so I thought you might like to check that out as a good next step. See: WhatIsjPOS.

In terms of your specific implementation (as much as I can glean from your e-mail), I can add the following factors for you to consider as to whether or not you're going to be able to 'build' within a six-month window vs. going the 'buy' route (specifically is it relates to my experiences building a product using the jPOS framework):

These are presented (loosely) in order of relative importance

1. Number of network interfaces - Will all transactions come to you from a single gateway, or will you have multiple connections to various networks? If you're contemplating a gateway, then Build is still in the picture. If you're needing to go live with two or more network connections Day 1, then Buy (again: my opinion here, not fact) would be your best bet - not because of jPOS' inability to help you manage that task, but rather because you've got two or more third-party certifications to manage, and those can be lengthy and outside of your ability to completely control them. (Note that, for example, each interface may employ differing models for reversal matching and pre-auth-completion matching. These nuances sometimes don't reveal themselves until the certification stage.)
2. Familiarity with encryption processing - Do have experience interfacing with Hardware Security Modules ('HSM')? Handling Triple DES-enabled key changes from network partners? Calculating offsets from customer-selected PINs? Accepting DUKPT-enabled card activation transactions? If that all sounds familiar to you, then Build is a possibility. If not, than consider the Buy route, because coming up to speed on these complexities may not be possible in a six-month period (given everything else you're going to have going on).
3. Your authorization needs - Are you simply going to maintain balances and make decisions based on whether the money is in the account? Or, are you considering a more robust engine that allows you to (for example): assess internal fees (for approvals and declines); set limits for number and/or dollar amount of transactions per business day; restrict allowable transaction types based on card status; assign cards to specific programs (each with their own limits and fees). Obviously, the more feature-rich you want/need to make your authorization engine, the less Build is an option and the more Buy looks like the safer path (assuming the six-month window is sacrosanct).
4. Incidentally, the chief challenge of any authorization engine lies in a way to succinctly and accurately capture increments and decrements to a starting balance (all of us who have built an issuer-side jPOS-based system have faced this challenge, and we've all ultimately written something custom for it). You may want to consider checking out an ancillary jPOS project regarding a 'work in progress' tool to tackle that challenge - it's called MiniGL. You can Alejandro's intro to the concept here: MiniGL
5. Your inter-system responsibilities - Will your intended system sit as relatively isolated part of your enterprise? Or, will it need to interact with in-place back-office accounting, settlement, adjustment, card management systems? If your inter-system responsibilities are relatively low for the six-month target, then Build is an option. However, if your burden is high, then consider the Buy route (lest, you'll spend a good chunk of your time managing those inter-system relationships and hand-off points, and maybe not have enough time to put your focus where it ought to be (building an engine that guarantees timely, accurate authorization and logging).

I hope this is helpful.

Andy Orrock