Result Codes, Part II

About a year back, I wrote a piece discussing the importance of establishing a result code infrastructure when building your jPOS payment systems solution.  There are various ways to do this, but in general the objective is to set up a repeatable and extensible framework that allows you to translate result codes from external to internal and back to external.  Let's deconstruct that sentence. 

First, three assumptions: I'm laying this out from an Acquirer's perspective; for simplicity's sake, let's assume that all the remote authorizers are ISO8583-based; and we connect to a series of endpoints and/or gateways providing Debit/EBT, Credit and Stored Value Card (aka, Gift Card) authorization or transaction routing (e.g., a typical Debit/EBT interface sends traffic to a gateway like FDR North, which in turn determines the card owner and routes the transaction to them).

So, by "external to internal and back to external" what I mean is:

• The remote auth interfaces get a result code back from the authorizer or gateway in ISO Field 39 (in MTI 0110, 0210, 0230).
• You need a slate of internal result codes (IRCs) in order to standardize these external errors (since each organization will have its own unique slate of result codes they use to populate ISO Field 39 - in fact, you can't even be assured that '00' means 'APPROVAL' in all cases...one very prominent Stored Value Card issuer has implemented '01' as its 'APPROVAL' code).
• Then, you need to translate your application's internal error into something that will recognized by the origin points.  Your IRCs mean nothing to the POS devices that initially formatted and sent you the request.  As a good example, in what I'm about to show you, the devices expect back a two-position 'response-code' (e.g., 'AA' = approval, 'ND' = Decline) and complementary 16-position 'display-message' (APPROVAL, TRY AGAIN LATER, INVALID CARD, etc.).

If you manage this correctly, you'll have something that's extensible (i.e., you can easily integrate new external connections) and replicable, meaning that you can pick up your entire application and drop it into your next customer site and repeat what should become a series of cookie-cutter exercises for you.

With all that as prelude, I did this very informal visual description the other day using TechSmith's Jing Project that I hope shows what Alejandro and I did in a better way than me trying to describe it here.  Watch it here.

That  was something I did to answer a specific question posed to me, which is why it has such an ad-hoc feel to it.  Some specific comments about the content you see there:

• That slate of IRCs shown is available here on my site as a PDF.
  
• The POS devices in this example use a Visa Gen 2 message format
• I mention the American Express ISO8583 interface as part of my talk.  Those are available freely online.  These are really great docs to help with your understanding of ISO8583 and the behavior of remote authorizers.  Get it here.