Answers.Body: <p>Rob,</p>
  
  <p>Since you're processing a lot of transactions I think we can assume that there isn't an issue with CiviCRM or the payment processor or gateway.  We have seen this occur with our clients with a variety of payment processors and generally we recommend not spending much time researching unless it starts to happen regularly. </p>
  
  <p>I do recommend that create a daily reconciliation report (you may have already done so) that gets emailed to out accountant each morning so that the CiviCRM transactions and the payment processor transactions can be compared.  For larger organizations something like this is required by their auditing practice.  Ensure the CiviCRM report uses the same time cut-off as the payment processor.   </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-14T20:14:58.333Z
Answers.Text: We've managed to correlate this behavior with a coredump in apache:
  
  child pid 30252 exit signal Bus error (7), possible coredump in /etc/apache2
  
  Not at all sure what's causing the coredump.  I increased the max memory in php.ini as a wild guess.
Answers.UserDisplayName: Rob Brandt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-03T13:35:00.660Z
Answers.LastActivityDate: 2015-10-03T13:35:00.660Z
Answers.UserDisplayName: pkeogan - BackOffice Thinking
Answers.Body: <p>I have seen this before on several occasions with Eway as the payment processor.</p>
  
  <p>It happened more frequently when we had a spate of double processing of a single transaction when our settings were to leave out the contribution confirmation page. Often only one of the transactions would be recorded in CiviCRM although both were processed by Eway.</p>
  
  <p>Since we went back to including the contribution confirmation page, double processing of a payments has stopped.</p>
  
  <p>However, very occasionally we have the situation where two different people submit transactions to Eway within one second of each other and only one of those contributions is recorded in CiviCRM.</p>
  
  <p>I am not a developer, so don't know whether Eway or CiviCRM is the culprit. Our developer has looked at the problem, but there was no easy fix for the money we could afford to spend.</p>
  
  <p>As our organisation reconciles Eway income and income recorded in CiviCRM as coming from Eway on a daily basis, we just live with it.  (The daily reconciliations have 'always' been done and include income from all sources, they haven't been introduced because of this problem.) </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-12T17:44:49.587Z
Answers.Text: I haven't heard of other double transactions, but @JoAnne or Eileen may have.
Answers.UserDisplayName: Joe Murray
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-03T03:17:34.310Z
Answers.Text: FWIW, we use the confirmation page.  We have never to my knowledge experienced double transactions.  I don't think I have any way of knowing if there were simultaneous transactions.
Answers.UserDisplayName: Rob Brandt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-03T01:04:33.783Z
Answers.LastActivityDate: 2015-10-03T01:04:33.783Z
Answers.UserDisplayName: JoAnne
Answers.Body: <p>@Rob Brandt, your comment in response to @pkeogan's answer is illuminating. My sense is that the transaction was sent to your payment processor but the Apache process died for some reason before the response from it was recorded. There could be innumerable issues that would cause a thread to crash, such as memory issues like you have guessed.</p>
  
  <p>Organizations with auditors, and some without that are well-run, invest in followable auditable procedures. This generally means checking financial transactions in two ways. Reconciling your CiviCRM system data against actual receipts from payment processors is an essential part of this. CiviCRM allows you to export financial information in batches that can be imported into a number of financial account packages like QuickBooks or anything that accepts a .csv file.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-20T20:01:01.217Z
Answers.Text: Thanks, actually I don't remember how we solved this back in October but the problem is gone.
Answers.UserDisplayName: Rob Brandt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-12T17:53:33.373Z
Answers.LastActivityDate: 2016-01-12T17:53:33.373Z
Answers.UserDisplayName: Joe Murray
Body: <p>using 4.6.8 on Drupal 7.  FirstData is our payment processor.</p>
  
  <p>This week we received a transaction confirmation from FirstData from one of our long time members.  FirstData calls this a "gateway receipt" and is generated directly from them with no involvement with CiviCRM, for every transaction approved.  We have his money.</p>
  
  <p>But there's no record of the contribution in CiviCRM itself.  I've looked through the database directly (phpmyadmin), looking for transactions of the same dollar amount, or for the same contact, or even orphaned line items with no transaction.  Nothing.</p>
  
  <p>Has anyone seen this before or have ideas about how it can happen?  Possibly a timeout for transaction response from FirstData?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-10-02T23:35:24.170Z
Comments.Text: Rob,  Is it safe to assume you have many other successful transactions?  Do you have any other transactions that same day?
Comments.UserDisplayName: pkeogan - BackOffice Thinking
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-10-03T03:15:12.307Z
Comments.Text: Yes, many thousands of transactions overall and 1 or 2 dozen that day.
Comments.UserDisplayName: Rob Brandt
Tags: <civimember><contributions>
Title: Transaction went through, but Contribution missing
ThreadText: # Transaction went through, but Contribution missing
  
  (Asked by: username_0 on 2015-10-02)
  
  using 4.6.8 on Drupal 7. FirstData is our payment processor.
  
  This week we received a transaction confirmation from FirstData from one of our long time members. FirstData calls this a "gateway receipt" and is generated directly from them with no involvement with CiviCRM, for every transaction approved. We have his money.
  
  But there's no record of the contribution in CiviCRM itself. I've looked through the database directly (phpmyadmin), looking for transactions of the same dollar amount, or for the same contact, or even orphaned line items with no transaction. Nothing.
  
  Has anyone seen this before or have ideas about how it can happen? Possibly a timeout for transaction response from FirstData?
  
  **Tags:** civimember, contributions
  
  > **Comments:**
  > **username_1**: Rob,  Is it safe to assume you have many other successful transactions?  Do you have any other transactions that same day?  
  > **username_0**: Yes, many thousands of transactions overall and 1 or 2 dozen that day.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2015-10-03. Score: 1
  
  Rob,
  
  Since you're processing a lot of transactions I think we can assume that there isn't an issue with CiviCRM or the payment processor or gateway. We have seen this occur with our clients with a variety of payment processors and generally we recommend not spending much time researching unless it starts to happen regularly.
  
  I do recommend that create a daily reconciliation report (you may have already done so) that gets emailed to out accountant each morning so that the CiviCRM transactions and the payment processor transactions can be compared. For larger organizations something like this is required by their auditing practice. Ensure the CiviCRM report uses the same time cut-off as the payment processor.
  
  > **Comments:**
  > **username_0**: We've managed to correlate this behavior with a coredump in apache:  child pid 30252 exit signal Bus error (7), possible coredump in /etc/apache2  Not at all sure what's causing the coredump.  I increased the max memory in php.ini as a wild guess.  
  
  ---
  
  ### Answer by username_2 on 2015-10-03. Score: 0
  
  I have seen this before on several occasions with Eway as the payment processor.
  
  It happened more frequently when we had a spate of double processing of a single transaction when our settings were to leave out the contribution confirmation page. Often only one of the transactions would be recorded in CiviCRM although both were processed by Eway.
  
  Since we went back to including the contribution confirmation page, double processing of a payments has stopped.
  
  However, very occasionally we have the situation where two different people submit transactions to Eway within one second of each other and only one of those contributions is recorded in CiviCRM.
  
  I am not a developer, so don't know whether Eway or CiviCRM is the culprit. Our developer has looked at the problem, but there was no easy fix for the money we could afford to spend.
  
  As our organisation reconciles Eway income and income recorded in CiviCRM as coming from Eway on a daily basis, we just live with it. (The daily reconciliations have 'always' been done and include income from all sources, they haven't been introduced because of this problem.)
  
  > **Comments:**
  > **username_0**: FWIW, we use the confirmation page.  We have never to my knowledge experienced double transactions.  I don't think I have any way of knowing if there were simultaneous transactions.  
  > **username_3**: I haven't heard of other double transactions, but @username_2 or Eileen may have.  
  
  ---
  
  ### Answer by username_3 on 2016-01-12. Score: 0
  
  @username_0, your comment in response to @pkeogan's answer is illuminating. My sense is that the transaction was sent to your payment processor but the Apache process died for some reason before the response from it was recorded. There could be innumerable issues that would cause a thread to crash, such as memory issues like you have guessed.
  
  Organizations with auditors, and some without that are well-run, invest in followable auditable procedures. This generally means checking financial transactions in two ways. Reconciling your CiviCRM system data against actual receipts from payment processors is an essential part of this. CiviCRM allows you to export financial information in batches that can be imported into a number of financial account packages like QuickBooks or anything that accepts a .csv file.
  
  > **Comments:**
  > **username_0**: Thanks, actually I don't remember how we solved this back in October but the problem is gone.  
  
  ---
  
  