topic Re: IDTECH card reader - which part of the encrypted string needs to be submitted? in Integration and Testing

IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Wed, 01 Jul 2015 18:58:23 GMT

Hi.

I have an IDTECH SecureMag card reader that was pre-configured to work with authorize.net. As far as I know, it uses encryption level 3.

I have looked through the support documents and manuals both from authorize.net and IDTECH but have not found the details I need.

We are planning on writing an API that will send the plain text output of the card reader to authorize.net. I have found the entries in the documentation that tells me where this code needs to go, but what I couldn't find out is which part of the output needs to be submitted.

As far as I know, the encrypted text should start with "02" and end with "03". The entire output does, but not all of it is encrypted. There are the owner's name and the first and last 4 digits of the card number embedded in plain text within the encrypted code.

The example in your documentation only shows hex input, so I am wondering what it actually is that I need to submit to your API - the entire string starting with "02" and ending with "03", or only the part before/after the plain text information?

I am aware that the reader needs to have a key for the decryption to work - it supposedly was already entered before we got it.

Thanks in advance!

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Wed, 01 Jul 2015 19:11:55 GMT

I should add that the card reader I have is a USB Keyboard reader, not USB/HID. So this device creates the output like a regular keyboard would.

I don't know if this will make a difference, but I thought I'd add it.

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Wed, 08 Jul 2015 18:58:00 GMT

Here is an example string of what the card reader sends back (with a few minor changes to avoid abuse):

02D901801F4F2800039B%*3751*******1356^SMITH/JOHN              ^**********************************?*;3751*******1356=*********************?*E490DA8F8BB96CEC8B1C25AD7933EA11EAA2C15C23D4AC073318AED730FA80B5036BB530D1C144629BB85E98491E697F4642C3CB8EA3B3C7B6A6A5D55D1BACF72B17D7EB136CA14C810B65EA9880493F59D78C4BA1FDB7F6822324DC8DC1F21DC165B139AB18BAAE8AB1004627B470081C844CFB6296B815123D1C1109BC2D9AFDC020CBC9AEEAD863D2C2290077277D32C2B90F2FB526272282C656E21F5D4276379501000233000008224C03

I have looked at the documentation of the card reader, but I can't make heads or tails of it, and I don't know what authorize.net expects to receive.

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

RichardH — Wed, 08 Jul 2015 20:59:23 GMT

Hello @rlund

Normally you would obtain the encrypted data block from the SDK provided by the hardware manufacturer. I'll check with our integration team about your observations.

Was the specific device you have injected with the Authorize.Net key?

Richard

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Wed, 08 Jul 2015 21:16:43 GMT

Thanks!

Yes, the device I have has received an authorize.net key.

I have had trouble finding an SDK from the manufacturer that gives me useful information so far, but I could probably find out the details I need once I know what information I need to supply to you.

I found a program on the manufacturer's site that decrypts the data as far as it can, and does split up the information into Key Value, KSN, and Decrypted Data in HEX Format. I don't know which of this information is needed by you - I was under the impression that everything between the starting "02" and the ending "03" was needed...

If you only need that encrypted data block, I at least have something to look for in the SDK (even though I don't know the programming language it uses).

Someone else I have talked to says you need the KSN information, and if that is correct, how do I add the KSN to the encrypted data - or is that included in the encrypted data?

Then there's the issue of the Device Information - another forum post first talks about how it can be a specific string for every device, and then another answer says that the authorize.net key needs to be included in it ...

To be honest, I am completely stuck and confused because I have yet to find the correct information I need.

Can you supply me the bits I am missing?

Thanks so much!

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Tue, 14 Jul 2015 13:38:12 GMT

Still looking for an answer...

I have managed to pick apart the string from the card reader into its parts, but I still don't know what information you require - track 1, track 2, track 3, ksn, some of them, all of them? And if you require multiple parts, how do they need to be separated and in what order?

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

RichardH — Tue, 14 Jul 2015 15:37:20 GMT

Hello @rlund

Can you please confirm the specific model/part number of the device you are using.

You won't be parsing the encrypted data, you must send the entire encrypted data block to Authorize.Net to be decrypted.

Richard

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Tue, 14 Jul 2015 15:46:05 GMT

The Model # is: IDRE-334133BE.

It's a SecureMag reader in KB mode, so it outputs the masked data as ASCII (see my submitted example).

Please give me a definition of what is considered "the entire encrypted data block" since I have heard too many answers to know what is what anymore...

The data coming from the reader contains 10 bytes of header data (data length, track information, etc.), then track 1 masked, track 2 masked, track 3 encrypted, track 1 and 2 hashes (20 bytes each), then 3 Bytes of checksum and end data.

Out of this, what is considered "the entire encrypted data block" - all of it?

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

Lucas — Mon, 20 Jul 2015 17:22:32 GMT

Hi Rlund,

We have implemented the IDTech Shuttle for card-present MPOS payments in our app. Be advised that there are two versions of the IDTech Card Readers on the POS Portal website, one for Dev and one for Production. The devices encrypt the card data at the magentic head with one-way encryption and the key is different between Dev and Prod and this is why you need to have both for testing and deployment.

You do not want to decrypt this data. Below is a sample XML request using AIM method. I've placed the important part relating to your question in red.

Instead of placing the <creditCard> block inside <payment>, you use <encryptedTrackData> instead. You'll leave most of that block alone, as the <DeviceInfo> tells Authorize.net how to decrypt the data. You'll take the encrypted block that the IDTech device spits out and put it inside <EncryptedData><Value>. You'll also need the <retail> block at the bottom. The API documentation will tell you what values to enter there.

<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>API_LOGIN_ID</name>
    <transactionKey>API_TRANSACTION_KEY</transactionKey>
  </merchantAuthentication>
  <refId>123456</refId>
  <transactionRequest>
    <transactionType>authCaptureTransaction</transactionType>
    <amount>5.66</amount>
    <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>
									02f300801f342600039b252a343237352a2a2a2a2a2a2a2a353637355e332f54455354205e2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a3f2a3b343237352a2a2a2a2a2a2a2a353637353d2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a3f2a521db2603bfe6169fc371211161c4ad6edd7294a8352af1ba8b388c527d8d6335286413ad67521b8be085da998cef7ae3621b0b72eecd6d61953a4a268e02a8cdff3d365216df73646b326d8dac369c11a2a3a4a9336addc4a15ae5d8843e0163bae895b9b4df3253439b4dd885363ad108604ea04f2e4fac701a5a0e65c54e1301a5ed7706eb88762994901000000400015ac1e03
								</Value>
							</EncryptedData>
						</DUKPT>
					</Scheme>
				</Value>
			</FormOfPayment>
		</encryptedTrackData>
	</payment>
    <order>
     <invoiceNumber>INV-12345</invoiceNumber>
     <description>INVOICE DESCRIPTION</description>
    </order>
    <tax>
      <amount>4.26</amount>
      <name>MARINA TAX</name>
      <description>Sales Tax</description>
    </tax>
    <customer>
      <id>99999456654</id>
    </customer>
    <customerIP>192.168.1.1</customerIP>
    <retail>
    	<marketType>2</marketType>
    	<deviceType>4</deviceType>
	</retail>
    <transactionSettings>
      <setting>
        <settingName>testRequest</settingName>
        <settingValue>false</settingValue>
      </setting>
    </transactionSettings>
  </transactionRequest>
</createTransactionRequest>

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Mon, 20 Jul 2015 17:54:05 GMT

Thanks for your reply.

I already knew the basics of the XML structure to submit, but what was missing was the Device Info and the Encrypted Data that actually needs to be included.

In your example, it looks as if the entire string that the card reader produces goes into the data section (starting "02" and ending "03"), so that's good to know.

Where did you get the Device Info string, though? I have tried various versions that I found in this forum, but all kept returning "E00061 Device information is not formatted correctly(1)".

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

Lucas — Wed, 29 Jul 2015 00:26:20 GMT

I snagged it from an old PDF integration guide. I can't even remember where it was from.

Did the one I provide work?

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Wed, 29 Jul 2015 12:55:28 GMT

I had the same PDF to work with and have tried the Device Info before without success.

I'm in contact with Authorize.net directly who at this time are saying that my particular reader is not yet supported...

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

grandejon — Fri, 21 Aug 2015 14:49:53 GMT

Hello @rlund,

Did you ever get this sorted out?

I'm also looking into using an encrypted card reader for a computer, but I haven't been able to find any encrypted readers for Authorize.Net except for those meant to plug into mobile devices like tablets/phones.

Could you tell me where you got your Authorize.Net compatible encrypted card reader from?

-Jon

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Fri, 21 Aug 2015 14:57:14 GMT

Sorry, I haven't had any luck with this yet...

As far as I know, the reader I was given to work with is currently NOT supported by authorize.net even though the manufacturer added an official authorize.net key to it.

I honestly don't know what the status is on this (i.e. if authorize.net is working on it or not) as I was told to put the project on hold for the time being.

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

grandejon — Fri, 21 Aug 2015 15:09:22 GMT

Thanks for the update!

I was afraid that was the situation, Authorize.Net seems utterly uninterested in providing a USB encrytped card reader solution to their customers.

On a side note, if your project allows you to switch out the payment gateway I would highly recommend Element Payment Services (www.elementps.com). Their solution includes encrypted card reader support and even uses the same IDTECH card reader model that you mentioned (IDRE-334133B-E1). I've been using their services for the past 3 or 4 years now and have been very pleased with them.

Re: IDTECH card reader - which part of the encrypted string needs to be submitted?

rlund — Fri, 21 Aug 2015 15:18:36 GMT

Thanks for the suggestion. I think we're probably stuck with authorize because we use them for other services already, but we'll see what happens. I think someone said they would work on it on their end, but I have no idea if that's still in the talks or not.