End point confirmation for TLS 1.2 upgrade

[Malith]

Hello,

Currently we are in the prcess of upgrading the connectivity to TLS 1.2 as per the requirement announced by Authorize.net.

Currently we are using the below urls/end pints. We need your confirmation if we can use these urls without any issue.

TEST:
https://test.authorize.net/gateway/transact.dll

LIVE:
https://secure2.authorize.net/gateway/transact.dll

[Aaron]

Hi @Malith,

Yes, those endpoints can be used. The test.authorize.net endpoint currently only supports TLS 1.2, so if you can process successfully with that endpoint, you should be fine once secure2.authorize.net switches to TLS 1.2 only in September.

[tcomtom]

Hello, 

We are using the DPM with the following end points as well:

Test:

https://test.authorize.net/gateway/transact.dll

Live:

https://secure.authorize.net/gateway/transact.dll

I just tested the test url and the transaction worked fine. 

Just wan't to be sure if there is anything else I need to do before the September TLS migration for live.

Thanks,

Tom

[Aaron]

If it works on the sandbox site, you should be fine.

One thing to be aware of with DPM, though. Since you're having customer's browsers post directly to us, your customer's browsers will need to support TLS 1.2 with the appropriate ciphers. That's usually not a big deal as most browser releases that are less than a few years old will work fine. Where you'll have problems is with those holdouts still using IE 8 or older (for example).

You can check out the ssllabs.com report for test.authorize.net and see a comprehensive list of which browser version will and won't be able to connect. Between now and the cutoff date you can prepare for the customer impact when armed with this information.

Some things you might want to do in preparation:

• Analyze server logs to get a breakdown of browser version and determine how much your customer base might be impacted.
• Educate anyone providing support to your customers that browser version is going to determine if the customer can properly make a payment
• Send a proactive notification to existing customer reminding them to upgrade their browser. That would also be a good time to let them know that if they don't upgrade, they won't be able to pay other places as well, and won't be able to pay anywhere after the PCI-DSS cutoff date in June 2018.
• Post a notice on your payment page with browser requirements.
• Script your payment page to identify the customer's browser and display an error message if the browser isn't a supported version.

[tcomtom]

Thank you for the detailed reply and the recommendations. 

[Malith]

Hi Aaron,

For my post on the 06-01-2017 03:01 AM, you confirmed the below url is working but unfortunately we are now receiving java.net.SocketException: Connection reset.

URL : https://test.authorize.net/gateway/transact.dll

Can you please check and advise if the url is working.

[rcourtois]

I'm having a similar problem trying to post to the following URL from a machine running Windows Server 2008:

https://apitest.authorize.net/xml/v1/request.api

The socket can be opened, but trying to start encryption results in the server resetting the connection.  I am trying to send a getHostedPaymentPageRequest request.  Every once in a while it will work and return a payment form request token, but probably 9 out of 10 times the connection gets reset.  The same code does run fine when run from a desktop macine running Windows 7.

[unaisk]

Hi,

I am using the following URL on production:

https://api2.authorize.net/xml/v1/request.api

Please let me know if this is TLS1.2 compliant. Its urgent.

Also, let me know if it is AKAMAI URL?

Thanks in advance.

[RichardH]

@unaisk  Yes, the endpoint https://api2.authorize.net/xml/v1/request.api is an Akamai endpoint.  Starting this morning it will be configured to only accept a TLS 1.2 connection for approximately 4 hours and then it will return to accept TLS 1.0, 1.1 and 1.2 until Feb 28th.

Please see https://status.authorize.net for details.

[mattlt]

For years now we have been using the https://secure2.authorize.net/gateway/transact.dll to talk to authorize.net, and for many months we have been using only the TLS 1.2 protocol on our server.

However, during the test today, all connection attempts resulted in no response from authorize.net.

We confirmed our TLS 1.2 status at SSLLabs.

Any idea what could be going on here?

(Current time is 13:10 PST, but the problem persists).