We have an older shopping cart that's been working for years on IIS 6 and classic ASP. Yesterday, credit card transactions failed. The only error I get is a server status 403. Called support twice and they said their SSL had been updated and I needed to enable compression on my server. I did that. Same issue.
I've run a URL test order through on the server to https://secure.authorize.net/gateway/transact.dll and it works. Our conclusion at this point is that the header is incorrect. We are using a ServerXMLHTTP header. I've tried several additions with no success. My latest attempt is below:
Set objhttp = Server.CreateObject("Msxml2.ServerXMLHTTP")
objhttp.open "post", "https://secure.authorize.net/gateway/transact.dll", false
objhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
objhttp.setRequestHeader "Accept-Encoding", "gzip, deflate, sdch"
objhttp.setRequestHeader "Content-Length", len(strrequest)
objhttp.send strrequest
Original code:
Set objhttp = Server.CreateObject("Msxml2.ServerXMLHTTP")
objhttp.open "post", "https://secure.authorize.net/gateway/transact.dll", false
objhttp.send strrequest
The only thing I get back is a 403. No response text. Any suggestions?
Solved! Go to Solution.
07-25-2014 06:42 AM - edited 07-25-2014 06:53 AM
We have been encountering the same issue - here's what we have discovered:
1) Any orders with an http POST of 1882 characters or less succeeds
2) Any orders with an http POST of 1883 characters or more returns the 403 error.
Has anyone identified a tech support person at Authorize.net that is helpful? I have an open support ticket, but we're not making much progress.
Mary
10-29-2014 11:25 AM
Hello @inxcapable
Are you able to duplicate this in the sandbox? If you can provide the support ticket number and Gateway ID, we can look into this further.
Richard
10-29-2014 11:44 AM - edited 10-29-2014 03:30 PM
@inxcapable We have the Gateway ID and ticket number now, and I'll bring this up to our developers. Thanks.
10-30-2014 09:00 AM
Was there any resolution to this? I thought capitalizing the POST would have resolved it but it did not.
12-02-2014 07:09 PM
@ppatel How long is your POST string?
As @inxcapable discovered, request strings over 1882 characters are causing HTTP 403s. Our developers will be looking into fixing this, but not until after the holiday season.
We find that the larger request strings are more common among merchants using the itemization features, and that in many cases it's possible to reduce the description of each line item to fit the request string into 1882 characters or less.
12-03-2014 02:44 PM
I apologize for not posting a follow-up sooner.
This situation recurred for another developer recently.
Upon investigation, we confirmed that, if you are using parameterized URLs, and thus submitting the info using HTTP GET rather than HTTP POST, you will run into HTTP 403 errors when exceeding 1800+ characters. (The exact character count depends on the size of your individual HTTP request headers, which in turn depend on the platform you're using.)
We strongly encourage any developers encountering similar issues, to switch to HTTP POST immediately. The legacy API guides had been previously updated to encourage using HTTP POST for submitting all transaction requests.
Note that this limitation only applies to using HTTP GET to submit transactions. The Authorize.Net API, documented at https://developer.authorize.net/api/reference/, only allows HTTP POST by default. Any future RESTful APIs we may release, will support HTTP GET for requesting service resources, but will require HTTP POST for submitting data in an API call.
Thanks.
05-16-2016 09:27 AM