#brayden-upcoming-sub-invoice

1 messages · Page 1 of 1 (latest)

oblique steeple
#

Hello 👋
Give me a moment to catch up here and I'll respond as soon as I can 🙂 Thanks
Feel free to add more context here in the meantime

icy garnet
#

Sure, will do.

#

Here's a test subscription that might help us send links back and forth: https://dashboard.stripe.com/test/subscriptions/sub_1LKo5pALivADE4JrVU8JfHXG

So here's the general flow that causes us issues:

  1. A subscription schedule is created for the invoice containing a future phase.
  2. On cancellation, we create an upcoming invoice for the subscription and then iterate through the line items on the upcoming subscription to determine how much of a refund the customer should get.
  3. Once we determine the amount of refund to give to the customer, we begin to go back through the customer's charge list, refunding the max amount that we can on the charge until we've refunded the full amount required.
  4. We then make a balance transaction adjustment to offset the customer balance that does not get cleared due to the refund.

Here's a gist that shows the actual code that we're running: https://gist.github.com/braydensterrett/9dae540890b8393a4cca46a4c1553644

#

What we're finding is that the upcoming invoice has more items on it than we would expect. This seems to be because of the subscription schedule that gets created? At the end of the cancellation workflow, we end up charging the customer an amount that basically adds up to all of the negative line items on the invoice. You can see why this is happening on line 14: https://gist.github.com/braydensterrett/9dae540890b8393a4cca46a4c1553644#file-sub_cancellation-rb-L14 since we're summing all of the negative lines in the upcoming invoice.

We've had this exact code functioning for over 2 years without change in our integration, and it has only recently started causing us these issues. We're hoping to understand what changed, and then, more importantly, how we should perform this a better way?

#

We're simply wanting to be able to cancel a current subscription and pay out a prorated amount back to the customer based on the current price and the end date of the current subscription.

oblique steeple
#

do you have any example subscription IDs that I can look into?

icy garnet
#

Yeah I sent one at the start of that rant lol

#

Can you see test subs?

#

I always forget

oblique steeple
#

ah sorry, missed that in the details 😄
give me a few to look into it

icy garnet
#

I can start that cancellation workflow that's described in the gist whenever you want to see how it behaves.

edgy violet
#

Hi @icy garnet 👋 apologies for the wait here. I'm going to take over. This question is really complex and difficult to troubleshoot in real-time during peak Discord hours, so I want to acknowledge that I see you've been waiting a while, before I take over the thread

icy garnet
#

Sure man, no worries. I've actually been working with a bunch of folks in this channel over like a week

#

I realize how complex it is, but I can't really find an avenue of support with you guys that allows us to get to a solution

#

We just kind of run in circles until one or the other of us has to leave the channel lol

#

We basically have had this cancellation workflow that worked for the last 2 years, and sometime in the last couple of months it stopped refunding customers the correct amount.

#

It's been difficult to understand exactly what has caused the workflow to stop functioning as well, because we haven't changed this code on our end.

edgy violet
#

That's fair. Let me get caught up on your thread and take a look at the Subscription you provided

icy garnet
#

Sure thing, appreciate your help!

#

If we struggle to get to a solution here, I think we're kind of in the mode of trying to audit our current implementation (a lot changes in 2 years and I'm sure Stripe has improved in many ways that we were likely coding around in the past).

#

So if it comes down to it, I'd be interested in understanding how we should better structure the things that we're trying to do with our subs

edgy violet
#

For sure! You're on an older API version than our current one, so it's possible something changed and had downstream effects on your integration.

#

Circling back to the issue:

#

You mentioned there are more line items than expected. Do you have a Subscription I can look at that was working as intended so I can compare with this one (sub_1LKo5pALivADE4JrVU8JfHXG)?

icy garnet
#

Let me dig a bit and see if I can find one from a while ago

#

One second

#

This might be a good one.. This guy would have had a sub schedule

#

Ehhh, hang on. That one looks messed up to me too

edgy violet
#

And when you say "line items", which field do you mean specifically? The Subscription you sent has only one Subscription Item (si_M2ttJp27ASk3DX) and its corresponding Invoice has only one Line Item (il_1LKo5pALivADE4Jr360mcMqf)

icy garnet
#

Yeah, I haven't actually cancelled it yet.

#

Did you take a look at the gist I linked?

#

We create an upcoming invoice

#

We use this upcoming invoice to determine how much we owe in prorated refund to the customer. This upcoming invoice has 3 line items

#

One of them seems to be the correct amount. The other 2 items seem to be the full amount of the annual period, one being positive and one being negative

edgy violet
#

The upcoming invoice has a negative and a positive amount that should cancel each other out, but you're saying you have internal logic on your end that adds the items up and issues a refund for the total amount, rather than looking at the total due on the upcoming Invoice. Is that correct?

Sorry, still just trying to fully understand what's awry.

icy garnet
#

This is what we've always used to determine the full amount that we need to refund.

edgy violet
#

Is there a reason you wouldn't simply look at the total due on the Invoice?

icy garnet
#

This is then used to create a balance transaction for the customer after the refunds are processed since refunding doesn't affect the customer's balance

edgy violet
#

If you have multiple line items on an Invoice, they should automatically add up to the total due on that invoice

icy garnet
#

I'm actually not sure about that question. Unfortunately, I inherited this rat's nest. I didn't write it myself so these decisions were made before I worked here.

edgy violet
#

Ahhh, yes. Very familiar with this pain

icy garnet
#

We can do really anything that we want to change the system, we just need to be able to end up with a correctly refunded customer with no balance left on their account.

#

It's the worst lol

#

Like, why are we having to loop through the charges the customer has incurred and refund them one by one to get the customer fully refunded? Is that really the way that we have to do this?

#

Or is this a relic?

edgy violet
icy garnet
edgy violet
#

Do you post-bill your customers?

icy garnet
#

lol could this be because this was written mid-2020?

#

What do you mean by post-bill?

edgy violet
#

So if subscription started on July 1st, I would get billed for July on August 1st

icy garnet
#

Nope, we bill them immediately for the entire period. We only offer annual and semiannual subs

#

We do allow the amount to change an unlimited number of times though.

edgy violet
#

And when throughout the process are the refunds created? It seems odd to refund ahead of when someone is actually charged

icy garnet
#

Hmm not sure I understand that one

#

We charge on the day the sub is started, so a refund is always after a charge

edgy violet
icy garnet
#

Wait, so don't use the upcoming invoice at all? Sometimes we do have small adjustments to make.. so I'm worried about like always relying on the "last paid invoice"

#

I've also got a hard stop in 20 minutes. Is there a way we can continue this conversation at some point?

edgy violet
#

It depends on what you want to have happen. For example, do you want to refund them the most recent invoice total? Or do you want to prorate it for the day that they cancel?

So, if I have Subscription that I paid on July 1st, and I cancel it on July 15th, do you want to charge me for the 15 days?

icy garnet
#

prorate it for the day they cancel.

#

So if they have an annual sub for $100 and they cancel 6 months in, we're wanting to refund them $50

#

Sorry if that wasn't clear.

edgy violet
#

I've also got a hard stop in 20 minutes. Is there a way we can continue this conversation at some point?
We're available again tomorrow and you can link this thread in your reply so that whoever is here can get caught up before answering. I'll leave a summary at the end of the thread so that whoever picks it up will have a good starting point

edgy violet
icy garnet
#

We sometimes have differences in rating with the company that underwrites the insurance policies that these subs represent. They might adjust a policy by a small amount

edgy violet
#

Ah, okay. And that amount is more or less arbitrary?

icy garnet
#

Yes, basically.

edgy violet
#

Okay. So my first thought is: use the Customer Balance to track how much you need to refund, but that won't let you create refunds for the balance; it only applies balances to future invoices. If you were on the latest API version, you could use Stripe Treasury to do this in a much easier way, because you would just track the Customers balance and payout to whatever financial account they've linked, but as it is now you have to use refunds to get money back to the customer.

#

Right now, I would say: get off of using future invoices, because those invoices have variable behavior based on what the customer has or will do to their subscription. For example: if your customer schedules a future change to their subscription, then cancels their current subscription, then you might end up with a weird future invoice based on a price you don't want to refund