Wed, May 27
This is done!
Tue, May 26
Mon, May 25
Thu, May 21
@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.
Wed, May 20
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¤cy=INR&amount=500&country=IN&ffname=astropay-in
Tue, May 19
Mon, May 18
Fri, May 15
Thu, May 14
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.
Wed, May 13
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.
Tue, May 12
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:
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.
Mon, May 11
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.
Thu, May 7
Wed, May 6
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.
Tue, May 5
D*Local is already full redirect.
Mon, May 4
Fri, May 1
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'.
Apr 29 2020
OK, added the translation and pushed it to production.
Apr 28 2020
@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.
Apr 27 2020
It looks like there's a builtin php function that could help here: https://www.php.net/manual/en/function.preg-grep.php
Apr 25 2020
Apr 21 2020
Apr 16 2020
Apr 15 2020
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'.
Apr 14 2020
@EMartin Thanks for bringing this to our attention!