title: SagePay direct timeout period
body: <p>We set 30 seconds as our limit for a response from SagePay (direct) before timing out and send the customer a "timed out, try again" message.  Sometimes, rarely,  SagePay can take much longer than this to respond.</p>
  
  <p>Have had a few (rare) instances with SagePay direct where their response has taken up to 2 minutes (called SagePay support to trace the transaction).  Apparently it's due to the downstream bank's system taking a long time to respond.  This results in orphaned transactions,  where we've told the customer that it's failed,  but SagePay has completed the transaction.  The customer then tries again and we end up with duplicate transactions (or,  in one case,  the card being declined following a successful transaction which we registered as a fail).</p>
  
  <p>This is rare,  but it's a few dozen transactions on hundreds of thousands and causes grief for customer services and the accounts department who need to refund these transactions.</p>
  
  <p>Questions:</p>
  
  <ol>
  <li>Can you set a timeout on SagePay Direct to prevent this?</li>
  <li>What is a sensible application timeout value (2 minutes is way too long for a web application)?</li>
  <li>Alternatives to mitigate this rare occurrence?  For example,  can I query SagePay to see if the transaction completed?  (but then again, we're stuck because we would send this query before SagePay has completed, e.g. after 30 seconds)</li>
  <li>Are there any timeout differences between "E"commerce and "M"OTO transactions?</li>
  </ol>
  
  <p><strong>Update 1 - 2nd Sept:</strong><br>
  Happened again on 1st Sept where SagePay were failing over their databases so "transactions were taking longer than usual".  These transactions took well over a minute to complete,  by which time we'd timed out and told the customer to try again even though their transaction ultimately completed.</p>
  
  <p>When asked,  SagePay said that their timeout interval is 15 minutes,  which is an extraordinary length of time to wait for an HTTP response.  IIS has,  by default,  a maximum time of 90 seconds before a request is killed.</p>
  
  <p>Again,  does anyone have workarounds for this?</p>
  
  <p><strong>Update 2 - 29th Sept:</strong>
  More failures at SagePay as their gateway fails over,  it kills some in-flight transactions,  we get the following:</p>
  
  <blockquote>
    <p>The underlying connection was closed: A connection that was expected
    to be kept alive was closed by the server.</p>
  </blockquote>
  
  <p>However,  unfortunately some of these transactions have succeeded,  i.e. SagePay have billed the client,  but we're not aware of it.</p>
  
  <p>Any suggestions for improving this?</p>
  
  <p><strong>Update 3 - 26th Feb 2016:</strong> 
  There's nothing that can be done about this.  You need to allow a certain timeout period,  say 30 seconds,  and then handle it as an error.  The best option is to ensure a warning is raised/logged and then you can track it down later.</p>
  
  <p>Just one of those things that's never going to be addressed... :-(</p>