This is done!

@EMartin we just want to make sure we don't send donors through the 3DS flow inside an iframe. So if Ingenico chooses whether to show the 3DS flow instead of us choosing on our side, we'd probably want to give all donors the full-redirect experience.

Hi Evelyn, that looks just like the logo we're already using: https://payments.wikimedia.org/index.php?title=Special:AstroPayGateway&appeal=JimmyQuote&payment_method=bt&recurring=&uselang=en&language=en&currency=INR&amount=500&country=IN&ffname=astropay-in

The payments-wiki headers still don't include cache-control. Reopening.

@Aklapper donate.wikimedia.org is a production-cluster wiki that hosts fundraising-related landing pages, thank you pages, and first-step donation forms with suggested amounts. The donor can choose an amount and a general payment method (card/paypal/bank transfer) and is then redirected to payments-wiki.

Deployed a fix for the underlying problem! If we don't see the errors for another few weeks we can revert the debug logging patch.

To test the audit processors you can also use the files from the unit tests. Set the log path to point to your local test dir <crmRoot>/sites/all/modules/wmf_audit/tests/data/logs/ at page <civiHost>/admin/config/wmf_audit/configure and set the incoming audit dirs to appropriate subdirectories of <crmRoot>/sites/all/modules/wmf_audit/tests/data/<gateway>/ under the gateway-specific audit config pages:
admin/config/wmf_audit/ingenico_audit
admin/config/wmf_audit/astropay_audit
admin/config/wmf_audit/amazon_audit
admin/config/wmf_audit/adyen_audit

I made a few changes to try to get the initial c_t rows set up consistently, but they didn't seem to do the trick. I guess we want to have the initial contribution_id set on the row, but I'm not seeing where that was done in the tests before this change.

I looked at it, and we don't actually install csv-parse - it's just a devDependency of one of the things we do have installed. We've seen a few false alarms like this because of checking our node_modules into git. It's funny to see a bot conversation like that though!

The last patch added some logging, but it didn't fix the problem. I was leaving the task in 'doing' till we got another one with some more diagnostic info to help reproduce the issue.

All set. I deployed this directly to production since it was a one character change.

It would be nice to have a generalized way to multiplex any of the queues defined in our config yaml files.

D*Local is already full redirect.

Timely question @Reedy - this extension mostly just manages a single connection string at this point, and we're hoping to obviate the need for it later this month. So pretty soon we should be able to 'finish this one off'.

OK, added the translation and pushed it to production.

@MBeat33 if they're at 'settled' in the console, I'd consider that definitive and that we should refund all but one.

OK, the ratio of those 'buffered' warnings to total payment attempts has been more or less constant over the year to date at about 1 in 3, so there's no spike in that particular problem. Will look at the rest of those attempt IDs and also at iDEAL IPNs in general to see if we're getting the notifications we expect.

Looking for the first attempt ID in the logs, I see neither a return to payments-wiki nor an IPN message confirming the payment capture (there are logs of the attempt initialization on our side and of an IPN message confirming the authorization). The return and the capture message are the first two places we can send the donation to Civi.

It looks like there's a builtin php function that could help here: https://www.php.net/manual/en/function.preg-grep.php

Notes from a tech talk where we discussed potential alternatives to deploying a file as the data source: https://etherpad.wikimedia.org/p/fr-tech-talk

OK @MBeat33, 'Completed' is now showing as 'Active' again in Civi.

I think I know what this is - 'Completed' to core means a recurring contribution is over and done with, but we had been using that status to mean 'OK' and still in process. We should be switching the status to 'In Progress' after we charge contributions. Let's check to make sure new records aren't being created as 'Completed', and reinstate the core hack that makes 'Completed' not show up as 'Inactive'.

@DStrine I need to deploy a patch (which @mepps and @Cstone are currently reviewing), then I'll turn the recurring charge job back on.

@EMartin Thanks for bringing this to our attention!