We have recently moved some scheduled tasks to a new scheduling system in Sidekiq, where we accidentally passed in the top_up_id
for failed top ups that we wanted to retry. By passing the existing failed top up ID it meant that we were retrying a top up that was already in a failed state instead of initiating a new top up object. By retrying a failed top up it meant that the top up could never move out of a top_up_failed
state, but the payment was still attempted.
This failed top up had a new payment instance created for it that has overwritten the old one. This payment seems to be in an odd state of processing_payment
, and it's currently unclear whether a) that payment has been taken from the user without giving them a top up, and if so b) how we may give the user a top up without charging them again (possible solution: goodwill top ups) and placing the attached payment in a correct state.
There seem to be at time of writing 1,014 top ups