Error Code 13 - Login ID Confirmed, Same integration works on Sandbox

[cevo]

Hi All,

We're consistantly getting error code 13 on the live server (sandbox works perfectly)

we've confirmed the live login ID, both online and through the support line.

The XML we're sending to the Live server is identical (aside from login id and trans action key)
to what we're sending to the sandbox but stil get error 13

Server:https://secure.authorize.net/gateway/transact.dll
XML (stars on confidential information)
 

<?xml version="1.0" encoding="utf-8"?>
<ARBCreateSubscriptionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
       <merchantAuthentication>
              <name>********</name>
              <transactionKey>****************</transactionKey>
       </merchantAuthentication>
       <refId>50</refId>
       <subscription>
              <name>Subscription</name>
              <paymentSchedule>
                     <interval>
                     <length>1</length>
                     <unit>months</unit>
                     </interval>
                     <startDate>2012-01-26</startDate>
                     <totalOccurrences>9999</totalOccurrences>

              </paymentSchedule>
              <amount>27</amount>

              <payment>
                     <creditCard>
                     <cardNumber>************</cardNumber>
                     <expirationDate>****</expirationDate>
                     </creditCard>
              </payment>
              <billTo>
                     <firstName>******</firstName>
                     <lastName>******</lastName>
              </billTo>
       </subscription>
</ARBCreateSubscriptionRequest>

Any help would be greatly appreciated

Thanks

James

[stymiee]

We don't need to see all of that XML because this is a login issue and none of that other data will affect it. If you're getting this error then:

1. The transaction key probably is not correct. Reset it in the control panel and immediately place it in the code of the website. Make sure it is replaced everywhere. Ideally you should only have to place it in your code once and it is automatically updated everywhere. If this isn't the case then this is likely the culprit.
2. The login ID and transaction key are both case sensitive. Make sure you you enter it exactly as it is shown in your control panel.
3. Make sure you have trimmed any spaces before or after the login or transaction key.
4. Make sure you don't have any typos in your production code.

[cevo]

Hi,

Thank you for your response, please find my below everyone you've suggested has been verified prior to posting.

1 + 2. Login ID Case and Value were confimed by phone support and through our control panel,

1. The transaction key we re-generated and copied straight in just to make sure.

3. The xml pasted is a dump directly from what is being sent (not our code end but after it's been generated and in it's raw format to send to the server) there are no spaces between the xml tags for either the login id or the transaction id

4. The production code is not a copy of the sandbox code, it's the same code (ie there is only one version of this code)
we just change the url it's posting to and the login id and transaction key.

Thanks

James

[stymiee]

In cases like this there's something else is wrapped around your code that's breaking it. What your code is sending is not what Authnet is receiving. Otherwise they wouldn't be returning an error to you. Try to see if you can follow your code's output every step of the way until it literally leaves your server and see if you can find what is affecting it. Something is. You probably just don't know it yet.

[cevo]

Hi,

Thank you for your response again.

As before the xml posted is just before it's sent using curl to the authorize.net server.

it is literally dumped then curl is initialized and the data is sent, there is no more processing inbetween, i've even made it so the server doesn't go through any processing and what Curl is sending is to the correct URL

it's PHP and here is the send code:

function sendRequest($mode,$request,$server)
{
            file_put_contents("files/tmp/request-".mktime(),$request);
            $ch = curl_init("https://secure.authorize.net/gateway/transact.dll");
            curl_setopt($ch, CURLOPT_HEADER, 0);
            curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
            curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml"));
            curl_setopt($ch,CURLOPT_POSTFIELDS,$request);
            curl_setopt($ch,CURLOPT_POST,1);
            curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
            $response = curl_exec($ch);
            curl_close($ch);

            return explode($this->delimChar,$response);

}

file_put_contents("files/tmp/request-".mktime(),$request);

is where the xml is dumped (and thus pasted into the forum), curl is then initialized and executed. no further changes happen to the xml data.

Also as I said the same request works just fine on the sandbox

Thanks
James 

[stymiee]

Then are you sure you're properly changing servers from test to production?

[cevo]

Again, to make sure (as shown in the code above)

I have manually put the server address into the curl initialization.

[stymiee]

I'm just trying to throw everything out there as error 13 are basic errors. I'm hoping to maybe point out the little thing that might be the problem for you.

Maybe while you wait for other ideas you can try building a very simple solutions from the ground up and see what happens. If very basic smaple code gives you can error from the get go then you know the error lies elsewhere. If not, it can help you track down where the error pops up.

[TJPride]

Well, if you've actually verified everything, and it seems like you have, there's only one thing you can't verify, and that's your transaction key. Are you the only one with access to the account? Try setting a new one, just for the heck of it. I've seen people who were absolutely certain they had the right key discover they had an old one or someone else had changed it without them knowing about it.

[cevo]

Hey, 

Thanks for your response, first thing we tried I'm waiting for the client to return so we can test a raw submission (ie XML straight to curl) as stymiee suggested, but honestly if that doesn't work i'm not sure what else to check or try.

Authorize.net have told me beyond asking on here there is no resolution, they can't verify the details they are receiving apparently so I guess the only alternative is use a different provider.

Thanks

James