Store and Forward, Part II

A while back, I wrote this piece on Store and Forward ('SAF').  I had a chance to readdress the question recently, and - while I ended up reconstituting some of that write-up - I also added some new thoughts and comments.  jPOS implementers will want to know about SAF viability and 'how to' specifics of implementation, especially those of you charged with implementing ISO8583-based connections to Debit/EBT gateways like FDR, Genpass, and Fifth Third; or, to stored value card ('SVC') interfaces like inComm, GreenDot and Stored Value Systems ('SVS').  Each of these interfaces mandates SAF-based reversals as part of certification. 

As mentioned in that first piece, working with Alejandro we've been able to put together a straightforward and functional jPOS-based SAF framework.  Our model was initially put in place for a Debit/EBT gateway.  But, it was open and extensible enough that we could quickly configure new implementations for each succeeding interface that has come along that requires SAF capabilities.  Note that SAF won't be a necessity for 100% of your authorizer endpoints.  AMEX, for example, takes a pure credit card-based philosophy that reversals are something a customer handles internally...the result being that a reversed transaction doesn't make its way to the nightly AMEX settlement file.  By contrast, in the Debit/EBT/SVC world, the auth partner/endpoints point need you to be as close as possible online in terms of balance-affecting card events at points-of-sale under your control as an acquirer.  That means you need to implement SAF.

After that long intro...here's what I wrote:

Store and Forward (‘SAF’) functionality is supported within the framework and fully configurable on an interface-by-interface basis. As an example, here is an SAF configuration file taken from a high-volume Debit/EBT/Credit gateway interface at one of our client implementations:

<saf name='saf' logger='Q2' realm='saf' class='org.jpos.saf.SAF'>
<property name='space' value='jdbm:saf' />
<property name='mux' value='fdr-mux' />
<property name='flag-retransmissions' value='no'>
if MTI is in list, messages would be retransmitted as xxx1
</property>
<property name='initial-delay' value='60000' />
<property name='inter-message-delay' value='1000' />
<property name='wait-for-response' value='60000' />
<property name='max-retransmissions' value='1000' />
<property name='expire-after' value='86400'>
in seconds
</property>
<property name='valid-response-codes' value='*' />
<property name='retry-response-codes' value='91,NL,NM,N8,CE' />
</saf>

Reading through this implementation, you can see that the SAF mechanism:

• Makes use of the persistent space to store transactions to be sent
•  Uses the authorization multiplexer (‘mux’) to send the SAF requests
•  Allows retransmissions of the SAF requests to be flagged as xxx1 Message Type Indicators (‘MTIs’) if demanded by the authorizer’s implementation
•  Allows the implementer to specify an initial delay, inter-message delay and timeout (wait for response)
•  Provides limitations for when to terminate SAF sending (i.e., allows the implementer to decide when to give up and take an item off the top of the SAF queue)
•  Allows the implementer to specify what response codes constitute a ‘good’ response (i.e., when the top-of-queue SAF request should be removed from the queue as a ‘success’) and which ones should trigger a retry (i.e., the endpoint has reported some type of temporary condition that demands another attempt from you as the acquirer).

In the example above, Response Code (ISO Field 39) values of 91, NL, NM. N8 or CE will trigger a re-send of the SAF item on the top of the queue. All other return codes will result in the SAF mechanism deleting the top-of-queue item and proceeding to the next item on the list.

The jPOS/OLS.Switch implementer can obtain online ‘visibility’ into the current status of an SAF queue via the corresponding configuration of an ‘SAF Monitor.’ As an example, the SAF monitor definition corresponding to the SAF implementation described above looks like this:

<saf-monitor class='org.jpos.ee.status.Monitor' logger='Q2'>
<monitor id="saf1 FDR SAF 01 Status" delay='10000' period='30000'>
<class>org.jpos.saf.SAFMonitor</class>
  <property name='saf' value='saf' />
</monitor>
</saf-monitor>

With that monitor definition in place, system stakeholders can get SAF current status visibility (i.e., MUX state, number of items in persistent space-based queue) via a UI screen. The UI interrogates the current contents of the status table in the underlying DB to produce results like this screenshot (see line marked ‘FDR SAF 01”):