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.
Comments