Page MenuHomePhabricator

CiviCRM interface for repairing damaged recurring contributions
Open, NormalPublic

Description

Performing this stuff from inside of Civi would be a big win, because it gets rid of the trust and intentionality issues with responding to external information. For example, let's run GET_ORDERSTATUS on questionable charges, which may have been partially processed, and put those transactions into some kind of manual intervention required state. We'll give donor services a button to settle status 600 charges, which will SET_PAYMENT, create the contribution record, and increment the effort_id as usual.

I can't get myself comfortable with doing this totally automatically, cos there's the danger of runaway train charging people's subscriptions due to bugs.

Another possible approach, which makes me a little queasy, is to trust whatever comes in through the nightly audit file, and if the effort ID is equal to or greater than what we think it should be, we increment our effort id counter.

Event Timeline

awight created this task.Aug 24 2015, 6:53 PM
awight claimed this task.
awight raised the priority of this task from to Normal.
awight updated the task description. (Show Details)
awight added subscribers: Aklapper, awight, MBeat33, atgo.
awight updated the task description. (Show Details)Aug 24 2015, 6:55 PM
awight set Security to None.

Thanks @awight - would this Civi button apply just to damaged reccurrings at status 600, or to any status 600 we needed to settle?

What's the marked difference between doing this in Civi vs. in the GC console?

@MBeat33: It would be difficult to have it apply to non-recurring status 600s, because those aren't in our system yet. We could have a freeform field for order ID, I suppose. Is this something that would be useful to you? If so, can you explain a bit more about the use case?

@atgo: The difference is that we've got to do two things at once, * clean up incomplete charges in Civi and get the subscription back into a usable state, and * make the settlement happen. If the settlement is done from the GC console, it seems tricky to apply that information to Civi. Not impossible, though, so I'll have to look at the options more carefully. At this point, I mostly want to understand whether this would be helpful for the Donor Services workflows.

@awight, from DS's end there's no need to build it so that it applies to non-recurring 600s, I was just checking to see if/how/when we'd use it. Likewise if the first instance of a recurring donation needs to be settled, we'd still do that at the processor's portal?

I am not sure how often we'd need to use this button, so what is the process for doing this manually in Civi? Is that something that anyone with Civi access can do?

I don't think there's a way to do this from the Civi web ui--recurring contributions aren't very well supported. There's no way to create the new contribution and associate it with the subscription, nor is there a way to increment the effort id.

The problem is simpler than I thought--I'm making a change to the recurring charge code so that the default behavior is to resume half-complete transactions. That will prevent us from having this problem in the future, because the second day's job will complete any status 600 failures from the first day.

Once that change is deployed, we need to reset the failure retry date for the affected transactions. That could be the responsibility of a CiviCRM page, with a textarea for listing order IDs to reset.

Be careful to change the failure retry date and nothing else. If we have to change subscription status, there's a chance of accidentally charging twice in a month. Don't let that happen.

atgo removed a subscriber: atgo.Mar 30 2016, 10:06 PM
DStrine removed awight as the assignee of this task.Jun 22 2017, 9:06 PM
mmodell removed a subscriber: awight.Jun 22 2017, 9:33 PM