Partial Auth and the Blackhawk Effect

I’ve discussed Partial Authorization ('Partial Auth') projects in the past, specifically in the context of AMEX’s capability to provide partial auth or 'balance return' of their gift cards as part of an AMEX CAPN certification. 

Over the past two weeks, I’ve been analyzing the “2007-2” version of the FDR North ISO specification.  I noted, vs. when we first certified one of these interfaces in 2006, FDR North now includes support for partial auth of Visa, MasterCard and Discover Gift Cards.  This addition reflects the growing importance and market slice of Gift Cards.  All you have to do is look at Blackhawk’s predicted growth trajectory (in a word:  huge) to know that Gift Cards are going to become an increasingly large component of the transaction mix.  Walk into any grocery store or the two biggest pharmacy chains these days...see that Gift Card Mall?  Notice how they all look alike?  One word: Blackhawk.

One of our OLS.Switch clients had some analysis presented to it by AMEX:  since we'd certified originally for Balance Return (not Partial Auth, because of some infrastructure issues described below), 22% of all AMEX Gift Card rejects were due to Insufficient Balance.  This stat has the ring of truth to it.  I did some spot-checking of AMEX transactions at that site and saw that the average AMEX ticket is approx. $35.  I suspect that a fair number of consumers – upon having their card rejected for insufficient balance – simply walk away from the sale.  If you had even 10 walkaways a day throughout the chain (probably within reason given that this client does up to 50,000 AMEX transactions a day), that’s $127,750 in lost sales per year. 

And that's just AMEX.  Now, gift card penetration is spreading dramatically to the bankcard brands (VI, MC, DS), spearheaded mostly by Blackhawk’s tremendous growth and its massive penetration of the supermarket space.  How dramatically?  How does a predicted $20 billion in sales by 2012 grab you?

[To clarify:  You activate, deactivate or refresh a card via a product activation/sales channel network like Blackhawk, but subsequent card usage for purchase of goods is performed along "regular" auth channels like FDR North, Fifth Third, AMEX, Discover, etc. depending on card type.  In fact, the acquiring system (do the needful and build it or by it in jPOS!) can't discern a 'regular' check card or credit card from a Stored Value/Gift Card...you route by BIN and put that burden on the Issuer.]

One available option is to implement and supply the ‘Balance Return’ feature.  FDR North and the others now have this option, just like AMEX introduced in CAPN.  The cardholder then has visibility of their remaining balance, allowing them to tailor a second purchase attempt.  However, that strikes me as a half-measure.  If you’re going to pursue a project like this – which requires coordinated changes throughout the entire transaction sequence – you'd get better value going for partial auth.

Assuming a retail-based, multi-lane acquirer configuration where the store systems are in your span of control, here are the features of a Partial Auth implementation project (I use FDR North and AMEX here as specific implementation examples; your implementation will vary on field details, but the general concept will be the same):

• The Store System will need to implement split tender capabilities for VI, MC, DS and AX card types.  The Store System (and your payment switch for that matter), have no idea what cards are Gift Cards – only the issuer knows and makes that determination.  We’ll only know for sure on the response.
• The Store System will need to signal to the payment switch which devices have partial-auth capabilities – you'll need to re-purpose or create a field in the incoming request to signal to your payment switch if an origination point is capable of supporting a partial authorization response.  [This is important, because the response will be constructed differently if partial auth is in play.]  You can’t format partial auth responses to a device that doesn’t support it.
• Your payment switch team needs to re-certify its remote auth interfaces (e.g., FDR North, AMEX, etc.) interfaces for Partial Auth – For transactions from origination points where the store system has indicated that it’s partial auth-capable, you’d format the Auth requests (1100 to AMEX, 0100 to FDR North) with the small differences in the request indicating that you’ll take a partial auth (Trigger Table 63.68 in the FDR North Auth; Partial Auth indicator ‘181’ in Field 24 of AMEX Auth).
• Switch out Credit Card Terminal Reversals and Voids for FDR North – Now, we start to get into some very interesting divergences in the AMEX and FDR North models.  With the advent of Partial Auth support, FDR North will start accepting Credit Card Reversals….but only *store-based* reversals (i.e., not Host Timeouts like the Debit/EBT implementation).  This is important.  Though the real “letter of record” in Credit/Offline Debit is still the settlement file, since we’re talking about real cash on the card vs. a credit line, it’s important to implement this feature.
• Configure Host-based timeouts (aka, 'query_or_reverse') for AMEX – AMEX also will start wanting reversals, but their model is different: what they want to see are the host-based timeouts.  I’ll also make note that these are fairly odd ones; instead of serializing the request with a new reversal MTI (1420 here), it’s sort of a brand new request – different processing code (004000) and a new STAN…not your typical timeout reversal, but readily implementation within a well-thought-out jPOS reversal framework (discussed with my personal TMI style here).
• You'll need to alter your TransactionManager to address the two model changes discussed in the previous two steps.
• You'll need to alter the logging to the tranlog of your payment switch – instead of populating the 'amount' column on your tranlog with the incoming amount on the request, on FDR North and AMEX interfaces you will now want the amount value returned (comes back in in Field 4 of the response; this is how all the interfaces work - this field in the auth/purchase reply is the authorized amount) as the approved amount (logs in the 'amount' column).  I’d also suggest you take this opportunity to create a new transaction column called originalAmount and populate it whenever the approved amount is different than the original requested amount.  That will allow you to track, query and report on partials.
• Lastly, create a variable Response back to store: IF the device has signaled to the host that it’s partial auth-capable AND the issuer has provided Balance and Approval Amounts on the reply, THEN you would format a response back to the device (our client already had one defined for its branded gift card, so we'll seek to leverage that); ELSE the store would get back the current “plain” response.  You may want to discuss with the store systems team if they additionally would want a flag indicating what response type is in play.