Andy Orrock | Payment Systems

Discover joins the Life Cycle Identifier club

I've been taking a look at Discover's latest authorization and settlement specs.  It's their v08.01.  One of their biannual upgrades.  "Biannual" is one of those weird words that can mean two entirely different things: twice a year or once every two years.  Honestly, I don't which of the two apply here, but suffice to say that we've got some changes to make in April.

Our OLS.Switch client gateways their auths through FDR North, so most (not all) of our impact is on the settlement side.  Discover has done a really good job here with the packaging.  I was pleased to see their document entitled "Differences Between 7.1 and 8.1,' which does a good job spotlighting the change areas.  One thing that stuck out immediately is that they're getting rid of their 'Group Header' concept.  Thank God.  I got a laugh out of the Discover rep when I expressed that reaction.  The Discover implementation is a good one - light, clean and well-documented.  But those Group Headers were always an unwarranted complication.  It'll be good to see the back of them.

The other far more interesting note is that with v08.1, Discover has joined the Life Cycle Identifier club.  Basically, a Life Cycle Identifier is a value that an authorizer passes back to you in their online response; subsequently, you've got to plop it somewhere (per the specifications) into the corresponding settlement record.  Visa did this back before of the turn of the century (1992, to be exact) with their PS/2000 project.  MasterCard, of course, soon followed suit with a similar concept.  AMEX's CAPN program - which kicked off in 2006 - did the same thing.  In fact, the concept is so prevalent that the ISO 8583:2003 specification has allocated Bit 21 as the designated spot for it.  We also get a much more precise definition there:

Transaction life cycle identification data is a unique identifier used to match transactions across message classes, e.g. authorization to financial presentment or financial presentment to chargeback. It shall contain the same value in all message classes throughout a transaction's life cycle.

Excellent.  Those Swiss are so precise.  Alejandro is also making use of it in his IMF concept (now under development in jPOS' labs).

Discover puts their identifier - which they call their 'Network Reference ID' - into a different place: Field 48, which ISO defines as 'Additional Private Data.'  It's certainly a good practice to put it there, too.  Discover strings together a series of data elements in Field 48.  Network Reference ID sits in positions 11 through 25.

The complicating factor are those situations where your auth goes one way and settlement another.  Like in this specific situation where we gateway Discover auths through FDR North.  In order to implement this upgrade, we're going to have to find out how FDR North maps the Discover reply (we don't see that, the gateway partner does) to its own reply, which is what's visible to us acting as the acquirer.  I suspect this will be somewhere in their Field 63 (FDR North has a series of Tables defined in Field 63).  Once we've got that knowledge in hand, it's a straightforward implementation because in OLS.Switch we've got a very well defined process for handling life cycle identifiers.

Auth goes one way, settlement the other

One of our OLS.Switch clients called me earlier this week perplexed, wondering how it could be that they sent Discover authorizations, got them approved, then had the transactions rejected for "Invalid Merchant" when they sent them that night in the settlement file.  The answer lies in their operating model. 

This client authorizes Discover purchase requests through the FDR North payment gateway.  You can see that configuration clearly specified in our Routing table (see UI image at left).  [Under the covers, the Routing information is constructed from the 'binrange' and 'cardtype' SQL tables in our jPOS-EE framework.]  But subsequently, we create a settlement file of Discover approvals built to Discover's specifications and FTP it directly to them. 

Of note is that this is the only major card type at that implementation where auth goes one way, settlement goes the other.  MasterCard and Visa, for example, go to FDR North for auth and settlement, and AMEX is both authorizer and settler of their own card.  [Some clients elect to authorize AMEX over their gateway, but here the economics made sense to set up a direct authorization link to them.]

Anyway, the key to the issue is the value of the all-important Merchant ID ('MID') - in the auth, that's the data that goes into Field 42.  Since we are gateway-ing the authorization requests through FDR North, the MID (and the TID, for that matter) sent in all auth requests to FDR North - regardless of card type - is the single MID/TID combination assigned to that location by FDR.  Behind the scenes, FDR North's gateway takes care of mapping that MID/TID to the appropriate Discover-assigned MID while creating the related 0100 Auth to send outbound to Discover. 

During the subsequent settlement process, however, we create the Discover settlement file using the Discover-assigned MID that we have on file in our OLS application (in our 'merchant_external_info' SQL table).  In other words, two different data sources are in play over the lifecycle of the transaction.  That second value (i.e., the one in merchant_external_info) proved to be incorrect for two store locations, thus resulting in the the rejected transactions.

The jPOS MUX Pool, Part 3

See previous posts on the jPOS MUX Pool in Part 1 and Part 2 of this series.  This one is quicker.  I just wanted to pass along the little test I sent to our client after we made the changes discussed in Part 2:

1. Install
2. Ensure clean start-up
3. Watch traces for, say, 30 minutes to ensure echoes get generated correctly on both channels every 90 seconds.*
4. Try a CMC transaction.
5. STOP the ‘A’ channel
6. Do a transaction.  [Should get authorized via the ‘B’ channel.]
7. START the ‘A’ channel.
8. STOP the B’ channel.
9. Do a transaction.  [Should get authorized via the ‘A’ channel.]
10. START the ‘B’ channel.
11. Do a transaction.

* On Step 3, where I say "every 90 seconds," it's because 90 seconds was what we chose as our echo-interval.  Your value may differ here, but you get the idea.  You know your MUX Pool implementation is NOT working if the echoes get sent to one channel or another (but not both) over a period long enough to prompt a peer-disconnect from the other side.

Don't put this into production until you confirm that this works.

The jPOS MUX Pool, Part 2

I've written in the past about when and where it makes to make use of the jPOS MUX Pool.  We've recently encountered a second situation in our OLS.Switch project world where it makes sense for us to do it.  I'll make this really easy for you: Go for the MUX pool when the following three things are true:

1. Your MUX implementation has more than one channel.
2. The authorizer employs what I call a "tight disconnect model," i.e., if no traffic over a channel in X minutes (typically like 3 - 5 minutes), they forcibly rupture the existing connection with a peer-disconnect.
3. You have ability and tools to keep the connection alive with a Network Message Request (for example, with an Echo Request).

Before proceeding, this post assumes:

1. You've read my On-Boarding Guide.
2. You've already got a multi-channel MUX (the plain vanilla kind) implemented.
3. You've read my previous post on this subject (see reference above).

To go from the plain vanilla multi-channel MUX to the MUX Pool, you do the following things in the deploy dir:

1. Add a MUX pool definition.
2. Add a second MUX definition.
3. Modify the first MUX definition.
4. Modify the channel managers.
5. Modify the logon managers.

Exactly what you do is best described by showing you my SVN check-in that shows you the diffs.  I've annotated it by highlighting the differences within the existing files in red and showing you the new items in blue.  I think this is important because upon having to do the exercise a second time, I'm struck by the fact that my original post wasn't as precise as it could have been in terms of specific focus on the diffs.

Two other important notes:

1. In your LogonManager code, you have to take care to ensure that each channel gets a unique "echo space key."  For example, in our Stored Value Systems ('SVS') implementation, our SVS LogonManager instance is written in such a way that we end up with distinct keys in TSpace: "SVS_ECHO.svs-logon-mgr" and "SVS_ECHO.svs1-logon-mgr" (the code picks up the name of the specific logon manager instance it is running).  I learned the hard way that if your Logon Manager doesn't take care to do this practice, your MUX Pool won't behave as you want it to.
2. If your connection features a SAF component, you've got to renumber it.  What I mean by this is that typically our SAF component is called something like 20_xxx_saf.  But you'll notice that the MUX Pool (see check-in examples referenced earlier) is numbered 25_xxx_mux_pool.  These things load in numerical order.  You need the MUX to get totally resolved before deploying the SAF.  Therefore, in our MUX Pool implementations, we've shifted the related SAF item to 30_xxx_saf to accomplish that objective.

The Easter Bunny Effect

Our biggest OLS.Switch acquirer-side client continues to convert stores (picked up in a big acquisition) at a healthy clip.  We now stand at 4,447 separate retail locations spread across the four US continental time zones.  Last year at this time, we were at 3,300 or so.   We'll end up at 5,000 or so when the conversion project is complete.  Each of these locations has up to a dozen separate cashier lanes. 

Put this sizable store increase together with the Easter Bunny Effect and the result for this jPOS-fueled implementation is a significant transaction bulge on Good Friday (939,271) and Holy Saturday  (1,026,776).  That's a lot of chocolate Easter Bunnies and a mad sugar rush across the nation on Sunday morning.  Even Maundy Thursday saw 864,471 transactions, though - I must admit - I'm only mentioning that because I've wanted to use Maundy Thursday in a sentence ever since I saw it on a church billboard while driving  through Dallas here last week.  [Who knew?]

So, for you jPOS service providers out there who are doing your thing for large general merchandise retailers: add Holy Saturday to your pantheon of crush days.  It comes in at #3 on the charts behind permanent #1 of December 24th (procrastinating or overworked parent effect) and #2 of February 14th (the almost-forgetful boyfriend/husband effect).