Andy Orrock | Payment Systems

Payment Systems Podcast, Episode #2

My OLS colleague Dave Bergert (author of the Payment Systems Blog) and I got together in Dallas recently as part of our preparation for the upcoming ATM, Debit & PrePaid Forum 2008.  While together, Dave arranged a second episode of our Payment Systems podcast series.  You can read Dave’s introduction and overview of the session and get the MP3 link to the recording here.  It’s about 40 minutes in length.  If you’re tasked with building or supporting an enterprise-class payment switch, I think it’s well worth your time to listen in. 

One big topic in this episode is Merchandise Returns.  Dave talks about some of his recent real-world retail experiences and frustrations with Return policies and how those ought to translate into good payment systems practices.  The treatment of merchandise returns is something that I’ve blogged about in the past.

Legacy Payment Switch Conversion (Part 1)

Over the past couple of years, I’ve been involved in some successful ‘legacy payment system’ conversion projects.  In fact, that’s the one of the main themes of my blog: detailing the transition of the payment systems domain away from specialized architectures and computing practices and into the mainstream of computing on the code, server, database and project fronts.  Now, with the unveiling of some notable strategic shifts by the payment industry’s largest software vendor, interest in legacy payment system conversion has grown more acute. 

In the 80s and 90s, the two dominant payment systems offerings were S2 Systems’ ON/2 (and its successor, OpeN/2) and ACI Worldwide’s BASE24.  Our successful conversion customers are those who saw the writing on the wall in regards to the future of these offerings.  They made proactive, strategic decisions to look at new-generation alternatives.  Now, ACI has put the writing on the wall in large capital letters: having bought a flailing S2 a couple of years ago, they’ve already issued end-of-life (or ‘sunset’) letters to all ON/2 and OpeN/2 customers.  You can’t say this is a bad strategic move: they took a competitor out of play at a cost that has probably already paid for itself.

They’ve gone one step further and EOL-ed BASE24 as well.  To clarify what I’m talking about here:  BASE24 is the “[ACI] product line [that] operates exclusively on Hewlett-Packard Company ("HP") NonStop servers.” [Originally, these were Tandem computers until H-P bought them….or, more correctly, until Compaq bought Tandem and H-P turned around and bought Compaq.]  That’s taken from ACI Worldwide’s 2007 10-K.  ACI is phasing out BASE24 and going all-in on BASE24-eps.  Again, the official product description from the ACI’s 10-K:

BASE24-eps is an integrated electronic payments processing product that supports similar features as BASE24, but uses a more modern set of technologies and architecture. BASE24-eps uses an object-based architecture and languages such as C++ and Java to offer a more flexible, open architecture for the processing of a wide range of electronic payment transactions…it represents the future platform to which current BASE24, ON/2, OpeN/2, and AS/X customers are expected to migrate over time…[it] operates on International Business Machines Corporation ("IBM") zSeries, IBM pSeries, HP NonStop, HP-UX and Sun Solaris servers

The language there (“it represents the future platform to which current BASE24, ON/2, OpeN/2, and AS/X customers are expected to migrate over time”) hints at official EOLs for those platforms, but dances around the subject.  The latest 10-Q from the company is clearer on the subject:

We are maturing many of our retail payment engines. These products were developed or acquired by ACI over several years and include BASE24, TRANS24-eft, ON/2, OpeN/2 and ASx. Our strategy is to help customers migrate to our next-generation BASE24-eps solution as we discontinue standard support for previous products.

Well, that’s relatively clearer.  The word ‘maturing’ here is ACI’s gentle way of telling customers that it’s yanking support.

The upshot?  If you took a snapshot of the year 1992, BASE24 and ON/2 split the lion’s share of the payment switch marketplace…loosely along an 80/20 line re. relative market share.  Now, anyone from that era still operating on those platforms is being put into play by ACI. 

There are three possible directions for organizations put into this position:

1. Stay with what you’ve got and use third-party support organizations (or your internal team if you’ve built up the requisite expertise) to do the needful.
2. Do the proscribed ACI route – do the BASE24-eps thing and enter into the ACI/IBM ‘migration factory’ (more on that in a subsequent post).
3. Consider your strategic alternatives in the marketplace.

If you’re reading this post and have come this far, I suspect you’re doing your due diligence regarding option 3. 

Cardholder Data Flow

Here are two high-level diagrams I did recently which trace the flow of cardholder data (issuer side implementation, acquirer side implementation) within OLS.Switch, our host-based payment switch application.

I Want My DTV (part 2)

It’s pounded into me every night during my local news that the transition of over-the-air television to digital service is taking place on February 17, 2009.  In fact, one community – Wilmington, NC – agreed to be a guinea pig.  They pulled the trigger yesterday.  For those of you wondering who’s left watching TV over-the-air, the FCC has identified a number of communities where that segment of the market comprises over 15% of viewership.  Constituencies include college students, viewers in rural areas and the elderly.  Plus, many of us have that one television tucked in a workout room or a basement that’s not hooked up to cable or satellite.

The US government is giving out $40 coupons to defray the cost of obtaining the digital converters.  For a good overview of the IT and home set-up implications, can I suggest the following three pieces:

• My colleague Dave Bergert has a good and typically comprehensive piece on his in-store experiences with the converter box coupons.  
• In my DTV, Part 1 post, I discussed in depth how we helped implement the TV Converter Box Coupon Program in our of our OLS.Switch acquirer-side payment processing implementations.
• BusinessWeek’s “tech maven” Stephen Wildstrom discusses how to set up the converter at home…and what to expect.  his conclusion: 

  On the whole, the converter is acceptable for analog TV sets you rarely use. But if you want the best from over-the-air TV after the analog cutoff, give yourself a treat. With high-def, 26-inch LCDs available for $400 to $600, the price of updating is not too dear.

On the Horizon: Half a Billion Served

We’re rapidly approaching a notable milestone at our largest OLS.Switch acquirer-side payment switch: the ‘half-a-billion transactions processed’ mark.  With our application rollout complete and our client’s significant store-onboarding exercise successfully in the rearview mirror (the result of a recent merger), we’re fairly leaping towards the milestone in daily gulps of nearly a million. 

I did some in-depth analysis of last Friday (Sept. 5, 2008).  At 1,013,817 transactions, this now constitutes a fairly typical Friday at this processing location.  In the referenced spreadsheet (presented here as a PDF – contact me if you want the source spreadsheet), I group by extracted vs. non-extracted transactions, and then by subclass (e.g., Debit/EBT vs. Credit vs. a slew of internal applications we put under the rubric of ‘EV’), card type (here, for example, Debit, EBT Food and EBT Cash are broken out), and card brand (used for situations like Credit and certain Stored Value applications where we require further break-out by BIN).

What strikes me is the recent proliferation of rows in these daily summaries.  It’s representative of the increasing scope and flexibility of our implementation.  We’re up to 52 lines now, thanks in part to a trio of recent new initiatives: our Digital TV Converter Coupon project; the considerable work to implement Flexible Spending Accounts; and Dave Bergert’s MethCheck initiative (an XML-based integration that accesses Appriss, Inc.’s database of pharmacy logs from across the country).