In OLS' role as an Acquirer-side payment switch, we engage in a lot of practices that fall into the category of what I call 'Defending the Transaction Originator' (not to be confused with 'Defending Your SAF'...though the principles of protective measures are the same). These practices have led to a group of Internal Result Codes that I refer to as the 'Non-Approval Approval' range (4xxx in the OLS.Switch framework). We have:
4000 (FORCE_APPROVAL) - Whenever we get a message that comes from the originator's SAF queue, we're obligated to approve it. But there are situations where we may encounter a legitimate error, most typically in timeout reversal processing where, more often than not, we can't find a corresponding original. The originator's SAF queue doesn't care about your decision-making details. It only wants to know: did you receive the transaction or not? FORCE APPROVAL tells us internally of the error condition and then we map that as an APPROVAL going back to the originator so that we keep their SAF queue clean...lest you run into the dreaded endless transaction loop between originator and host. Not pretty.
The Force Approval transaction participant looks like this:
<participant class="org.jpos.ev.SetRC" logger="Q2" realm="force-rc">
<property name="abort-rc" value="4000" />
</participant>
[See a general discussion of transaction participants here, including a short discussion of the force approval.]
4001 (DUPLICATE_APPROVAL) - We always check for duplicates. If we determine internally that the current transaction is a duplicate, we flag it internally with an IRC marker that denotes it as a known duplicate. The originator doesn't have a clue about that (which is why it sent the same transaction in the first place). We map this 4xxx series code to an APPROVAL going back to the originator. Both sides of the transaction equation are happy.
4002 (STANDIN_APPROVAL) - Some of our customers want stand-in approvals to be denoted with a special result code. So, we've implemented that here.
Comments