I think this is still a valid ticket - we use SmashPig to make Gravy API calls as well as other provider API calls, and it would make things easier if we had the error handling standardized in all cases

Hah, no, Gravy requires different params for different backends too and afaik doesn't have a programmatic way to tell us what fields are required before we submit. It would still be nice to have in SmashPig.

I don't think we need to do any updates to the SmashPig library for this - it's just configured in CiviCRM

This is implemented in the current email preferences center (only for a 90 day period) and sets an custom field on the email which is visible in CiviCRM and propagated to Acoustic as a 'snooze':

Just tested in production via Gravy and got an error. This was the raw response from the DLocal side:

"payment_method_flow": "REDIRECT",
"country": "CO",
"created_date": "2026-06-04T18:41:22.000+0000",
"status": "REJECTED",
"status_detail": "rejected_other_reason",
"status_code": "300",
"order_id": "7e02z9DuzBSAumGb4kQOTN",

Pros for DonationInterface:

• already has all the i18n strings and config
• easier to make logging look pretty uniform between different form layers
• fastest way to implement would be just to re-use donation submission API

We have some more of these lately, reusing this old ticket

The earliest ones started April 20th and have failure_count=3 so they would be canceled on the next failure. I'll reset the failure count for now.

I'm worried that all of the iDEAL recurrings that were started between March and when you added the IPN have not been stored at gravy. That's 74 recurring donations with a total of €1313 monthly value. None have been canceled yet. We could either try to get Gr4vy to do some kind of backfill or we could try to update our database to charge them directly via Adyen. That second option might end up with some funny-looking values in a few fields but I think we could do it.

OK, that other little fix is deployed. I am now seeing the refund activities under the donor's activity tab, e.g. this one I just refunded: https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=70449310

Probably rows still to clean up after the fix to T423638: Check on handling of payment-method.deleted IPNs from Gravy

Odd, you did that about 10 minutes after I refunded my test donation. I got an activity on the activity tab and that donor didn't. Let me see what's happening there.

OK, the merchant reference is now appearing on the refund form, and it's now creating an activity with the person doing the refund as the 'Added By' contact.

Again the SmashPig code looks like it's doing the right thing - when they give us additional_identifiers.payment_service_authorization_id and the backend processor is paypal or adyen, we return the auth ID as the backend_processor_transaction_id. If we're not reliably getting the auth IDs I guess we can go back to solving the problem in the CRM and payments-wiki layers, even though that means repeating the same logic in multiple places.

Here's what Gravy gave us back in this case:

I just sent 6 IDs with iDEAL failures from the last 3 days to the Gr4vy team on Slack.

Sadly we didn't record the raw API response in our job logs.

@CHudson-WMF oops forgot to tag you on that last comment

Oops, sorry, 19, 20 are the IDs in the local development environment - in production paypal IDs are 6, 7

OK @Pcoombe , all of the translations for those 3 messages have been restored to the production cluster.

Yes, it should work for Adyen, Braintree, dLocal, Gravy and PayPal direct.

OK, I've restored all the translations of those 3 messages. I merged it to master. Let me see if there's a good way to get those on to donatewiki this week without having to wait for the next automatic branch cut.

Sorry, @Pcoombe, I included that txt file in the list of sources for message names when I ran my cleanup script. I'll restore them now. There was one manual step in the cleanup process and that's probably where I screwed up.

I cleaned up all the ones that were obviously unused, besides the currency names. The error message keys are often dynamically generated and need some more scrutiny. We can do that scrutiny as part of T379197

@CHudson-WMF that sounds like the Adyen auto-rescue flow, where they retry a charge for us over a couple weeks. We only activate that for recurring installments, and only for those charged directly via Adyen. The 'Start' activity means that a donation failed (for a retry-able reason, e.g. low balance) but has entered Adyen's rescue flow. The 'Success' activity means that they were able to get a successful charge.

This is done for Gravy and Adyen-direct. Could still be done for dlocal.

Instead of a separate action, maybe this could be another change to the cancel modal? e.g. when you select 'unintended recurring' it will add a checkbox that by default refunds all but the first donation.

OK, this is ready to use. The one caveat is that if you try to refund more than 25 donations in a single batch, it will send them to the background job runner which we haven't quite gotten working for refunds in production.

Looks like main still doesn't have a way to switch off cert validation for development, so we WILL still need the overlay mount to turn it off.

Lars' patch to fix the permissions errors under coworker seems to be working, but we're getting new errors under coworker.

Sadly, they still haven't added calls to programmatically download reports from the marketplace web services endpoint. I gave up on my merge request to the original SDK after a couple years of rebases and just left smashpig pointing to my fork. I guess we'll just remove Amazon Pay support till there is enough donor demand.

Just found another issue with the deployed code while trying to test Lars' coworker patch: when I select 6 contributions from searchkit results and select 'refund' it posts the id list but the form doesn't load. It kicks off this killer query (note no filters)

Oh hey, I can close that php-queue issue - https://github.com/CoderKungfu/php-queue/commit/2c47686c20df3d1035243ebf57d426aa68b51195 fixed it last year.

Hah, looks like it's time to remove the old Amazon Pay support.

This is deployed, but refunding more than 5 (via coworker) is currently failing with permissions errors.

Let's revisit the idea of sending emails via a queue rather than a batch lookup: T172300: Spike: should thank you mail send be a queue consumer?

Hi @Jdforrester-WMF I think the plan for the fundraising cluster is to go to trixie and 8.4 in a couple of weeks, so that's what we're targeting first.

I deployed the CiviCRM patch to handle payment tokens in subscr_cancel messages yesterday, and deployed the SmashPig patch to send them that way today, so hopefully we should stop seeing the 'payment method not found' failmails from Gravy/PayPal recurrings by this time next month. There is one follow-on patch still in review that will stop special-casing the contribution_recur.trxn_id for gravy/paypal.

OK, I've added another commit to the MR adding a redo button. It seems to work well in basic testing. After making multiple changes then undoing them, you can redo them, at least until you do any edit that is not an undo. Any other edit stops you being able to redo.

Hmm, it would certainly be cleaner to have a real hook that other extensions could subscribe to. Let me see if I can add one of those.

OK, the current MR seems more reliable than the version I had yesterday. I guess we probably want a redo button as well?

A Campaign Mixin should be fine to use - those are not deprecated. The drawback of the wgCentralNoticeMaxCampaignFallback hack is that it will prevent us from recording a reason that the banner was not shown, so our pageview / impression ratio will be off.

I've got a work in progress up on this branch: https://gitlab.wikimedia.org/ejegg/centralnotice-banner-editor/-/tree/undo . I think I need to re-evaluate the approach to tracking current state vs state-from-undo after taking a little break.

Update: @MHorsey-WMF and @Oyelola_Victoria have made the tool available at https://centralnotice-banner-editor.toolforge.org/ . The current workflow involves copying generated code to the CN banner admin page. @Oyelola_Victoria mentioned that translations are on the TODO list. Would integration with CentralNotice be the easiest way to get that? @Pcoombe mentions a benefit of it being hosted on toolforge and not in CN is that it's possible for non-CN-admins to design their own banners.

Oh right, we're getting the landing page concatenated into the utm_source (wmf_source) from upstream

The third part seems to be ignored at the consumer, so we just need to send landing_page separately

I think we can re-use all the Civi-level logic from the Adyen autorescue to work with the gravy-drenched version. We would need to do at least this much on the SmashPig level:

• Update our request mapper to send rescue options on recurring charges (where the backend is Adyen), e.g.

"connection_options": {
      "adyen-card": {
          "autoRescue": true,
          "maxDaysToRescue": 5
      }
  },

• Update our response mapper to indicate when the charge has entered the autorescue flow and add an identifier
• Implement the cancelAutoRescue function for Gravy and mark it with the interface
• Add failure IPN processing to send the appropriate message to the queue, like we do with Adyen in CancelRecurringAction
• (might need a small CRM change): when a successful autorescue message comes in, get it into the donations queue and ensure we clear the autorescue ID. Need to see if an autorescue IPN is any different from a normal capture IPN.

One big thing to resolve came up in a meeting today. We currently have a clear dividing line between the site where our general privacy policy applies (main cluster + donate-wiki first-step forms) and the site where our donor privacy policy applies (payments-wiki). This makes it clear exactly when we can load the third-party scripts that are needed to render a button for Apple Pay / Google Pay / Venmo that responds immediately.

Thanks @RKumar_WMF ! I had mis-named the payment instrument option in Civi at first. I forgot our convention with all bank transfer type methods is to prefix the name with 'Bank Transfer: '. I have just fixed it and pushed the donation through the queue again.