0

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

With a membership section

enter image description here

Improve this question
8
  • 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?
    – Chris Burgess
    Commented Apr 6, 2017 at 7:46
  • For further debugging: the location of this error message in CRM_Core_Payment_eWay::doDirectPayment(), and the definition of CRM_Core_Payment::checkDupe() ... you might need to add some debug to these to understand what's happening.
    – Chris Burgess
    Commented Apr 6, 2017 at 7:51
  • 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!
    – Chris Burgess
    Commented Apr 6, 2017 at 11:23
  • 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.
    – Interlated
    Commented Apr 6, 2017 at 20:17
  • 1
    I confirmed the issue arose when page was set to "Separate Membership Payment" and did not occur when that setting was turned off.
    – petednz - fuzion ♦
    Commented Apr 11, 2017 at 7:19

1 Answer 1

Reset to default
1

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.

In our case the membership types were moved out of the form into a price set.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.