#Obo-subs
rugged inlet
is there an api flag we can set that would either:
- refund the user for their unused time directly back to their CC
- when they switch from a higher plan down to a lower plan, and then back to a higher plan, that stripe should use their built in credits instead of charging them again.
it seems odd that a user would have nearly 2k in credits built up, but their card keeps getting charged for switching between plans
fresh sand
Do you have some example requests showing what happens when you switch from a higher plan -> lower plan -> higher plan? If you were using the same customer + subscription, I'd expect them to use the same credits
fresh sand
Yes, the customer ID would be perfect
rugged inlet
cus_LoJdHKXYRy1f1v
fresh sand
The three most recently created subscriptions for that customer are using the customer credit balance from what I can see - do you have a specific invoice or subscription that isn't using the credit balance?
rugged inlet
let me try and find it
all I know is somehow the customer has 2k in credits 🙂
my dev said he basically just switched between plans a bunch, which in our system involves:
- creating a new subscription
- cancelling an old subscription when that's done
from looking at the user, I'm not seeing any subscription that isn't paid for using credits, so I'm not sure how they got to 2k in credits
if you look at their credit balance page, you can see this happening: https://dashboard.stripe.com/test/customers/cus_LoJdHKXYRy1f1v/balance_transactions?starting_after=cbtxn_1L6j4bAnNL7nO1d0dy9oW24N
for some reason it just keeps debiting the user with the reason "invoice too small"
fresh sand
Those are not debits - all the "Invoice too small" balance transactions are credits (probably from when a subscription is canceled and the remaining time is prorated + credited back).
To clarify - I'm not seeing what you described where you said that the move from higher plan -> lower plan -> higher plan didn't use whatever customer balance was available. From what I can see, all your invoices are using the customer credit balance if it's available.
rugged inlet
I'm still not understanding how this would cause the user's credits to balloon in value though
From looking at the user's payment details
it seems like each subscription they're creating is using their card instead of the built in credits
do we need to pass in anything special via the API to get it to use those credits instead of charging the card?
fresh sand
Again, do you have an example showing a subscription that uses their card? I'm not seeing any on my end, so I just want to be sure we're looking at the same thing
rugged inlet
sure: pi_3L6i4HAnNL7nO1d01WYCQPz5
fresh sand
That one uses a credit card because there was no credits on the customer at the time - this customer first got a credit at 2022-06-03 22:08:30 UTC time, and that payment is from an hour earlier at 2022-06-03 21:30:04 UTC.
After 2022-06-03 22:08:30 UTC (when the customer first had credit), I'm not seeing any charges that were made using the card
In other words, you have some older charges that used a card because at the time there was no credit balance. However, ever since the customer had credit balance, that is what has been used instead of the card.
fresh sand
👍
rugged inlet
okay
so please check out this customer: https://dashboard.stripe.com/test/customers/cus_LpStLv6dYg44rd
cus_LpStLv6dYg44rd
I was on a plan, and then upgraded to a new one
and then downgraded back to the previous plan
it appears that there are now 2 drafts on the account
which appear to be refunding the user
fresh sand
Ah, I see what you're talking about now
So the reason this sequence of events isn't working is because the invoice from cancelling the subscription still has a 1 hour draft period before it's finalized and the balance is applied to the customer. Since your creating the new subscription BEFORE the invoice has finalized, the balance hasn't been added to the customer yet
Also want to note one thing - why aren't you just updating the subscription to the new price instead of cancelling + creating a whole new subscription?
rugged inlet
it's a good question, and is one I asked our dev team
but didn't really get a straight answer
unfortunately this bug was found waaay too late in our release cycle so I'm trying to do quick damage control here before things head out live
Is there a way to instantly finalize invoices?
if not, I may need to pull an all nighter
fresh sand
Yup you can use the API to finalize the invoice: https://stripe.com/docs/api/invoices/finalize
fresh sand
Unfortunately not - it'll need to be a separate call. You would just take the Invoice ID you get back from latest_invoice after cancelling, and use that in your finalize request
fresh sand
If invoice_now: false then an invoice is not cut as part of cancellation (so if prorate: true you'd have to wait for the next invoice for those invoice items to be added to an invoice)
rugged inlet
so theorhetically in this case
if the user was mass upgrading / downgrading
would that actually help?
would all of those just apply to the upcoming invoice?
fresh sand
It depends on what you want i guess - if you sent invoice_now: false and prorate: true then I believe the behavior you'd get is:
- you cancel the subscription and get a pending invoice item for the credit back
- when you downgrade (create the new subscription with the lower price) the pending invoice item should be automatically pulled in to the created invoice
rugged inlet
from testing this out
I think this is what we'll do for now
it seems to solve the case
as it all gets piled into the upcoming invoice
which at least solves the extreme credit issue we were seeing
fresh sand
👍 yeah i imagine it saves you the trouble of those extra finalization requests
when you're not under a huge time crunch, i'd definitely suggest taking another look into why you're creating new subscriptions since Ibelieve you can accomplish the same thing with subscription updates
rugged inlet
yeah definitely