Jump to content

KirkM

Member
  • Posts

    188
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by KirkM

  1. 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.

  2. 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')).'\"}"
    				}]
    			  }
    			}
    		  }';

     

  3. 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.

  4. 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.

  5. 9 hours ago, Al Brookbanks said:

    The documentation is poor.

    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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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

  12. 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.

  13. 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.

  14. 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

  15. 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.

  16. 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...

  17. 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 response

    Format: 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.

  18. 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.

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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.

×
×
  • Create New...