Integration and Testing

[revivemedia]

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

[Lilith Administrator]

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?

[revivemedia]

@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]

https://community.developer.authorize.net/t5/Integration-and-Testing/Authorize-Retiring-IP-Email-to-...

look like that an old ip address

[revivemedia]

@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 :)

[revivemedia]

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

[Lilith Administrator]

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

[revivemedia]

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

[Lilith Administrator · Accepted solution]

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

[revivemedia]

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