Hi @krobinson, @AMJohnson , @EMartin and everyone else following! We just deployed the iDEAL 2.0 changes to production. The first time I loaded the form it took ten seconds or so (I think for the payment method lookup call we make to Adyen). On subsequent loads our name/email form loaded rapidly.

Update - looks like last year's stats are the outlier. Looking at July for 22-23 we see similar numbers to this year.

Some of those new ones are still a bit hazy on where the process breaks - at least one says PayPal is not working, which would mean they likely can't load paymentswiki at all. But at least one mentions filling out their name and choosing a bank before the process fails. That could point to iDEAL 1.0 problems. We have some changes in review to implement iDEAL 2.0, but nothing deployed yet.

OK, I've just updated the trxn_id on those two recurring subscriptions and re-sent the damaged messages from July and August.

Hi @AMJohnson, they should indeed be 'cancelled by merchant'. Here's one we cancelled this morning after not getting any donations since May 22: https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=60859723&selectedChild=contributions

Looks like there are just 2 subscriptions getting these issues - maybe just update the data to match the subscr-id in the IPNs

So the big difference with payments-wiki is that we only serve it over IPv4, not IPv6 - we might need to revisit that decision.

In T372571#10077632, @krobinson wrote:

It feels like this is happening in the handoff from donate.wiki to payments.wiki and I don't feel like I understand if this is an Adyen issue or a WMF issue.

In T372571#10075275, @EMartin wrote:

@AMJohnson Adyen is saying they cannot troubleshoot and think the matter is something on our end since it isn't contained to only iDeal but involving Paypal and Apple Pay as well.

Hah! Nice catch, @Pcoombe.

This is deployed - now we watch for failmail!

I'll try to get a patch ready to add more fields to contribution_extra (see T372468: Finalizing Gravy fields in Civi)

@MSuijkerbuijk_WMF this is available for testing at

@MSuijkerbuijk_WMF this is available for testing at

Hmm, we had some code to truncate before we tried to create the entities in the Civi API, but that code was removed in the big queue refactor. Maybe we need to add it back?

I reopened the original issue we filed for that: https://phabricator.wikimedia.org/T205316

New UI has the same issue

I had requeued the failed job using the damaged message interface, but since there was a nested array that interface broke it. We would need to update the damaged message UI to fix that.

I just checked recurring record statuses for all the failed rescue IPNs from this month, and they are all cancelled. Closing as done.

It looks like this year's banners have the 'already donated' link which I didn't see in one of the banners from last year. That link seems to set a week-long banner-close cookie rather than the hour-long banner close cookie set by the close button.

So this query seems to be focused on just the last entry in the log: I see a lot of

event.l[cardinality(event.l)]

OK, this script has been run. All were successful except for the ones that were already refunded or charged back.

@MSuijkerbuijk_WMF one more thing we'll need before this goes live: T371848

Waiting for DLocal to reply to an email asking about format to send state to API.

So we want a state dropdown for India, I guess. I'll use the list I found here if that looks good: https://www.drupal.org/node/2471497

The donation also seems to be recorded already, directly from the recurring charge job. We could also check whether the gateway_txn_id exists in Civi before throwing this error.

In T368155#10033082, @MSuijkerbuijk_WMF wrote:

Posting here the final variant we have discussed with notes on second screens too.
https://docs.google.com/document/d/121zeT8zm_odXcGwPA01FJIyvr7yw7kuGad-OAeiI3Vs/edit#heading=h.svp7ls6ziyoj

Screen if they click the 'No, but I'll set up an annual gift':

In T367594#10015679, @CDenes_WMF wrote:

Hi @Ejegg, are these counts of all time? Not time boxed?

Yep, those are all-time counts

@Dwisehaupt this might be a fr-tech-ops task. looks like the batch input screen might just post back a zillion POST vars (#_of_columns x #_of_donations). Do you have any concerns with setting that PHP variable limit higher in php.ini, to e.g. 2000?

@krobinson Here's what I can get for languages with a quick query on the contribution_tracking table:

select language, count(*) from civicrm_contribution_tracking where utm_medium='endowment' and contribution_id is not null and language <> 'en' group by language order by count(*) desc;

Sorry for the delay reviewing that merge! I've finished looking it over and smoke testing locally, and have given it C+2.

For a few years now, we have been running a daily job that marks any active PayPal recurrings as 'Cancelled' if they haven't received any donations in 90 days. We wrote that before we had the ability to connect to PayPal and actually cancel it on their end.

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