cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Authorize.net Payment Not Going Through - Woocommerce 2.4.10

Prior to launching https://gsgelato.com, the site was in development - during development a payment was tested and the order was successful. Since launching the site by pointing nameservers, the payments have stopped going through to Authorize.net. I have reset transaction keys and placed multiple test orders. I've contacted Auth.net to see if there's an error on there end and they do not see one and believe the payment should be successful. I have a relay response set (the payment still does not go through when this page is set to a thank you page). What other solutions are available to make sure these payments go through to Auth.net.

 

The Woocommerce plugin I am using is Authorize.Net DPM.

revivemedia
Contributor
18 REPLIES 18

@Lilith

 

The site was not in sandbox mode for Auth.net items. The customer placed a live order previously, there fore test.authorize.net was never used. The relay response page is going to secure.authorize.net.

Thanks for clarifying that you're in our Production environment, and using secure.authorize.net.

From your web server, can you run dig or nslookup on secure.authorize.net, and let us know what IP address you get, please?

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

@Lilith

 

[root@host ~]# dig secure.authorize.net.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> secure.authorize.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19391
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;secure.authorize.net. IN A

;; ANSWER SECTION:
secure.authorize.net. 1136 IN A 64.94.118.32

;; AUTHORITY SECTION:
authorize.net. 296 IN NS ns1.dnsvisa.com.
authorize.net. 296 IN NS ns3.dnsvisa.com.
authorize.net. 296 IN NS ns2.dnsvisa.com.

;; Query time: 0 msec
;; SERVER: 10.10.10.10#53(10.10.10.10)
;; WHEN: Tue Nov 24 15:26:07 2015
;; MSG SIZE rcvd: 119

@RaynorC1emen7

 

But the bottom of that thread says this from the developer of WooCommerce: 

The Authorize.net gateway doesn't use direct IPs so your gateway will continue to function after September 30th :)

 

@RaynorC1emen7 We have a blog post that addresses the IP address situation with much more detail, at https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-Authorize-Ne... For right now, secure.authorize.net remains on its old IP address, but we expect to migrate secure.authorize.net to Akamai's network front-end sometime in 2016. (We'll make another announcement to all merchants, resellers, and developers when that's approaching.)

I only asked about the IP address to confirm that the new nameservers @revivemedia mentioned, were resolving secure.authorize.net correctly.

@revivemedia, it doesn't make sense that a change of nameservers would cause connection issues, and the IP address is correct. But I believe I located the Production account in question, and I confirmed we haven't seen any new transactions on the account since November 23.

I also attempted a test order, and Woo Commerce indicated it was successful. (Or rather, it said "Thank you for your order!" without displaying any further details.) No transaction appeared on this end.

I think we need details from Woo Commerce about what happens to data sent to your Relay URL. (I believe that URL is set to https://gsgelato.com/checkout/order-placed/ here.)

As a thought--could you check your network logs to see if your server is seeing traffic from either of these IP addresses?

 

198.241.168.60 
198.241.162.104

 

Relay Response data should be returned from there.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

@Lilith

 

I've checked with Liquid Web to see if they see anything on their end about the IPs.

 

I see neither of those IP's are caught in the firewall. They also do not appear in the apache error log. The only entry in the access log for this domain is:

198.241.162.104 - - [25/Nov/2015:10:22:40 -0600] "POST /checkout/order-placed/ HTTP/1.1" 200 18988 "-" "-"

 

It looks like the IP address attempted to access both the secure version of your site, and the nonsecure version:

/home/domlogs/gsgelato.com:198.241.162.104 - - [25/Nov/2015:10:22:40 -0600] "POST /checkout/order-placed/ HTTP/1.1" 200 18988 "-" "-"
/home/domlogs/gsgelato.com-ssl_log:198.241.162.104 - - [25/Nov/2015:10:22:40 -0600] "POST /checkout/order-placed/ HTTP/1.1" 200 18988 "-" "-"

 

Prior to setting the relay response, which was a suggestion of a Auth.net support person on the phone, the test gave a plain text response saying the payment went through. Was this suggestion incorrect? Should I have something else on the relay response page or is a reciept page the way to go instead so payments are processed correctly? Basically, now I'm wondering if it is the change made on my auth.net account instead of on the website itself since that has been the only thing (other than nameservers) that changed.

@revivemedia Whether you need Relay Response depends on whether your site uses the SIM/DPM methods (rather than the AIM method, which doesn't use Relay Response). It might be worth contacting Woo Commerce to determine which method they implemented.

That said, it wouldn't hurt to remove the Relay URL from your account. It's entirely possible there is some error occurring that isn't being displayed by Woo Commerce. The error may even have something to do with the Relay URL itself.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

@Lilith It ended up being relay response. I removed the page URL, refreshed, tried my transaction again and I'm seeing it in unsettled transactions and got the payment reciept. Previously, removing the URL just caused a failed transaction.