Jump to content
CubeCart Bot

Authorize.Net - Accept Hosted

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

HI Kirk,

We have another merchant with the error message;

Quote

User authentication failed due to invalid authentication values.

Can you confirm that this integration is working for you and live payments are working on your store?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

There was a bug in live mode which is now fixed. We have a merchants successfully taking live payments now. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

The documentation is poor. I saw somewhere that an order object can be added with invoice number. I have a feeling that it was rejected but we will need to look into it again. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)

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.

Edited by KirkM
typo

Share this post


Link to post
Share on other sites

Yes I saw that then couldn't find the page. I'll try it tomorrow.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Thank you. I haven't been able to get around to looking at this. If you can share the code I'd be grateful. 

Auth.net won't return to the default return URL which has parameters in it. For this reason we have to work around it with a custom return URL. This is breaking the path detection in CubeCart for the URL. 

I'd suggest editing the email template to hard code the logo URL. 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Thanks for this. 

Please let me know if the order status is updating to Processing once the silent post url has been set. When I built the extension it worked well but we have a merchant which it isn't working for. I'm currently cloning their store to test.... 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Thanks for this. Confirmed working. 1.0.4 released.

15 hours ago, KirkM said:

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 can't find a way to do that and anything in the documentation that looks like it can do that seems to break the request to build the iframe URL. Frustrating.

Saying this. The silent post url should be triggered before the button is clicked anyway? Maybe I'm wrong. 

Share this post


Link to post
Share on other sites
Posted (edited)
8 hours ago, Al Brookbanks said:

The silent post url should be triggered before the button is clicked anyway? Maybe I'm wrong. 

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.

8 hours ago, Al Brookbanks said:

anything in the documentation that looks like it can do that seems to break the request to build the iframe URL

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.

Edited by KirkM

Share this post


Link to post
Share on other sites
Posted (edited)

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.

Edited by KirkM
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Al -

Just noticed that the First Name and Last Name  are inverted in versions 1.0.4 & 1.0.5 on lines 179 & 180 in gateway.class.php

Edited by KirkM
I'm stupid
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...