Issue Details (XML | Word | Printable)

Key: CRM-3024
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed/Completed
Priority: Minor Minor
Assignee: Yashodha Chaku
Reporter: Mathieu Lutfy
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
CiviCRM

Recurring contributions: sql error in civicrm 2.0.1 when using authnet gateway

Created: 23/Apr/08 06:08 PM   Updated: 22/Dec/08 03:04 PM
Component/s: CiviContribute
Affects Version/s: 2.0
Fix Version/s: 2.1

Time Tracking:
Not Specified


 Description  « Hide
Hi,

We are having a problem with recurring transactions: the insert statement into civicrm_contribution_recur complains that "Duplicate entry '1' for key 2, 1062". From what I understand, it seems that the insert causes a duplicate entry on the key (domain_id, trxn_id).

The insert statement doesn't seem to insert the "trxn_id". The existing entry in the database has a null value for trxn_id, and the insert statement shown in the backtrace does not insert the trxn_id either. However, the payment gateway code (authorize.net) returns a valid trxn_id (I did a var_dump before returning the $params).

I modified CRM/Contribute/Form/Contribution/Confirm.php to add:
 
 $recurParams['trxn_id'] = $params['trxn_id'];

a bit before the call to "$recurring =& CRM_Contribute_BAO_ContributionRecur::add( $recurParams, $ids );" (i.e. around line 689). And it seems to fix the problem, i.e. the trxn_id is stored in the database, and inserts no longer cause a duplicate key error.

However, I am wondering maybe this was intentional. Recurring transactions are processed by the gateway, and I guess that it will send the donor a new receipt every time the credit card is billed. I do not feel very comfortable editing the code related to the processing of transactions. I am offtrack?

We are using CiviCRM 2.0.1, PHP5, Drupal 5. I made a diff with civicrm 2.0.2 and did not see any fix on that specific issue.

A full backtrace is available in the forum:
http://forum.civicrm.org/index.php?topic=3088.new

thanks,
mathieu (bgm on #civicrm)

 All   Comments   Work Log   Change History   FishEye      Sort Order: Ascending order - Click to sort in descending order
Donald A. Lobo added a comment - 23/Apr/08 08:16 PM

This has been fixed in 2.1, i fixed it earlier on the 2.1.menu branch

Kurund Jalmi added a comment - 12/Aug/08 12:58 PM
- checked with paypal standard, working fine. I had worked on similar issue with Authorize.net, so this fix should also work for authorize.net, since authorize.net sends unique transaction id for live transaction and we generate unique txn id during Test Drive.