-
Posts
201 -
Joined
-
Last visited
-
Days Won
5
Everything posted by KirkM
-
https://developer.authorize.net/api/reference/index.html click down the "REQUEST FIELD DESCRIPTION" accordion link under the code examples.
-
According to the API documentation, I think the issue might be here - Instead of this block (or in addition to it if CC needs this echoed back): "userFields": { "userField": [{ "name": "cart_order_id", "value": "'.$GLOBALS['cart']->basket['cart_order_id'].'" }] } It looks like it needs: "order":{ "invoiceNumber": "'.$GLOBALS['cart']->basket['cart_order_id'].'" }, Actually, I have had clients that use multiple stores with a single Authorize.net account so I have always modified the old extension with the x_description along with the x_invoice_num so I would put in something like this in the new API: "order":{ "invoiceNumber": "'.$GLOBALS['cart']->basket['cart_order_id'].'", "description": "STORE NAME order # '.$GLOBALS['cart']->basket['cart_order_id'].'" }, Where STORE NAME is whatever the client wanted to use for a unique store identifier. Let me know if the "userFields" is needed for CC response or not and I will modify and test the code with these modifications.
-
You can say that again! I have gone over it a couple of times in the last 6 months so that I could understand the new API and it was typically poor documentation from them. Clear, thorough explanation has never been their strong point. I will go back to it again and see if I can fish something out of that mud. I think that is the only little issue with the extension. Other than the invoice number, it looked like everything processed correctly and the silent post url worked too. The only other thing is I need to find out where the formatting is for the approved message. The store name at the top is HUGE. But that is just formatting. The mechanics of the CC API client seem solid. Thanks very much Al.
-
I can verify that version 1.0.1 did have the live payments issue and 1.0.2 processes successfully. However, there is still a problem as the invoice number is not being passed to Authorize.net in 1.0.2. It was x_invoice_num in the old SIM extension but I am not familiar enough with the new API to see at first glance why it isn't being sent in the json string.
-
I can not confirm at this time as I have so many projects going right now, I simply haven't had time to go back to continue testing the new accept hosted extension. I do know that I have NEVER been able to use test mode with Authorize.net to an actual account without failure. I would first confirm whether this error is occurring in test mode or live mode. I'm not sure, but it may be that test mode only works with their testing sandbox. Or, it could be that I just don't know what I am talking about. The only way I have ever been able to test any authorize.net gateway extension is by logging in as admin in the middle of the night, closing the store and then going out to the storefront and making a purchase (store set to authorize but don't capture). This way, I get a real customer experience and know exactly what is going to happen with actual customers. If there are no issues, then great. If there are, I hopefully can find the problem, fix it and then confirm with another test purchase. Then I just delete the purchases in CC and void the transactions in the Authorize.net gateway (I require that my customers give me full admin rights in their Authorize.net accounts) and re-open the store. I realize testing in the production environment is really not the best way to go about this but I have had so much trouble with the authorize.net testing environment that I just gave up and do this hack to test. I will try to carve out some time to do a midnight test and upgrade of one of my client's stores. I can report back the results.
-
Found it on line 192 of gateway.class.php: "settingValue": "{\"showReceipt\": false, \"url\": \"'.$process_url.'\", \"urlText\": \"Confirm\", \"cancelUrl\": \"'.$cancel_url.'l\", \"cancelUrlText\": \"Cancel\"}" Looks like an "l" got inadvertently typed in front of the backslash. Needs to be corrected on the download package.
-
Just trying this out and got this when testing the order cancel button: Not Found The requested URL /modules/gateway/authorize_accept_hosted/cancel.phpl was not found on this server. My first thought was there was a typo in the gateway.class.php file putting a stray character on the end of the php file name. But I don't see any problems with it when I look at the file. I also did a search over the entire store for "cancel.phpl" and there isn't anything. So, it must be getting generated somewhere by a piece of typo'd code but I haven't been able to find it.
-
From my math (actually, my iPhone calculator's math), it looks right when I do some random shopping. Thanks very much, I am off to put this into the other two stores. I assume this will be included in the next dot release so I won't have to tag it in my customization notes for my stores.
-
It is close, but still not completely accurate. It isn't cutting the tax in half anymore, but it is rounding it. The 8.25% rate is being calculated at 8% in the store when you use a coupon. Without a coupon, it is still correct. If you can kill the rounding of the tax percentage, I think you will have it. Thanks
-
Al Brookbanks has verified the bug and is working on a fix at this time.
-
Thanks for the info. I did file a support ticket and Al is going to take a look. The change in 5.2.13 must be it. I upgraded from 5.2.12 to 5.2.14 for all 3 stores and they started complaining this week when they noticed customers using coupons weren't being taxed enough.
-
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.
-
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
-
Authorize.net pending to processing Need help with Relay Response URL
KirkM replied to bkessler91's topic in Technical Help
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. -
Authorize.net pending to processing Need help with Relay Response URL
KirkM replied to bkessler91's topic in Technical Help
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... -
Authorize.net pending to processing Need help with Relay Response URL
KirkM replied to bkessler91's topic in Technical Help
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. 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: 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. -
Authorize.net pending to processing Need help with Relay Response URL
KirkM replied to bkessler91's topic in Technical Help
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.
-
Didn't help No, only the successful logins from Chrome and Firefox. It does not register any login failures from the affected browsers. 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.