I have invoked the create subscription API with profile data (Sandbox). Im getting this error on my server log
[Server:service-node2] 18:21:45,943 ERROR [net.authorize.util.HttpCallTask] (pool-11-thread-1) Http request execute failed: 'Read timed out' [Server:service-node2] 18:21:45,944 WARN [net.authorize.util.HttpCallTask] (pool-11-thread-1) Adding ErrorMessage: Code: 'java.net.SocketTimeoutException', Text: 'Read timed out' [Server:service-node2] 18:21:45,944 ERROR [net.authorize.api.controller.base.ApiOperationBase] (http-/192.168.5.28:8090-2) Invalid response:'net.authorize.api.contract.v1.ANetApiResponse@475528b6'
But Subscription was created successfully when i check in merchant login.
In our web application we will be offering products on Success resonse after invoking API. What if this error happens in production environment , where a customer will be charged but no products offered.
This is scaring me. Is this a usual scenario. How to get rid of this.
Kindly someone help me in this.
Suresh Babu R
How often you seeing this error ? is this on sandbox only or have seen it on prod .
Also look at signing up for webhooks for subscriptions to be notified realtime on the subscription events .
||Notifies you that a subscription has been created.|
||Notifies you that a subscription has been updated.|
||Notifies you that a subscription has been suspended.|
||Notifies you that a subscription has been terminated.|
||Notifies you that a subscription has been cancelled.|
||Notifies you when a subscription has only one recurrence left to be charged.|
Thanks for your reply!!
Rarely this is happening to me in Sandbox. I've not moved this to Production yet. I need a clarification about this before going live on production.
Without webhook can we solve this or can we get rid of this?
Suresh Babu R
I had/ have this too, and reported it on this Forum.
When I tested using production credentials, the AIM / ARB sailed through with no problems. Only the sandbox seems to be affected. The **REAL** problem is that the sandbox is NOT a mirror of the production environment, IMHO, even though the documentation and the website says it is.
For me, the AIM transaction times out at 30s, but the transaction does in fact succeed. This is forcing us to code in a trap for the SocketTimeoutException to enable testing, which is a dangerous thing. We have to be very sure to remove this in production.
Needless to say, we are not very happy with the state of things.
Interestingly, website version (at https://developer.authorize.net/api/reference/), where you can enter your (test!) credentials to have the API populated, seems to work ok. It still hangs on the AIM AuthAndCapture but it does go through and you can see the response. I suspect that the timeout may have been relaxed greater than the 30s enabled by the SDK.
I'm about to re-build the SDK for the nth time to see if a 60s timeout would allow for the transaction to go through for testing.
Also, here's my stack trace, even with the 60s timeout set for both . I'm using:
java 1.8 (for both build and deploy)
eclipse Oxygen and Junit4
Sending to Sandbox
java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983) at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940) at sun.security.ssl.AppInputStream.read(AppInputStream.java:105) at org.apache.http.impl.conn.LoggingInputStream.read(LoggingInputStream.java:84) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) at net.authorize.util.HttpClient.execute(HttpClient.java:174) at net.authorize.Merchant.postTransaction(Merchant.java:285) at net.authorize.aim.functional_test.SimpleAuthCaptureTest.testCreditCardAuthCapture(SimpleAuthCaptureTest.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498)
The transaction clearly made it to the server.
|17-Mar-2018 15:36:57||Test, John||V||XXXX1111||USD 27.36||--|
I'm suspecting a connection that is not being released and a return response that is not being sent.
Any luck on the Authorize.net side, guys? This has been going on for a while it seems.
Have you seen the TLS 1.2 link https://support.authorize.net/s/article/Authorize-Net-Support-for-SSL-TLS-FAQ
For cipher support ECDHE and AESGCM are preferred, SHA-1 ciphers will be not be supported. For a full list/report SSL Labs report can be run to see and verify TLS version and ciphers supported. Please see below for a matrix of reports available, by API endpoint and environment.
Also you can reach out to our support at 877.447.3938
|Transact, Legacy (Non-Akamai)||https://www.ssllabs.com/ssltest/analyze.html?d=secure.authorize.net||Not Applicable|
|ANet API, Legacy (Non-Akamai)||https://www.ssllabs.com/ssltest/analyze.html?d=api.authorize.net||Not Applicable|
|ANet API, Akamai||https://www.ssllabs.com/ssltest/analyze.html?d=api2.authorize.net||