Repeated transaction attempts fail

[xurizaemon]

When making a second attempt at a transaction (either due to network / browser timeout, failed initial transaction etc):

8002: Duplicate error - existing contribution record(s) have a matching Transaction ID or Invoice ID. Contribution record ID(s) are: 70957

Similar to eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor#26 ?

[eileenmcnaughton]

So these are failed at their end? do they accept non-numeric? I'd kinda like to append a payment number with some sort of demarcation

[jitendrapurohit]

Not sure, but the error message seems like it is failing in core when it tries to create a pending contribution and finds a duplicate transaction id in the civicrm_contribution table.

I think it is by design as I've seen similar message with dummy processor too while doing a debug at a point after contribution gets created.

[eileenmcnaughton]

Are you sure the trxn_id is duplicated not the contribution_id - that seems odd

[jitendrapurohit]

Depends on how the second attempt of transaction is made? In my case, this is just by doing a refresh when an exit is done after submitting the confirm page(to check something after contribution is created). For eg -

$contribution = CRM_Contribute_BAO_Contribution::add($params);
debug returned $contribution
exit;

and then do a reload of a page(due to same $params with same trxn id inserted) - will lead to this error.

Similar I think is the error with network loss/browser timeout as chris mentions when a reload is performed with same params.

[eileenmcnaughton]

OK - I think that is considered invalid actually - & mostly hit in testing.

[xurizaemon]

This happens for this and other processors in CiviCRM if the initial transaction fails, eg you don't have enough funds in your bank account (or mistype your CC), then retry the transaction.

[eileenmcnaughton]

so there are a few things in play here - one is that under some circumstances I don't think Civi copes that well with browser refresh. But I've also observed in testing that sometimes the rollback does not delete the line items, causing DB fails - I think that doesn't happen 'in the wild'. However, you are talking about something else again?