Jump to content

Authorize.net pending to processing Need help with Relay Response URL


bkessler91

Recommended Posts

The problem was, when re-directed to Authorize.net's secure site for processing, the customer had to click "Confirm order and Return to Site".  Then the inventory would be adjusted.  What I did was log onto Authorize.net and make a header above the button to make clear that the button should be clicked.

 

From what I understand you can set up a Relay Response URL.  So after the customer enters credit card info, they automatically get re-directed back to your site, avoiding clicking that button. But I have yet to figure the Relay Response URL out.  Maybe someone can help with this?

Link to comment
Share on other sites

Hello bkessler91,

 

I assume you are using the SIM mode of the Authorize.net gateway?

 

(In CC520b1) The CubeCart programmers appear to be trying to figure out how to get the Relay Response URL working. In the code for that module, they have commented out that data.

 

There is data sent to Authorize.net that specifies what to say and where to return to should the customer want a receipt from the store (Receipt Link). They are using that as the default return method to actually process the order.

 

I do have a test account with Authorize.net (haven't used it in a while - I should see if it still active), but if you want to try to edit the code in the module to use the Relay Response, you can find it here:

modulesgatewayAuthorizegateway.class.php, around line 80:

                'x_receipt_link_text'    => 'Return to Store & Confirm Order',

                'x_receipt_link_url'    => $GLOBALS['storeURL'].'/index.php?_g=remote&type=gateway&cmd=process&module=Authorize'


                /* Ideal setup doesn't work 

                'x_receipt_link_url'    => $GLOBALS['storeURL'].'?_a=vieworder&cart_order_id='.$this->_basket['cart_order_id'],

                'x_relay_response'        => 'TRUE',

                'x_relay_url'            => $GLOBALS['storeURL'].'/index.php?_g=rm&type=gateway&cmd=call&module=Authorize'

                */
Replace all of the above with:
                'x_receipt_link_text'    => 'Return to Store & Confirm Order',

                'x_receipt_link_url'    => $GLOBALS['storeURL'].'/index.php?_g=remote&type=gateway&cmd=process&module=Authorize',


                /* Ideal setup doesn't work 

                'x_receipt_link_url'    => $GLOBALS['storeURL'].'?_a=vieworder&cart_order_id='.$this->_basket['cart_order_id'], */

                'x_relay_response'        => 'TRUE',

                'x_relay_url'            => $GLOBALS['storeURL'].'/index.php?_g=rm&type=gateway&cmd=process&module=Authorize',

 

But if the CubeCart programmers are not happy with this, I stress to you to not have high expectations that this experiment will work.

Link to comment
Share on other sites

  • 1 year later...

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.

Link to comment
Share on other sites

"The page the user gets is a version of the store with no css and the url is still on authorize.net."

 

Weird.

 

I have had some success with the PayPal gateway module. To apply that to Authorize (CC529):

'x_receipt_link_url' => $GLOBALS['storeURL'].'/index.php?_g=remote&type=gateway&cmd=process&module=Authorize'

I replaced the & sequence with just &. PayPal (and one other) used the URL verbatim to send the customer back to the store. (Not fetch a copy to show from their site.)

 

If Authorize is wanting to fetch a copy of the site to show the customer, that's a departure from what I've know them to do.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

"The return receipt is actually shown WITHIN their receipt page, and does NOT send the browser back to the actual site, which probably explains why the css gets trashed."

 

I was reading a gateway's API (Virtual Merchant, I think) that said this was how it worked for them. Thus, any images and CSS would need to be preloaded at the merchant's account file storage(?) so that the pulled HTML would have the resources there so that they can be served under the same SSL connection.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

A few moments ago, I downloaded the Authorize.net AIM and SIM Developer's Guides (PDF). The SIM manual mentions a process by which you open a support ticket, attach images to the ticket, and then these images are available for your purposes.

 

"The store HTML uses relative links."

 

Some places, yes, Some places are absolute. (I am referring to the stock skins. I have little knowledge about third-party skins.) I have mentioned to others that the <base href="xxx"> tag in the <head> section will tell the browser how to handle relative links. And if that won't work, CubeCart has the {$STORE_URL} template variable available.

Link to comment
Share on other sites

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 &amp; (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.

Link to comment
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...