In the jPOS mail forums (see jPOS Users and jPOS Developers), we see variations on a common question asked over and over again. It goes something along the lines of “hey, there’s a field that is supposed to contain seven bytes and I’m only getting four? Why?”
The vast majority of the time, the reason has to do with a mismatch between the ISO packager/depackager you’ve got deployed and the specific implementation of the ISO8583 interface that you’re trying to test and certify. Getting your packager in synch with the specific implementation decisions and nuances of a ‘real-life’ interface is the essential jPOS task. That’s why in the jPOS Programmers’ Guide, Alejandro mentions in a very clear manner that “It's very important to read your interchange specification(s) as soon as possible.” And, then later: “You can see it is very important to become familiar with your interchange specifications as soon as possible.”
Some people don’t grasp this crucial step of aligning the packager to a specification. The packager incorporates such ISO8583 implementation decisions as: the format of numerical values (display or BCD?); the character set used for alphanumerical values (ASCII or EBCDIC?); the length of each data field; whether the LLVAR or LLLVAR construct is in play for a particular field; whether numerical values should be padded to the full field length; and other important implementation policies that have been made by an organization (e.g., American Express, FDR, etc) and incorporated into their specifications.
We’ll go through the alignment steps here in this post. Many people search the web looking for ‘jPOS examples,’ so it seems appropriate to lay out a very clear and clean example here. I’ll use the American Express online interface here as our example. There are a number of reasons that make this interface the best example I can show you here:
AMEX’s interface specification (“Global Credit Authorization Guide”) is something AMEX makes freely available online.
AMEX’s Card Acceptance Processing Network (“CAPN”) initiative is resulting in a lot of re-certifications around the globe, so it’s an ideal time to consider making a commitment to jPOS.
As hinted at in the last point, AMEX’s interface is global in scope, meaning that this example is as apropos in Chile, India and Russia as it is in the US.
American Express’ interface is relatively simple and ‘thin’ – AMEX only makes use of 41 out of 128 possible ISO8583 data fields, meaning that I can comfortably walk through the entire ‘spec alignment’ exercise within the context of this single post.
AMEX’s spec is clear and well-written. The AMEX team provides top-notch technical support and structured walkthroughs (via teleconference). The supporting documentation (e.g., test scripts, telecom details) is also very helpful. All these factors improve your chances at success.
Now, we do the jPOS packager alignment with the spec. I mentioned above that AMEX only defines usage of 41 of the 128 ISO8583 fields. You can confirm for yourself in Section 3.3 of the Global Credit Authorization Guide that those ISO8583 fields are: 2; 3; 4; 7; 11; 12; 13; 14; 15; 19; 22; 24; 25; 26; 27; 30; 31; 32; 33; 35; 37; 38; 39; 41; 42; 43; 44; 45; 47; 48; 49; 52; 53; 54; 55; 56; 60; 61; 62; 63; and 64.
Reading the spec, you can also make the following observations:
All the numerical values are in ‘display’ form, not BCD. In other words, if there’s a 12-digit number, it’s expressed in 12 bytes, not crammed into 6 bytes (like a BCD representation would be).
All displayable characters are in EBCDIC, not ASCII.
All 41 ISO8583 fields in use are defined via the primary bit map; the secondary bit map is never in play (i.e., fields 65 – 128 are not used).
AMEX uses the ISO8583 1993 standard (not the 1987 standard that many others use as their framework).
Now, even though there are only 41 fields defined by the authorizing organization, it’s definitely a best practice to define all 128 fields in your isopackager (because you want your implementation to be as adaptable as possible). So, setting aside the bitmap field (which is ‘IFB_BITMAP’ class type – you should read the jPOS Programmers’ Guide for an explanation of the different class types that Alejandro and team have defined), you start with the default isopackager that comes with the jPOS download and make the following adjustments to the file to start to align with the AMEX spec:
Numeric fields become IFE_NUMERIC
Numeric fields with a variable length < 100 become IFE_LLNUM
Numeric fields with a variable length < 1000 become IFE_LLLNUM
Amount fields become IFE_AMOUNT
Alphanumeric fields become IFE_CHAR
Alphanumeric fields with a variable length < 100 become IFE_LLCHAR
Alphanumeric fields with a variable length < 1000 become IFE_LLLCHAR
[For a complete list of all ISOFieldPackager class types, refer to Appendix C of the jPOS Programmers' Guide.]
I tend to make those types of changes using global edits commands. The idea is to get the basic themes of a spec (here, display data in EBCDIC format) incorporated into the isopackager before focusing individually on each of the 41 fields.
Next, you put your focus on a close reading of each of fields in the spec and make sure that the isopackager matches them exactly. Many times, an organization – especially with some of the ‘PRIVATE USE’ fields like Field 62 and Field 63 – will define a field against your expectations; other times, they might re-use (or ‘steal’) a commonly used field for their own purpose. For each of the fields in play, it your responsibility to ensure that the length, class (and any special characteristics like padding) are in lockstep with the spec you’ve been handed.
Now, I’ve done that exercise for American Express CAPN, and the following XML file is the result of my efforts. I’ve highlighted in bold blue each of the 41 fields ‘in play’ by AMEX so that you can draw a straight line back to the specification.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE isopackager SYSTEM "genericpackager.dtd">
<isopackager>
<isofield
id="0"
length="4"
name="MESSAGE TYPE INDICATOR"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="1"
length="16"
name="BIT MAP"
class="org.jpos.iso.IFB_BITMAP"/>
<isofield
id="2"
length="19"
name="PAN - PRIMARY ACCOUNT NUMBER"
pad="false"
class="org.jpos.iso.IFE_LLNUM"/>
<isofield
id="3"
length="6"
name="PROCESSING CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="4"
length="12"
name="AMOUNT, TRANSACTION"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="5"
length="12"
name="AMOUNT, SETTLEMENT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="6"
length="12"
name="AMOUNT, CARDHOLDER BILLING"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="7"
length="10"
name="TRANSMISSION DATE AND TIME"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="8"
length="8"
name="AMOUNT, CARDHOLDER BILLING FEE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="9"
length="8"
name="CONVERSION RATE, SETTLEMENT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="10"
length="8"
name="CONVERSION RATE, CARDHOLDER BILLING"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="11"
length="6"
name="SYSTEM TRACE AUDIT NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="12"
length="12"
name="DATE AND TIME, LOCAL TRANSACTION"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="13"
length="4"
name="DATE, EFFECTIVE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="14"
length="4"
name="DATE, EXPIRATION"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="15"
length="6"
name="DATE, SETTLEMENT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="16"
length="4"
name="DATE, CONVERSION"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="17"
length="4"
name="DATE, CAPTURE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="18"
length="4"
name="MERCHANTS TYPE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="19"
length="3"
name="ACQUIRING INSTITUTION COUNTRY CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="20"
length="3"
name="PAN EXTENDED COUNTRY CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="21"
length="3"
name="FORWARDING INSTITUTION COUNTRY CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="22"
length="12"
name="POINT OF SERVICE DATA CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="23"
length="3"
name="CARD SEQUENCE NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="24"
length="3"
name="FUNCTION CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="25"
length="4"
name="MESSAGE REASON CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="26"
length="4"
name="CARD ACCEPTOR BUSINESS CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="27"
length="1"
name="AUTHORIZATION IDENTIFICATION RESP LEN"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="28"
length="9"
name="AMOUNT, TRANSACTION FEE"
pad="true"
class="org.jpos.iso.IFE_AMOUNT"/>
<isofield
id="29"
length="9"
name="AMOUNT, SETTLEMENT FEE"
pad="true"
class="org.jpos.iso.IFE_AMOUNT"/>
<isofield
id="30"
length="24"
name="AMOUNT, ORIGINAL"
pad="true"
class="org.jpos.iso.IFE_NUMERIC">
</isofield>
<isofield
id="31"
length="48"
name="ACQUIRER REFERENCE DATA"
class="org.jpos.iso.IFE_LLCHAR">
</isofield>
<isofield
id="32"
length="11"
name="ACQUIRING INSTITUTION IDENT CODE"
pad="false"
class="org.jpos.iso.IFE_LLNUM"/>
<isofield
id="33"
length="11"
name="FORWARDING INSTITUTION IDENT CODE"
pad="false"
class="org.jpos.iso.IFE_LLNUM"/>
<isofield
id="34"
length="28"
name="PAN EXTENDED"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="35"
length="37"
name="TRACK 2 DATA"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="36"
length="104"
name="TRACK 3 DATA"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="37"
length="12"
name="RETRIEVAL REFERENCE NUMBER"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="38"
length="6"
name="AUTHORIZATION IDENTIFICATION RESPONSE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="39"
length="3"
name="RESPONSE CODE"
class="org.jpos.iso.IFE_CHAR">
</isofield>
<isofield
id="40"
length="3"
name="SERVICE RESTRICTION CODE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="41"
length="8"
name="CARD ACCEPTOR TERMINAL IDENTIFICACION"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="42"
length="15"
name="CARD ACCEPTOR IDENTIFICATION CODE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="43"
length="99"
name="CARD ACCEPTOR NAME/LOCATION"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="44"
length="25"
name="ADITIONAL RESPONSE DATA"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="45"
length="76"
name="TRACK 1 DATA"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="46"
length="999"
name="ADITIONAL DATA - ISO"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="47"
length="287"
name="ADITIONAL DATA - NATIONAL"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="48"
length="40"
name="ADITIONAL DATA - PRIVATE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="49"
length="3"
name="CURRENCY CODE, TRANSACTION"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="50"
length="3"
name="CURRENCY CODE, SETTLEMENT"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="51"
length="3"
name="CURRENCY CODE, CARDHOLDER BILLING"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="52"
length="8"
name="PIN DATA"
class="org.jpos.iso.IFB_BINARY"/>
<isofield
id="53"
length="8"
name="SECURITY RELATED CONTROL INFORMATION"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="54"
length="120"
name="ADDITIONAL AMOUNTS"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="55"
length="255"
name="INTEGRATED CARD CIRCUIT SYSTEM RELATED DATA"
class="org.jpos.iso.IFB_LLLCHAR"/>
<isofield
id="56"
length="35"
name="ORIGINAL DATA ELEMENTS"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="57"
length="3"
name="AUTHORIZATION LIFE CYCLE CODE"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="58"
length="11"
name="AUTHORIZING AGENT INSTITUTION IDENTIFICATION CODE"
class="org.jpos.iso.IFE_LLNUM"/>
<isofield
id="59"
length="99"
name="TRANSPORT DATA"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="60"
length="300"
name="NATIONAL USE DATA"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="61"
length="100"
name="NATIONAL USE DATA"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="62"
length="60"
name="PRIVATE USE DATA"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="63"
length="205"
name="PRIVATE USE DATA"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="64"
length="8"
name="MESSAGE AUTHENTICATION CODE FIELD"
class="org.jpos.iso.IFB_BINARY"/>
<isofield
id="65"
length="1"
name="BITMAP, EXTENDED"
class="org.jpos.iso.IFB_BINARY"/>
<isofield
id="66"
length="1"
name="SETTLEMENT CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="67"
length="2"
name="EXTENDED PAYMENT CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="68"
length="3"
name="RECEIVING INSTITUTION COUNTRY CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="69"
length="3"
name="SETTLEMENT INSTITUTION COUNTRY CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="70"
length="3"
name="NETWORK MANAGEMENT INFORMATION CODE"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="71"
length="4"
name="MESSAGE NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="72"
length="4"
name="MESSAGE NUMBER LAST"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="73"
length="6"
name="DATE ACTION"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="74"
length="10"
name="CREDITS NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="75"
length="10"
name="CREDITS REVERSAL NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="76"
length="10"
name="DEBITS NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="77"
length="10"
name="DEBITS REVERSAL NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="78"
length="10"
name="TRANSFER NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="79"
length="10"
name="TRANSFER REVERSAL NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="80"
length="10"
name="INQUIRIES NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="81"
length="10"
name="AUTHORIZATION NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="82"
length="12"
name="CREDITS, PROCESSING FEE AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="83"
length="12"
name="CREDITS, TRANSACTION FEE AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="84"
length="12"
name="DEBITS, PROCESSING FEE AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="85"
length="12"
name="DEBITS, TRANSACTION FEE AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="86"
length="16"
name="CREDITS, AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="87"
length="16"
name="CREDITS, REVERSAL AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="88"
length="16"
name="DEBITS, AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="89"
length="16"
name="DEBITS, REVERSAL AMOUNT"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="90"
length="42"
name="ORIGINAL DATA ELEMENTS"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
<isofield
id="91"
length="1"
name="FILE UPDATE CODE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="92"
length="2"
name="FILE SECURITY CODE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="93"
length="5"
name="RESPONSE INDICATOR"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="94"
length="7"
name="SERVICE INDICATOR"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="95"
length="42"
name="REPLACEMENT AMOUNTS"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="96"
length="18"
name="MESSAGE SECURITY CODE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="97"
length="17"
name="AMOUNT, NET SETTLEMENT"
pad="false"
class="org.jpos.iso.IFE_AMOUNT"/>
<isofield
id="98"
length="25"
name="PAYEE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="99"
length="11"
name="SETTLEMENT INSTITUTION IDENT CODE"
pad="false"
class="org.jpos.iso.IFE_LLNUM"/>
<isofield
id="100"
length="11"
name="RECEIVING INSTITUTION IDENT CODE"
pad="false"
class="org.jpos.iso.IFE_LLNUM"/>
<isofield
id="101"
length="17"
name="FILE NAME"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="102"
length="28"
name="ACCOUNT IDENTIFICATION 1"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="103"
length="28"
name="ACCOUNT IDENTIFICATION 2"
class="org.jpos.iso.IFE_LLCHAR"/>
<isofield
id="104"
length="100"
name="TRANSACTION DESCRIPTION"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="105"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="106"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="107"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="108"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="109"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="110"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="111"
length="999"
name="RESERVED ISO USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="112"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="113"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="114"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="115"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="116"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="117"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="118"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="119"
length="999"
name="RESERVED NATIONAL USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="120"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="121"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="122"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="123"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="124"
length="3"
name="DEBIT FUNCTION CODE"
class="org.jpos.iso.IFE_CHAR"/>
<isofield
id="125"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="126"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="127"
length="999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFE_LLLCHAR"/>
<isofield
id="128"
length="8"
name="MAC 2"
class="org.jpos.iso.IFB_BINARY"/>
</isopackager>
Hopefully, it goes without saying that you need to repeat this exercise for every interface you deploy. It should be obvious that you can’t take this file, rename it ‘fdr.xml’ and expect it to work straight away for a First Data interface. FDR North, for example, is BCD- and ASCII-based so it’s probably quicker and cleaner to start anew from Alejandro’s jPOS-bundled example instead of molding the FDR North isopackager from AMEX roots.
I am working on creating an interface to First Data North platform using the ISO 8593 Retail Standard. Can anyone suggest which one of the packagers in jPOS would be the best one to start with? Also does anyone know which Channel would work?
Thanks,
Jon
Posted by: Jon | Monday, August 06, 2007 at 16:34
Jon -
I'm sending you a copy of the fdr.xml packager via direct e-mail. That file implements the FDR North ISO8583 data structure.
Andy
Posted by: Andy | Tuesday, August 07, 2007 at 16:26
Hi,
I am working on ISO5883 message format, In particularly for Amex Authorization, I found this Message board is so informative along with the JPos Developers guide.
However there were still issues. I wondered about the following data field:
id="1"
length="16"
name="BIT MAP"
class="org.jpos.iso.IFB_BITMAP"/>
which version of American Global Authorization guide you used for this schema, As per the document I received the length for this field is 8 bytes.
If you can, Please forward me a copy of the above xml, alternative can I use your code with the copy right details with in the code.
Thanks,
Prasad
Posted by: prasad | Friday, September 14, 2007 at 05:22
Thanks for reading my blog.
The length parameter is immaterial for a field defined as a BITMAP. The fact that the AMEX bit map is defined as IFB_BITMAP means the packager knows the primary bit map is 8 bytes in length. I've got that field defined as 16 in all my implementations (some where the BITMAP is BCD, others where it's ASCII) without issue.
The AMEX packager presented in-line in this post is certified for usage in conjunction with AMEX's version 3.2 of their 'Global Credit Authorization Guide.'
Posted by: Andy Orrock | Friday, September 14, 2007 at 10:49
Andy,
Thanks for your time and support, I will go through your code.
Thanks,
Prasad
Posted by: prasad | Friday, September 14, 2007 at 10:49
In further answer to Jon's post above, where he asks "Does anyone know which Channel would work (for FDR North)?"
Answer: None of the standard jPOS channel managers work. You need to write and implement a custom channel manager to manage the custom header - 'FD' - and custom trailer - 'FD' - with which FDR asks you to wrap messages.
Posted by: Andy Orrock | Friday, September 14, 2007 at 10:54
Hi you
I intend to use jPOS in my project but I have a thing to wonder: Is there some places in a ISO message in its standard format (described by ISO) for storing real length for each field? I ask you this silly question 'cause I think it's very difficult to parse an ISO message in string form who contains varied length fields, so we could not retrieve exactly value of a particular field by following its offset in the messsage.
Could you give me a guide, pls?
Thansk for your reply
Posted by: akinokehai | Sunday, October 14, 2007 at 23:50
Yes, well, that's the point entirely: it *is* difficult to parse an ISO8583 message via the eyeball method, which is why the jPOS packager is such a nice approach. You sound like you may be going about this via a reverse-engineering approach - trying to divine every from a trace. You need to get the spec, build a packager file from the spec, and iterate that until it parses correctly.
Posted by: Andy Orrock | Monday, October 15, 2007 at 09:39
Hi,
I have an another question to you. It's not an ISOPackager related question. It's about ISOMUX in jPOS: I'm using jPOS in my software which is deployed and runs in an application server (more precisely, IBM Websphere AS). ISOMUX uses Thread class to implement multithreading feature. I heard that an application server does not allow to launch a Thread manually. So my question is: Can jPOS run in a AS? If not, could you help me to resolve this problem, please?
Thank you so much.
Posted by: akinokehai | Tuesday, October 16, 2007 at 23:57
This is a question that needs to be posed on the jPOS Developers mailing list. See:
http://www.yahoogroups.com/group/jpos-dev/join
Posted by: Andy Orrock | Wednesday, October 17, 2007 at 09:48
Thank you for this nice blog post, when i review Global Credit Authorization Guide of AMERICAN EXPRESS , i found that the field type of field 11 "SYSTEMS TRACE AUDIT NUMBER" is : Alphanumeric &
special characters and i noticed that you made it numeric :
id="11"
length="6"
name="SYSTEM TRACE AUDIT NUMBER"
pad="true"
class="org.jpos.iso.IFE_NUMERIC"/>
are u mean that , or this is made by error ?
Posted by: Ahmed El-Malatawy | Thursday, April 24, 2008 at 07:14
Hi Ahmed -
Good observation. We're populating that value on our side in our acquirer implementation. We happen to use numeric values for our STAN, which AMEX is obligated to echo. So, the numeric definition causes no harm here.
Thanks for reading.
Andy Orrock
Posted by: Andy Orrock | Thursday, April 24, 2008 at 10:40
Hi! This website is very informative!
If any of you have to share the xml files for other card types such as visa, mastercard, etcs, that would help to everybody.
Thank you,
Pius
Posted by: Pius Yoon | Tuesday, May 06, 2008 at 16:00
Hi! This website is very informative!
If any of you have to share the xml files for other card types such as visa, mastercard, etcs, that would help to everybody.
Thank you,
Pius
Posted by: Pius Yoon | Tuesday, May 06, 2008 at 16:44
Thanks. Check out some of the Google Group conversations about packagers , like this one:
http://groups.google.com/group/jpos-users/browse_thread/thread/cabaaaebdf0a30c9
There's a couple of packagers referenced there that you can download as a resource.
Posted by: Andy Orrock | Tuesday, May 06, 2008 at 17:20
hi,
i want the information of bitmap conversion in ascii and other formats .can u provide with the examples please/
thanks inadvance
ensskumar.
Posted by: ensskumar | Monday, July 07, 2008 at 07:54
Hi,
I am also building a First Data North ISO 8583 global implementation with JPOS. Could i get a copy of the packager emailed to Jon?
thanks
Simon
Posted by: Simon | Wednesday, January 07, 2009 at 21:47
DONE! Thanks for reading, Simon.
Posted by: Andy Orrock | Thursday, January 08, 2009 at 11:35
Hi andy;
could you please send me a sample transaction implementation and please explain to me in details cause I have a jpos programmers guide but am not understanding the concept of creating your own transaction manager. Waiting to hear from you
Posted by: Peter Olingo | Tuesday, February 03, 2009 at 23:51
Hi Andy,
Can I join the party?
I am also building a First Data North ISO 8583 global implementation with JPOS. Could i get a copy of the packager emailed to Jon?
Thanks
David
Posted by: David | Tuesday, March 24, 2009 at 19:36
Done.
I also have working packagers for AMEX, Discover, Incomm, Green Dot, Stored Value Systems ('SVS') and FDR Omaha.
-- Andy
Posted by: Andy | Tuesday, March 24, 2009 at 21:23
Hi Andy,
Once more, could I get a copy of that famous packager for First Data North?
Thanks
Jelena
Posted by: Jelena | Saturday, April 18, 2009 at 14:24
DONE! Thanks for reading.
Posted by: Andy | Saturday, April 18, 2009 at 15:09
Hi Andy,
This page is a lifesaver. I'm currently working on a packager for Mastercard. Do you have something similar done yet?
Thanks
Elaine
Posted by: Elaine | Wednesday, May 13, 2009 at 03:40
Hi Elaine -
Sending you our MC packager under separate cover.
-- Andy
Posted by: Andy | Wednesday, May 13, 2009 at 08:39