So this looks like something we would do in the orphan rectifier. We currently delete pending rows (so the rectifier doesn't have to process them) when a payment is rejected. To make this work, we would stop deleting pending rows in that case and have the orphan rectifier take more info into account when deciding to capture.

We would only get this for Ingenico that way - this is the task to implement orphan rectifying for Adyen: T145708

Concerns: we might end up with too many orphans to keep up with a peak times, as this process is one at a time. Fanning it out into multiple parallel jobs could be hacky - maybe do it by modulo of contribution_tracking_id ?

One other process point: sometimes legitimate donors get a status 600 but retry shortly after, and the next attempt succeeds. Can we add logic to scan for recent donations so that we don't inadvertently cause donors to donate twice?

<just seeing point #4 above in initial comment!> thanks Evelyn

Some notes on implementation possibilities here:
https://etherpad.wikimedia.org/p/T276183

That sounds like a good guard to add in, @MBeat33 !

Thanks for the implementation notes, @Ejegg. I was considering picking this up, but it looks like there could well be a few tickets created off the back of this task, depending on the implementation chosen.

I'm inclined to say I prefer your proposed ideal solution of moving this over to a new Civi extension. That would help to reduce the coupling to the DI composer package in drupal/civi and also protect us from any future Drupal upgrade refactoring, I think!

I was just chatting with @EMartin and there might be one other factor to consider: manually settled GC600s have historically taken much longer to reach Civi than ones settled automatically. Our macro that we send to donors who alert us to GC600s tells them to expect their TY emails in a longer timeframe.

If a new script settles 600 from past donors, how long will it be before they receive their TY email? From the donor's point of view, will they have seen the TY page from the initial attempt? If not, they may also not get their TY email very quickly, and so have no way of knowing that their donation actually processed. This might lead to extra attempts on their part.

If there is anything we can do to ensure these script-settled 600s reach Civi more quickly than manually settled ones?

update:

I looked up a few recent manually settled Ingenico's:

This last donor made an extra donation on the 8th, 104584410.1, likely because they did not know the earlier attempt had been settled.

Even from just looking up a handful, what I notice is:

• the variation in times to reach Civi, from as little as two days to ones that have not arrived after three days
• a donor who likely made an extra donation because of this delay in Civi sending the TY email

Would it be possible to ensure that any new script-settled donations reach Civi more quickly, to prevent donor confusion and possible duplicates? There was an old Task, {T172216} from I think the old integration, maybe a similar adjustment could be made here?

Adding to @MBeat33 's comment above: will donors still see the error message they see when something gets caught at 600? As if we go ahead with this, I feel we need to ensure they don't see an error message, as settling something after we tell them it has failed as a new default feels like it could lead to donor confusion and disengagement in the long run, and more work and digging to figure out edge cases for Donor Relations.

Per our conversations today @Ejegg says the goal is to process these in 30 minutes. This is way faster than is already occurring. Also @Ejegg is going to look into adding tags to these so DR can differentiate these from other donations.

If the process includes the donor getting the TY email within 30 mins, that's great and should mitigate the extra donations to some (hopefully large) degree.

I think that automating this process is still something of an unknown, as there are as far as I know no metrics on how many donors that we are currently manually settling for who also then make extra donations before they get a TY email. One in five from a tiny sample seems high? Just because we don't see tickets about this does not mean that we aren't confusing or alienating some donors with a donation flow that seems to fail and then succeeds.