Skip to content

Recurring Contribution Failure Handling

Alan Dixon edited this page Jan 15, 2016 · 1 revision

[This page documents the upcoming failure handling for 1.5+]

Recurring contribution failures are handled for three distinct scenarios:

  1. Unexpected server failures.
  2. Credit card reported lost/stolen, or any ACH/EFT failure (i.e. fatal card errors).
  3. Other card errors (i.e. possibly transient card errors).

You can set an email address in the iATS configuration page to generate an automated email on every job run that includes any of these failures, and which sends a list of those failures.

We strongly recommend that you configure this value and monitor your errors.

Unexpected Server Failures

In some cases, the extension code will run, but one or more of the transactions will not complete normally.

For these cases, the contribution will be created in CiviCRM if possible, but left in a pending state.

If the attempted transaction did actually take place on iATS, the verify job will complete or fail the matching pending contribution payment as appropriate, or create a new one if it doesn't find a matching one.

If no corresponding transaction took place at iATS, you will have to manually remove the contribution and deal with the issue.

Card Reported Reported Lost/Stolen, or any ACH/EFT Failure (fatal card errors).

In these cases, the corresponding contribution is marked as Failed, and the corresponding schedule/sequence status is changed to pending, to avoid more automated attempts to charge the card.

You will need to contact the cardholder and get replacement card information, or else set the schedule/sequence to Failed.

Other Card Errors

Other card errors are not definitive about why they have failed, and may be transitory, so the contribution is created and marked as failed, but the next scheduled contribution date is not changed, to allow the script to try again with the next execution of the job.

However, after 3 (configurable) failed attempts in a row, the next scheduled contribution date is moved forward, to avoid too many repeated failures. The number of failures since the last success is stored in a field called "Failure Count", which can be edited if you wish.