A reader had some really great comments to my "Real Systems Do Extracts - Part 1" post. I liked his questions and comments so much, I think all of them are worthy of separate posts. In this first one, he wonders why the example tran log I posted had only one amount field. Read on...
The reader said in his post: "One of the things I noticed in the tran log is the one amount field. A request amount and a response amount may be beneficial if there are partial approvals."
You are correct. The tranLog shown in the original (“Part 1”) post was for an acquirer system in which partial approvals are not part of the picture. This isn’t because of some shortcoming in jPOS or our OLS.Switch implementation. Rather, whether partial approvals are implemented is directly related to the capabilities of the acquirer’s POS System; specifically, it must have the capacity to do ‘split tender’ operations. If the in-store system can’t split a purchase into more than one tender type (either because of programmatic limitations at the device or due to a policy decision), then it makes no sense to support partial approvals. That was the case in the example in the initial post.
As you state, were partial approvals something you need to support as an Acquirer, then, yes, by all means you would want to log two amount fields on your tranLog entry: the requested amount and the approved amount.
We have some issuer implementations that have to deal with the real possibility of a similar issue: that of the ATM partial dispense. And – unlike an acquirer implementation – you can’t decide to not implement this feature (sorry for the double-negative) because these are policy decisions under the acquirer’s control, not yours as issuer). So, we have an Issuer system tranLog that looks like this:
amount – The originally requested amount (for example, in a BASE/24 gateway, this info comes to us in ISO Field 4 on the 0100, 0200, 022x or 042x request)
networkFee – If the ATM request has a fee tacked on to it by the Acquirer, we place it here (BASE/24 gateways place this information into ISO Field 28 on the request).
issuerFee –This information is part of our OLS.Switch implementation of jPOS. It comes not from the ISO message, but rather from some internal “program” tables we maintain as part of our solution framework (you can place cards into different programs and then assign fees for ATM vs. POS transactions, International vs. domestic, Withdrawals vs. Inquiries, etc.).
cashback – This is the cash component of POS Purchases with Cashback (Competent Acquirers and gateways will break out this information for you; BASE/24 gateways provide it on ISO Field 54 of the request).
replacementAmount – Here’s the partial dispense information. In the BASE/24 example implementation I keep referring to here, we can get an ATM Reversal (0420), but we need to interrogate the request to determine whether ISO Field 95 (“Replacement Amount”) is present. If so, the reversal isn’t a complete reversal, but a partial. In these cases, we go find the original (actually, you always must find the original in order to accept – at the financial level – a reversal), update the replacementAmount (and its associated fee – see next) fields and then code our extract to determine if the replacement amount fields in the tranLog are != 0 and NOT NULL. If so, the extract uses the replacementAmount, not the original amount.
replacementFeeAmount – The Acquirer and gateway may also implement a replacement fee (i.e., a replacement of the original ‘network fee’ as described above) concept. In the BASE/24 gateway example, this information is also sent in ISO Field 95 of the partial reversal request (ISO Field 95 in the BASE/24 implementation is a series of sub-fields). It’s easy to imagine a scenario in which an acquirer implements a policy to waive or reduce a fee if the requesting cardholder cannot obtain all the cash they requested.
Back to acquirer implementations for a moment, one other thing worth noting is something American Express is implementing with its most recent CAPN initiative. It reflects a world in which much of AMEX’s card base is now of the prepaid variety and carry actual cash balances rather than an ‘open to buy’ credit limit. From the AMEX viewpoint (as per their most recent “Global Credit Authorization Guide”), the acquiring world is thereby divided into two types:
You support Partial Authorization of these prepaid cards – If so, you send AMEX an indicator in ISO Field 24 of all 1100 auth requests (note that AMEX follows the ISO8583:1993 standard, thus the auth is 1100, not 0100). AMEX calls this field the ‘Function Code’ and by placing a value of ‘181’ in there, you are indicating that “this…system and/or POS device accepts and processes response messages for partial authorization of transaction amounts less than the full value originally submitted for authorization. Please note that the merchant must collect the remainder from the Cardmember via another form of payment.”
You support Authorization with Balance Return – By placing a value of ‘182’ in there, you are indicating that “the…system and/or POS device accepts and processes…balances in response messages. This alternative for systems that do not support partial authorizations returns the Prepaid Card balance to the merchant so that an authorization request can be resubmitted for the available amount when transactions are denied for insufficient balance.”
In the acquirer system example I posted in conjunction with the original post, we are obviously a ‘Balance Return’ implementation. chhil’s comments refer to a ‘Partial Return’ implementation.
Comments