Answers.Body: <p>It has been confirmed by @petednz and by testing without the 'Separate membership payment' option, that unsetting this option resolves the 'transaction is a duplicate' error. </p>
  
  <p>In our case the membership types were moved out of the form into a price set.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-04-11T23:35:35.487Z
Answers.LastActivityDate: 2017-04-12T00:48:40.700Z
Answers.LastEditDate: 2017-04-12T00:48:40.700Z
Answers.UserDisplayName: Interlated
Body: <p>Are other people seeing the error message:</p>
  
  <blockquote>
    <p>Payment Processor Error message: 9003: It appears that this transaction is a duplicate. Have you already submitted the form once? If so there may have been a connection problem. Check your email for a receipt from eWAY. If you do not receive a receipt within 2 hours you can try your transaction again. If you continue to have problems please contact the site administrator.</p>
  </blockquote>
  
  <p>We are using the Eway Payment processor and CiviCRM.</p>
  
  <p>We had a donation and a membership submitted at the same time and we had the donation go through but not the membership. The membership seemed to fail regularly so I rebuilt the form with profiles and captcha. We are still getting this error.</p>
  
  <p>I can see the error message in the code. <a href="https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/eWAY.php" rel="nofollow noreferrer">https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/eWAY.php</a>. It looks as though it is checking for a unique invoice id. Is there a way to manage the way invoice id's are created that we are not managing correctly? Is it a race condition?</p>
  
  <p>CiviCRM 4.7.17.</p>
  
  <p>The http server logs (cleaned up) from this IP address are:</p>
  
  <pre><code>[06/Apr/2017:16:02:32   +1000]  POST /civicrm/contribute/transact HTTP/1.1  200 16030   https://www.colongwilderness.org.au/civicrm/contribute/transact?reset=1&amp;id=1
  [06/Apr/2017:16:05:07   +1000]  POST /civicrm/contribute/transact HTTP/1.1  200 15965   https://www.colongwilderness.org.au/civicrm/contribute/transact
  [06/Apr/2017:16:05:36   +1000]  POST /civicrm/contribute/transact HTTP/1.1  200 15947   https://www.colongwilderness.org.au/civicrm/contribute/transact
  [06/Apr/2017:16:06:05   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact
  [06/Apr/2017:16:06:34   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact?_qf_Confirm_display=true&amp;qfKey=d30c3a51b960fea81a73d70d656af1a9_8907
  </code></pre>
  
  <p>It is referring back to itself which I can't explain.</p>
  
  <p>A working test (form 4 not form 1)</p>
  
  <pre><code>[07/Apr/2017:05:10:25   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact?reset=1&amp;id=4
  [07/Apr/2017:05:10:59   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact?_qf_Confirm_display=true&amp;qfKey=37ea51cf5a1e3f5197f136c5801cba2f_4643
  </code></pre>
  
  <p>The log does show that the contribution was being made on an old form that I had replaced. </p>
  
  <p>This form only uses the inline options for donations and memberships. Thew new form uses price sets.</p>
  
  <p>Old form configuration</p>
  
  <p><a href="https://i.sstatic.net/IR4KI.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/IR4KI.png" alt="enter image description here"></a></p>
  
  <p>With a membership section</p>
  
  <p><a href="https://i.sstatic.net/RnE7C.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/RnE7C.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-06T07:46:03.820Z
Comments.Text: Four details to add to this: The IP address(es) (from your webserver logs) that is/are the origin IP when the error message is generated - do they belong to the visitor, or eWay? Does that URL get hit once, twice, or more often? What is the invoice ID / contribution ID which CiviCRM thinks is duplicated? What is the end status of the contribution / membership?
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-06T07:51:14.240Z
Comments.Text: For further debugging: the [location of this error message in `CRM_Core_Payment_eWay::doDirectPayment()`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/eWAY.php#L263), and the [definition of `CRM_Core_Payment::checkDupe()`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L1288) ... you might need to add some debug to these to understand what's happening.
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-06T11:23:02.060Z
Comments.Text: I checked three sites which are using eWay, and none of them were exhibiting this behaviour. Another potential cause might be duplicate submissions, either due to javascript or users double-clicking the submit button. But that's just guesswork - debugging will find you facts. Good luck!
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-06T20:17:46.977Z
Comments.Text: The person did find an old form. My theory is that there are donation amounts and a membership price set in the same form. I can't see 2x transactions in eway - they just declined it. Maybe they aggregate on their end. Of course we don't keep any log of the hits our server makes on eway.  I'll add the web-server trace to the question.
Comments.UserDisplayName: Interlated
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-11T06:57:10.480Z
Comments.Text: Yes I have just had same issue reported on a site that was upgraded to 4.7.x from 4.6.x. The Contribution page offers Donation (inc Other amount) and Membership (not via a Price Set) AND uses "Separate Membership Payment"
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-11T07:19:16.153Z
Comments.Text: I confirmed the issue arose when page was set to "Separate Membership Payment" and did not occur when that setting was turned off.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-11T08:32:01.990Z
Comments.Text: Yes.  I've run it for a week now without that setting and not had a problem
Comments.UserDisplayName: Interlated
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-04-12T00:48:23.607Z
Comments.Text: may also relate to https://issues.civicrm.org/jira/browse/CRM-20172
Comments.UserDisplayName: petednz - fuzion
Tags: <civicontribute><payment-processor><eway>
Title: Payment processor, avoiding payments being rejected due to 'transaction is a duplicate'?
ThreadText: # Payment processor, avoiding payments being rejected due to 'transaction is a duplicate'?
  
  (Asked by: username_0 on 2017-04-06)
  
  Are other people seeing the error message:
  
  > Payment Processor Error message: 9003: It appears that this transaction is a duplicate. Have you already submitted the form once? If so there may have been a connection problem. Check your email for a receipt from eWAY. If you do not receive a receipt within 2 hours you can try your transaction again. If you continue to have problems please contact the site administrator.
  
  We are using the Eway Payment processor and CiviCRM.
  
  We had a donation and a membership submitted at the same time and we had the donation go through but not the membership. The membership seemed to fail regularly so I rebuilt the form with profiles and captcha. We are still getting this error.
  
  I can see the error message in the code. <https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/eWAY.php>. It looks as though it is checking for a unique invoice id. Is there a way to manage the way invoice id's are created that we are not managing correctly? Is it a race condition?
  
  CiviCRM 4.7.17.
  
  The http server logs (cleaned up) from this IP address are:
  
  ```
  [06/Apr/2017:16:02:32   +1000]  POST /civicrm/contribute/transact HTTP/1.1  200 16030   https://www.colongwilderness.org.au/civicrm/contribute/transact?reset=1&id=1
  [06/Apr/2017:16:05:07   +1000]  POST /civicrm/contribute/transact HTTP/1.1  200 15965   https://www.colongwilderness.org.au/civicrm/contribute/transact
  [06/Apr/2017:16:05:36   +1000]  POST /civicrm/contribute/transact HTTP/1.1  200 15947   https://www.colongwilderness.org.au/civicrm/contribute/transact
  [06/Apr/2017:16:06:05   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact
  [06/Apr/2017:16:06:34   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact?_qf_Confirm_display=true&qfKey=d30c3a51b960fea81a73d70d656af1a9_8907
  
  ```
  
  It is referring back to itself which I can't explain.
  
  A working test (form 4 not form 1)
  
  ```
  [07/Apr/2017:05:10:25   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact?reset=1&id=4
  [07/Apr/2017:05:10:59   +1000]  POST /civicrm/contribute/transact HTTP/1.1  302     https://www.colongwilderness.org.au/civicrm/contribute/transact?_qf_Confirm_display=true&qfKey=37ea51cf5a1e3f5197f136c5801cba2f_4643
  
  ```
  
  The log does show that the contribution was being made on an old form that I had replaced.
  
  This form only uses the inline options for donations and memberships. Thew new form uses price sets.
  
  Old form configuration
  
  [![enter image description here](https://i.sstatic.net/IR4KI.png)](https://i.sstatic.net/IR4KI.png)
  
  With a membership section
  
  [![enter image description here](https://i.sstatic.net/RnE7C.png)](https://i.sstatic.net/RnE7C.png)
  
  **Tags:** civicontribute, payment-processor, eway
  
  > **Comments:**
  > **username_1**: Four details to add to this: The IP address(es) (from your webserver logs) that is/are the origin IP when the error message is generated - do they belong to the visitor, or eWay? Does that URL get hit once, twice, or more often? What is the invoice ID / contribution ID which CiviCRM thinks is duplicated? What is the end status of the contribution / membership?  
  > **username_1**: For further debugging: the [location of this error message in `CRM_Core_Payment_eWay::doDirectPayment()`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/eWAY.php#L263), and the [definition of `CRM_Core_Payment::checkDupe()`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L1288) ... you might need to add some debug to these to understand what's happening.  
  > **username_1**: I checked three sites which are using eWay, and none of them were exhibiting this behaviour. Another potential cause might be duplicate submissions, either due to javascript or users double-clicking the submit button. But that's just guesswork - debugging will find you facts. Good luck!  
  > **username_0**: The person did find an old form. My theory is that there are donation amounts and a membership price set in the same form. I can't see 2x transactions in eway - they just declined it. Maybe they aggregate on their end. Of course we don't keep any log of the hits our server makes on eway.  I'll add the web-server trace to the question.  
  > **username_2**: Yes I have just had same issue reported on a site that was upgraded to 4.7.x from 4.6.x. The Contribution page offers Donation (inc Other amount) and Membership (not via a Price Set) AND uses "Separate Membership Payment"  
  > **username_2**: I confirmed the issue arose when page was set to "Separate Membership Payment" and did not occur when that setting was turned off.  
  > **username_0**: Yes.  I've run it for a week now without that setting and not had a problem  
  > **username_2**: may also relate to https://issues.civicrm.org/jira/browse/CRM-20172  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-04-11. Score: 1 | Accepted answer
  
  It has been confirmed by @username_2 and by testing without the 'Separate membership payment' option, that unsetting this option resolves the 'transaction is a duplicate' error.
  
  In our case the membership types were moved out of the form into a price set.
  
  
  ---
  
  