Issues resolved since Task was active

@AMJohnson had a donor reach out in Zendesk where it looked like we refunded both of the donations. I spot-checked from the Adyen Temp Table for Refund tab, and it looks like about 60% of the sample were refunded multiple times (we did not keep any of the settled transactions).

One other straggler, for which Dominic at Gravy has a ticket open. Zendesk 1659060 Merch ref 229591889.1 is still at Capturing status.

• reminder to cancel the recurring once it reaches CiviCRM

Hi @AnnWF the four transactions mentioned in the April 17th comment are not in Civi yet. The first three are at status Capturing, while the last one 229688953.1 is at status Captured. Just flagging so that the patch can include these too.

Christmas in April, thank you @Cstone. I tested this and Gr4vy found my CVV error just like you said. Awesome.

And, thanks too Amber for the suggestion that a letter prefix to the error code that designated the method, like

Thank you @AnnWF

@AnnWF Kristie is out until Wednesday, so I hope it's ok if I say that we should refund any duplicates that we have settled.

Many thanks, @AnnWF

Another example of a donation manually settled at Adyen, still at Capturing status at Gravy:

From a batch of 10 refunds on 3/31, two yielded Server Error messages and then moved to status canceled, but the reversals are not in Civi:

Either option would be great @jgleeson though I think once we switch over fully to Gravy, these edge cases should diminish in frequency (if that affects the demand for a button in Civi).

The donor in cid=30720151 had a pending donation manually settled inadvertently at Adyen, when it was a Gravy transaction. At Adyen it's at status Settled, at Gravy it's been at status Capturing since 3/28. Gravy IDs are b8c8be73-63ad-4bed-a013-52e914281943 and 229570312.2

One possible solution might be, is it possible to use Google docs to publish updates to Zendesk. Google Cloud says their "Zendesk connector lets you perform insert, delete, update, and read operations on Zendesk database."

Zendesk suggested https://developer.zendesk.com/api-reference/ticketing/business-rules/macros/#update-many-macros which "Updates the provided macros with the specified changes."

Thanks for the follow up and for making this Task, @jgleeson. Credit where due, I was escalating what @AMJohnson discovered.

Thanks for importing that stray from December 6th, @jgleeson. I followed up with the donor, all is set now.

Thank you @Ejegg

I have one straggler from Civi, cid=1276663 who started a recurring PayPal on December 6th. The initial donation never made it to Civi but January and February's did.

Many thanks @Damilare for the info re the 12 day manual settlement timeframe, I'll share that with the DR team. And thanks for the option to revise the limit to capture as needed, that should be a rare case.

Jake at Adyen said that the best way to pick up when new PaymentMethod variants are added is to receive alerts from the "New from payment partners" category of alerts:

227750668.1 reached Civi, thank you.

Thank you so much, @Damilare. I will mention to our Adyen rep that them adding methods without publishing them causes issues for us, maybe they can improve that on their end.

Also, does everthing on the /referrals list need merging? I exported the results and there were over 21k, but only 1930 were missing an email address in one of the columns.

Thank you. I sorted the referrals list by clicking the column heading for original donor -primary Email, which seemed to be the best way to isolate the ones missing email addresses. The first few I've tried yield this error:

Thanks @Eileenmcnaughton I hadn't seen those links before.

It looks like the # of CIDs without emails is 1930 from the /referrals list. The scale of this kind of snuck up on us and I'm wondering, what is the best way to fix this before the EoY recurring TY email goes out?

Another manual settle not in Civi:

One more straggler to watch for:
cid=65941722
GRAVY 0aa8d92e-9330-4032-baa9-aeae1289342b
invoice ref: 222175344.1
refunded at Adyen 12/31

We're seeing more donors affected by this, including donors receiving fundraising emails after they've recently donated. The donor experience is not great, and we anticipate the EoY TY email will be complicated for these people as well. @XenoRyet do you know whether this is likely to be resolved soon?

I found another one today that generated the error in Civi. PayPal let me cancel at their console. Just want to make sure that if Civi initiates another donation PayPal will not process, and just generally curious whether there's any way we can make these accurate in Civi.

@Cstone cid=54570476 is another one that we found through Zendesk contact.

Many thanks for documenting this @jgleeson and for pointing out the challenges to DR workflow. Beyond complicating the search process, we will definitely also see more bulk email complaints from recent donors, and potential confusion from recurring donors.

When refunding at the Paypal, it said "you have already refunded this" and yet still shows the transaction as Complete (& refundable), so this is likely an issue with Paypal's console? I will raise with our rep Scott.

Thanks @AKanji-WMF I'll close this as not needed

Once I get admin access, I will see if I can adjust this setting

@Eileenmcnaughton I probably should have phrased this Task as a question, like, 'If we do not already delete phone # when pressing Forget Me, can we add that so we can confirm that to donors?' Thanks for clarifying, and if I can close this please let me know.

I think 90 days would be a nice balance between giving donors time to update their method on file at PayPal, and sparing other donors the dunning messaging from PayPal for recurring donations that remain active without a method, thanks @Ejegg

Thanks Anil and Damilare.

dLocal's current explanation is that the funds were debited from the donor's bank but did not reach the payment processor. We've asked them to look into how any such transactions reach our CRM as settled donations.

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 (or the only-fails) 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