Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by KirkM

  1. Here is what I have from tonight's test: - Order DOES go to "processing" even if the customer bails out after hitting the "Pay" button and doesn't go back to the store by clicking the "Confirm" button on the Auth.net results window. This is great. - Created a copy of the "Default emails" template, called it "Hard-coded emails", replaced the header image and signature macros with hard-coded urls and made it the default. - Under the "Email Contents" tab, I modified Cart: Order Confirmed and Admin: Order Received, replacing the macro {$DATA.link} with a hybrid hard-code / macro combination of https://mystore.com/index.php?_a=vieworder&cart_order_id={$DATA.cart_order_id} (where mystore.com is the actual store domain and the order number is handled by the dynamic macro {$DATA.cart_order_id}). - Have NOT been able to solve the gigantic store title issue on the Auth.net transaction results page. Will have to keep looking or call their support and find out how to get this under control. It looks like all of the information is being sent correctly and the transaction was successful. (NOTE: I only tested auth only since my clients all capture funds when the item ships.). Generally, it works with a few workarounds and the need for a small formatting tweak. I much prefer the new embedded frame and the clean form look and operation to the old SIM. It works well enough for me to put it live in one of my client's stores. We will see how it goes over the next 24 hours of live use.
  2. Or maybe you are right. It happened when I first tested this extension but there were other things misfiring so that could have been it. I know the old SIM extension did that but we didn't employ the silent post URL with that. I will check v4 overnight (HST) and look at the status in admin before I click the CONFIRM button. Seems to be the standard M.O. with their API and documentation. Lots of blanks you have to fill in yourself. One other thing - Do you know if it is possible to format this? "settingName": "hostedPaymentOrderOptions", "settingValue": "{\"show\": true, \"merchantName\": \"'.addslashes($GLOBALS['config']->get('config', 'store_name')).'\"}" The store name is HUGE. I have searched around the Auth.net docs and I don't see it. If the store name is a moderately long word, it word-breaks and wraps. It looks pretty terrible.
  3. Yes, it went to processing and returned to the store correctly and displayed the receipt / summary CC page when the "confirm" button was clicked. Perhaps the customers aren't clicking the "confirm" button to complete the return to the store? I would love to get this extension to return without that extra step by the customer to return to the store. If they bail out without clicking the "confirm" button after the transaction is submitted, the order stays pending even though the transaction was completed on the authorize.net side. I wish I could get some quality time to work with this. I will try to get back to it as soon as I can. I am just hammered right now.
  4. Ahh, I was wondering about having to do a Silent Post URL in the Authorize.net admin. I am quite busy but really want to get this straightened out so I will try to get back to testing soon to try to figure this return issue out. Here is the request json code block that successfully processed the transaction with invoice number and description (this code insert feature blows out the formatting for some reason): $request_json = '{ "getHostedPaymentPageRequest": { "merchantAuthentication": { "name": "'.$this->_module['merchant_login_id'].'", "transactionKey": "'.$this->_module['merchant_transaction_key'].'" }, "refId": "'.bin2hex(openssl_random_pseudo_bytes(8)).'", "transactionRequest": { "transactionType": "'.$this->_module['payment_type'].'", "amount": "'.$GLOBALS['cart']->basket['total'].'", "profile": { "customerProfileId": "'.$customer_id.'" }, "order":{ "invoiceNumber": "'.$GLOBALS['cart']->basket['cart_order_id'].'", "description": "STORE NAME order # '.$GLOBALS['cart']->basket['cart_order_id'].'" }, "customer": { "email": "'.$GLOBALS['cart']->basket['billing_address']['email'].'" }, "billTo": { "firstName": "'.addslashes($GLOBALS['cart']->basket['billing_address']['last_name']).'", "lastName": "'.addslashes($GLOBALS['cart']->basket['billing_address']['first_name']).'", "company": "'.addslashes($GLOBALS['cart']->basket['billing_address']['company_name']).'", "address": "'.addslashes($GLOBALS['cart']->basket['billing_address']['line1'].' '.$GLOBALS['cart']->basket['billing_address']['line2']).'", "city": "'.addslashes($GLOBALS['cart']->basket['billing_address']['town']).'", "state": "'.addslashes($GLOBALS['cart']->basket['billing_address']['state']).'", "zip": "'.addslashes($GLOBALS['cart']->basket['billing_address']['postcode']).'", "country": "'.addslashes($GLOBALS['cart']->basket['billing_address']['country_iso']).'" }, "userFields": { "userField": [{ "name": "cart_order_id", "value": "'.$GLOBALS['cart']->basket['cart_order_id'].'" }] } }, "hostedPaymentSettings": { "setting": [{ "settingName": "hostedPaymentReturnOptions", "settingValue": "{\"showReceipt\": false, \"url\": \"'.$process_url.'\", \"urlText\": \"Confirm\", \"cancelUrl\": \"'.$cancel_url.'\", \"cancelUrlText\": \"Cancel\"}" }, { "settingName": "hostedPaymentButtonOptions", "settingValue": "{\"text\": \"Pay\"}" }, { "settingName": "hostedPaymentStyleOptions", "settingValue": "{\"bgColor\": \"blue\"}" }, { "settingName": "hostedPaymentPaymentOptions", "settingValue": "{\"cardCodeRequired\": false, \"showCreditCard\": true, \"showBankAccount\": '.$showBankAccount.'}" }, { "settingName": "hostedPaymentSecurityOptions", "settingValue": "{\"captcha\": false}" }, { "settingName": "hostedPaymentShippingAddressOptions", "settingValue": "{\"show\": false, \"required\": false}" }, { "settingName": "hostedPaymentBillingAddressOptions", "settingValue": "{\"show\": true, \"required\": false}" }, { "settingName": "hostedPaymentCustomerOptions", "settingValue": "{\"showEmail\": false, \"requiredEmail\": false, \"addPaymentProfile\": true}" }, { "settingName": "hostedPaymentOrderOptions", "settingValue": "{\"show\": true, \"merchantName\": \"'.addslashes($GLOBALS['config']->get('config', 'store_name')).'\"}" }] } } }';
  5. I got the order->invoiceNumber and description to work. All children of the transactionRequest that you decide to use MUST be in the exact order listed in the documentation or you will get a namespace error. For the "order" child and its children, it had to be after "profile" and before "customer". I tested and it worked fine. Now there are two outstanding issues I am having. Both the order confirmation and payment confirmation emails to the customer have the logo url and store url going to the authorize_accept_hosted directory instead of each of the appropriate urls. Other emails from the store work fine. Not sure where to go to look for this problem but those emails are a disaster.
  6. https://developer.authorize.net/api/reference/index.html click down the "REQUEST FIELD DESCRIPTION" accordion link under the code examples.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. Al Brookbanks has verified the bug and is working on a fix at this time.
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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...
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  • Create New...