So it sounds like there are 3 cases to handle:

1. successful attempt
2. failed attempt
3. not going to try again

so here's what we could do:

1. record the successful payment - need to be able to look up the associated recurring record. Probably the listener sends a new type of job to the jobs-adyen, so we can run it where it can look things up in the db
2. Either ignore it, or record an activity against the donor record. These activities could be an alternative way to get some reporting on the rescue attempts if we don't want to parse a whole new file as suggested in T340159
3. change the recurring record to failed.

The trickiest part I see with these is that the only identifier they will send is the merchantOrderReference that we sent with the initial payment attempt, and we aren't storing failed or pending contributions anywhere in the DB. Since our orderReference is ct_id + . + sequence_id, we should generally be able to find the recurring record via the contribution_tracking_id.

Change 955775 had a related patch set uploaded (by Damilare Adedoyin; author: Damilare Adedoyin):

[wikimedia/fundraising/SmashPig@master] WIP: Implement Auto-Rescue Webhook handling

https://gerrit.wikimedia.org/r/955775

Change 956478 had a related patch set uploaded (by Damilare Adedoyin; author: Damilare Adedoyin):

[wikimedia/fundraising/crm@master] Push recurring transaction to pending queue when auto rescue is on.

https://gerrit.wikimedia.org/r/956478

Change 956478 merged by jenkins-bot:

[wikimedia/fundraising/crm@master] Push recurring transaction to pending queue when auto rescue is on.

https://gerrit.wikimedia.org/r/956478

Here is a flowchart describing the proposed flow for the auto rescue feature using the existing process.
Starting from the contribution recur trxn

Listener receives message about a successful authorisation that occurred during one of the AutoRescue attempts and pushes to the job-adyen queue. Someone before now the pending queue consume has been run.

Job Adyen queue consumes this message and capture the payment, indicating the capture payment status in the pending table row.

Listener receives message about successful capture and pushes to the job-adyen queue.

Job adyen pushes the transaction to the recurring queue with txn_type="subscr_payment" to update the contribution recur row. The pending table row is deleted.

The recurring queue consumer updates the contribution recur row and sets the next_sched_contribution_date appropriately.

@EMartin highlighting the above flows.

Change 955775 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Implement Auto-Rescue Webhook handling

https://gerrit.wikimedia.org/r/955775