DPM, WooCommerce, "Error: Transaction Approved."

[inthrees]

I know this has to do with the receipt/response urls, but I cannot for the life of me figure out what the issue is.

WordPress with WooCommerce installed. at www.domain.com

Checkout/card entry is www.domain.com/checkout/pay/

The thank you page is www.domain.com/checkout/order-received/

What do I need to enter, and where, to cause my site's thank you page to show up after a dpm payment? I've made several purchases of a test product so far and just can't seem to figure this out.

edit - I have already entered http: and https: urls to the 'thank you' page in the receipt/response section of the merchant control panel at auth.net, but that didn't do it.

x_relay_url - what is this, exactly? It doesn't match the thank you page url, but I added to receipt/response anyway, and it's still not working.

[inthrees]

(Can't edit the previous post again or I wouldn't double.)

After further investigation I am REALLY stumped.

md5 is turned off both in the auth.net control panel and on the site.

the contents of x_relay_url have been added to the list of receipt/response urls.

Trying to access ^ that url directly results in my site telling me I am not authorize.net. Which is good, so it *should* work, but apparently after a transaction authorize.net is not redirecting back to the response/receipt url?

Any ideas? I've googled extensively and every promising bit of information I've found has essentially boiled down to "make sure the correct url is on the response/receipt list". And it *is*.

[TJPride]

Between the checkout page and the final thank-you page, there should be a relay response page, that invisibly checks the order status and forwards you to the thank-you page if everything worked properly. View source on your checkout page and look for a hidden form field called x_relay_url, and if it's there, put that URL into your control panel's relay response URL setting.

EDIT: Didn't see your second post before I posted. What error codes or response are you getting when you submit a transaction?

[inthrees]

The transaction stops at the authorize.net dll with (I should note the transactions are going through, just that the customers are not getting the pretty order receipt page.)

"An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

      This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service."

This would suggest to me that it's not trying to redirect to the response url, which *has been added* to the list of approved receipt/response urls on the auth.net control panel.

Thanks for the response!

[TJPride]

Oh, well there are a variety of reasons why Authorize.net might not be able to access your relay response page:

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Relay-Response-Basics-a...

Just to give you a really obscure example, one person discovered his hosting firewall was blocking non-standard user-agents.

[inthrees]

Questions for you fine folks:

1. Transaction version is 3, and apparently there is a 3.1 now. Could this have an effect? I don't want to just change it, because the authorize.net account is used for more than one site and I don't want to break anything else.

2. If the contents of x_relay_url are correctly listed on the auth.net control panel under receipt/relay urls, but there are also OTHER urls there, would that matter somehow?

3. error logging wasn't enabled (by default, apparently, yay godaddy) but access logging was. I checked yesterday's access logs and during the times I made actual real test purchases, there were no access attempts from any other sites/visitors/anything after the checkout. Would an authorize.net relay show up under access? It would, right? (unless apache was rejecting it, then it would show up under errors?) I'll be able to look at the error log after midnight, since apparently you can't look at real-time logs with godaddy's shared hosting.

Everything I've seen from googling this suggests that it should work, unless it's a server / traffic error.

[inthrees · Accepted solution]

Pretty sure it's bad behavior blocking because of the user agent. Will know shortly, but setting this thread to resolved.