barco57:
1.5.5.e
found that includes/modules/pages/checkout_payment/jscript_zen_colorbox.php causes an issue when using the Authorize.net (AIM) module. Seems to pass the CC number to the confim page but when you click the confirm button you get sent back to the paument page with the following error ""Credit card number is required. - Your credit card could not be authorized for this reason. Please correct the information and try again or contact us for further assistance."
I assume the jscript_zen_colorbox.php is on that page to load the cvv popup in colorbox instead, so I solved the problem by removing jscript_zen_colorbox.php from that path so it doesn't load on that page.
Looking back through things a little, the colorbox option is provided on the checkout_payment page to offer an in place popup of the coupon window help and that only (sure it could likely be used to support entry for some other popup as well I would think, but that was not its original consideration for the payment page). That said, there are a few things not quite right here... For one, the link does not appear until a coupon has been entered (either entered without selecting a payment or having returned to the payment page). Another is that if the link is presented it potentially causes mixed content (which then can carry over into the colorbox segment and becomes more "apparent"). Then there is the fact that it is a javascript like link instead of a simple link used say on the product information page. So I'm not entirely sure which of the above played a factor in the problem seen with authorize.net (AIM) because of the additional information below as well. Of course another slightly more "limiting" condition would be to prevent the javascript from loading if the store doesn't offer coupons to begin with which is likely a good course of action but doesn't necessarily solve the issue.
What I'm seeing in the code based on the error message is that the checkout_payment page is submitted and some amount of data is sent to the checkout_process "page". Then within the checkout_process module received data is evaluated for accuracy and sent to authorize.net (AIM). In this scenario, the error is actually coming directly from authorize.net (AIM) which has identified that the credit card number was not provided. So it seems that either colorbox at one point or another is affecting the credit card number collection or there is some validation that has occurred as part of the submission and prior to processing in the checkout_process module that has disturbed the credit card number.
I've made the following changes though to includes/modules/pages/checkout_payment/jscript_zen_colorbox.php having tested this functionality in place on a cart that hasn't had anything changed in this area but still without an authorize.net (AIM) payment module in place. I also modified includes/modules/order_totals/ot_coupon.php function credit_selection() beginning at line 131 from:
function credit_selection() {
global $discount_coupon;
// note the placement of the redeem code can be moved within the array on the instructions or the title
$selection = array('id' => $this->code,
'module' => $this->title,
'redeem_instructions' => MODULE_ORDER_TOTAL_COUPON_REDEEM_INSTRUCTIONS . ($discount_coupon->fields['coupon_code'] != '' ? MODULE_ORDER_TOTAL_COUPON_REMOVE_INSTRUCTIONS : '') . ($discount_coupon->fields['coupon_code'] != '' ? MODULE_ORDER_TOTAL_COUPON_TEXT_CURRENT_CODE . '<a href="javascript:couponpopupWindow(\'' . zen_href_link(FILENAME_POPUP_COUPON_HELP, 'cID=' . $_SESSION['cc_id']) . '\')">' . $discount_coupon->fields['coupon_code'] . '</a><br /><br />' : ''),
to:
function credit_selection() {
global $discount_coupon, $request_type;
// note the placement of the redeem code can be moved within the array on the instructions or the title
$selection = array('id' => $this->code,
'module' => $this->title,
'redeem_instructions' => MODULE_ORDER_TOTAL_COUPON_REDEEM_INSTRUCTIONS . ($discount_coupon->fields['coupon_code'] != '' ? MODULE_ORDER_TOTAL_COUPON_REMOVE_INSTRUCTIONS : '') . ($discount_coupon->fields['coupon_code'] != '' ? MODULE_ORDER_TOTAL_COUPON_TEXT_CURRENT_CODE . '<a href="javascript:couponpopupWindow(\'' . zen_href_link(FILENAME_POPUP_COUPON_HELP, 'cID=' . $_SESSION['cc_id'], $request_type) . '\')">' . $discount_coupon->fields['coupon_code'] . '</a><br /><br />' : ''),
This ensured that the link would be generated according to the page's load type (https: or http:). In a way this is becoming a moot point because either a store is going completely SSL or doesn't have one... But, regardless the link generated was one that was http: and then when colorbox got involved this caused mixed content.
The changes I made to includes/modules/pages/checkout_payment/jscript_zen_colorbox.php were:
From:
require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'zen_colorbox/display_link.php');
to:
require_once(DIR_FS_CATALOG . DIR_WS_CLASSES . 'zen_colorbox/display_js_link.php');
Operation on a responsive template ZC 1.5.5e version was improved. I don't have credentials against which to test authorize.net (AIM) to see what is/was going on, but if you could answer a few questions perhaps this issue can be resolved.
Does the store support coupons?
Does the problem occur before/without any coupon entered?
What browser(s) were used to test this?
What other javascript related items are loaded beyond the default install and jscript_zen_colorbox.php?
If the store uses coupons then please consider the below as well.
Is it possible to enter a coupon without selecting a payment method and selecting the continue button and does the problem then occur if the payment method is selected and continue with process?
What is it about the confirmation page information that indicates that the number (in its entirety) has been successfully passed to the confirmation page?
