2f7b22522e2454166b54de3b1b0ea0e4ba6d517306c46f5c64cbba62ee4c8c246e0c4e02943aa24414971bfc9c1be4a7321678d9496bf96b3db5591bb58956b9
sha512
2f7b22522e2454166b54de3b1b0ea0e4ba6d517306c46f5c64cbba62ee4c8c246e0c4e02943aa24414971bfc9c1be4a7321678d9496bf96b3db5591bb58956b9
sha512
Thank you, Lars for confirming the links will have the same form.
Thanks, Lars, I was thinking more in terms of the URL that we will see, some will have the CID and some not, is that correct?
Thank you for the information @Lars
Not the same person, so no merge.
Thank you @Dwisehaupt I'll confirm with Laura and if that's her, will merge the CIDs.
Marc at Trustly confirmed Monday, "the change has been finalized. No users will be able to pay via MEC."
Thanks, @Lars for the update. I'll send a followup note to the donor.
Do we know if we're more likely to either deprecate MEC and treat recurring Trustly from banks not on the list as an unaccepted method, OR build the flow so that these transactions generate tokens? Zendesk tickets are accruing.
thank you @Pcoombe
@Pcoombe Lindsay has one donor who received donate_interface-error-msg-payment_service-ec (for a Stripe donation on June 27 that ultimately succeeded)- is it safe to assume this was a one-off error in the donatewiki flow?
The donor followups are all set. Two had no donations after the donor attempted the cancellation.
I can refund any donations from that list that processed after the cancel date
One from July 7:
One more Venmo straggler without PII from July 2:
@AMJohnson detected a cluster of tickets since April that are receiving the error message ""Please enter a valid credit card number for one of the accepted credit card types". We're unable to replicate, and will ask donors for their specs (might be related to Firefox's Enhanced Tracking Protection or autofill) but this is the kind of error triage that we hope the list from this Task will enable.
Thanks, Lars, sounds good.
If you can that would be great, and we can make a point of opting them out as we go, going forward. Thanks @Lars !
Thanks @Lars The known fraudster checkbox was a feature request to help prevent us from duplicate-researching the sneaky edge cases who use plausible aliases and persist over time. It can be helpful when determining whether someone is a fraudster or a legitimate donor, but you're right that 139 is not a lot of examples. As such I'm fine with closing this Task, as that volume won't affect email rates.
The only other case I can think of that might be worth tracking, we get chargeback alerts from Ethoca (and Adyen), so maybe one additional checkbox could be 'Chargeback Alert'. We can already use Zendesk macro tags for the range of refund reasons.
Thanks, @AKanji-WMF The new ability to select transactions from a list for bulk refund is excellent, and allows agents the flexibility we need, so we might be good with this.
two more donations from Finland made using Apple Pay via the App:
Thank you @ppenloglou, I appreciate the hyperlink, and the draft mailing looks good.
Can we repurpose this Task into a followup email inviting donors to create new donations?
Excellent, thank you @Ejegg !
Thank you @Ejegg Where does the Added By info live? I recently refunded CID 70442458 and don't see the refund in Activities, how would another agent be able to tell it was me?
Reopening this Task per prior comment
Demo-ed this at the DR team meeting today, and this was welcomed with much delight and wiki-love.
Thanks, @Ejegg for confirming editability and all the available methods.
@Ejegg this is really a helpful tool, thank you. Some followup questions:
Thanks @Ejegg this touches on a few wider workflows with recurring cancellations, so I'm adding more subscribers for wider input.
Thank you for confirming, and the filter option. When a great tool gets even better, that's a good day - TY.
Thank you @Lars The one line per transaction in the export is great.
Thank you so much, @Lars
Excellent, thank you @Lars
Great, thank you @Lars
Closing this, but if we get confirmation of something buggy from the donor may reopen.
Thank you for looking into this @jgleeson. Their card attempts at Adyen are showing the error Revocation Of Auth (Revocation of authorization for recurring or installments) so I added the card to the trust list, maybe that will help them donate via that method.
If there are multiple error codes, DR team would appreciate any documentation on them if we can use them to guide donors.
Thanks, I'm happy to tinker as needed ;)
@Lars that's plenty for my needs! And yeah, I never use the xlsx option. Thanks for fixing this.
I refunded the non-Civi duplicates from Order ID: 245232778.1, Order ID: 245240435.1 & Order ID: 245246263.1
Thanks, @Cstone
I got one of these "Error sending cancel request to processor: 11552" messages today from https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=5991045 today, as a data point.
Thanks, @Ejegg for confirming that. It might make sense to have the code apply to just chargebacks.
If a donor requests a refund of their initial recurring annual donation at PayPal (via ordinary request to PayPal, or via dispute at the Resolution Center), will Civi likely know to cancel the recurring so that we don't try to charge them the next year?
re: the two unrefundable dLocal's at Gravy, Love replied that "The refund was rejected because the account is closed." I've asked them if they can improve their process and update the statuses of these transactions.
@Eileenmcnaughton do you know, would the work in this Task enable (or relate to) Civi to cancel annual recurring PayPal donations if the first donation is charged-back via the Resolution Center?
Thanks, Eileen - I refunded 7cf1f269-aa40-480a-afcc-c080b0ac07aa and will send the donor a note letting them know.
I have escalated the unrefundable dLocal's from the Feb 12 comment to the Gravy tracker.
@Eileenmcnaughton if looks like this donor succeeded the next day via PayPal direct. I can either refund the Mastercard donation after it reaches Civi or before, whichever makes the most sense. I added this to the Transaction Log in the Gravy tracker as well.
Two more recent frauds that we're unable to refund at Gravy, this time from dLocal. The statuses seem to agree between them, but Gravy yields an 'unable to refund' message' and no option to void them.
Many thanks, @Eileenmcnaughton Maybe going back to June 1 2025 might be good to establish clean numbers for the fiscal year? I'm not sure of the $ amount involved, or the tech load to do so. @EMartin do you think it would matter for reconciliation purposes to go back farther?
@RLewis yeah, this transaction stopped at Gravy at Declined: suspected_fraud, so we never received the funds.
Many thanks, @Damilare
Per thread in Slack, a recent inadvertent manual settle at Adyen reached Civi the next day, thanks to recent work by @Eileenmcnaughton
Sorry for my confusion on this, the chargeback was from early 2025 (which explains the search limitations at the consoles).
| Zendesk ticket # | Date reported | CID | Country | Tech Specs | Donor comment | Url? |
| 1812300 | 12/26/2025 | n/a | EN6C | n/a | Error reference: 243636120.1 | n/a |
| 1804679 | 12/17/2025 | 48367213 | US | n/a | Error reference: 242696558.1 | email4 |
fixed per Slack thread, many thanks!