Hello all,
How do I format the <DeviceInfo> element within an <EncryptedTrackData> element?
I'm trying to integrate an encrypted card reader from ID Tech with an iPhone application using AIM. I'm using the information found in http://www.authorize.net/support/AIM_guide_XML.pdf.
In appendix B it instructs to add an <EncryptedTrackData> element to the <payment> element, and shows an example. I have integrated the example into my code, and I'm getting the following error :
E00061 Device information is not formatted correctly(1).
The device information element <DeviceInfo> in the example contains the following, Hex encoded:
FID=IDTECH.UniMag.Android.Sdk?v1^SomeTBDKey1=someothervalu
At best that looks incomplete. I've tried many different variations on that format and can't get past it. Do I need to have a specific FID? If I take the FID portion out, it complains of a missing FID value, so I think I'm on the right track, but cannot find any documentation on how to format the DeviceInfo section.
Here is my request:
<?xml version="1.0" encoding="utf-8"?>
<createTransactionRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<sessionToken>DbXl3bX4jhhnn3o44EFePBJ1S_qG6sn3wh0n$yenCMWQTTDSabyzGeggUWFm9jXW$EViMAdMTv8KXGgl0OX0DnVifttUFmUXVbHw4V_pGPYzAUaGLq5eKqB1YLwo$SM8xvAjRW6MbYMXju98zTxwqAAA</sessionToken>
<mobileDeviceId>641D3C27_88A4_4842_A1BC_7E0765CAA0E9</mobileDeviceId>
</merchantAuthentication>
<transactionRequest>
<transactionType>authCaptureTransaction</transactionType>
<payment>
<encryptedTrackData>
<FormOfPayment>
<Value>
<Encoding>Hex</Encoding>
<EncryptionAlgorithm>TDES</EncryptionAlgorithm>
<Scheme>
<DUKPT>
<Operation>DECRYPT</Operation>
<Mode>
<Data>1</Data>
</Mode>
<DeviceInfo>
<Description>4649443D4944544543482E556E694D61672E416E64726F69642E53646B76315e536f6d655442444b6579313d736f6d656f7468657276616c756</Description>
</DeviceInfo>
<EncryptedData>
<Value>02f700801f4824008383252a353434392a2a2a2a2a2a2a2a333336345e43414c4457454c4c2f48454154484552202020202020202020205e313230372a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a3f2a3b353434392a2a2a2a2a2a2a2a333336343d313230372a2a2a2a2a2a2a2a2a2a2a2a3f2a027eada5988a4718602b6d9df5942be84a197f9b1eba2f6b2abd139f7da070678267cf8254ec1d32c74733e6eb665b21ad52d29f24f8c2068c12f4f07e429a1591308158a909f5028c62d4da048fe77d9ff2b81e6a2cc01c1c626d7bbc5a0bfb85739b5a8ad097f76fef5cbf2b9bf8515431333431323032333376379501000140e0002c8f1503</Value>
</EncryptedData>
</DUKPT>
</Scheme>
</Value>
</FormOfPayment>
</encryptedTrackData>
</payment>
<order/>
<lineItems/>
<customer/>
<billTo/>
<shipTo/>
<transactionSettings/>
<userFields/>
</transactionRequest>
</createTransactionRequest>
And here's the response I'm getting:
<?xml version="1.0" encoding="utf-8"?>
<createTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<messages>
<resultCode>Error</resultCode>
<message>
<code>E00061</code>
<text>Device information is not formatted correctly(1).</text>
</message>
</messages>
<sessionToken>yOetHv0orjnUdVosJNP4X$lB5RGsPmCtGrL0hdcrg3arjzaCojNW8zCkUl0BT2N9Bwo50DTtA3Oi3zMXgRaZGTG6MJZwB9M15K5sv$mrv5wllbSgcUJ3Mq66wk6YuNxywgqC8Pi0aiaGqOEqKfpZqwAA</sessionToken>
</createTransactionResponse>
Thanks for your help!
-Dustin
Solved! Go to Solution.
03-18-2014 08:54 PM - last edited on 03-19-2014 09:29 AM by RichardH
Dustin, I read the portion of the AIM XML guide you referenced, and I agree it's a bit confusing. I'll discuss it with our technical writers and see if we can clarify things.
I believe, however, that right now we don't need more than "FID=IDTECH.UniMag.Android.Sdkv1" in the encoding you selected with the Encoded element.
Would you try setting the Description element to "4649443D4944544543482E556E694D61672E416E64726F69642E53646B7631", please?
03-21-2014 09:37 AM - edited 03-21-2014 09:38 AM
Apparently, "IDTECH.UniMag.Android.Sdkv1" should work with all the UniMag readers. It is also currently the only FID we'd accept. It should not matter that the FID has the word "Android" in it--my understanding is that it should work with iOS as well.
Shortly we will release support for Common Track enabled readers, at which point we will have a new FID option, "COMMON.EncryptedTracks.Sdkv1", available.
I'm investingating the KSN error you mentioned.
03-24-2014 09:49 AM - edited 03-24-2014 10:27 AM
One possibility that has been raised is that the card reader you have may be assigned a KSN intended for our Production environment, which means it cannot be used in our Sandbox environment--or vice-versa. Did you get this reader directly from IDtech? Also, which posting URL are you using?
03-24-2014 10:26 AM
Dustin, I read the portion of the AIM XML guide you referenced, and I agree it's a bit confusing. I'll discuss it with our technical writers and see if we can clarify things.
I believe, however, that right now we don't need more than "FID=IDTECH.UniMag.Android.Sdkv1" in the encoding you selected with the Encoded element.
Would you try setting the Description element to "4649443D4944544543482E556E694D61672E416E64726F69642E53646B7631", please?
03-21-2014 09:37 AM - edited 03-21-2014 09:38 AM
I am now getting:
Could not resolve KSN to a registered merchant: 76379501000140E0002F(3).
Am I correct in assuming that it uses the FID= value in the DeviceInfo element to determine which KSN to decrypt with? If so, I need to know the FID to use for IDTech UniMag ios. Do I get that FID from authorize.net or from IDTech?
Here's the full response:
<?xml version="1.0"?>
<createTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<messages>
<resultCode>Error</resultCode>
<message>
<code>E00061</code>
<text>Could not resolve KSN to a registered merchant: 76379501000140E0002F(3).</text>
</message>
</messages>
<sessionToken>MS3z7PbPFBjQJrjYaWJfIr4xaMk2fsoEajDzFwX9ns$4ov7aQ2cDfTdwi79VPnfTE_AzNjh1KelWXvq8anbD2bW$2J93Pss3Ra9D_ON4OwuIzOZUXxa6jSByDxdSW4D8If6IaDpvkTo1vixFtKdmLwAA</sessionToken>
</createTransactionResponse>
03-23-2014 12:20 PM
I tried using FID=IDTECH.UniMag.iOS.Sdkv1 which I didn't really expect to work, and indeed it didn't:
<code>E00061</code>
<text>Invalid FID value(3).</text>
03-23-2014 12:24 PM
Apparently, "IDTECH.UniMag.Android.Sdkv1" should work with all the UniMag readers. It is also currently the only FID we'd accept. It should not matter that the FID has the word "Android" in it--my understanding is that it should work with iOS as well.
Shortly we will release support for Common Track enabled readers, at which point we will have a new FID option, "COMMON.EncryptedTracks.Sdkv1", available.
I'm investingating the KSN error you mentioned.
03-24-2014 09:49 AM - edited 03-24-2014 10:27 AM
One possibility that has been raised is that the card reader you have may be assigned a KSN intended for our Production environment, which means it cannot be used in our Sandbox environment--or vice-versa. Did you get this reader directly from IDtech? Also, which posting URL are you using?
03-24-2014 10:26 AM
I am using the sandbox, and while not certain, I wouldn't be surprised if it is intended for the production environment.
We did get this directly from IDTech.
I am using the iOS SDK, but it looks like that is posting to https://apitest.authorize.net/xml/v1/request.api
If I switch to the production environment, with this start working?
Is there a way to test this in sandbox?
Thanks for your help!
03-24-2014 11:32 AM
I just determined that, unfortunately, we don't currently have card readers for the Sandbox environnment. We're discussing options to resolve that situation, including seeing if we can enable Production KSNs in the Sandbox environment. Until then, it seems that any testing would have to be done with a Production account.
03-25-2014 09:07 AM
You can sign up to be notified when additional details for encrypted reader support is available by using this form: http://forms.authorize.net/encrypted_reader_interest_form
03-25-2014 09:54 AM
I was able to get a swipe and charge to work successfully. After changing to the production environment, I started getting different errors, such as the familiar Error 87: Transactions of this market type cannot be processed on this system.
This was caused by the sample code missing the following:
requestType.retail = retailInfoType;
Once I put that in, transactions started flowing.
Thank you to Lilith for the coaching that got me past the big issues.
03-26-2014 09:30 PM