Store and Forward, Part III

Alejandro just committed his Store and Forward ('SAF') model to the jPOS-EE code base.  I've written in the past about our very positive experiences with this piece of software.  Together, Alejandro and I were able to collaborate on our experiences with payment systems and - by working smarter not harder, with a sense of urgency and a bias for action - we ended up with a configurable, enterprise-class SAF mechanism battle-tested and ready for use at high-volume acquirer locations. 

Who needs SAF?  Any merchant or acquirer connecting to a Debit/EBT Gateway or Stored Value Card ('SVC') issuer/authorizer needs it.  Well, that's the need expressed from a business perspective.  From a technical implementer's perspective, if you're presented with the task of installing an ISO8583 interface that requires you to implement reversals (MTI 04xx) or completions (022x), then you must 'SAF' these transactions (okay, I've picked up the habit of some of our customers of using SAF as a verb...we talk about 'SAF-able transactions'). 

Let me point out one thing:  from a strict ISO8583 definition standpoint, there's a distinction drawn between real-time reversals (0400) and SAF-based reversals (0420).  In practice though, my experience is that gateways and authorizers choose either the 0400 or 0420 without distinction....everyone goes the SAF-able route, but some implement it as the 0400, others as the 0420.  So, get that definition clear before implementing.  FDR North, for example, uses the 0400 and it is definitively SAF-based.  Nothing wrong with that.  Just get understanding before implementing. 

Okay, now another thing about SAF:  you must understand and communicate to your business owners the "asynchronous nature" of SAF.  What I mean is:  the response from the gateway/issuer (for example, the 0410 response to the 0400...or the 0430 to the 0420) IS NOT coming from the issuer indicating that the transaction has been processed financially...rather, it's from the gateway (or front-end) indicating that that they received the SAF request and they've parsed it correctly.  Now, asynchronously and subsequently, that transaction may fail for a myriad of reasons (for example, the reversal can't be matched up to a matching original).  But the gateway's responsibility is to 'ACK' your request so that you can take it off the top of your queue.

Oh, one more thing from experience: take utmost care that you're not sticking a crap record in the SAF queue.  It'll crater the entire channel apparatus until you get rid of that record.  Let me give you an example: we were in a position where a store-based system was sending us requests featuring 22-position PANs and/or Track II stripes greater than 37 positions.  In each case, those definitions exceeded the respective ISO field definitions.  Now, the real-time request failed once, which is (relatively) okay.  But that failed request raised an exception, which dropped through our code and resulted in a related reversal request being placed into our SAF queue.  Now, that's a debilitating occurrence, because the channel connection drops every time we try to format that outgoing reversal request. 

The lesson there is to do as much checking and vetting of the ISO message construction as you possibly can while building it.  Specifically here, we truncate the PAN and Track II to their maximum lengths of 19 and 37 positions respectively.  As Alejandro aptly puts it, the acquirer's guideline here should be:  "Protect yourself and let the issuer raise the objection."  Exactly.