Geotex

and, on the other hand, it is just my opinion that the overall system should never be "held hostage" to any plugin provided and submitted by outside sources. We need to be certain that whatever information submitted for gateway processing be at least validated as to correct format and completeness prior to submission. But, again, that is just me...

re: what causes the form to be re displayed? Any error returned from the cc processor. re: SIM then, does not count as it goes directly to authorize.net for entering and checking the credit card information. What we are dealing with here is forms that are in the cart environment prior to submission. Where ever they are generated from, and it appears they are part of each gateway module, looking at the authorize.net module and the generic credit card module I use for testing, I will look at a couple of other gateway payment methods, but I suspect I will find the same. And yes, the form is populated with order. price and basic customer info. However, everything except the total and order number is fully editable, and with virtually no skill, the price can also be fixed before submission, all with no verification whatsoever of any input before submitting the information to the payment processor. We need at least validation of proper formation of credit card numbers, and at least verification that name, address parts of the form that need data are populated. This will go a very long way to increasing user satisfaction with the purchasing process, which is historically difficult when compared to swiping your phone near a payment device when checking out in a retail environment. The submit block should also be deactivated until a return from the gateway since it appears the order total is reset to zero at least until the auth codes are returned and the page is refreshed. This is in addition to the work you started to alter the response displayed to a customer, which from feedback I got from one user is still an issue. Not having the full fraud detection suite active at authorize.net seems to have cleared up a lot of issues, but that is something we cannot depend on. Our merchants need all the protection that can get.

Running transactions on my test cart, which is a basic install, upgraded to latest version 6.1.12, shows there is no basic field verification of any data prior to submission from the form displayed at "index.php?_a=gateway." I feel really bad that I assumed this was taken care of only because nothing should ever be released for production without at least basic form validation. Depending on the plug-in module to do this verification is not an acceptable alternative. Basic PayPal is okay because you get an immediate redirect to PayPal with a transfer of only order number and amount, never taking you to the input screen at "index.php?_a=gateway" for any other payment module.

I have run into 2 additional issues with the use of authorize.net, and I know it is because either the cart or the authorize.net module is not verifying the data prior to sending. Another issue is that if a response is delayed for whatever reason, more than one submit is permitted prior to getting a response. I found the following 2 errors (both repeated, but only shown once here for example) "3|1|5|A valid amount is required.||P|0||Payment for order #|0.00|CC|auth_capture||" (same time stamp, right after an approval, signifying multiple clicks to submit) " 3|2|33|Credit card number is required.||" (just hit submit without checking or filling out any info on payment screen) Both of these errors are allowed because there is no verification of input prior to submitting the order for payment to authorize.net (and probably any other payment, although not tested yet, that will follow today on my test cart). In other words, when you get to the screen to verity your cc, address, etc. you can just click on the green submit payment button, and off it goes.

Thanks. I made a copy of the code. I have not heard back from my client. However, we both know the cause of the problem. I am working to get that resolved, but will go ahead and try the code out to see if that can resolve the repeated processing attempts.

Interesting follow up. My client has talked to both authorize.net and her processor technical departments, and they both claim no responsibility, pushing the entire issue back on the "programmer" and yet we both know the issue is in the set up either in the authorize.net or the processor control panel. I know for certain this issue is in one of those control panels as I have 2 other accounts using cube cart and authorize.net with absolutely no issues. However, IMO, we still need C C programmers to deal with the response of 4|1|256 in a more acceptable face to the customer using the cart to place an order.

I don't know right now just what the issue is, but best guess is you are correct about the fraud detect. However, having my own card hang is not an issue with my account. It may be due to actions my client has taken, or problems the client caused the processing company. My client talked to Authorize.net for some unknown reason and relayed that the issue was not theirs, but mine. So we are back at having the client talk to the horse's mouth. I will try to convey your comments to my client, but I suspect that will cause another 1/2 dozen or so emails telling me why I need to fix it. Thanks for all the time spent on this. I will update you with the outcome as soon as I can verify the changes.

The account is definitely set for authorize and capture, and, as far as I know, was working properly set that way until this upgrade. Just to be certain, I did set to authorize and back to authorize and capture, but did not process another test order. The customer probably has the account set to approve but not bill until she goes in and marks as shipped. I have explained carefully and sent log copies and asked they contact there credit card processor, so we will see.. However, CC should be able to handle the notice without throwing up a red flag, causing the user to attempt to reprocess the card, thereby placing several orders. Being able to change the color to yellow, with a notice that the card was authorized but will not be billed until the order is shipped would be nice.

Just updated a customer to CC 6.1.11 and have the latest authorize.net extension, 1.1.3 installed, and set to authorize and collect. In logs, return is: "4|1|252|Your order has been received. Thank you for your business!|etc." and the red banner is back, still showing an amount due on the order. We stopped this problem using the recommendations in the Sept. correspondence, but with the upgrades it is back. Any suggestions other than disabling the Authorize.net module until various programmers can get together and resolve this issue.

Thank you. Very solid advice. You have gone so much deeper into this program than I ever will. My business has gone so much general sites using owner-friendly frameworks over the past few years, causing my ecommerce development to take a back seat.

I have been busy on nonecommerce accounts for the past several months and not paying that much attention to CC. I should have known that. Thanks, bsmither that is exactly where the error is listed, it shows the transaction sent in, and the response. Code is 4|1|252|Your order has been received. Thank you for your business! And, looking at the settings in authorize.net, I see the owner has transactions set to "Authorize Only", which I would be willing to guess is the cause of the errors. Since there appears to be no reason to only authorize then do a rerun and capture, I am going to help her out and just change the setting, we will see what happens.

I am getting the same error on some cards processed. This has been a recurring but random error. Using Authorize.net v 1.1.2 openssl ciphers -v | awk '{print $2}' | sort | uniq which returns SSLv3 TLSv1.2 so I know the module and ciphers are current. Almost a certainty that fraud control is set to a high level with the card processor. I suspect the issue revolves around invalid customer input, like forgetting a middle initial or suffix in the name on the card. Does a detail error show in CC somewhere? Admin and System log both return blank. Also, php error logs show no entries for this issue.

Maybe the guy made it up and just copied the top part. Who knows. There are some other meanings, mainly made from the heads of animals, head cheese (brain) and nose, tongue, etc. Not a big deal, if I see any problems, I will do a restore on the full site and switch back to the default foundation skin for updates. Thanks for the input. We will just put this one down, as I have an issue to explore with authorize.net plug in randomly crashing when an approval comes back from the credit card processor. I can see the error in the error log, but cannot duplicate it as my tests are always returned either approved as supposed to be, or declined when testing with a dead card. I will post in the appropriate area if I can't resolve shortly, so no need to answer here. Thanks for the input, always nice to see you around the boards.

I am inheriting service on a cart for a customer whose husband passed not long ago. The skin installed is named Souse. here is the relevant part of the config.xml file <type>skin</type> <name><![CDATA[souse]]></name> <display><![CDATA[Souse]]></display> <version>1.0</version> <minVersion>6.0.0a</minVersion> <maxVersion>6.0.*</maxVersion> <creator>CubeCart Limited</creator> <homepage>http://www.cubecart.com</homepage> <mobile>false</mobile> <responsive>true</responsive> Any info would be appreciated, as I have no reference to any documentation, or even compatibility with the currently installed CC-6.1.8 and I hesitate to upgrade to 6.1.10 with an unknown skin installed and shown as only for 6.0.0a thru 6.0.x Searches in this forum, on the main site, and various search engines have turned no info that I can locate. Thanks for taking a look, and any input you may have.

The error here is in the interpretation of the logic. All countries that have "state" have the states listed and tied to their country code in table CubeCart_geo_zones. If the country does not have states, there is no listing. The current coding will provide a drop down if states exist, no drop down if states do not. exist. The issue comes with Submit, as the field states is required, and the ajax validation script does not recognize that the state is no longer required. The excellent patch you provided Muscator works and can be applied to table CubeCart_addressbook. That should clear Muscator's problem, and I am sure he can find the lines. I would suggest the issue is best resolved by also having "required" removed from the state input when the country code is not present in CubeCart_geo_zones. Currently, the only change is to not create the drop down state option, it does not remove the "required" statement that causes the error in skins/[your template]/js/vendor/jquery.validate.min.js. I have not had time to fully investigate, but that the only logical place to properly correct the issue is at the form level, and each form that requires a state/county input needs to be dealt with. This is a bug that, if not submitted already, should be as it is an extremely aggravating issue in the many, many countries that do not have states or similar regional districts and is a wide-reaching problem covering both registered and non-registered purchasers, as well as all addresses in the CubeCart_addressbook table and possibly a few others.