Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

on authorize.net module, what's with the x_fp_hash?


Guest

Recommended Posts

The authorize.net module wasn't working for me, so I kept debugging it until I found out that the hidden field with x_fp_hash=$fingerprint was the problem.

 

This stuff is on line 97 of the authorizenet.php

 

So I just commented out that line, and I had to replace it with x_dummy_data='test', because this object requires 3 values I guess. Anyway authorize.net ignores that and now the transactions work!

 

So it was the x_fp_hash screwing it up. What the heck is that and what do I need it for? I am not familiar with the PHP code of osCommerce at all, I was just skimming through it.

 

Thanks!!!

-Carlos-

Link to comment
Share on other sites

That is the fingerprint hash and is required by Authorize.net to process transactions.

 

Download from Authorize.net's site the programmer's guide for online processing and all of the fields are explained. ;)

"Great spirits have always found violent opposition from mediocre minds. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence." - A. Einstein

Link to comment
Share on other sites

Thanks Jim, I know where the manuals are. I will probably read everything later.

 

But the thing is, the x_fp_hash actually PREVENTED transactions from working. By removing it, now they work. So do you know why this may be so?

 

I'd rather have the x_fp_hash in the code since it is SUPPOSED to be there, rather than my quick fix of removing it.

 

Thanks!

-Carlos-

Link to comment
Share on other sites

If you are in production mode then Authorize.net should not accept the transaction with the fingerprint.

 

To verify your fingerprint is accurate, take an order to the checkout confirmation page, view source, go to Sluggis, click on SIM Troubleshooting, Error 99, and enter the information in the fields and see what it says.

 

If it is correct (as is usually the case), then Authorize.net screwed something up and needs to fix it.

"Great spirits have always found violent opposition from mediocre minds. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence." - A. Einstein

Link to comment
Share on other sites

Ahh... I see.

Ok correct me if I'm wrong.

 

I understand from you that:

 

If I am in production mode, there is no need for x_fp_hash.

 

Therefore, the authorizenet.php module has a bug, because it should remove the x_fp_hash hidden field if you select "production mode", but it does not.

 

Am I right?

Thanks for the sluggis link! I'll check that out!

 

-Carlos-

Link to comment
Share on other sites

No, I am afraid that you have it reversed.

 

If you are in production mode, you must have the fp_hash in order for Authorize.net to accept and process your transaction.

"Great spirits have always found violent opposition from mediocre minds. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence." - A. Einstein

Link to comment
Share on other sites

that is strange, my friend, for on my tests, it is the reverse of what you say. I am in production mode, and x_fp_hash actually ruins the whole process.

 

You can take a look at www.elskateshop.com. On the order confirmation page, you'll see that there is no more x_fp_hash hidden field, but one I replaced it with called x_dummy_data.

 

Actually, all authorize.net wants at a minimum is the following:

 

https://secure.authorize.net/gateway/transa...l?x_Login=(YOUR LOGIN NAME)&x_Card_Num=(THE CARD NUMBER)&x_Exp_Date=(THE EXP DATE)&x_Amount=(DOLLAR AMOUNT).

 

In fact, a transaction can go through successfully with just that.

 

The authorizenet.php module adds a bunch of extra variables, such as customer name, id, timestamp, the version number (which I changed from 3.0 to 3.1), and of course, the infamous x_fp_hash, which broke the whole process.

 

Simply removing it fixed everything. Sorry if I sound repetitive... just want to make sure you don't think anything weird is going on.

 

Thanks!

-Carlos-

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...