AuthNet IM Module problem

[esebm]

Yes, you are right with the sequence.
The order process goes through steps 1,2 3 -->confirm order -->enter credit card info -->Submit -->Sending and back to step 2.

The buyer gets an e-mail from Auth.net that the order was approved.

The buyer gets an e-mail confirming the order with the correct price but no description of what was ordered.

The seller basically gets a similar e-mail but again, no description of the item that was ordered so they have no clue what to ship.

Hope that helps.

The log file follows below.

Thanks,

Ed

Nov-05-2010 04:06:22
=================================

Response Code: 1.
Response Text: This transaction has been approved.

Results Received back from Authorizenet: Array
(
[x_response_code] => 1
[x_response_reason_code] => 1
[x_response_reason_text] => This transaction has been approved.
[x_avs_code] => Y
[x_auth_code] => 087277
[x_trans_id] => 3274952363
[x_method] => CC
[x_card_type] => Visa
[x_account_number] => XXXX366X

** SNIP **

[x_amount] => 330.00
[x_tax] => 0.00
[x_duty] => 0.00
[x_freight] => 0.00
[x_tax_exempt] => FALSE
[x_po_num] =>
[x_MD5_Hash] => 37D74281436EFB33451DE2C29C022A07
[x_cvv2_resp_code] =>
[x_cavv_response] =>
[x_test_request] => false
[zenid] => 2f3211e5bb71f8b0f66ca254ba5aa5fa
[HashValidationValue] => FC69882D5AC74676FA7534AE4A970777
[HashMatchStatus] => FAIL
[url] => https://secure.authorize.net/gateway/transact.dll
)

[DrByte]

[HashValidationValue] => FC69882D5AC74676FA7534AE4A970777
[HashMatchStatus] => FAIL

That's telling you that the MD5Hash you entered in your Authnet account settings doesn't match the MD5Hash you entered in your Zen Cart module.
Thus Zen Cart is rejecting the order because it can't be validated as trustworthy ... ie: might be fraudulent.

The solution is to pick a phrase of less than 20 chars and put that into both sides as the MD5Hash value, as per the setup instructions.
https://www.zen-cart.com/tutorials/i...hp?article=403

[esebm]

Well, we have done that just yesterday but we will do it again.

Why does Authorize.net let the purchases go through if it can't be trusted?

Has that something to do with the seller not getting reported which item was ordered?

[DrByte]

Well, we have done that just yesterday but we will do it again.

Why does Authorize.net let the purchases go through if it can't be trusted?

Has that something to do with the seller not getting reported which item was ordered?

Read my post more carefully: It's Zen Cart that's rejecting the payment, not Authorize.net.
Zen Cart is rejecting it because the hash codes don't match, thus Zen Cart cannot be certain that the payment isn't a spoofed attempt to trick your store into thinking it's got payment when it really doesn't.

The only way to get the hash codes to match is for *you* to enter them the same on both sides. It's very simple.


Or, you can use the AIM module instead, and not have any of this hassle with hashing requirements being necessary.

[esebm]

Okay, didn't read it thoroughly, my bad, sorry. The zen cart rejects the payment, understood.

Just out of curiosity (pardon my stupidity), but why does the zen cart let the purchases go through to Authorize.net if it is not certain that the purchase is legit?

[DrByte]

You're misunderstanding it.

Think of it this way. You're a customer. You create an account and add products to your cart and go thru checkout. The only thing Zen Cart knows about you is the address that you entered. It has no way of knowing anything about you or your purchase. Since you're using SIM, which takes ALL the payment knowledge completely out of Zen Cart's control or knowledge, Zen Cart must simply pass on all the information and wait for the customer to come back from the other site with a code that says whether Authnet accepted the payment or not.

How do you expect Zen Cart to know whether it's legit or not?

There's no way ... short of the hash code that's calculated on both ends and checked for validity before Zen Cart accepts the payment response. Only if those codes match will Zen Cart store the order and send out its confirmations.


As I said, if you want seamless operation and to avoid ALL of that hassle, use the AIM module instead. It handles all that stuff directly with Authorize.net and isn't subject to having to validate hash codes etc because it controls the whole payment process.

[Kim]

Moderator's note - the hijacked portion of the previous thread has been moved to its own thread.

[esebm]

DrByte,

You are correct, I'm a customer and no ZC expert, hence my stupid questions.

Thanks a lot for the explanation, it has helped me understand things better.