I work at a service provider that has several clients using Authorize.net as their payment gateway.
Our system has a 60-second timeout for API requests, and if a transaction takes longer than that, our system will not receive the response about the success or failure of the transaction. This happens infrequently but often enough that some of our clients have noticed and reached out about it.
We are trying to evaluate what will provide the best user experience, and part of that is to determine whether Authorize.net's payments API has a time out, and if so, how long the timeout is. Or, is there a recommendation or best practice for how long we should wait for a response before timing out the request?
As Authorize.Net is a Payment Gateway, timeouts are relative to many factors and do not solely reside within our system. They can occur at various times for various reasons as a result.
While the 60 second timeframe you currently have in place will suffice for 99.9% of the use cases, there are times when a response can take longer than 60 seconds. It's rare, but it happens.
The question here, I think, isn't what the timeout length is but rather what to do if a timeout occurs and the connection is closed before a response has been returned. As this occurs very rarely, it is up to you to decide what workflow effort is worth the low % of occurence rate. You do have options however.
You can, of course, increase your timeout timeframe. This may or may not solve the issue 100% of the time. As mentioned, this would be unknown because we cannot account for every factor outside of our system that may contribute to this timeframe.
You can also use getUnsettledTransactionListRequest Reporting API method to obtain the Unsettled Transactions in your account currently. This would allow you to identify if a transaction exists that you do not have accounted for in your database on your end.
I hope this information is helpful to you.