Thanks for reporting this @jgleeson, I did some log diving on this and it seems we are not cancelling trustly recurrings that fail due to the donor cancelling the subscription from their bank. Unfortunately this implies we have some more contributions in Civi from the recurring charge job that actually failed because of the Gravy - Trustly flow. @Cstone dropped an example here of such scenarios where a contribution is recorded on Civi because the initial status was capture_pending but eventually failed with cancelled_payment_method.

Gravy just mentioned that they do not get a notification when a payment method is deleted on the Processor, as such they'd only know about a cancelled payment method on the next recurring charge. This affects our Trustly recurring as we do not cancel the recurring subscription when a payment method is cancelled and subsequent charges yield the error "Split token is invalid".

@Cstone can we move this to closed as its working according to design.

Thanks for highlighting this transaction @MBeat33, I can see the Donor details in the PayPal's response on Gravy but not in the Gravy's response. I've reached out to them with my findings, you can follow the conversation on this slack thread.

Having looked at this, I can see the last discrepancy for contributions from the Recurring flow was in October (2025-10-28 12:10:01) and for Direct payment wiki flow was back in September (2025-09-10 16:39:19). I also attempted some test transactions on my profile (one time and recurring charge) and I noticed the last contribution currency was updated on the contact record. Perhaps this might have fixed itself for the DonationQueueConsumer flow.

I scanned the logs for the error string that is returned after sending the request, since this are all direct connection Braintree, I used this grep command to search for the failures in the logs:

Hi @AKanji-WMF, yes we can close as all active recurring plans have been exported from Fundraiseup into Gravy.

That's interesting and it could be related from what I've seen online. We could experiment with adding this update to the UserAgent as recommended in the docs to see if it makes any difference, otherwise we might need to take down the GooglePay option for iOS.

Hi @Tsevener, thanks for looking into this. Yes, I think the second error is possibly a rate limit, I was able to debug the request using a proxy and saw the empty response as well. The error displayed on the page made it a bit confusing, as I couldn't tell if it was evidence of the other issue we are looking to debug.

Chaos crew completed tasks

• T409211: Validation for AmEx BINS in India - Validation for AmEx BINS in India
• T409234: Fill Phone source when importing from Acoustic - Fill Phone source when importing from Acoustic
• T409744: Benevity import not showing errors - Benevity import not showing errors
• T410566: Clean up supplemental address 1 data in CiviCRM - Clean up supplemental address 1 data in CiviCRM
• T410095: recent Gravy-PayPal contribs without PII in Civi - recent Gravy-PayPal contribs without PII in Civi
• T410561: Country mismatch between Civi and Acoustic causing incorrect email sends - Country mismatch between Civi and Acoustic causing incorrect email sends
• T410669: Direct Mail Activity Import File - November 2025 List - Direct Mail Activity Import File - November 2025 List
• T410789: CIDs in November Direct Mail list are not found in Civi - Cannot import Activity Update - CIDs in November Direct Mail list are not found in Civi - Cannot import Activity Update
• T410734: Gr4vy card input fields have grey background on mobile - Gr4vy card input fields have grey background on mobile
• T410169: Apple Pay issues 11/14/2025 - Apple Pay issues 11/14/2025
• T411011: Omniactivity "Legacy Giving Signup (Wiki domain)" failures - Omniactivity 'Legacy Giving Signup (Wiki domain)' failures
• T411272: Trustly Access for DR team - Trustly Access for DR team
• T411279: Allow No Value / IS NULL is SearchKit for booleans - Allow No Value / IS NULL is SearchKit for booleans

Feature team completed tasks

• T410071: Report number of rows in Unsubscribe export file to prometheus - Report number of rows in Unsubscribe export file to prometheus
• T410454: Remaining discrepancy in generated audit files - Remaining discrepancy in generated audit files
• T410342: Address audit failing to remove file due to not seeing fee rows as found - Address audit failing to remove file due to not seeing fee rows as found
• T409590: Add donation link for restart recurring - Add donation link for restart recurring
• T388755: Implement recurring donation amount modification for donor portal - Implement recurring donation amount modification for donor portal
• T388753: Implement recurring donation monthly-to-annual conversion - Implement recurring donation monthly-to-annual conversion
• T410770: Add autocapitalize attributes for address inputs - Add autocapitalize attributes for address inputs
• T409576: Prevent [ change email ] from breaking onto multiple lines in email preferences centre - Prevent [ change email ] from breaking onto multiple lines in email preferences centre
• T407453: Donor Portal - Problems Logging In Flow - Donor Portal - Problems Logging In Flow
• T411031: WP25 Payments Wiki - Localization (fr, pt-br, es-419) - WP25 Payments Wiki - Localization (fr, pt-br, es-419)
• T410737: Remove Fundraiseup from donatewiki CSP - Remove Fundraiseup from donatewiki CSP

Thanks @AMJohnson I was able to reproduce this behaviour on my iPad has described, looks like it only happens on the portrait mode also. A similar appears on Payments. We might need to add more specific rules for iPad-type screens to ensure the payments page width stays within the viewport, @Pcoombe thoughts?

The update on this is that Gravy has been able to fetch Donor Details for one time transactions but the last test for recurring transactions was unable to get the Donor's details. They have made some changes and we are due for another round of tests.

Thanks for the quick fix @Aklapper. I'd have to wait for the deployment as I'm getting this error with the work around through the wiki phab api:

Awesome, thanks! Yes the last time I successfully ran the script was in late June. The 200 response made it a bit hard to notice also when I began using it.

Thanks @Aklapper, I just made another attempt at September 10, 5:47 PM UTC. Here's the line in the script where the request is being made.