Authorize.net AIM not returning any errors or notice on the 'test decline' card #...

i'm have the Authorize.net AIM module is test mode. But when entering in the Automatic Decline CC # 4222222222222 (as shown in the admin module) it is proceeding w/ check out anyway. Shouldn't it post a notice?,
and not proceed w/ checkout?

In fact, this module is proceeding w/ checkout no matter what you put in the CC form,

ie., choose the AIM payment method, and even you enter in absolutely nothing,
the checkout transaction proceeds until the end.

i know how to do front-end validation w/ js but seems that a ZC payment module should also have some form validation going on..?,

please note, in this situation the SSL is turned on but the security certificate is not engaged. don't know if that has anything to do with it or not

any insight at all would be greatly appreciated, thanks!

If it's accepting "anything" for a card number, and never rejecting a truly invalid card, then you've got something else broken other than the payment module.

You're right: Zen Cart DOES do validation before even submitting the transaction to the gateway. Relying on front-end JS for card validation is foolish, let alone pointless, for security reasons.

I can't recall ever using special card numbers to force a decline such as the one you mentioned. I simply use a truly invalid number, ie: one that doesn't pass proper cc validation rules.
Also, it's possible that the "test mode" is very different from "developer mode" where specific prices and card numbers and cvv codes trigger very specific gateway responses.

Valid numbers for testing include: http://www.zen-cart.com/content.php?187
To get an invalid one, increment any of those numbers by "1", or change the first digit to a 9.

If your store passes the invalid number to the gateway without any error first, then you've broken the built-in validation logic. Start by putting that back to normal.

am troubleshooting this now.

can you confirm that the MD5 Hash is not needed for the AIM module?

i'm fairly certain that's what i read on the Authorize.net FAQ's.

MD5 Hash is used for the AIM module when using it with Authorize.net.
The FAQ article for instructions on setting up the AIM module will confirm what you need.

thanks!, i will review. i was mistaken, thought it was only for SIM

Doh. My bad. It's optional for AIM. But if you've set it up in your authnet account, you need to set it into your payment module settings too.

http://www.zen-cart.com/content.php?291-how-to-set-up-the-authorizenet-aim-payment-module

ok thanks,

when doing a var_dump on $GLOBALS, I see the selected module is not set, and that is on the

'tpl_checkout_confirmation_default.php' page. Although 'paymentClass' is set, ...so i dunno.

If i select Authorize.net AIM and then checkout, none of Authorize.net Aim's methods get run.

i'm turning off FEC checkout for now, to continue TS's (troubleshooting)

I can't speak to all your alterations and plugins, but I know it works correctly out-of-the-box on a fresh install.

i turned off FEC and now at least the javascript_confirmation is now firing. but still no selected module.

there is no security certificate in place even though the SSL is turned on. could that be the problem??

am trying to determine that now.

sorry for all the questions!,

should there be this $_SESSION var?, $_SESSION['SSL_SESSION_ID'] ...?

it's not present on the tpl_checkout_confirmation_default page via a var_dump($_SESSION).

like i said, am trying to determine if having the SSL on but without a Security Certificate is causing the problem.

ug, thanks for all the help, i really appreciate it.

AIM will not work ... will not even show up ... if SSL is not enabled.

You can't use a payment module which takes credit card numbers without encrypting those numbers when the browser sends them. And that requires SSL.

Stop "testing" payment modules in an unsecure environment ... cuz all you're testing is that your environment is wrong, not the payment processing.

thanks for answering my Post Dr. Byte

the situation is.. the SSL is on, but there is no security certificate.

tcarden:

the situation is.. the SSL is on, but there is no security certificate.
Then ... SSL is not really "on".

Setting ENABLE_SSL to 'true' only tells Zen Cart to use the HTTPS_SERVER value instead of HTTP_SERVER when handling pages which deal with sensitive info.

But if your HTTPS_SERVER value points to a URL that does not actually have SSL on it, then you're NOT actually using SSL at all.

In short, what you're doing with "SSL is on but there is no security certificate" is pointless, and counterproductive. And your payment modules won't work any better with this faked-out scenario.

thanks, i did not know that.

though i had a feeling....!,

i've stated this scenario on a couple of other forums but that it is the clearest answer i've gotten so far.