3 replies to this topic

[Medworks]

Customer chooses shipping method and shipping cost on page 1 of checkout.

Customer chooses payment method "Credit Card (Processed by Authorize.net)" on page 2 of checkout.

Customer sees total based on choices and items purchased and is prompted for credit card owner, number, expiry date, check number (CVC) on page 3 of checkout. Address at top is:

https://secure32.inmotionhosting.com/~medexa5/oscommerce1/checkout_confirmation.php?osCsid=693423eca....

Customer presses "confirm order" button on page 3 of checkout.

Customer is directed back to page 2 of checkout with the following message at the top of the screen: "There has been an error processing your credit card" followed by these words inside a pink highlighted box: "Please try again and if problems persist, please try another payment method." Address seen at top of page is now:

https://secure32.inmotionhosting.com/~medexa5/oscommerce1/checkout_payment.php?payment_error=authorizenet_cc_aim&error= Credit card number is required.&osCsid=693423eca....

Note error message "Credit card number is required" in website address bar. No evidence of any event occurring appears within quickcommerce; no transaction, neither accepted nor declined, is reported. Most likely conclusion based on observation is that null string is submitted for credit card number instead of 15 or 16 digit number entered into that field, and possibly null character string is submitted for name, expiry date and check number as well but I cannot confirm or deny this. Module was functional until September 16, was damaged by hacker, restored by me, and then module was not functional. Authorize.net, quickcommerce, webhost refuse to assist.

User settings of module are:

transaction server and mode live, transaction method is authorization, payment zone none, set order status pending, sort order of display 4, cURL Program Location /usr/bin/curl, name of module authorizenet_cc_aim. Went into quickcommerce and added in a MD5 hash and entered the same character string into MD5 hash in oscommerce module. Occurrence of error unaffected. Unwilling to change transaction method to capture because then the amount charged cannot be adjusted (lowered), and the need for this occurs frequently due to items out of stock, shipping being only an estimate, and customers contacting to submit modifications to the order they just submitted. Sort order of display changed between 2 and 3 and 4. Observed that authorize.net payment option was not shown when another payment option, even if disabled, had the same sort order of display. That is all.

Request diagnosis of failure of module and course of action for correction.

Edited by Medworks, 13 November 2010, 06:08.

[satish]

As there is a third party involved( payment gateway).
I recommend you should first capture teh request sent and the response received.


Paste those here( offcourse xxxx the critical details like cc number,cvv etc).

Satish

[Medworks]

satish, on 21 November 2010, 12:17, said:

As there is a third party involved( payment gateway).
I recommend you should first capture teh request sent and the response received.


Paste those here( offcourse xxxx the critical details like cc number,cvv etc).

Satish

How do I capture the request sent? Some program that records data stream packets sent and received to various IP addresses? That might not work either since there would be stuff going on between medexamtools.com and the payment gateway that the user might not see. Is this record saved somewhere in cpanel automatically that I can just go and look up?

[Medworks]

I have solved it. The 7 .php files beginning with "checkout" in the oscommerce root directory: checkout_XXXX.php, for XXXX ε {confirmation, payment, payment_address, process, shipping, shipping_address, success} were of a version that was not compatible with the 2 credit card module files includes\modules\payment\authorizenet_cc_aim.php and includes\languages\english\modules\payment\authorizenet_cc_aim.php. Modifying the 2 credit card php files could not accomplish the task because the problem was with the 7 checkout php files that interface with them and nothing could be done to the 2 credit card php files to fix the credit card processing functionality because there was nothing wrong with those 2 files to fix. In September the 7 checkout files along with everything else in the root oscommerce directory were replaced, but the replaced version for some of the files, the 7 php checkout files among them, were, based on the comments within the files, from 2003, while the version from June was from 2006. Apparently the full official oscommerce file set I procured in September was in fact less up to date than what I had already.