Integration and Testing

[dev-usa]

Authorize.net is sending emails telling merchants that they are using software that is generating $_GET requests to AN and that they should change to $_POST.  The merchants that I have been workiing with are using WooCommerce, which uses $_POST, at least in all of my applications.  Does anyone know of a "GET" option for WooCommerce?  Or, better yet, why is AN telling merchants that are using POST that they are using GET?

[Lilith Administrator · Accepted solution]

@dev-usa We're blocking GET requests to Transact -- in other words, to these domains:

• secure.authorize.net
• secure2.authorize.net
• cardpresent.authorize.net
• transact.authorize.net
• test.authorize.net

What we're really hoping to do here, is to encourage API details to be placed in the HTTP body, which is what POST does. Using GET means URLs with parameters can be cached, logged, or bookmarked, so there is a risk of sensitive details being retained by accident.

The Authorize.Net API -- that is, the XML/SOAP/JSON API -- must use POST since you can't easily turn structured data into a URL query string.

When we release our RESTful API, it will allow GET for requesting server resources, but not for submitting data.

And of course, GET works on our corporate site, and in the Merchant Interface, for its intended purpose of requesting HTML, graphics, and other server resources.

As for testing for uptime, I'd recommend using POST for that, and simply include x_login. You'd get RRC 103 since you aren't providing full API credentials, but that should be enough to distinguish a successful connection from one that terminates with HTTP 500, HTTP 503, or a connection timeout.

[Lilith Administrator]

@dev-usa If we're telling merchants they're using GET, it's because we can see the HTTP GET calls in our Transact logs.

If you send specific API Login IDs to https://developer.authorize.net/support/contact_us/ we can research this and confirm whether we're seeing GET, POST, or a combination thereof, for these merchants. We can also provide originating IP addresses, and if these are successful transaction requests, we can provide transaction IDs for auditing purposes.

Note that it's entirely possible -- although conjecture on my part -- that Woo Commerce might be using GET to test for server availability, rather for submitting transactions outright. But it's hard to say without having API Login IDs to research.

[dev-usa]

WooCommerce does use GET for some non-monetary transactions such as testing, as you suggest.  Are you saying that AN is going to block ALL GET access after 30 July?

[Lilith Administrator · Accepted solution]

@dev-usa We're blocking GET requests to Transact -- in other words, to these domains:

• secure.authorize.net
• secure2.authorize.net
• cardpresent.authorize.net
• transact.authorize.net
• test.authorize.net

What we're really hoping to do here, is to encourage API details to be placed in the HTTP body, which is what POST does. Using GET means URLs with parameters can be cached, logged, or bookmarked, so there is a risk of sensitive details being retained by accident.

The Authorize.Net API -- that is, the XML/SOAP/JSON API -- must use POST since you can't easily turn structured data into a URL query string.

When we release our RESTful API, it will allow GET for requesting server resources, but not for submitting data.

And of course, GET works on our corporate site, and in the Merchant Interface, for its intended purpose of requesting HTML, graphics, and other server resources.

As for testing for uptime, I'd recommend using POST for that, and simply include x_login. You'd get RRC 103 since you aren't providing full API credentials, but that should be enough to distinguish a successful connection from one that terminates with HTTP 500, HTTP 503, or a connection timeout.