Europay like DE48 with a twist
793 views
Skip to first unread message
JayPoser
Jan 9, 2009, 7:20:21 PM1/9/09
to jPOS Users
So, I'm dealing with a packager spec for MC that describes DE48 as
"free-form, variable-length alphanumeric-data".
One its important sub-fields is a 1char TCC (tx cat) followed by tag-
value items, such that the total DE48 is 103 bytes. The non-TCC
subfields are encoded like this: 2byteTag + 2byteLength +
1-96byteData;
The overall DE48 might look like this {being confirmed, as the spec is
not clear on TCC in response}:
3byteDE48Length + 1byteTCC + (2byteSETag + 2byteSELength +
1-96byteSEData ... nth SE).
So, the twist comes from the fact that the TCC might not be present,
which makes the Europay subfield packager choke on the misaligned
DE's.
My question is if the TCC behavior is confirmed (that is it cannot be
counted on to be always there), the best I could do is turn DE48 into
a IFA_LLLCHAR packaged field and make up my own parsing rules about
the data, right?
Or perhaps I could look into modding the sub-fld packager for the
special scenario?
Thanks,
Karl
"free-form, variable-length alphanumeric-data".
One its important sub-fields is a 1char TCC (tx cat) followed by tag-
value items, such that the total DE48 is 103 bytes. The non-TCC
subfields are encoded like this: 2byteTag + 2byteLength +
1-96byteData;
The overall DE48 might look like this {being confirmed, as the spec is
not clear on TCC in response}:
3byteDE48Length + 1byteTCC + (2byteSETag + 2byteSELength +
1-96byteSEData ... nth SE).
So, the twist comes from the fact that the TCC might not be present,
which makes the Europay subfield packager choke on the misaligned
DE's.
My question is if the TCC behavior is confirmed (that is it cannot be
counted on to be always there), the best I could do is turn DE48 into
a IFA_LLLCHAR packaged field and make up my own parsing rules about
the data, right?
Or perhaps I could look into modding the sub-fld packager for the
special scenario?
Thanks,
Karl
Alejandro Revilla
Jan 9, 2009, 7:38:12 PM1/9/09
to jpos-...@googlegroups.com
>
> So, I'm dealing with a packager spec for MC that describes DE48 as
> "free-form, variable-length alphanumeric-data".
>
> One its important sub-fields is a 1char TCC (tx cat) followed by tag-
> value items, such that the total DE48 is 103 bytes. The non-TCC
> subfields are encoded like this: 2byteTag + 2byteLength +
> 1-96byteData;
>
Can you define field 48.0 as an IF_CHAR?, i.e.:> So, I'm dealing with a packager spec for MC that describes DE48 as
> "free-form, variable-length alphanumeric-data".
>
> One its important sub-fields is a 1char TCC (tx cat) followed by tag-
> value items, such that the total DE48 is 103 bytes. The non-TCC
> subfields are encoded like this: 2byteTag + 2byteLength +
> 1-96byteData;
>
<isofield
id="0"
length="1"
name="PLACEHOLDER"
class="org.jpos.iso.IF_CHAR"/>
JayPoser
Jan 9, 2009, 8:43:47 PM1/9/09
to jPOS Users
Yeah, it doesn't seem to work when sending, during packing. The sub-
fld packager kept croaking on it with NPE at line-75.
I had to define DE48 like this:
...packager="SubFieldPackager" emitBitmap="false" firstField="2">
<isofield
id="2"
length="1"
name="TCC"
class="org.jpos.iso.IF_CHAR"/>
That makes it work going out, but on the response, since TCC is not
there, the unpacking fails.
fld packager kept croaking on it with NPE at line-75.
I had to define DE48 like this:
...packager="SubFieldPackager" emitBitmap="false" firstField="2">
<isofield
id="2"
length="1"
name="TCC"
class="org.jpos.iso.IF_CHAR"/>
That makes it work going out, but on the response, since TCC is not
there, the unpacking fails.
Alejandro Revilla
Jan 9, 2009, 8:51:21 PM1/9/09
to jpos-...@googlegroups.com
>
> Yeah, it doesn't seem to work when sending, during packing. The sub-
> fld packager kept croaking on it with NPE at line-75.
>
You can try to set that field 0 to a dummy value at send time.> Yeah, it doesn't seem to work when sending, during packing. The sub-
> fld packager kept croaking on it with NPE at line-75.
>
JayPoser
Jan 12, 2009, 2:52:29 PM1/12/09
to jPOS Users
I think my problems come from the fact that sub-fld packagers either
need to use a DE48 sub-fld bitmap, or ensure that ALL sub-flds are
present ALL the time, but MC doesn't look at DE48 that way.
It seems thatl the response may or may not contain the 1 byte TCC
value from the send, also the order of the sub-flds is not
guaranteed, such that SF#11 is before SF#44.
Consequently, DE48 sub fields have to be parsed from their length+tag
+value, in the order they appear in the DE48 data.
need to use a DE48 sub-fld bitmap, or ensure that ALL sub-flds are
present ALL the time, but MC doesn't look at DE48 that way.
It seems thatl the response may or may not contain the 1 byte TCC
value from the send, also the order of the sub-flds is not
guaranteed, such that SF#11 is before SF#44.
Consequently, DE48 sub fields have to be parsed from their length+tag
+value, in the order they appear in the DE48 data.
Mark Salter
Jan 12, 2009, 3:33:45 PM1/12/09
to jpos-...@googlegroups.com
JayPoser wrote:
> Consequently, DE48 sub fields have to be parsed from their length+tag
> +value, in the order they appear in the DE48 data.
> Consequently, DE48 sub fields have to be parsed from their length+tag
> +value, in the order they appear in the DE48 data.
May I suggest a manual parsing of the content of field 48?
You could write a class that knows about the tags and pulls out the
one's that are present, shouldn't be too hard, but I'm fairly sure you
cannot do this without writing a new class.
We should probably have this sort of TLV handler, perhaps something for
the wish list...
--
Mark
Alejandro Revilla
Jan 12, 2009, 3:43:28 PM1/12/09
to jpos-...@googlegroups.com
I'm not sure why this is not working, I'm aware of several applications
connected to MC and letting jPOS deal with DE48.
connected to MC and letting jPOS deal with DE48.
JayPoser
Jan 12, 2009, 3:43:48 PM1/12/09
to jPOS Users
Oh yeah, fully agree that this I have to do manually. No big deal,
obviously. I just hope I didn't come across accusing JPOS for falling
short. I was just curious if there's something in sub-packager land I
missed.
obviously. I just hope I didn't come across accusing JPOS for falling
short. I was just curious if there's something in sub-packager land I
missed.
Mark Salter
Jan 12, 2009, 3:49:48 PM1/12/09
to jpos-...@googlegroups.com
JayPoser wrote:
> Oh yeah, fully agree that this I have to do manually. No big deal,
> obviously. I just hope I didn't come across accusing JPOS for falling
> short. I was just curious if there's something in sub-packager land I
> missed.
> Oh yeah, fully agree that this I have to do manually. No big deal,
> obviously. I just hope I didn't come across accusing JPOS for falling
> short. I was just curious if there's something in sub-packager land I
> missed.
No you didn't come across like that at all.
This is certainly getting my mind going after my xmas break, perhaps I
am missing something obvious 8).
Can you describe your field definition once more please?
Do you have a length field followed by a number of TLV subfields -
combination/order unknown, without a bitmap?
In my mind this would need some extra work to handle, but is this what
you actually have - or did I dream it 8)?
--
Mark
Andy Orrock
Jan 12, 2009, 3:58:53 PM1/12/09
to jpos-...@googlegroups.com
I suspect the field definition will look like this (EBCDIC edition):
<isofieldpackager
id="48"
length="999"
name="EUROPAY FIELD 48"
class="org.jpos.iso.IFE_LLLBINARY"
packager="org.jpos.iso.packager.EuroSubFieldPackager">
<isofield
id="1"
length="18"
name="Field 48 - Sub-element 01"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="2"
length="4"
name="Field 48 - Sub-element 02"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="3"
length="4"
name="Field 48 - Sub-element 03"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="4"
length="4"
name="Field 48 - Sub-element 04"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="5"
length="98"
name="Field 48 - Sub-element 05"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="6"
length="4"
name="Field 48 - Sub-element 06"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="7"
length="4"
name="Field 48 - Sub-element 07"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="8"
length="4"
name="Field 48 - Sub-element 08"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="9"
length="0"
name="Field 48 - Sub-element 08"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="10"
length="16"
name="Encrypted PIN Block Key"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="11"
length="54"
name="Key Exchange Block Data (Double-Length Keys)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="12"
length="1"
name="Routing Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="13"
length="0"
name="Field 48 - Sub-element 13"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="14"
length="0"
name="Field 48 - Sub-element 14"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="15"
length="0"
name="Field 48 - Sub-element 15"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="16"
length="0"
name="Field 48 - Sub-element 16"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="17"
length="0"
name="Field 48 - Sub-element 17"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="18"
length="0"
name="Field 48 - Sub-element 18"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="19"
length="0"
name="Field 48 - Sub-element 19"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="20"
length="1"
name="Cardholder Verification Method"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="21"
length="0"
name="Field 48 - Sub-element 21"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="22"
length="0"
name="Field 48 - Sub-element 22"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="23"
length="0"
name="Field 48 - Sub-element 23"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="24"
length="0"
name="Field 48 - Sub-element 24"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="25"
length="0"
name="Field 48 - Sub-element 25"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="26"
length="0"
name="Field 48 - Sub-element 26"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="27"
length="0"
name="Field 48 - Sub-element 27"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="28"
length="0"
name="Field 48 - Sub-element 28"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="29"
length="0"
name="Field 48 - Sub-element 29"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="30"
length="0"
name="Field 48 - Sub-element 30"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="31"
length="0"
name="Field 48 - Sub-element 31"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="32"
length="0"
name="Field 48 - Sub-element 32"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="33"
length="36"
name="PayPass Mapping File Information"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="34"
length="11"
name="Dynamic CVC 3 ATC Information"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="35"
length="2"
name="PayPass Non-Card Form Factor Request/Response"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="36"
length="0"
name="Field 48 - Sub-element 36"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="37"
length="0"
name="Field 48 - Sub-element 37"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="38"
length="1"
name="Account Category"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="39"
length="0"
name="Field 48 - Sub-element 39"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="40"
length="40"
name="E-Commerce Merchant/Cardholder Cert. Serial Number (Visa
Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="41"
length="95"
name="E-Commerce Cert. Qualifying Info"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="42"
length="7"
name="E-Commerce Indicators"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="43"
length="32"
name="Universal Cardholder Authentication Field"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="44"
length="20"
name="Visa 3-D Secure E-Commerce XID"
class="org.jpos.iso.IFEMC_LLCHAR">
<!-- NEED BINARY -->
</isofield>
<isofield
id="45"
length="1"
name="Visa 3-D Secure E-Commerce Transaction Response Code"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="46"
length="2"
name="Card-Level Result (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="47"
length="8"
name="MC Payment Gateway Transaction Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="48"
length="0"
name="Field 48 - Sub-element 48"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="49"
length="0"
name="Field 48 - Sub-element 49"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="50"
length="0"
name="Field 48 - Sub-element 50"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="51"
length="0"
name="Field 48 - Sub-element 51"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="52"
length="0"
name="Field 48 - Sub-element 52"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="53"
length="0"
name="Field 48 - Sub-element 53"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="54"
length="0"
name="Field 48 - Sub-element 54"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="55"
length="0"
name="Field 48 - Sub-element 55"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="56"
length="0"
name="Field 48 - Sub-element 56"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="57"
length="0"
name="Field 48 - Sub-element 57"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="58"
length="33"
name="ATM Additional Data"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="59"
length="0"
name="Field 48 - Sub-element 59"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="60"
length="0"
name="Field 48 - Sub-element 60"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="61"
length="5"
name="POS Data, Extended Condition Codes"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="62"
length="0"
name="Field 48 - Sub-element 62"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="63"
length="15"
name="Trace ID"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="64"
length="0"
name="Field 48 - Sub-element 64"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="65"
length="0"
name="Field 48 - Sub-element 65"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="66"
length="0"
name="Field 48 - Sub-element 66"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="67"
length="0"
name="Field 48 - Sub-element 67"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="68"
length="0"
name="Field 48 - Sub-element 68"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="69"
length="0"
name="Field 48 - Sub-element 69"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="70"
length="0"
name="Field 48 - Sub-element 70"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="71"
length="40"
name="On-behalf Services"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="72"
length="16"
name="Issuer Chip Authentication"
class="org.jpos.iso.IFEMC_LLCHAR">
<!-- NEED BINARY -->
</isofield>
<isofield
id="73"
length="0"
name=""
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="74"
length="30"
name="Additional Processing Information"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="75"
length="0"
name="Field 48 - Sub-element 75"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="76"
length="1"
name="MasterCard Electronic Acceptance Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="77"
length="3"
name="Payment Transaction Type Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="78"
length="1"
name="U.S. Deferred Billing Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="79"
length="50"
name="Chip CVR/TVR Bit Error Results"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="80"
length="2"
name="PIN Service Code"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="81"
length="0"
name="Field 48 - Sub-element 81"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="82"
length="2"
name="Address Verification Service Request"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="83"
length="1"
name="Address Verification Service Response"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="84"
length="2"
name="Merchant Advice Code"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="85"
length="1"
name="U.S. Existing Debt Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="86"
length="1"
name="Relationship Participant Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="87"
length="1"
name="Card Validation Code Result"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="88"
length="1"
name="Magnetic Stripe Compliance Status Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="89"
length="1"
name="Magnetic Stripe Compliance Error Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="90"
length="1"
name="CPS Request (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="91"
length="19"
name="CPS Request Transaction ID (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="92"
length="6"
name="CVC 2 or CVV2"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="93"
length="19"
name="Fleet Card ID Request Data (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="94"
length="4"
name="Commercial Card Inquiry Request or Response (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="95"
length="6"
name="MC Promotion Code or AMEX CID"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="96"
length="1"
name="Visa Market-Specific Data Identifier"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="97"
length="1"
name="Prestigious Properties Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="98"
length="6"
name="MasterCard Corporate Fleet Card ID/Driver Number"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="98"
length="6"
name="MasterCard Corporate Fleet Card Vehicle Number"
class="org.jpos.iso.IFEMC_LLCHAR"/>
</isofieldpackager>
<isofieldpackager
id="48"
length="999"
name="EUROPAY FIELD 48"
class="org.jpos.iso.IFE_LLLBINARY"
packager="org.jpos.iso.packager.EuroSubFieldPackager">
<isofield
id="0"
length="1"
name="PLACEHOLDER"
class="org.jpos.iso.IFE_CHAR"/>
id="0"
length="1"
name="PLACEHOLDER"
<isofield
id="1"
length="18"
name="Field 48 - Sub-element 01"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="2"
length="4"
name="Field 48 - Sub-element 02"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="3"
length="4"
name="Field 48 - Sub-element 03"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="4"
length="4"
name="Field 48 - Sub-element 04"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="5"
length="98"
name="Field 48 - Sub-element 05"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="6"
length="4"
name="Field 48 - Sub-element 06"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="7"
length="4"
name="Field 48 - Sub-element 07"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="8"
length="4"
name="Field 48 - Sub-element 08"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="9"
length="0"
name="Field 48 - Sub-element 08"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="10"
length="16"
name="Encrypted PIN Block Key"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="11"
length="54"
name="Key Exchange Block Data (Double-Length Keys)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="12"
length="1"
name="Routing Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="13"
length="0"
name="Field 48 - Sub-element 13"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="14"
length="0"
name="Field 48 - Sub-element 14"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="15"
length="0"
name="Field 48 - Sub-element 15"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="16"
length="0"
name="Field 48 - Sub-element 16"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="17"
length="0"
name="Field 48 - Sub-element 17"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="18"
length="0"
name="Field 48 - Sub-element 18"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="19"
length="0"
name="Field 48 - Sub-element 19"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="20"
length="1"
name="Cardholder Verification Method"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="21"
length="0"
name="Field 48 - Sub-element 21"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="22"
length="0"
name="Field 48 - Sub-element 22"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="23"
length="0"
name="Field 48 - Sub-element 23"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="24"
length="0"
name="Field 48 - Sub-element 24"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="25"
length="0"
name="Field 48 - Sub-element 25"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="26"
length="0"
name="Field 48 - Sub-element 26"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="27"
length="0"
name="Field 48 - Sub-element 27"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="28"
length="0"
name="Field 48 - Sub-element 28"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="29"
length="0"
name="Field 48 - Sub-element 29"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="30"
length="0"
name="Field 48 - Sub-element 30"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="31"
length="0"
name="Field 48 - Sub-element 31"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="32"
length="0"
name="Field 48 - Sub-element 32"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="33"
length="36"
name="PayPass Mapping File Information"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="34"
length="11"
name="Dynamic CVC 3 ATC Information"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="35"
length="2"
name="PayPass Non-Card Form Factor Request/Response"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="36"
length="0"
name="Field 48 - Sub-element 36"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="37"
length="0"
name="Field 48 - Sub-element 37"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="38"
length="1"
name="Account Category"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="39"
length="0"
name="Field 48 - Sub-element 39"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="40"
length="40"
name="E-Commerce Merchant/Cardholder Cert. Serial Number (Visa
Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="41"
length="95"
name="E-Commerce Cert. Qualifying Info"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="42"
length="7"
name="E-Commerce Indicators"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="43"
length="32"
name="Universal Cardholder Authentication Field"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="44"
length="20"
name="Visa 3-D Secure E-Commerce XID"
class="org.jpos.iso.IFEMC_LLCHAR">
<!-- NEED BINARY -->
</isofield>
<isofield
id="45"
length="1"
name="Visa 3-D Secure E-Commerce Transaction Response Code"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="46"
length="2"
name="Card-Level Result (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="47"
length="8"
name="MC Payment Gateway Transaction Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="48"
length="0"
name="Field 48 - Sub-element 48"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="49"
length="0"
name="Field 48 - Sub-element 49"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="50"
length="0"
name="Field 48 - Sub-element 50"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="51"
length="0"
name="Field 48 - Sub-element 51"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="52"
length="0"
name="Field 48 - Sub-element 52"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="53"
length="0"
name="Field 48 - Sub-element 53"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="54"
length="0"
name="Field 48 - Sub-element 54"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="55"
length="0"
name="Field 48 - Sub-element 55"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="56"
length="0"
name="Field 48 - Sub-element 56"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="57"
length="0"
name="Field 48 - Sub-element 57"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="58"
length="33"
name="ATM Additional Data"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="59"
length="0"
name="Field 48 - Sub-element 59"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="60"
length="0"
name="Field 48 - Sub-element 60"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="61"
length="5"
name="POS Data, Extended Condition Codes"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="62"
length="0"
name="Field 48 - Sub-element 62"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="63"
length="15"
name="Trace ID"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="64"
length="0"
name="Field 48 - Sub-element 64"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="65"
length="0"
name="Field 48 - Sub-element 65"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="66"
length="0"
name="Field 48 - Sub-element 66"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="67"
length="0"
name="Field 48 - Sub-element 67"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="68"
length="0"
name="Field 48 - Sub-element 68"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="69"
length="0"
name="Field 48 - Sub-element 69"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="70"
length="0"
name="Field 48 - Sub-element 70"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="71"
length="40"
name="On-behalf Services"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="72"
length="16"
name="Issuer Chip Authentication"
class="org.jpos.iso.IFEMC_LLCHAR">
<!-- NEED BINARY -->
</isofield>
<isofield
id="73"
length="0"
name=""
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="74"
length="30"
name="Additional Processing Information"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="75"
length="0"
name="Field 48 - Sub-element 75"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="76"
length="1"
name="MasterCard Electronic Acceptance Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="77"
length="3"
name="Payment Transaction Type Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="78"
length="1"
name="U.S. Deferred Billing Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="79"
length="50"
name="Chip CVR/TVR Bit Error Results"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="80"
length="2"
name="PIN Service Code"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="81"
length="0"
name="Field 48 - Sub-element 81"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="82"
length="2"
name="Address Verification Service Request"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="83"
length="1"
name="Address Verification Service Response"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="84"
length="2"
name="Merchant Advice Code"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="85"
length="1"
name="U.S. Existing Debt Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="86"
length="1"
name="Relationship Participant Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="87"
length="1"
name="Card Validation Code Result"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="88"
length="1"
name="Magnetic Stripe Compliance Status Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="89"
length="1"
name="Magnetic Stripe Compliance Error Indicator"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="90"
length="1"
name="CPS Request (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="91"
length="19"
name="CPS Request Transaction ID (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="92"
length="6"
name="CVC 2 or CVV2"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="93"
length="19"
name="Fleet Card ID Request Data (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="94"
length="4"
name="Commercial Card Inquiry Request or Response (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="95"
length="6"
name="MC Promotion Code or AMEX CID"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="96"
length="1"
name="Visa Market-Specific Data Identifier"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="97"
length="1"
name="Prestigious Properties Indicator (Visa Only)"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="98"
length="6"
name="MasterCard Corporate Fleet Card ID/Driver Number"
class="org.jpos.iso.IFEMC_LLCHAR"/>
<isofield
id="98"
length="6"
name="MasterCard Corporate Fleet Card Vehicle Number"
class="org.jpos.iso.IFEMC_LLCHAR"/>
</isofieldpackager>
Mark Salter
Jan 12, 2009, 4:31:26 PM1/12/09
to jpos-...@googlegroups.com
Andy Orrock wrote:
> I suspect the field definition will look like this (EBCDIC edition):
>
[snip *very* working generic packager xml definition 8)]> I suspect the field definition will look like this (EBCDIC edition):
>
What I am struggling to see is how the field presence is decided?
I'm looked for the class mentioned (org.jpos.iso.IFEMC_LLCHAR) to see if
it tested for or used the 'Tag' presence - and thus that a subfield
order was assumed?
The shared classes (org.jpos.iso.IFMC_LLCHAR & IFMC_LLBINARY) determine
their field numbers at unpack time, I'm not sure I see how that would
work when the order and mix of format(s) could vary?
I think now I am missing something obvious, perhaps someone can point
out my error, and save me from embarrassing myself further?
8)
--
Mark
Alejandro Revilla
Jan 12, 2009, 4:38:23 PM1/12/09
to jpos-...@googlegroups.com
>
> I think now I am missing something obvious, perhaps someone can point
> out my error, and save me from embarrassing myself further?
>
Sorry for the short response (will try to expand later), but the order> I think now I am missing something obvious, perhaps someone can point
> out my error, and save me from embarrassing myself further?
>
defined in the GenericPackager XML configuration actually doesn't
matter at all. The fields are unpacked based on their tag number. We do
not preserve the order at pack time though (would get sorted), but I
believe that's OK for the host.
JayPoser
Jan 12, 2009, 6:23:25 PM1/12/09
to jPOS Users
The version my collegue was using originally had
"org.jpos.iso.IFMC_LLCHAR" as field packagers.
Also, later on, we had a version where only certain subfields were
defined. So, for instance, flds 0-1 and 3 through 10 were in the
packager definition. This kept breaking with a NPE, so when using
firstField="2" seemed to fix this issue, we went with that.
> ...
>
> read more »
"org.jpos.iso.IFMC_LLCHAR" as field packagers.
Also, later on, we had a version where only certain subfields were
defined. So, for instance, flds 0-1 and 3 through 10 were in the
packager definition. This kept breaking with a NPE, so when using
firstField="2" seemed to fix this issue, we went with that.
>
> read more »
Andy Orrock
Jan 12, 2009, 6:25:54 PM1/12/09
to jpos-...@googlegroups.com
That's the ASCII version. This is the EBCDIC version. Same difference.
-----Original Message-----
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
Behalf Of JayPoser
Sent: Monday, January 12, 2009 5:23 PM
To: jPOS Users
Subject: Re: Europay like DE48 with a twist
-----Original Message-----
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
Behalf Of JayPoser
Sent: Monday, January 12, 2009 5:23 PM
To: jPOS Users
Subject: Re: Europay like DE48 with a twist
Alejandro Revilla
Jan 12, 2009, 8:02:14 PM1/12/09
to jpos-...@googlegroups.com
Are you sure you're using org.jpos.iso.packager.EuroSubFieldPackager ?
JayPoser
Jan 12, 2009, 8:15:25 PM1/12/09
to jPOS Users
Oh yeah, just happened to try it again earlier today for reasons
unrelated to this discussion, btw:
<isofieldpackager
id="48"
length="100"
name="MASTERCARD FIELD 48"
class="org.jpos.iso.IFA_LLLBINARY"
packager="org.jpos.iso.packager.EuroSubFieldPackager"
<isofield
id="11"
length="70"
name="Sub Element 11 - Key Exchange Block Data"
class="org.jpos.iso.IFMC_LLCHAR"/>
...
The above would work for the send, but the unpacking of the response
broke on the missing sub-fld#2, when parsing this char sequence, which
is DE48 in the return msg: "0077703C01"
DE48-length='007', DE48.2='7', DE48.11-tag='70', DE48.11-length='3C'
=> NumberFormatException...
unrelated to this discussion, btw:
<isofieldpackager
id="48"
length="100"
name="MASTERCARD FIELD 48"
class="org.jpos.iso.IFA_LLLBINARY"
packager="org.jpos.iso.packager.EuroSubFieldPackager"
emitBitmap="false"
firstField="2">
<isofield
id="2"
length="1"
name="TCC"
class="org.jpos.iso.IF_CHAR"/>
firstField="2">
<isofield
id="2"
length="1"
name="TCC"
<isofield
id="11"
length="70"
name="Sub Element 11 - Key Exchange Block Data"
class="org.jpos.iso.IFMC_LLCHAR"/>
...
The above would work for the send, but the unpacking of the response
broke on the missing sub-fld#2, when parsing this char sequence, which
is DE48 in the return msg: "0077703C01"
DE48-length='007', DE48.2='7', DE48.11-tag='70', DE48.11-length='3C'
=> NumberFormatException...
David Bergert
Jan 12, 2009, 8:33:17 PM1/12/09
to jpos-...@googlegroups.com
What type of Message is this ? a 100 or a 800, or another type ?
I ask because I don't see a TCC of "7" in my specs
But this makes more sense to me for the value you provided
"0077703C01"
007 - Length
77 - tag (77 Payment Transaction Type Indicator an-3)
03 - tag length
C01 - value (C01 = Person-to-Person)
Looks like you are defining a TCC when you are not receiving one.
Regards,
David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of JayPoser
> Sent: Monday, January 12, 2009 7:15 PM
> To: jPOS Users
> Subject: Re: Europay like DE48 with a twist
>
>
I ask because I don't see a TCC of "7" in my specs
But this makes more sense to me for the value you provided
"0077703C01"
007 - Length
77 - tag (77 Payment Transaction Type Indicator an-3)
03 - tag length
C01 - value (C01 = Person-to-Person)
Looks like you are defining a TCC when you are not receiving one.
Regards,
David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of JayPoser
> Sent: Monday, January 12, 2009 7:15 PM
> To: jPOS Users
> Subject: Re: Europay like DE48 with a twist
>
>
JayPoser
Jan 12, 2009, 9:11:56 PM1/12/09
to jPOS Users
Sorry, if this wasn't clear, but this was from the response, a 210
msg. My 200 msg as sent did include DE48.2 and DE48.77, but only
DE48.77 was sent back. So, indeed, TCC is being defined, but only
because it is required (in some cases) in the input.
msg. My 200 msg as sent did include DE48.2 and DE48.77, but only
DE48.77 was sent back. So, indeed, TCC is being defined, but only
because it is required (in some cases) in the input.
David Bergert
Jan 12, 2009, 9:20:19 PM1/12/09
to jpos-...@googlegroups.com
Try Setting this (TCC) to: id="0" instead of "2"
> > > firstField="2">
> > > <isofield
> > > id="2"
> > > length="1"
> > > name="TCC"
> > > class="org.jpos.iso.IF_CHAR"/>
Look at the src code for EuroSubField Packager: it looks like there is some
"special" code to handle the "first field" and it explicitly looks for it in
field 0 in the pack method().
Also, have you ever seen a TCC in a response message from your testing or
messages ?
It looks like the 4th byte after the 3 byte length is a TCC if it is a " "
or A-Z, all of the tags are 00-99 - so you could code some logic to see if a
TCC is present or not, based on these rules. It looks like it can be sent
*sometimes* depending on the capabilities of the issuer.
> > > firstField="2">
> > > <isofield
> > > id="2"
> > > length="1"
> > > name="TCC"
> > > class="org.jpos.iso.IF_CHAR"/>
"special" code to handle the "first field" and it explicitly looks for it in
field 0 in the pack method().
Also, have you ever seen a TCC in a response message from your testing or
messages ?
It looks like the 4th byte after the 3 byte length is a TCC if it is a " "
or A-Z, all of the tags are 00-99 - so you could code some logic to see if a
TCC is present or not, based on these rules. It looks like it can be sent
*sometimes* depending on the capabilities of the issuer.
David Bergert
Jan 12, 2009, 10:02:45 PM1/12/09
to jpos-...@googlegroups.com
>It looks like it can be sent
> *sometimes* depending on the capabilities of the issuer.
> *sometimes* depending on the capabilities of the issuer.
Actually, it looks for non-800 messages that there should always be a TCC if
DE 48 is present.
Are you acting as the Acq or Issuing? are you sending or recieving that 210
message ?
Mark Salter
Jan 13, 2009, 11:37:03 AM1/13/09
to jpos-...@googlegroups.com
Alejandro Revilla wrote:
>> I think now I am missing something obvious, perhaps someone can
>> point out my error, and save me from embarrassing myself further?
>>
> Sorry for the short response (will try to expand later),
No need, I took a closer look at the code for myself..>> I think now I am missing something obvious, perhaps someone can
>> point out my error, and save me from embarrassing myself further?
>>
> Sorry for the short response (will try to expand later),
> but the order defined in the GenericPackager XML configuration
> actually doesn't matter at all.
Ok.
> The fields are unpacked based on their tag number.
I was missing the fact that this subfield packager pulls the tag from
the bytes to be consumed to identify the field that should be called to
unpack/consume it's bytes.
This is the key and what I had not noticed.
> We do not preserve the order at pack time though (would get sorted),
> but I believe that's OK for the host.
I was happy that the order of the fields could go back in a different
order, I was simply not looking 'high' enough up the processing to see
what was right in front of my eyes.
8)
--
Mark
JayPoser
Jan 13, 2009, 2:36:26 PM1/13/09
to jPOS Users
Acquirer, receiving the 210's. Right now, testing against a simulator
that's supposed to act identical to the MIP.
that's supposed to act identical to the MIP.
Alejandro Revilla
Jan 13, 2009, 3:04:41 PM1/13/09
to jpos-...@googlegroups.com
As Dave has pointed out, we still have a problem with 0800 messages
where the TCC is not present. Problem is the subfield packager doesn't
know about the outter MTI ... quite a dilemma ...
where the TCC is not present. Problem is the subfield packager doesn't
know about the outter MTI ... quite a dilemma ...
JayPoser
Jan 13, 2009, 5:58:50 PM1/13/09
to jPOS Users
So, the TCC is only applicable for transaction messages, which the
0800 isn't. So, DE48 is not normally present in 0800 messages, right?
My tests include 0800 exchanges with the simulator and they look ok.
It seems to me the problem is from the fact that during unpack, the
sub-fld pkgr has no way of knowing if the TCC is present. If it isn't,
it consumes the 1 byte for it as designed and the rest of the TLV
items are off.
I am working with my MC contact to see if this is only a glitch in the
simulator, or an actual valid scenario. The specs are not clear (to me
at least) as to how the TCC is handled upon return from issuers.
0800 isn't. So, DE48 is not normally present in 0800 messages, right?
My tests include 0800 exchanges with the simulator and they look ok.
It seems to me the problem is from the fact that during unpack, the
sub-fld pkgr has no way of knowing if the TCC is present. If it isn't,
it consumes the 1 byte for it as designed and the rest of the TLV
items are off.
I am working with my MC contact to see if this is only a glitch in the
simulator, or an actual valid scenario. The specs are not clear (to me
at least) as to how the TCC is handled upon return from issuers.
Alejandro Revilla
Jan 14, 2009, 9:03:12 AM1/14/09
to jpos-...@googlegroups.com
Do you need to send DE48 in the 0800 messages?
The solutions I see here are:
1) use DE48 as an opaque field and deal with it at a higher level
2) use the dynamic packager support and have two different packagers
(one for 0800s with DE48 defined just as a regular field and the other
one with the euro subfield packager).
Alwyn Schoeman
Jan 14, 2009, 2:29:20 PM1/14/09
to jpos-...@googlegroups.com
Sorry I came in at the end so I haven't read all the messages.
I'm currently working through the IPM format documentation and the
specifications says that for
each PDS forming part of DE 48:
Tag - 4 bytes
Length - 3 bytes
Data - LLLVAR
--
Alwyn Schoeman
I'm currently working through the IPM format documentation and the
specifications says that for
each PDS forming part of DE 48:
Tag - 4 bytes
Length - 3 bytes
Data - LLLVAR
Alwyn Schoeman
JayPoser
Jan 15, 2009, 11:16:46 AM1/15/09
to jPOS Users
Yes, 0800 messages are required and are working as is.
And indeed, if MC confirms that 0210 (and perhaps 0110) responses may
not always have TCC in DE48.2, then implementing choice #1 is not a
big deal.
And indeed, if MC confirms that 0210 (and perhaps 0110) responses may
not always have TCC in DE48.2, then implementing choice #1 is not a
big deal.
JayPoser
Jan 16, 2009, 8:02:50 PM1/16/09
to jPOS Users
Ok, so just got confirmation that TCC is supposed to be included in
the 210 responses and the simulator is busted. Getting new version and
the mapping should work coming and going.
the 210 responses and the simulator is busted. Getting new version and
the mapping should work coming and going.
David Bergert
Jan 17, 2009, 7:50:23 AM1/17/09
to jpos-...@googlegroups.com
Great Thanks for the update. I suspected that was the problem, according to
my intrepretation of the spec.
David Bergert, CISSP, CISA, CPISM/A
http://www.paymentsystemsblog.com
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of JayPoser
> Sent: Friday, January 16, 2009 7:03 PM
> To: jPOS Users
> Subject: Re: Europay like DE48 with a twist
>
>
my intrepretation of the spec.
David Bergert, CISSP, CISA, CPISM/A
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of JayPoser
> Sent: Friday, January 16, 2009 7:03 PM
> To: jPOS Users
> Subject: Re: Europay like DE48 with a twist
>
>
Mark Salter
Jan 17, 2009, 8:10:16 AM1/17/09
to jpos-...@googlegroups.com
JayPoser wrote:
> Ok, so just got confirmation that TCC is supposed to be included in
> the 210 responses and the simulator is busted. Getting new version and
> the mapping should work coming and going.
> Ok, so just got confirmation that TCC is supposed to be included in
> the 210 responses and the simulator is busted. Getting new version and
> the mapping should work coming and going.
Please may I ask which simulator software you are using, and which
type/version if is from MasterCard?
--
Mark
Alejandro Revilla
Jan 17, 2009, 8:23:24 AM1/17/09
to jpos-...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages