| krobinson | |
| Oct 5 2023, 2:17 PM |
| F37988056: image.png | |
| Oct 5 2023, 8:41 PM |
| F37987301: Screenshot 2023-10-05 at 16.15.02.png | |
| Oct 5 2023, 2:17 PM |
Donor CID 43618550 / Zendesk #1368406 had the second installment of their recurring donation debited twice.
The donation was set up on 09/01 and installment #2 was billed on 09/30 and again on 10/01. There are no duplicate recurring donations set up, and both charges have made it to Civi.
@fr-tech. I see ~400 double billed donors from 9/30 and then again on 10/1. It seems to be isolated to PayTM/UPI recurring in India. I will raise this with Dlocal as well but could we have run a recurring file twice? Can we run a reversal or refund file to back out the duplicates? Examples attached:
I think there was some time math issue on our end where we didn't calculate the next_sched_contribution_date right, looking into this now.
cid=43618550 and recurid=1595496 which started on 2023-09-01 08:15:00 had next_sched_contribution_date
Initially 2023-09-30 00:00:00
then 2023-10-01 00:00:00 (How did it end up here?)
Then that was charged again on the 10/1 and now it's 2023-11-01 00:00:00
For refunds we don't have the script made yet task here T334311: dlocal refund and script to batch refund csv files
yeah, @Cstone will be working on that today as that would probably be faster than clicking around for those affected.
Looks like the bad calculation setting the next date to 10/01 happened during the recurring charge job for that row on 09/30, so that narrows down the places to look in code.
Change 964070 had a related patch set uploaded (by Ejegg; author: Ejegg):
[wikimedia/fundraising/crm@master] Calculate UPI next charge from one day later
Change 964074 had a related patch set uploaded (by Ejegg; author: Ejegg):
[wikimedia/fundraising/crm@master] UPI: stop setting early next_sched_contribution_date
Change 964077 had a related patch set uploaded (by Ejegg; author: Ejegg):
[wikimedia/fundraising/crm@master] UPI: cycle_day must match next_sched_contribution_date
Have these refunds processed? In Civi both still show as live, thanks for confirming once they're done! We have a couple of donors waiting. I can refund manually if not, but I think that may lead to duplicate refunds, so I'd prefer to wait for the script.
cheers!
@krobinson I just deployed the refund script and ran specifically the donor mentioned in this phab. I'll work on refunding the bigger bunch next.
Thank you @Cstone.
Kristie is out for the rest of the week but I will confirm this refund with the donor today. Thanks again.
Okay I ran the script to refund 452 more. I left the most recent charge alone and refunded the ones made on 9/30 as they should have been charged on the 1 to begin with.
I'm not seeing them immediately show up in the dlocal console but you can find the refund by clicking on a 9/30 payment and then at the bottom of the screen that pops out from the side.
Change 964074 merged by jenkins-bot:
[wikimedia/fundraising/crm@master] UPI: stop setting early next_sched_contribution_date
There were 4 donors that had this situation set up for october 31, I manually fixed them to go to November 1. That and when the above patch was deployed should stop this from happening again
Change 964077 abandoned by Ejegg:
[wikimedia/fundraising/crm@master] UPI: cycle_day must match next_sched_contribution_date
Reason:
Used Ie07ba6ec2811ff737d381a2d3d7c83ac0c8ece7a
Change 964070 abandoned by Ejegg:
[wikimedia/fundraising/crm@master] Calculate UPI next charge from one day later
Reason:
Used Ie07ba6ec2811ff737d381a2d3d7c83ac0c8ece7a