cancel
Showing results for 
Search instead for 
Did you mean: 

Production Mode does not work

Obviously I'm missing something here. I used your charge credit card sample code in php after installing the new code base from GitHub using composer.  I even ran the recommended update a few minutes ago to 1.8.8.

 

In sandbox the charge credit card works as expected, but when I change it over to PRODUCTION it fails everytime. 

 

I read another post on here about the coming updates and found the constants in the file located in the vendor/authorizenet/authorizenet/lib/net/authorize/api/constants/ANetEnvironment.php file, but after running the composer update that file is gone. However, even before it disapeared I updated the PRODUCTION constant to use your new URL and it made no difference.  And SANDBOX still works, so obviously that's not where it's being set I suspect.

 

The only response I get back, even from the command line (which works for SANDBOX using the sandbox credentials)  is the one below. I verified the constants are set by running a test from the command line and via the script I was calling this from and they are set correctly.

 

Charge Credit Card ERROR :  Invalid response

 

The same login credentials worked on an older curl setup on our old server, but have been unable to get it towrk on the new server setup.  In fact that's why I updated to your php sample because it is much cleaner code and I mistakenly thought it would be simpler to get it working.  Maybe it's serious lack of sleep, but this is beyond frustrating.  Any help would be appreciated.  And btw, I spoke to support on the phone and he basically said your sample code is not production ready and that you need to set the PRODUCTION server URL.  If that's true, why and where is the documentation on the EXACT file location in the tree on where to do it.  In the old code using curl, it was pretty obvious where to make the change.  This is frustrating to say the least. Thank you in advance!

 

 

 

altdev
Member
4 REPLIES 4

@altdev Just to clarify -- are you saying that switching to PRODUCTION is failing, with no other modifications to the SDK? Did you update the API Login ID and Transaction Key to use a Production account?

 

You later make a comment about modifying "the PRODUCTION constant to use your new URL". But that shouldn't be necessary at all. All the PRODUCTION and SANDBOX constants do, is set the domain name. The rest of the URL is the same in both Production and Sandbox, so you only need to toggle between apitest.authorize.net and api2.authorize.net -- which is what the PRODUCTION and SANDBOX constants do.

And api2.authorize.net is what is used by the new Akamai SureRoute URL. The legacy, pre-Akamai URL is on api.authorize.net.

So you shouldn't need to modify any values to use the new URLs -- the SDKs already use them.

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

Yes, switching to PRODUCTION IS failing with no other mods to the SDK.  The only change I did beyond that was use an active account's Login ID and Transaction Key and ran the test from the command line just like the sandbox test recommends.  The sandbox test from the command line works as expected.  Btw, that account was working on a different server a few days ago with no problems.  I'm wondering if it's locked into that old domain or IP as a security thing.  We did change the secure URL to a different one as well as the IP changed with a new server in a different data center of course. :)

 

I thought it was strange too, but your phone support guy said we needed to set the Production URL, so I went looking for it and updated it in the file reference below.  When that failed to resolve it I went in and ran the composer update to the 1.8.8 file of yours.  When that failed to work I went back and noticed the file that held the constants was gone.  I assumed the update to 1.8.8 moved it somewhere else or deleted it.  I again switched back to sandbox to see if it would still work and it did work still, so I assumed the constants were moved elsewhere.

 

And now I just checked and the file is back again.  Maybe I had a brain meltdown. Lol  Here's the contents:

 

class ANetEnvironment
{
    const CUSTOM = "http://wwww.myendpoint.com";
    const SANDBOX = "https://apitest.authorize.net";
    const PRODUCTION = "https://api2.authorize.net";
}

 

 

Any suggestions?  I thought it was strange when I ported over the code from the legacy server and it failed to work.  I then took some newer code from another account of ours that uses the old XML setup (works for them) and tried to make that work.  After that i discovered the new sDK and went through all of this craziness.

 

I know I'm seriously lacking sleep this week, but something is off here.

 

 

@altdev Could you change the PRODUCTION constant to "https://api.authorize.net/" and let me know if that works, please?

I'm not advising this as a long-term solution, but want to rule out any potential issues that might be limited to the api2.authorize.net domain.

If api.authorize.net works, but api2.authorize.net keeps throwing the error, then I'd like to know your server IP address.

Also, is there a chance of you capturing the full HTTP response we're returning? There may be a Reference ID # there that we could use for troubleshooting, if there's an error preventing a proper API response.

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

It looks like the issue was with the transaction key.  By looking through the log I saw the error E00007, if I recall. (Sorry, still really punchy.)  Anyway, it was obviously a problem with the client's credentials so we had them reissue a transaction key. Once we replaced the old one it resolved it. Very odd that it worked on the old server and not the new one and the client swears to me they did not go in and reissue the key prior to me asking them to.  I'm just glad it's resolved and I can get on with my life. Lol Thank you so much for your help.  Your request for the logs, made me realize it was there in that directory and allowed me to find the issue.  Maybe if I had some sleep I would have realized it myself...  Thank you!! 

altdev
Member