KirkM
-
Posts
187 -
Joined
-
Last visited
-
Days Won
5
Posts posted by KirkM
-
-
I have exactly the same issue with a store in California. Tax rate is 8.25% and all is fine if no coupon is used.
As soon as a coupon is used, the tax is wrong.
Does anyone have an explanation for this?
CC 5.2.14
-
Here's a workaround I came up with for Authorize.net:
In the gateway admin on Authorize.net, put the url used in x_receipt_link_url in the Silent Response URL area of the settings.
This silently sends a duplicate of the correct url and query string to the store to change the order to processing as the receipt page on Authorize.net is displayed.
That way, even if your customer bails out before clicking through the receipt button back to the store, the order gets changed to processing. If they DO click back, they get that nice little message and it doesn't adversely affect the order.
You need to replace the $GLOBALS['storeURL'] with the absolute link to the site domain and use the straight & and not & (although it might still work that way).
https://yourdomain.com/mystore/index.php?_g=remote&type=gateway&cmd=process&module=Authorize
Even though I am now using SIM, I still have my client's sites SSL secured (many years of AIM with older CC store versions), so I use https.
This brings up another shortcoming in the Cubecart Authorize.net module:
The $GLOBALS['storeURL'] is the NON-secure domain name and that is what is sent in the x_receipt_link_url. If you are like me and have a secured site forced on all pages, then your customer will get a warning about the information being sent back unencrypted when they click the button on the receipt. I'm sure this freaks out a lot of people so they bail out on the link back to the site.
I have hard-coded the secure version of the site in the x_receipt_link_url in the CC module to stop this, but it would be very nice to have that global smart enough to know if you are running the site in full secure mode. Or even a place in the Authorize module that allows you to select secure or non-secure versions of the domain for the API's commands.
-
There is no merchant account "file storage" that I know of. You can (and I do) format the SIM payment form using absolute links to images and any other resources you want to use. However, this is not the same as loading the store page within the receipt as the store HTML uses relative links. Therefore, images and css are broken by being on another sever without absolute links.
There isn't a way I can see to circumvent this other than what Al has done to use the receipt link.
So far, I can't figure out a way to emulate the AIM response when using SIM either. I just hate the inelegance of trying to get the customer to click a link on the Authorize.net receipt page. Clunky, clunky, clunky...
-
Here is how they explain that the return receipt is actually shown WITHIN their receipt page, and does NOT send the browser back to the actual site. This probably explains why the css gets trashed showing the page.
Relay Response does not redirect the end user back to your server, but relays your specified Relay URL to the end user through our receipt page instead of displaying our default receipt page. If you would like to redirect the end user back to your server, please provide a link on your Relay URL for this purpose.x_receipt_link_url DOES send you back to the store site, but has to be a separate action on a link by the user -- NOT VERY ELEGANT -- and most bail on the receipt page on the gateway and the link never gets clicked so your store has what should be a "Processing" transaction is listed as a "Pending" transaction.
From Authorize.net Developer's center regarding x_relay_url:
x_relay_url
Value: The URL on the merchant’s website to which the payment gateway posts transaction results for a relay responseFormat: Any valid URL. Including name/value pairs in the URL(anything after a “?â€) is not recommended
Notes: If you submit this field, the payment gateway validates the URL value against the Relay Response URL configured in the Merchant Interface. If the URL submitted does not match the URL configured in the Merchant Interface, the transaction is rejected. If no value is submitted in the HTML Form POST, the payment gateway posts transaction results to the URL configured in the Merchant Interface.
It should be pointed out that the notes section is a bit misleading. If you do NOT put a URL in the area of the Merchant Interface, the transaction is NOT rejected. This security feature is only activated by a valid URL in the Merchant Interface, but is not required to process transactions with the x_relay_url.
-
I have been trying to get this to work as well.
First off, bsmither's code will not work as Authorize.net specifies that you can NOT use both x_receipt and x_relay_response at the same time.
In my experiments with the x_relay_response variables, I can get it to come back to the store and change order status to PROCESSING.
However, it is not acceptable because the page the user gets is UUUUUGGGLY! It gives you this blown apart version of the store with no css and the url is still on authorize.net.
Still working on it. My store clients all use authorize.net and HATE the fact that many, if not most, of their customers just bail out after submitting payment and never click back to the store. So valid "Processing" results are still listed as "Pending". It pretty much invalidates the whole status feature.
I really wish we could get this fixed.
-
I think you are correct as we are running CentOS 6.5 and php 5.4.
I do run logwatch and didn't get any NTP notifications, but I did have that "2 hours in the future" time bounce issue that seems to be resolved with a reconfigure all command on psa and having the server sync to pool.ntp.org.
-
It appears I have solved the issue. The server's clock was jumping time for some strange reason after the yum update. I did check it and reset it a couple of times and it would go hours off for unknown reasons just hours later.
I did a server re-configure and reset the system and hardware clocks and it solved the issue.
Now we wait and see if the system time stays stable. I have it sync'd to an ntp (pool.ntp.org) so that with the re-configure should do it (I hope).
The moral of the story is that some browsers will not validate the login if the server system clock is not accurate. I assume it is because the cookie shows as expired as soon as it is written so it jumps you right back to the login page.
Funny that Firefox and Chrome don't seem to care.
-
Has anyone else been able to duplicate this issue?
Are the CC devs sure that the store isn't dependent upon the Heartbeat handshake for authentication in some browsers?
Now that it is removed as part of the OpenSSL patch, that is about the only thing that has changed assuming the minor update of php from the Atomic Repo didn't do something. I am highly doubtful of that.
-
please disable CubeCart's use of SSL mode in the admin Store Settings screen.
Didn't help
Look in admin, Server Logs, Access logs, etc to see if the failed login attempts are recorded.No, only the successful logins from Chrome and Firefox. It does not register any login failures from the affected browsers.
Look in the CubeCart_blocker table. Remove all records this table may contain.That table was completely empty.
Another interesting discovery -
I went in to the SSL tab in the store admin using Firefox and added the domain in the cookie field as per the example (using the real domain) and then logged out of that browser. Not only did it have no effect on IE, it caused Firefox to start behaving the same way.
I had to go into Chrome and dump that setting and then dumped all the cookies in Firefox to be able to log in with that browser again.
Still no joy on IE, Safari and Opera.
-
Here's an interesting tidbit I just noticed -
If you put in the CORRECT user and password, it does virtually nothing. No error message, just loops back to the login page with empty input fields.
If you put in an INCORRECT user or password, it submits and gives you the correct error message back on the login page.
It appears that in these particular browsers, CC is authenticating the login and immediately logging out or somehow killing the session, so it defaults back to the login page.
And again, ONLY in these 3 browsers.
-
Don't think so. All other logins work on all browsers. WordPress, Webassist, my own authentication system, everything on my server except CubeCart works fine on all browsers and all platforms. Plus, this issue is only on IE, Safari and Opera - win & mac and only on CubeCart.
Even if it were a server setting, wouldn't it affect all browsers and not just these three?
-
Just FYI -
This was happening in 5.2.7 this morning BEFORE I upgraded to 5.2.9 to see if that would help.
5.2.7 was working fine in all browsers until I patched OpenSSL late yesterday and updated php to the latest Atomic version.
Don't know if it could be the OpenSSL fix or a problem with the new php version.
CC doesn't like something that changed between the two.
-
There is no activity. But, as I said, this is the case with IE, Safari and Opera (win & mac).
No problems with Firefox and Chrome on both win & mac.
This is the case on ALL systems from various ISP's in different locations.
All of my CC store clients report this in different parts of the country.
Something isn't playing nice with these browser engines in the CC login.
-
After updating my server to the latest OpenSSL to patch the Heartbleed vulnerability (and yum update everything else), all works fine EXCEPT the CC admin login doesn't work on IE, Opera (win and mac) and Safari. Works fine in Chrome and Firefox.
I updated to 5.2.9 and that didn't help. (php 5.4.27)
The affected browsers don't throw any error, they just clear the input text fields when the login button is pushed and nothing happens.
This just started today and I did the server updates yesterday so I am wondering what correlation there may be here.
No other login interfaces that I have for clients have been affected, only CubeCart's admin login and only in IE, Opera and Safari. My own admin program logins work and so does WordPress.
Any ideas about what this may be or if it is related to the OpenSSL patch? I do have the site secured with a valid certificate.
Thanks
-
That did the trick. Thanks very much for the quick confirmation.
Don't forget to add it to 5.2.5!
-
One of my clients on CC5 (upgraded from CC4) is getting AUTH_CAPTURE's on all transactions even though the store is set for AUTH_ONLY. It is using SIM method. I base64 decoded the setting in the database table and the setting is saving correctly. I then contacted Authorize.net to verify that SIM supported AUTH_ONLY, which it does.
I then went and looked at the code in the gateway module class for Authorize.net and don't see the x_type being set in the SIM block. It IS assigned in the AIM code block. Is this an accidental omission or am I missing where it is assigned?
I am wondering if I can just add the assignment to the $hidden array there and have it work.
Anybody else have this issue?
Thanks
-
I had a pretty good understanding of the files in CC4, but I am really not very familiar with CC5 since it is a total rewrite.
You might want to re-upload the smarty folder at /includes/lib/smarty and then check the permissions of the files. Also do the /classes/cubecart.class.php. I am just guessing on these since I haven't had time or opportunity to learn the new CC5 code structure.
On Linux, folders for these should be 755 and files should be 644.
Don't know if this will help. You can also just re-upload all the files in small batches so there are no timeout errors and see if that helps.
I am assuming this is a fresh install and not an upgrade from an earlier version of CC. Upgrades do work (I have done 2 from CC4), but the chances of something getting broken are certainly there, depending upon your mods and configuration in the CC4 version.
Hope you get this sorted.
Kirk
-
@salvador21 -
I believe the native coupon system in CC5 does work, aside from the lack of certain features. You may want to check your installation, it sounds like you might have a corrupt file or some file permission / other issue that is preventing the coupon system from working correctly.
Many times stalls in the long ftp upload can mess up a file or two. I have had it happen over the years a few times. Most of the time, re-uploading in small batches works to clear it up.
I have also had mysterious permissions errors on files that were ftp'd to my server. I have had permissions incorrectly set at 0, which doesn't allow the file to be accessed at all and will cause problems with the functionality that particular file provides.
Just some suggestions, FWIW.
-
I have had a few communications with Daren at Semper Fi Web Services about adding this feature to his existing CC5 coupon enhancements plugin. He seems very interested in doing it and I am hoping he will want to follow through and produce this upgrade. I think the more demand he feels there is, the more motivated he will be to do it, so if you or your clients would buy it, let him know.
-
@SimChris - I have multiple clients in exactly that position. All are waiting to upgrade to V5 but this coupon deficiency is the only hangup left now that Devellion bought Estelle's shipping plugin. The lack of adequate shipping functionality on CC5 was a deal breaker until that happened - I lost two clients to Shopify because of it and failed to land two other potential clients because of the lack of some really basic functionality in CC5, ESPECIALLY the shipping and coupons. Now that we have the shipping issue resolved, the only real stumbling block is the coupons. CC5 is definitely a great improvement, but some basics are still missing.
I'm surprised no dev has stepped into this void. The coupon system in CC5 is just plain awful, as it was in CC4, only now we don't have Estelle to fill the void. Devellion may not understand that a robust coupon feature deserves serious attention since it is a major and common way to drive sales. Therefore, it is an extremely important component for the end user to have in their store.
I have a query in to SemperFi about modifying his coupon enhancements plugin to add this feature. I figure if he already has a plugin for coupons written, it may be less of a task and shorter time frame for him to add a feature than for someone to create a plugin from scratch. I think he will sell quite a few more licenses if he has this feature.
It might not hurt if anyone who needs this feature shot him an email and let him know there is a market out there for it.
I'm keeping my fingers crossed...
-
And I fixed it. I just changed skins to one of the included ones and then back again to my custom skin and it all came back. Not sure what the hangup is, but it has to do with the skin. If you have this problem, just try changing the skin to a different one and see if it works. If so, change it back to the one you use and it should work also.
-
I always use the manual update and went from 5.1.5 to 5.2.2 and have this exact issue. The update seems to have gone fine and the store says it is 5.2.2 but nothing shows up on the category pages. The products are all there and assigned to the proper categories but they don't show up when you click the category menu links. I have cleared the caches, repaired the tables and even tried to do the upgrade again with no luck.
I cross-checked the database tables and the categories, category index and inventory tables all are intact and tracking correctly. And this is reflected in the store admin in the category and product sections.
This appears to be some sort of issue with the current version upgrade scripts. Is there a bad file that carries a critical function for this? Any info on where to go to check this? This is kind of urgent since the store is a client's production store.
-
Solved by CC support. It was on my end. With all versions through CC4, I had the orders.class.php script put a prefix in front of the order number for some clients who had multiple stores but used the same Authorize.net account. This enabled them to differentiate between the stores when pulling and auditing accounting information from Authorize.net. This always worked just fine. That was the only tweak I made on this store.
It turns out that in CC5, the security is much tighter and the order number has to strictly conform to the native formatting. Adding the prefix broke all kinds of things, including the admin and customer emails, plus the print order form gateway. My bad.
Al Brookbanks was very quick to spot it and educate me on this requirement. He was also very helpful in offering a modification suggestion to achieve what I need without breaking the store.
Very impressive customer service, I must say. So far, the CC5 store is tesing out perfectly now. If I could just get Estelle to push out her shipping mod for CC5, I would be very, very happy.
Thanks again for the help here on the forum. Sorry for the runaround!
-
Did you see bug report 0000173?
That issue appears to be about printing order details by the customer and was resolved in 5.1.0, which is the version I have clean-installed. My problem is with the Print_Order_Form gateway fatally erroring.
Just a huge guess...
In the file modulesgatewayPrint_Order_Formgateway.class.php (for CC510), there are statements that have this gateway calculate (recalculate?) and show taxes. The premise that follows may be the cause of the problem:
Premise: The Tax class may not have been instantiated when this file is executed.
If so, then statements that include $GLOBALS['tax']-> will throw a fatal error (method called on a non-object).
Some statements have this form, other statements have the form Tax::getInstance()->, which allows for using the class without formally instantiating it.
To try: change all instances of $GLOBALS['tax']-> to Tax::getInstance()->
The lines to edit are: 77, 78, 90, and 103 (but look for yourself for others I may have missed).
This is only a guess based on the above premise.
Thanks for that very through answer. It is a very interesting and insightful hypothesis. If true, that would appear to be a bug in 5.1.0. I am wondering i anyone else is experiencing this or not. If a bug, there should be many, if not everyone. If not, it must be something wrong with my settings or installation. I think I will use some support credits to get CC devs to see for themselves and fix the issue. This way, they will see first hand if it is a bug to fix or just some error on my end.
Thanks for the replies!
Tax is incorect
in Technical Help
Posted
I have discovered something interesting - with the coupon, the tax rate goes consistently to exactly 4%.
There is no tax class / rule in this store with anything set at 4%. There is only the standard tax of 8.25% and a class that is tax exempt (which is assigned to no products).
It doesn't solve anything but maybe it is a clue?
UPDATE:
I have done a bunch of things to see if I can follow this to the issue.
I am not sure, but it appears there is a logic error in the get() function in the classes/cart.class.php file.
I have been studying it but am not familiar enough with the way this is structured to see it easily.
I also have two large programming projects going right now and don't have the time to devote to solving the code problem in this store software. Some help from CubeCart Ltd would be greatly appreciated. I have 3 client stores operating in CA and they are none too happy about this.
I would like to file a bug report but can't seem to find the CC bug tracker. Anyone know where that is located?
It doesn't even pop up in a Google search, just a few links to forum posts about it being missing.