authorize.net problems

[scottb]

Here are the runtime errors I get in step two of the checkout.

[Ajeh]

What happens if you turn off your debugging in your browser?

[scottb]

The transactions go through fine with debugging turned off. I always run my production computers with several debugging tools active.

Now how do I get rid of this from step 2 of the check-out process?

MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK

See above error jpgs

[DrByte]

MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK

That is a constant, defined in the language file:
/includes/languages/english/modules/payment/authorizenet_aim.php

  define('MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK', 'What\'s this?');

I believe that entry was added for v1.3.7 ... which is likely why you're not seeing it, since in your case you started using this code to fix a problem -- before 1.3.7 was even released.

[scottb]

That define line does not exist in my /includes/languages/english/modules/payment/authorizenet_aim.php file

I am using 1.3.6

[scottb]

It does exist here

/includes/modules/payment/authorizenet_aim.php

Line #175 : 'field' => zen_draw_input_field('authorizenet_aim_cc_cvv', '', 'size="4", maxlength="4"' . ' id="'.$this->code.'-cc-cvv"' . $onFocus) . ' ' . '<a href="javascriptopupWindow(\'' . zen_href_link(FILENAME_POPUP_CVV_HELP) . '\')">' . MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK . '</a>',

But it breaks the checkout if I touch the line.

[sonrisa29]

Scott B, you wouldn't happen to be running on Mac OS 1.3.9 would you?

Is this a problem if you are using OS 1.3.9? It would help explain our problems with AIM!:)

[GFLKEN]

Updated module attached, which sets the delimiter and parses accordingly.
Parser is more intelligent now too and can handle encap characters also.
In fact, the module now explicitly sets the delimiter to | and encap to * so that it knows what to expect back from authorizenet.
Using the | is likely safer than using the comma because one could use a comma in their address and end up with a problem ... whereas a | is highly unlikely, and stripping out | symbols is likely less confusing than stripping commas. (Keep in mind that the ZC AIM module has always been stripping commas before sending, so as to prevent against these problems).

Thank you Drbyte for this fix. We installed it last month when it was discovered that single quotes returned from authorize.net in the city feild caused errors. Since the install, orders come through fine...I thought everthing was good until we started getting calls from customers not able to use their Amex card. After looking into the issue, we discovered that we haven't had any amex transactions since installing this upgrade. I have done some homework to pinpoint the problem, and here is what I found out:

• We have processed many amex cards before this update
• I can still process Amex through the virtual terminal on Auth.net
• My processesor has confirmed that everything is still set up correctly
• I also compared my installed file with the one in your zip file, and it is an exact match.
• To clarify, it's: @version $Id: authorizenet_aim.php 5534 2007-01-05 10:21:51Z drbyte $
• The error that I receive after entering an amex number is: The credit card number starting with xxxx was not entered correctly, or we do not accept that kind of card. Please try again or use another credit card.

Visa & MC work perfectly, just Amex is the issue.

FYI, AIM is the only payment module I have enabled.

I looked through the code and compared the changes with the original...unfortunately I am not very good with php (pretty new to zc too) and nothing jumped out at me as a source for the problem.

Do you have any suggestions? Any help is much appreciated, I need to get this running smoothly again...

FYI, I'll be adding Discover after Amex is back up and running, and finally, I plan to add Paypal as an alternative method of payment (but not until AIM is solid).

Thanks!!

[DrByte]

1. Do you have Amex enabled in Admin->Configuration->Credit Cards ?

2. The 'we don't accept that kind of card' message is a result of the card number-validation failing. Credit Card number-validations happen via /includes/classes/cc_validation.php. Amex rules are defined there along with all the other card types. Have you changed that file at all ? The one that comes with v.1.3.7 / v1.3.7.1 is the most current.

The rule is: ereg('^3[47][0-9]{13}$', $number) ... which means: starts with 34 or 37 and has 13 more digits.
What pattern is the amex number you were trying?

[GFLKEN]

Well...that's why you're the doctor!

Somehow Amex was turned off from admin. I had someone helping me, they must have done that when they installed the upgrade...probably for testing & forgot to turn back on. Anyway, I just put an order through, so its golden.

One question though...Amex (at least mine) has 15 digits, not 13...I guess the reg exp checks for the first 2 digits and counts the rest?

No biggie, because my site is working right now - just the curiousity factor.

Thanks again DrByte!