#alexpanda_webhooks
sullen mistBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1366560594999906337
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
jaunty plank
hello! looking into this now
do you have an example of where you were using a test card?
sullen mistBOT
mortal whale
The only one that you can even attach to a customer without it erroring out is the "Decline after attaching" card 4000000000000341.. but even this one fails "successfuly" meaning it does not generate a $0 paid invoice
It's unclear why the $0 invoice is created and sent to us, but we generally accept $0 invoices when the subscription_update reason is provided, since the custome rcould have a balance, but in this case there is no balance and we have no way of knowing in the event data
I am trying to work around this by looking at the subscription items, looking for any negative amount items that woudl imply a credit, but this feel hacky
the flow that customer experienced is:
- Subscribe to product A at $2/month
- Update to product B at $4/month on a card with no funds
- Product B is given to the account, since we get a $0 paid invoice and accept it
- Customer cancels subscription, but keeps the product, since we assume we got the payment
solemn breach
Hi @mortal whale I'm taking over this thread, let me take a look.
mortal whale
We use proration_behavior = always_invoice for changing the sub from product A to B, and it always charged the card or gives an error
but not in this case, any details or help would be appreciated 🙏
solemn breach
It looks like all invoices created for the same subscription has amount = 0
Ah, OK. This subscription is still on trial, the trial will ends at 2025-05-15 19:47:07. This explains the $0 invoices.
sullen mistBOT
mortal whale
interesting, so we during the trial, failures to charge the card do not cause a failed invoice but a $0 success?
what would be the correct way to have a customer on a trial for product A, that wants to pay for product B get switched over without this happening?
in our system, product A has option for trial, but product B does not.. we allow customers to switch products anytime
lost barn
to be clear, during a trial, there is no charge attempt to the card because it's a $0 price
mortal whale
right, that makes sense now, but what would be the best way to have this process complete correctly? moving a customer with a trial sub for product A, to non trial on product B? does the API call for subscription update need to remove the trial date?
lost barn
what would be the correct way to have a customer on a trial for product A, that wants to pay for product B get switched over without this happening?
So the customer is originally on a trial, now they want to update to product B, is this correct?
lost barn
when you update to product B, it should automatically end the trial, you can use always_invoice , and maybe you might want to consider using https://docs.stripe.com/billing/subscriptions/pending-updates also
have you tried and are you seeing something different?
in case you haven't seen this yet, you can use test clocks to mimic the passing of time : https://stripe.com/docs/billing/testing/test-clocks
mortal whale
I will give this a shot, thank you! we currently use always_invoice already
if always_invoice does not work, hsould I set the trial end date to yesterday?
Ah I see this in the docs
The special value now can be provided to end the customer’s trial immediately.
lost barn
hmmm, actually my bad, it looks like updating the price does not end the trial by default. And yes, you can use trial_end="now" assuming that's what you're looking at
mortal whale
Will try that, thanks for looking into this! the subscription was cancelled by the time I looked at it and I did not catch that important detail
I just tried to replicate this flow in test mode with 4000000000000341 but could not reproduce
Hmm, I dont see where the production customer got put on a trial, can you help me identify it?
We do not create a trial subscription in stripe, its all on our end, so its odd that the stripe subscription was on a trial
ah, I think I may have found it, it when a customer creates a subscription, cancels it, then resumes the same subscription later
the new sub is on a trial depending on how much time they paid for already
lost barn
great that you managed to figure it out