Weird, when I look at that txn in Adyen's console

@Ejegg I'm not sure if this is related, but cid=64078006 (not in group 2125) shows Adyen one-time 206831814.1 as settled, but it got a rejection response from the acquirer.

Thanks so much for the group @Ejegg. @SHust and I will concentrate on reaching out to the one-time donors in it, and trust Civi to email the recurring ones if their donations fail when they next process.

Thank you @Ejegg that will let us get ahead of them noticing the funds not transferring despite the TY email

Resolving as we haven't seen this issue in a long time.

@Ejegg are the 68 CIDs with only fails donors who were starting new recurring donations? If so + you can share the list, the DR team can follow up with the ones who haven't reached out to us. And if there's any other donor-facing part of the followup please let me know, we're happy to help.

@SBorriello found cid=13372557, which appears to be active in both Civi and at PayPal. When we try to cancel S-28F30184XJ410502J in Civi, we both get the same error:

Many thanks, @Ejegg

Great, many thanks for confirming @Ejegg I'll add that error code to the DR documentation

hi @Ejegg question for you, I just canceled a recurring that was at status Failing and got this message:

thank you @Cstone

Thanks for checking into it @Ejegg We can test it a little more, but even if we use the old method for stray legacy cancels, that's still a big win.

This is totally great news, thank you @Ejegg and @Cstone

Seilo and Kris surfaced an odd case that looks related. CID 36751576 has one recurring donation via Adyen. Civi shows four settled donations for May:

Thanks Damilare

Refunds from the script in T365751: run refund script for dLocal May 23rd also seem to be missing from Civi for the lack of these audit files.

script run by @jgleeson - thank you

One more from today:
cid=63845570 VXQMX5TH3SPTS5X3 (refused at Adyen)
cid=1993497 VXQMX5TH3SPTS5X3 (refused at Adyen)

Azubuike at Adyen just replied:

Thanks, Damilare

And if it's not too big a lift tech-wise, depending on the number of donors affected, scanning to filter out any who may have switched to PayPal or alternate methods after trying dLocal might prevent us from double-charging people.

@Damilare, @SBorriello has a Zendesk donor who I think was affected by this - they have multiple recent unsettled donations in ZAR, so just to check, can we settle only the most recent attempt if a given donor has multiple attempts at Auth?

Thank you, @Damilare

@Ejegg I've been thinking about how Poliane and I generally perform fraud refunds at the PSP consoles rather than directly in Civi, and wondering whether we could rely on the data in the Master Refunds spreadsheet (where refunds are labeled by reason) in order to use the data to see how our filters are doing? That would save us the step of having to label each refund in Civi. Maybe this Task is not as necessary as it was in 2016? OTOH if something like the Gr4vy integration would enable refunding from within Civi then that would add to the value of this feature request. What do you think?

Thanks for the info @Cstone. Adding folks for visibility.

Thanks for adding these examples, @AMJohnson. We continue to see tickets where these accumulating "outstanding balances" are donor pain points. I mentioned this case to @XenoRyet this week and he mentioned that this problem might connect to other actions we would like the PayPal API to do for recurring Paypal cancellations in T361636: ask Civi to use PayPal's API when humans cancel recurrings & T361243: ask Civi to use PayPal's API when canceling recurrings due to chargebacks.

Thank you @Cstone

thank you for this Task @AKanji-WMF

Thanks, @Damilare for the news

thanks @AKanji-WMF

Thank you @Damilare

I also found a refund from 12/7 that's not in Civi, 199183456.1 aka ADYEN TSXXF3XC2GHSD272 from cid=62012942

Thanks @jgleeson for Donor Relations it's helpful to have address data for searching. Short term adding country is fine, though I think the question of prioritization / scope of the issue touches more stakeholders (does email team use that data for segmentation? etc).

Many thanks for the context and the patch, @Ejegg

Ah got it, thanks for the helpful info.

@EMartin @jgleeson because "Typed card number doesn’t match card brand” is such a specific message, would it be worth asking Adyen if / how it originates from their part of the donation flow? Or do we think this might be generated from our part of the form?

There is one more:

I can confirm that those 4 ^^ are the most recent - we'll keep an eye out for any new ones.

Thanks @AKanji-WMF I'm checking with the DR team for any examples newer than Monday's additions of 192862907.1, 193222306.1,
192862907.1, and 193358067.1

Oct 1 Invoice ref. 191104808.2|dup-1696263975
Sep 30 invoice ref. 191104808.2

That's welcome news, thank you @Ejegg

cid=49363433 187546189.1 ApplePay Visa onetime Aug 3rd

Thanks for the extra improvement + the headsup

Awesome, many thanks @Eileenmcnaughton

Recent breadcrumbs:

Thanks @Cstone for adding the donor and making the followup Task

Thank you, @Cstone

Thanks @EMartin and all for the clarifications, and +1 @greg

@Pcoombe there are 967 in MXN via Adyen this week

Thank you, @AKanji-WMF

Thanks, @Damilare

I was looking at CZK contribs for this month and 18 one-time donations got this error too. Samples:

Thank you, @Cstone

After checking with @krobinson we decided to proactively refund the duplicates - thank you, Adri!

I sent these transactions to Adyen support, and they confirmed that similar notifications are being sent for the manual refunds + the API ones. Below are two notification logs they sent. This task is not a huge priority, so we can close it as below the threshold of need, unless it's a simple thing to change.

For sure, @AKanji-WMF fine to close

Great question, @Ejegg

No longer a thing.

Ok to decline, for sure, thanks for checking @Eileenmcnaughton

For sure, some update or patch helped with this!

I'm thinking this might have been from a time when the donor data delivery process was going to provide the donors with a direct d/l page.

We didn't see the issue recur with the EoY TY email sends for 2021 + 2022, so the one-off theory makes sense. I'm fine w/closing unless there's any other reason to keep it open @Eileenmcnaughton