OK, the logic is deployed to make sure they all are tagged with the main org record for PayPal Giving Fund (3729480). I started using the 'Move contribution' action from the ... menu on the contribution list, to move the existing donations. I moved all the ones from this year. Do we need all the previous ones moved too?

We tested this a bit in tech talk yesterday and Eileen posted some feedback upstream: https://lab.civicrm.org/dev/core/-/issues/5340

Back to review for the createBuyer / getBuyer stuff

Hi @SHust , sorry, that was a recurring contribution I had set as cancelled with a batch update.

Could the jobs be late because the export is so big? We spent a few days recalculating everyone's segment and status, and that marked all the donors as recently updated. So we're exporting and uploading all the rows instead of just two weeks of recent donors.

Hi @SHust. So when a donor puts an existing email address into an RML form and we pull that from Acoustic to Civi, we just discard it rather than creating a duplicate.

Done

Basically we can get a CreatePaymentResponse that returns FALSE from isSuccessful but returns an empty array from getErrors()

hmm, any hooks we could subscribe to from within the exchange rates extension?

Hi @RKumar_WMF , none of these tripped our internal filters. Looks like all of them were rejected at dlocal or the issuer.

@Pcoombe We've discovered that Adyen doesn't actually support SEPA in all the places it should work - see the list of countries in their docs here: https://www.adyen.com/payment-methods/sepa-direct-debit

@RLewis we should probably add another bit of explanation on the segments page - we tag the donor with the first one of the segments that they match, going from top to bottom - since CID 22341086 qualifies as mid-tier based on the total amount, and also has an active recurring, we tag them as mid-tier since that is the first status.

@MSuijkerbuijk_WMF so we need to support both variants being live at the same time, one with an annual option and one with a different amount option?

So we will remove the option to add a monthly gift in a different amount?

OK, I think I got it - the cancelRecurAutoRescue fires on civicrm_post . If we can blank the rescue_reference as we set the status we should be able to avoid that code calling anything in SmashPig.

OK, this is live on production! There's a slight visual alignment issue but it seems to save the value correctly.

Changes have been made, and the pull request was just accepted!

We seem to be getting these already! @Eileenmcnaughton can this be closed, or is there more to do?

Oops, the queued updates are failing with this unexpected message:

Moving this to the pending deploy column since the renumbering should fix it once we do a DB-wide wmf_donor update in an upcoming maintenance window.

Locally I re-queued and re-processed the donations queue. The invoice_id with the suffix was correctly saved to the invoice_id column without the error. So what could be different about production?

Hi @LWadleigh it looks like the Endowment TY message only exists in English and Swedish at this point. You can add new translations here: https://civicrm.wikimedia.org/civicrm/admin/messageTemplates?reset=1#/workflow

The message has both order_id and invoice_id. The invoice_id seems to correctly get re-queued with the |dup-1234 suffix attached to the invoice_id but the order_id is unchanged. Perhaps somewhere in the refactor we stopped consulting the invoice_id message field?

I just tried locally by manufacturing a message with a different gateway txn id but the same invoice id, and the error handling seems to be working fine. It looks like it would still failmail if the requeue time had expired - checking on that for the latest instance of this error in production.

https://phabricator.wikimedia.org/diffusion/WMFR/

Please let's not add anything more to djangobannerstats! Maybe we can add the new pages to FRUEC?

I think we're getting the pending message sent now

The deletion has been running (one-by-one) in the background for a while, and there are just 2000 erroneous donations still to go. Should be done within the hour.

In T365519#9887219, @MBeat33 wrote:

@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.

@MBeat33 I made a group for all donors who got a TY email for one of the failed auths mistakenly recorded as succeeded:

Hi @MBeat33 actually a lot of the only-fail donors are CZ online banking donors. For that payment method (and iDEAL) we record the contribution as complete as soon as we see a successful authorization. I can just delete the contributions for now and get you a list of the CIDs with only failed contribs.

There are 31,528 of them, associated with 9,385 different recurring subscriptions. I've got all the IDs in a table so I should be able to delete the contributions without too much trouble. 68 of the contacts only have the failed contributions (including the CIDs in your list), so I'll clean those up too.

Oh wow, there are a lot of donations in Civi that shouldn't be there, since I deployed a bug on May 8th that treated failed authorization IPNs as successful. I've just deployed a fix so they won't be treated that way any more. Next I'll figure out just how many were mistakenly reported and how to clean them up.

All the things the current prefs center can control are being exported to Acoustic, and the other proposed bits linked here have been declined.

F9R3WD3NK967VXW3 was a retry - looks like we sent it from the IPN listener to Civi as though it was successful when the auth was actually failed. Looking into the logic.

In T361636#9875843, @MBeat33 wrote:

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

I had canceled at PayPal's console seconds before using Civi. Are there any special considerations when canceling Failing PayPal recurrings? We're generally canceling in Civi first so if my doing this out of order caused the message, it would be good to know. cid=32423726

Seeing more failmail from deadlocks in this job lately. Perhaps we could requeue them for processing via coworker?

@MBeat33 the PayPal documentation suggests that the same command we use to cancel the newer (_ec) ones SHOULD be compatible with the old S- subscription IDs

Can this new functionality be made to cover legacy recurrings, or will we still need to cancel-in-both-places if the donation lacks the _ec suffix?

OK, this is done! @SHust / @AMJohnson / @krobinson: The Civi UI's cancel subscription button should now be cancelling subscriptions in PayPal.

OK, this is back on production and the upstream patch is merged.

OK @AMJohnson , this should be fixed now. Thanks for the phab task and the screenshot!