Mentioned in Gravy slack channel for visibility: https://wikimedia.slack.com/archives/C070F1DVBRN/p1787595063506599

Matheus Cruz  [2:24 PM]
Hello @stacy.burnett, I'm checking this one and will keep you posted

Response from Gravy: We confirmed that payment method 2bdccec0-e4ee-4397-9792-1897fe5b070c changed to a failed status on July 31, 2026 at 19:40:33 UTC.
7:13 PM
At that exact timestamp, we received a Webhook from Trustly indicating that the underlying authorization for this payment method had been cancelled. The Webhook shows the cancellation was initiated through Trustly's own consumer portal, meaning the action was triggered from the customer's side directly with Trustly, not from our system or the merchant.
7:13 PM
When we received that Webhook, our system marked the payment method as failed. Since that moment, we have no transaction logs for this payment method on our end. Please let me know if you have any questions on this.

@Lars - is there a way for us to assess how many people didn't complete a donation because of this error?

@SBurnett-WMF I'm not really the best person to answer that, anyone else is better situated for payments problems.

https://wikimedia.slack.com/archives/C070F1DVBRN/p1787595063506599

From Piero Piccini (the slack thread linked above): On the webhook: confirmed, no payment-method.deleted was sent. We don't emit a webhook when a provider reports that an underlying mandate or authorization was cancelled. That notification happens when the payment method at Gr4vy is deleted, for example via the delete payment method API endpoint

Our recommendation for recurring charges is to call GET /payment-methods/{id} before each attempt and proceed only when status is succeeded. That will prevent the failed attempts you're seeing against payment methods that are no longer chargeable. Doc: https://docs.gr4vy.com/reference/payment-methods/get-payment-method

On the June 17 transaction: that one traces to a bug from May where Trustly's stored credential could exceed a length limit in our database, so the payment method never finished storing and stayed in a pending state. We fixed the limit on June 8 and recovered what we could on June 11, but 2c42be9c-818d-4e5f-bf0e-e717aeb163dd and 9b422c52-e681-4276-b09e-49733a25b0b6 were not recoverable. They will not become chargeable, so they should be treated as dead and those donors asked to re-authorize. The third payment method, e87896a0-5f2d-48ef-839d-1b30d9e05408, was created after the fix, which is why it went through.

On how long "pending" persists: we currently have no job that clears payment methods left in a pending state for Trustly, so they can persist indefinitely. That is why you are still seeing May dates. These are not all from the bug above. The common case is a donor starting the bank authorization and not completing it, which correctly fails the transaction but leaves the payment method pending with nothing to reconcile it afterwards. I'm confirming with our engineering team whether the current retention behavior is intended. I'll keep you posted.

I think the actions for us from this information: could be:

Consider adding pre-charge status check to the recurring flow
Flag the two dead payment methods in Civi and trigger re-authorization outreach if necessary
Decide what to do with the Trustly methods while waiting for Gr4vy's answer - purge? pend? ignore?

Consider adding pre-charge status check to the recurring flow

Today we discussed in the team to move this conversation to a dedicated investigative task since the proposed approach from Gravy doesn't fix the underlying issue of the imminent charge being about to fail without us being able to prevent it. Since Gravy presumingly doesn't always send a webhook regarding a status change for a stored payment method, we would need to evaluate options and this requires discussions.

Flag the two dead payment methods in Civi and trigger re-authorization outreach if necessary

• https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=1969014: this contact has already an failed subscriptions already and activities show they got the failure emails (so we did already reach out).
• https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=69706921: this contact is still in the retry logic (status 'failing') but I think on Sept 1st their sub will be set to 'failed' and the automatic failure email will be sent.

Because of this I think we don't need to do anything manually for these users at this point.

Decide what to do with the Trustly methods while waiting for Gr4vy's answer - purge? pend? ignore?

For the purpose of this task (investigate and fix the errors affecting theses users) we learned that one of the two cases was traced to a bug from May where Trustly's stored credential could exceed a length limit in our database, so the payment method never finished storing and stayed in a pending state. Even if they came back with info on when the pending state should or may change, now we know that in theory this isn't probably communicated to us programmatically via webhooks. So how to deal with this would fall into the discussions in the follow-up phab.

Overall I think this phab can be closed since there is nothing we can further do for these contacts. To best prevent and/or improve future similar scenarios, we can and should discuss how to best deal with an active recurring contribution associated with a payment token we cannot charge. This is the topic of the follow-up task: https://phabricator.wikimedia.org/T436299