Andy Orrock | Payment Systems

Implementing MethCheck (New Initiatives, Part 2)

One of the gratifying things about the maturation of the OLS.Switch payment switch solution is that our clients have the confidence to come to us with challenging new point-of-sale payment initiatives.  Recently, we had one come our way that was quite unique.  It's called MethCheck, a new service from Appriss, Inc.  As you can tell from the service's name, this new initiative involves tracking the sale of Pseudophedrine.  This particular client is a large pharmacy chain, and they're being mandated by the state of Kentucky (surely only the first state of many to insist on this type of service) to implement it.  Here are some of Appriss' key talking points about the service:

• A single point of contact for managing compliance, ensuring pharmacies are submitting all required data to law enforcement.
• Tracks PSE purchase limits, any aggregate limits required by the law, box limits, pill counts, and acceptable forms of identification.
• Multi-state Compliance Manager (MSCM) keeps up to date with new PSE legislation.
• Communicates with state electronic PSE repositories allowing pharmacies to stay compliant without maintaining multiple interfaces.

Here's a nice diagram (see pop-up at left) from the Appriss site describing their solution.  OLS.Switch in this setting is just a piece of the orange box (as marked-up by me) in the upper-right corner.

My colleague Dave Bergert has an excellent post on his blog describing the nitty-gritty details of how we got this very non-standard message set flowing through our application.  Most notably, he relates how we used jPOS' FSDMsg class to get the job done in less than a week (see here for a post I did about Extracts - part of of my 'Real Systems Do Extracts' series that ends up spotlighting FSD). 

As a payment systems manager, the key takeaway here is that by implementing a jPOS-based solution, you become the go-to-guy (or gal) in your organization for anyone envisioning innovative uses of your payment systems infrastructure.  MethCheck is far afield from Debit/EBT, for example, but we achieved co-existence without jeopardizing what's already in place.  This is good news for you because we know the frustrations of those of you managing legacy payment systems.  You tell us it always seems to be "six months and major bucks" from your vendor for any initiative of this scale.  And for those of you outsourcing, well, best of luck getting some attention.

I want my DTV (New Initiatives, Part 1)

Here's the first of a series of three posts letting you know about some of the new initiatives we're tackling for our OLS.Switch clients.  This one has to do with compliance to the National Telecommunications and Information Administration ('NTIA') Coupon Program. 

The subtext to these posts drives to the heart of why, as a manager, you want run your own payment switch.  In short, you control your own destiny.  You can respond to any new initiative with alacrity, rather than fret and concern about when your processor or vendor will get around to thinking about you again (and looking rather ineffectual when you try to explain to your line-of-business partner why it'll be another nine months and/or $200k to even get mindshare).  With the cost of relevant hardware being a commodity these days, there's been a dramatic enlarging of the circle of enterprises who can and should consider running their own payment switch.  As I've mentioned ad naseum on these pages, we've got a client running over 1,000,000 transactions a day at peak (soon to be their 'new normal') and doing it on $28,000 of core server technology.  I recall the not-too-distant days when a similar-sized enterprise required a $14m initial investment in hardware, software and other build-out considerations in order to get into the game.  Moore's Law + powerful open source building blocks like jPOS + convergence towards Intel-based server computing + the flexibility offered by JVM-based computing + knowledgeable payment systems professionals = why the hell wouldn't you consider running your own switch?   

So, in this case, our client is sitting running their version of OLS.Switch.  Among various other facets of functionality, the thing runs three-quarters of a million transactions a day through a Debit/EBT/Offline Debit/Credit payment gateway to FDR North.  Now comes the NTIA requirement.  Instead of me fumbling through a re-explanation of the program, here's a nice program summary from Visa:

After February 17, 2009, the Federal Communications Commission (‘FCC’) will require full power television stations across the nation to cease analog broadcasting and begin broadcasting solely digital transmissions. An estimated 20 million American households rely exclusively on over-the-air broadcasting received by analog televisions not connected to cable or satellite services. In order to continue to receive television programming, this change will require the acquisition of a digital-to-analog converter box, a digital television, or cable or satellite television service.

To help consumers defray the cost of acquiring converter boxes, the U.S. government has authorized the NTIA to create a digital-to-analog converter box coupon program. After January 1, 2008, the NTIA will issue up to 33.5 million electronic coupon cards with a value of $40 to be used toward the purchase of a Coupon Eligible Converter Box (‘CECB’). These cards will be distributed with open eligibility on a first-come, first-served basis initially. Once initial funds are expended, more coupons will be available to over-the-air-only households.

Retailers choosing to participate in the sale of these digital-to-analog converter boxes may want to accept and redeem these coupons, which will be issued in the form of a non-branded plastic mag-stripe card. In total, there are six coupon redemption alternatives that are available for retailers to choose from.  VisaNet will offer support for three of the six coupon redemption alternatives.

[For more information, see Visa Business Review, October 2007.]

As mentioned in the Visa passage, the NTIA program offers six approaches to coupon redemption.  Visa supports three of them:  UPC@Auth; UPC@Clearing; and Sales Detail Reporting (see pop-up at left which depicts Visa's compare/constrast look at the three options).  Our client was looking for the approach that was the least distruptive to its store systems infrastructure.  UPC@Auth would require the store systems team to change their interface to OLS.Switch to start providing us the UPC info.  So, that's out (too high on the change-o-meter, especially with all the other important initiatives going on).  And, in the OLS.Switch operating model - where we do host draft capture ('HDC') from our framework for nightly extract to FDR North - there's essentially NO difference impact-wise between UPC@Auth and UPC@Clearing.  We would need to collect the UPC at auth time either way.  Sales detail reporting is the winner here:

1. Auths can come in just as they do today.  The coupon comes into OLS.Switch as a Visa or MasterCard-looking auth for $40.
2. We put a small change into OLS.Switch to reject the transaction locally if != USD 40.00.
3. We also made some entries to our BIN range table to identify the TV Converter transactions (we flag them with a specific 'cardBrand' of "TV").  These changes are made real time and require no down-time.
4. We route all transactions where cardBrand = "TV" out via our already-in-place multi-channel jPOS MUX connection to FDR North.
5. FDR North routes to TSYS, who - to the best of my knowledge - is providing online authorization of the TV Coupons on behalf of NTIA contact award winner CLC (the erstwhile Corporate Lodging Consultants).
6. We record the authorization response in OLS.Switch's tranlog, then extract it that evening for inclusion into nightly settlement activity.  [In this case, we wrote a new internal extract program extension to create a new file for delivery to our client's Data Warehouse.  These are all Approvals where cardBrand = 'TV'.]
7. [Not related to OLS.Switch...] Our client matches up this sales data we provide with a second asynchronous internal data stream from the stores that is already capturing UPC data; then, it will merge this data into something it'll deliver daily to CLC.

Only in Step 6 were we required to make any programming change, and that was 20 minutes to change, test and ready for prod branch inclusion.  In fact, when the Coupon program was under discussion with our client, FDR and CLC, there was a big conference call about how to approach, how to test, which option to choose, would the transaction get through FDR without a UPC, etc., etc., etc.  Lots of talking.  Knowing how OLS.Switch would handle this, I recommended that our client immediately add the 'TV' to the cardtype/binrange tables and then quickly walk down the street to the store and try it in production and see what happens (see resulting full table at left - this is the cardtype + binrange tables presented as a cohesive whole in the OLS.Switch UI, which leverages the strengths of the jPOS-EE offering).

That's exactly what they did.  Later that day, FDR was able to confirm that they passed the transaction along successfully to TSYS, and CLC got TSYS to confirm that they'd received and processed the transaction without issue.  Our client shared a good line with me that "this is the first time we went into production without certification...without testing, in fact!"  And, here, it was a good thing.  Indeed, it's been another month or two ensuring proper registration with the right governmental agencies.

The three most common jPOS questions

When people are directed to my blog, it's usually for one of two reasons:  They're trying to figure out how to make their Hardware Security Module ('HSM') work (I've got a lot of HSM tips and insights buried in these pages); or, they're curious about some aspect of jPOS.  For the heavy technical discussions about jPOS, you're probably best served by checking out the jpos-dev mailing list (and its archive).  But I try to address the user, business and management side of jPOS here in these pages.  So, I see these types of hits on my blog:

1. "Download free jPOS manual" - Please support jPOS by buying the Programmers' Manual.  At $50, it's a great investment.  Definitely a fantastic mean-time to payback on that $50!  [See mean-time to payback discussed here.]  As Alejandro points out "Whether you're new to jPOS, you're evaluating it for your next project, or you are already running it in production, the jPOS Programmers' Guide is a must-read.  It currently has over 165 pages that cover the most important jPOS components, including...components such as Q2, the Spaces, the UI framework and the TransactionManager." 
2. "jPOS example" - I've got lots of good examples here on these pages.  You can read about "onboarding" an authorization interface, implementing store and forward ('SAF'), implementing the jPOS ISO Packager, and many other topics.
3. "jPOS production transaction volume" - These are people looking for enterprise-class success stories to help make their business case.  Specifically, they are looking for metrics of enterprise-class, real-life jPOS implementations to see if it'll handle their proposed production volumes.  I recently wrote about one 'real life' transaction environment.  That environment (as described) is now comfortably processing up to 900,000 Debit/EBT/Credit (MasterCard, Visa, AMEX, Discover) transactions a day, with sustained peaks of 25 TPS over 30-minute durations.