Concerning my ‘Reversal Accepted’ post from yesterday, a dedicated reader asks:
My only other thought is - if a response code with a value of “Format Error” (say a “30” in old ISO versions) is sent back – is this a form of rejection and the sender should quit sending junk? Granted an exception case we should not see these in the real world. Does this give you Accept and Reject?
Excellent point. There does need to be a way for the sender to indicate a problem. We saw this very real-life situation just the other day (unfortunately) in one of our production OLS implementations. For one very unique message class, we weren’t ‘serializing’ the items (i.e., the objects) correctly in our store-and-forward (‘SAF’) queue. That meant that for any SAF item in that queue that we persisted to disk prior to sending, we ended up formatting and forwarding a malformed SAF request. That authorizer partner rejected those transactions. There needs to be a way to implement a capability like that.
Looking at the ISO 8583:2003 specification, I see two good values to use in Field 39 for a Reject: ‘9100’ (‘One or more data element errors’); and ‘9109’ (System Malfunction’).
In our implementations, we ask the partner to provide some good ‘display text’ in Field 63 and – if possible – give some extended description of the problem in Field 123. As an example, consider an exchange like this:
Here’s the request (note my malformed DE 56 – Original Data Elements – for the sake of example):
<isomsg>
<field id="0" value="2420"/>
<field id="2" value="6049990000000001"/>
<field id="3" value="000000"/>
<field id="4" currency="840" type="amount" value="100.00"/>
<field id="7" value="1025102859"/>
<field id="11" value="000000000084"/>
<field id="12" value="20091025163033"/>
<field id="14" value="4912" />
<field id="24" value="400"/>
<field id="25" value="4000"/>
<field id="32" value="12345678901"/>
<field id="37" value="230428339648"/>
<field id="42" value="123456789012345"/>
<field id="56" value="2100000000000083200910251628591234567xyzz"/>
</isomsg>
Here’s an appropriate reject response in this situation:
<isomsg>
<field id="0" value="2430"/>
<field id="2" value="6049990000000001"/>
<field id="3" value="000000"/>
<field id="4" currency="840" type="amount" value="100.00"/>
<field id="7" value="1025102859"/>
<field id="11" value="000000000084"/>
<field id="12" value="20091025163033"/>
<field id="32" value="12345678901"/>
<field id="37" value="230428339648"/>
<field id="39" value="9100"/>
<field id="42" value="123456789012345"/>
<field id="63" value="REJECTED"/>
<field id="123" value="Field 56 (Original Data Elements) is malformed"/>
</isomsg>
So: Reversals can be Accepted or Rejected. Still, the main point stands: no approval/deny logic should be exposed to the originator.
Recent Comments