cancel
Showing results for 
Search instead for 
Did you mean: 

Testing Akamai in the Sandbox

A discussion related to https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-Authorize-Ne...

 

  • Sandbox URLs are unchanged and are already configured with Akamai for testing
  • Version 1.8.5 of our language SDKs are configured to use the new Akamai endpoints
RichardH
Administrator Administrator
Administrator
40 REPLIES 40

Hi Richard (or anyone else who knows):

 

For our implementation (using the DPM method), we have a QA server that is not publicly accessible. It is configured to use a sandbox account. Previously, we had whitelisted two IP addresses to allow Authorize.net to post back to the QA server (198.241.168.60 and 198.241.162.104).

 

Now that requests to Authorize.net are going to be routed dynamically via Akamai, is it also correct that the postbacks will originate from a non-predictable set of IP addresses in the cloud, such that we would need to make the QA server public so that it can receive those postbacks?

 

Thanks in advance,

Jeremy

Hello @jeremyclifton

 

Relay Response and Silent Posts originating from Authorize.Net will not go through Akamai and the IP addresses will remain the same.

 

Richard

Richard,

 

Thanks for the quick response!

 

Best,

Jeremy

Hi all

 

I am familiar with akamai and have implemented it on a few websites, (I am also familiar with their DSA servivce). I understand what they are good for and they can improve performance when used correctly.

 

To the best of my understanding of how this works, I really don't see how it can benefit a use case like authorize.net

 

Every single request MUST reach out to the origin server (authorize.net server), so all you are doing is adding another layer of latency. (yes akamai can possibly have a faster network connection from their edge server to the origin than you might have had on your own, but that is a marginal benefit, only usefull when most of your traffic is cached and only some of your traffic needs to go back to the origin. BUT in this case where 100% of your traffic needs to go back to the original I suspect that the added layer will not give me any benefit).

 

any failures at authorize.net will down the system and nothing akamai can do to help. what are the odds of a routing issue preventing you from reaching authorize.net but allowing you to reach akamai and allowing akamai to still be able to reach authorize.net, (Routing IP traffic around localized network failures happens all the time transparently for all traffic, akamai doesn't have any secret sauce here) (if you are in the US I doubt it, perhaps in other countries that is more likely???)

 

anyway that is my two cents of how I see it.

 

mn

mnemanov
Member

Hi:

 

Please refer to the highlighted text in the following para:

 

  • Phase Two (June 2016) – We will automatically direct all of our existing transaction processing URLs to connect through Akamai in June of 2016. After this change, all transaction URLs will connect to Authorize.Net through Akamai.

When you say all transaction URLs, does that include all the following URLs (the old and the new ones):

 

Thanks

KK

kk_rm
Member

Hi:

 

To be more specific, I just need to know if the three new URLs will be active and work after phase 2 upgrades.

 

Thanks

KK

kk_rm
Member

Hello @kk_rm

 

After the change, either API* or API2* will work for the endpoint.

 

Richard

Including "Secure2.Authorize.Net"?

 

Thanks

KK

 Yes :)

 

Richard

Hi,

 

Can you please share the new Akamai Url for the Sandbox. I would like to test with the new sandbox Url before I deploy the changes to the production

 

 

Thanks,

Murali