cancel
Showing results for 
Search instead for 
Did you mean: 

AIM 403 Error using transact after Authorize updated SSL Certificate

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?

ppatel
Member
15 REPLIES 15

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

 

inxcapable
Member

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

@inxcapable We have the Gateway ID and ticket number now, and I'll bring this up to our developers. Thanks.

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

Was there any resolution to this? I thought capitalizing the POST would have resolved it but it did not.

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

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

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.

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