topic Re: Environment.PRODUCTION in API DLL different from documented? in Integration and Testing

Environment.PRODUCTION in API DLL different from documented?

dsandberg — Mon, 24 Sep 2018 16:43:58 GMT

I'm endeavoring to utility the NuGet AuthorizeNet DLL for getting tokens for Accept Hosted pages. But in revieiwng the source code from Github that is ostensibly related to that DLL, I see that the XML production environment is defined in Environment.cs as https://api2.authorize.net, while the API reference documentation indicates that the production environment API is accessed via https://api.authorize.net/xml/v1/request.api. This brings up two questions:

1) Why does one have the "2" appended to the "api" domain element, and the other does not?

2) May I assume that some other code within the AuthorizeNet DLL takes care of appending the rest of the URL ("/xml/v1/request.api") to that domain?

Fundamentally I am trying to assert that we aren't going to run into problems with incorrect URLs if we attempt to leverage the AuthorizeNet DLL from NuGet.

Re: Environment.PRODUCTION in API DLL different from documented?

mmcguire — Mon, 24 Sep 2018 18:58:53 GMT

Both api and api2 will work, the requests end up going the same route.

For more detail, here is the relevant blog post:

https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-Authorize-Net-Networking-Change/ba-p/51272

Re: Environment.PRODUCTION in API DLL different from documented?

dsandberg — Mon, 24 Sep 2018 19:13:26 GMT

That explains it nicely. I'd seen "Akamai" mentioned in a few places, but didn't understand the context until now. Thanks!

Re: Environment.PRODUCTION in API DLL different from documented?

dsandberg — Mon, 24 Sep 2018 19:26:31 GMT

Oh, there is one more, related question. hopefully a simple one to answer:

Can you please confirm that the same URLs that are embedded in the API DLL work for both U.S. and international merchants (Canada in particular)? We want to make sure that our Canadian clients are able to use our software to engage with Authorize.net without issues. (Our previous payment provider required different API URLs for the U.S. vs. Canada.)