Andy Orrock | Payment Systems

Developers and Project Managers

Our firm, On-Line Strategies, is going through a growth spurt, the result of hard work, attention to detail, successful projects and happy customers.  We’re on the lookout for new people to join our team. 

We have two immediate needs:

First:  Developers, Developers, Developers, Developers!  These positions report to Dave Bergert, OLS’ Technology and Development Director.  [See Dave’s blog here.] Dave's in the process of putting together some ads that will run on key forums.  But if you’re a regular reader of this blog, you know what we do.  Contact Dave directly to present your qualifications.

We're of the opinion that good technical talent knows no boundaries.  So, even though our HQ is in Dallas, TX, USA, don't be afraid to pitch your qualifications no matter where you are.

Second:  We’re scouting for Project Managers.  Our PMs are payment systems specialists who: interact with customers; gather and document business requirements; identify and create add-on business opportunities; present and explain development needs to Dave and his team; review unit tests; create test plans for customers; craft go-live plans; create internal documentation and release notes; manage customer expectations; interact with other PMs to find synergies and identify like solutions; expand and refine our on-boarding processes; participate in technical sales calls; assist in production support efforts; write blogs to expand our online presence; and…you get the idea.

Put another way, our PMs do everything in the customer lifecycle except sales (we have a team for that) and design, development, technology choices and hard-core production support (Dave’s team - see above).

Send me an e-mail expressing your interest and qualifications.  Unlike developers, our PMs need to be US-based in order to travel to our clients.

We look forward to hearing from you!

Payment Systems in the Mainstream Media

Over the last week, I've run across a series of very well-written payment systems articles in the mainstream media that are worth your time.

In last Sunday's (Oct. 17, 2010) New York Times, Digital Domain columnist Randall Stross (author of many classic technology culture books) writes that "Maybe Your Old Credit Card Is Smart Enough."  Stross' article contains the best single articulation as to why smart cards (and EMV) have not caught in the United States to date (the article reviews failed initiatives by Target and American Express).  Money quote:

When I spoke with Jim McCarthy, a senior Visa executive overseeing global products, I heard some good reasons for the early adoption of smart cards in Europe and the slow adoption by Americans. In Europe, telecommunication costs in the 1980s were prohibitively high. Purchase authorizations couldn’t be done on the spot. So security was built into the card itself, or, as he put it, “moved out to the edge of the network.”

But in the United States, magnetic-stripe cards could connect to very smart mainframes at the time of a purchase. These machines conduct fraud analysis in real time. By keeping cards dumb and security centralized, the company can easily upgrade its central system at any time; changes take effect throughout the network instantaneously. Visa has 686 million cards circulating in the United States; if all were smart cards, each would have to be replaced when it made some kinds of security upgrades, Mr. McCarthy says.

That same edition of the New York Times has a nice profile of MasterCard's new chief executive, Ajay Banga.  There's some excellent reporting here by Times reporters Vikas Bajaj and Andrew Martin, who've filed their report from Mumbai as Banga flies in as sort of a 'return of the conquering hero' type event.  Bajaj and and Martin note that "[Banga's] globe-trotting identity and animated personality are in jarring contrast to previous MasterCard chief executives, who were typically buttoned up, American and, often, Ivy League-educated." 

My thought is that Banga's wide deviance from that model isn't mere symbolism:  this must be one seriously talented guy.  A friend from his Citigroup days confirms that:

[Dinyar] Devitre says he believes the fact that Mr. Banga is a Sikh has ultimately worked to his advantage, despite an occasional uncomfortable glance or comment. He says it takes a lot of conviction to wear a turban, a central tenet of Sikhism, at an American-based corporation. “People look at him and say: ‘He wears a turban and he made it to the top. He must be extraordinarily gifted.’ ”

In a third article, AP Personal Finance writer Candace Choi "lived without a bank [for one month] and instead relied on check cashing, money orders and prepaid cards."  My local daily (the Dallas Morning News) published this story with the headline "Fees, confusion come with going bankless."   Yahoo Finance went with "Living without a bank: Fees and confusion galore." 

How did Choi's experiment go?  She wastes no time with her assessment - here are her opening lines:

The nickel-and-diming never stopped.

The fees were constant: $28 to cash a paycheck. $1.50 for a money order. A dollar or more every time I swiped the prepaid cash card I bought at the drug store.

In all, I racked up $93 in fees in a monthlong experiment of living without a bank and making a go of it on the economic fringe. That works out to $1,100 a year just to spend my own money.

Choi's recounting is generating a lot of heat in the YF comments section - there are 2,269 entries as I write this post.  I encourage you to read through the comments to get a feel for the debate.

In a fourth article, The Wall Street Journal's Jennifer Waters has an informative piece entitled "Watch Out for ATM Skimming."  The Dallas Morning News picked up Ms. Waters' story through Dow Jones Newswire and published it with some nice graphics from The San Jose Mercury News that detail "how debit card skimming works."  [Included among the depictions is a rendition of the PIN pad device swap that has nailed ALDI and others.]

I'm having trouble locating those graphics online, but the WSJ has something even better: a video that accompanies the article features an interview with MagTek's Chief Security Officer, Robert Patterson.  Patterson's presence here is purely educational for the layperson.  But industry insiders know of MagTek's good efforts to promulgate point-to-point encryption ('P2PE') schemes through their MageSafe Card Readers and MagnePrint card authentication technology.

Sales Employment Opportunity Here

OLS is in the market for a sales representative.  In short, we want someone to help us get out the word about the competitive advantages of the solutions and experiences discussed here on my blog and on Dave’s.  Even better if you’re confident you are this person and you’re located in the Dallas-Fort Worth area.  That way, you could soak up the chatter and buzz in our new offices, scribble ideas on our mega-whiteboards, and hit the Starbucks across the street each morning with me and Alex.

Please refer to our LinkedIn job posting for more details.

Global Payments Sells DolEx

August 12, 2003:  Global Payments acquires DolEx for $190 million + another $10 million contingent on performance in 2003.

December 22, 2004:  Global Payments acquires Europhil for an undisclosed purchase price.

November 18, 2009:  Global Payments agrees to sell DolEx and Europhil for $85 to $110 million

Ouch.  There’s a piece of very tangible evidence that the remittance business is really sucking wind right now...especially compared to 2003 valuations of remittance-based businesses.  Back then, every remittance business calculation looked like a hockey stick graph (much like the famous global warming graph included here on the left).  Now, newspapers are filled with incidental stories of remittances flowing in the other direction, e.g., money from Mexico to family members in the U.S. jobless and without the funds to travel back home.  

HP Greenbook: BASE24 upgrade options

Check out some great analysis by HP about the BASE24 displacement market. 

Money line:

The Standish Group estimates that BASE24-eps migration coupled with a platform migration (IBM System Z9), both conducted within one year, would only be completely successful in 18 percent of the cases.

As my good friend Mitch Green of Distra says:  ACI and IBM have given everyone in the payment systems industry a huge gift.

All you guys ever do is write documents

A few months back, a customer told me in a spurt of frustration “All you guys ever do is write documents.”  This was early in our relationship.  I could see how he could form that conclusion.  We spend a good portion of the early part of the project gathering business requirements and getting those on paper.  We don’t use any special approach or ‘school’ – we only seek to get the fine-grain details on paper in as ‘plain English’ as possible. 

It is true that we can drive people a bit crazy with frequent revisions.  But we control that by using Basecamp, where it’s a cinch to corral and categorize documents and easily point to the latest revision of each one. 

Of course, at a certain point in the project, we stand aside and let Dave and his development team design and develop a solution based on what we’ve compiled.  That’s one thing we don’t do in the doc:  direct the developers to a certain design or approach.  If I’m telling Dave or Alejandro how to do something technical, we’re in trouble.  I accept that.  Like Harry Callahan always said: Man’s got to know his limitations. 

Anyway – the proof is in the results: the success of our payment systems projects lies in the strength of these documents, which serve as a firm starting point.  This isn’t just me talking: Alejandro has told me the same thing – that when he does projects not related to OLS, he misses our documentation and attention to detail.

Randy tells me that when looking to demonstrate OLS’ capabilities to a sales prospect, he selects the most applicable documents from our growing repository, does the requisite redaction and presents those in lieu of any PowerPoint deck.  He says its an incredibly powerful tool. 

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.