#brayden-help
long spade
I gotchu
hanzo gave a brief summary of where we were at in that message that's linked
It was kind of determined that the way we cancel our subscriptions is super out of date and really convoluted.
It would be really nice to understand the proper way we should go about that but I think we have a couple of business rules that might stop us from using the most logical and easy methods.
steel steppe
Catching up now
It looks like the issue is with /v1/invoices/upcoming API where you're trying to compute the balance transfer
long spade
Yeah, right. We've got to do the balance transfer because if we don't, the refunded amount ends up on the next invoice that's generated
steel steppe
Can you share the sample response of GET /v1/invoices/upcoming as we don't log the GET response?
long spade
Yes, one second.
Here's the lines that are in that invoice:
See how we get 3 of those? We're kind of confused why we're getting 3 of them instead of just 1.
You'll notice that the invoice created here by the actual Subscription deletion has a $214.00 charge on it as well.. but this is wrong, because this customer has already paid for their entire $214.00 year subscription. The only thing that should be here is a single negative charge for the pro-rated unused time remaining on the subscription ($213.99).
steel steppe
This JSON response is a bit off and some parts are trimmed. Are you able re-share the full JSON response?
steel steppe
With these invoice items: it'll be -214 - 214 + 214 = -214 in total for credit balance
long spade
Yeah but we're adding up the negatives to get the balance transaction amount correct so that we don't have to wait an hour for the refund invoice to finalize
So we end up calculating that the total refund amount as $428.00
We used to be able to rely on the negative values that had a start date equal to the proration date adding up to the total amount needing to be refunded.
long spade
This JSON response is a bit off and some parts are trimmed. Are you able re-shar...
Unfortunately this is the best response I think I can get you. This is coming from the rails console, and that object is large and the console is having trouble displaying it correctly.
steel steppe
We used to be able to rely on the negative values that had a start date equal to...
I see! I'd recommend calculating the transfer balance with all line items instead of just the negative ones. The upcoming invoice itself also has a total which represents the sum of amount from all line items
long spade
Interesting.. I wonder if this will work in all of our different scenarios..
steel steppe
Upcoming invoice is based on the actions that you plan to do on the subscription later. Ideally, it should reflect the invoice after the actions are performed
long spade
Yeah, I guess I'm still just a bit confused why the $214.00 and -$214.00 charges are on the invoice when the delete action is performed?
I realize that they "cancel each other out", but I'm suspicious that they weren't always showing up for us.. I don't know how we could have ever successfully cancelled a sub if it wasn't the case.
Here's an old one that shows exactly what I'm talking about.. there 's no $766.00 and -$766.00 on the delete invoice. There's just the prorated -$741.56 on the invoice.
It's really important to note, also, that we're actually refunding the customer by iterating through their individual charges and refunding any remaining money left in said charges until we've refunded the complete amount.
So the invoice that we create for the subscription deletion should always be a net $0 invoice. This is why we do a balance transaction in the amount that will be refunded so that when this invoice finalizes, no money is charged and no money is refunded.
Here's the code where we're looping through the charges and firing off refunds: https://gist.github.com/braydensterrett/9dae540890b8393a4cca46a4c1553644#file-sub_cancellation-rb-L27-L63
steel steppe
Although there can be multiple line items that cancel each other out, the final total amount in the upcoming invoice will be the balance once the actions are performed. If your intention is to ensure the net $0 (by refunding the customer first, then transfer balance) from the upcoming invoice, total in upcoming invoice (or sum up amount from all line items) should be used for your case
long spade
Okay, I'll go ahead and give that a shot and run this through some scenarios and see if it works for all of our use cases. I appreciate your time again!
steel steppe
No problem! Feel free to ping here again or use the email thread we had earlier if you have further question
long spade
I definitely will. It still feels as if we're kind of bastardizing the process here. Hoping to make a larger effort to better clean up the process at a later date even if this quickly fixes our issues. Have a good one!