#lucas-subscription-integration

1 messages · Page 1 of 1 (latest)

modern thornBOT
granite warren
#

Hello, good question. Checking in to the requests that affected that invoice. Do you have the ID or other identifying info of the extra invoice item?

viscid jungle
#

yeah one moment..

#

everything in the box is what we intend, the 3 on top we usually ignore and they seem to net to the correct dollar amount

#

i can give you any/all of those ids

granite warren
#

It does look like these came from the dashboard with someone accidentally leaving prorations on https://dashboard.stripe.com/events/evt_1NDujOEk6sr5GyDh1CygaY67
https://dashboard.stripe.com/events/evt_1NDujOEk6sr5GyDhWBeSXqpf

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

#

You can see the dashboard requests themselves by clicking on "Dashboard" under the "Source" section on that page

#

Wait, I see "proration_behavior": "none", on the requests. Checking in to why there are prorations here...

viscid jungle
#

🙏

modern thornBOT
granite warren
#

I am still having trouble finding what created these prorations. I am not seeing updates outside of the dashboard but the actual requests that I am seeing from the dashboard don't seem to have prorations on

#

We are still looking in to this, just wanted to give a quick update...

viscid jungle
#

thank you!

granite warren
#

proration_behavior is create_prorations by default in the API, so when prorations are turned on in the dashboard it just excludes that parameter

viscid jungle
#

oh hmm. gonna restate back to you to see if i understand.

  • current theory is that the end user DID leave prorations on
  • when the dashboard makes the api request, if the proration radio is left on, the create_prorations field is absent in the logs, because the dashboard excludes that parameter (so the default here assuming is true)

can you explain more about the proration field we did see in the event logs?

civic nimbus
#

Hi 👋
I'm stepping in as @granite warren needs to go.

#

Can you clarify which proration field you are referring to?

viscid jungle
#

sorry, his was proration_behavior: none

civic nimbus
#

Okay I'm still very unclear on what the actual question is here. What Stripe object are you looking at that is causing the confusion?

viscid jungle
#

i dont know if yall keep longitudinal tabs on who asks what in this discord but .. honestly... this stuff is CRAZY confusing for very vanilla happy path scenarios. its really frustrating. and to continue to restate problems top of the hour isnt super fun either

10k ft view

my internal customer support team somehow got this subscription into a weird state that charged the wrong amount

they wanted to

  1. change items on the subscription
  2. bill the customer now

i have a theory that she forgot to turn off the proration slider. was looking to confirm that one way or the other.

im also looking to lean very heavily into stripe subscriptions soon by surfacing more edit functionalities to end users but this is all keeping me up at night honestly

i am considering rebuilding your portal UI in retool as internal admin UI at this point for my internal team to use just so they cant mess anything up for the again pretty simple use cases we have

sorry this is all spilling out now but it's really been a pain and i guess i need to vent

civic nimbus
#

That's understandable. The Subscription product as well as the editor has been built to allow a large number of use cases with the end result that you can do a lot of things you might not have wanted to.

viscid jungle
#

totally

civic nimbus
#

So, based on what @granite warren already found, the Dashboard request above shows that we did not provide a value for the proration_behavior so the default was applied

#

And I'm seeing we shared some event logs, is that where you noticed the unintended proration?

viscid jungle
#

yeah so i guess to step back,

@granite warren shared those two event logs, they both have proration: true (i think this is on line items), if you click through using the source -> "Dashboard" link to see what the dashboard called, it made calls using "proration_behavior": "none",, allegedly. on those events he shared. here #1113561922156101822 message

but then i think later on it was determined that this event #1113561922156101822 message was the true event that generated an invoice (?) and that that event was created via the dashboard and the clue in the api payload being that the field was missing which is what happens when proration is left on/true in the dashboard ui...

does that ring true?

civic nimbus
#

I'm doing my own digging on the events to make sure I have the full context but if the later request is the one that triggered the invoice and it did not have the "proration_behavior": "none" parameter then that would cause prorations to be generated.

#

The behavior of the "proration_behavior" parameter is per request so failing to have that set properly on a single request can trigger prorations to be generated

viscid jungle
#

❤️ thanks, i know we're in a rabbit hole here

civic nimbus
#

I totally understand. Billing (Invoices & Subscriptions) is a complex suite of products because of all the different use cases we had to work with. It means there's a lot you need to configure each time you work with them and it's easy to get confused.

#

Perhaps it would make sense to allow Admins to set some sort of default configuration for their account.

viscid jungle
#

yeah, makes sense. the good news is - i only have a few scenarios, so im hoping to find the proper calls for my usage and really solidify them and just shy away from anything really complex.

i think one bit that feels more frustrating than it should is that my particular use feels buried or not very specifically called out in the docs, im not metered billing, or "access to a resource" (proration), i just want to charge and ship essentially on a cron schedule. it'd be great to set out more docs for every usage scenario i suppose

and yeah - hindsight 20/20 maybe you have a certain subscription "type" / flavor then the different things you can do with that subscription - you reduce the combinatoric explosion of complexity by reducing the solution space of what needs to happen

#

btw ive tried to knock on a different door to hop on a call with somebody and walk through this from more of a product strategy standpoint but that avenue likes to shoot me down and refocus me back into this discord, which is stellar for quick technical support, but not so great for "lets take a step back here"

civic nimbus
#

With respect to the charge & ship approach, this is still something you want to be able to use the Dashboard for?

For the configuration, it's a feature I can request. Because this error seemed to occur when using the Dashboard, I thought it would be something that would automatically set the controls on the Update Subscription screen. Does that sound like it would work for your use case?

As for the product strategy, I agree we don't have a great resource for that. I'm sorry you got redirected here since, as you correctly point out, our mission is to unblock developers with API questions.

viscid jungle
#

i like the idea of an admin setting to say "never prorate" - seems easy without blowing up the entire subscription product you've built

#

and yeah - we've got a current active customer base of 7k that our internal team currently handles (with some clever hacks) to bill now, bill later, change items in their subscriptions. that's pretty much it for us from an end user scenario, its pretty vanilla

#

in order to expose to end users proxying it via our code - i think i have what i need with stripe subscriptions schedules & phases but oof, that was really complex and not called out in the docs for my use case

#

and im still somewhat leery of giving end users the ability to request to change items due to proration, but im hoping that as long as i always explicitly set it off, we'll be good

civic nimbus
#

Oh yeah, Subscription Schedules add another layer of complexity but they also address some of the biggest pain points for Subscriptions.

viscid jungle
#

set to "false"* i should say

civic nimbus
#

We're still talking about proration_behavior here, right?

viscid jungle
#

yeah

civic nimbus
#

In some cases, for immediate billing, always_invoice may work for you

viscid jungle
#

oh interesting, can you elaborate? the docs dont say much about it there

#

just to walk through this scenario, we wanted to change items and bill now in order to ship only the new items, and not the old items (charge or ship)

civic nimbus
#

If you want the customer to immediately pay the price difference when switching to a more expensive subscription on the same billing cycle, you can set proration_behavior to always_invoice

#

In this scenario the new Invoice is only for the difference between the prices for the prorated period (e.g. 15 days of a higher price if changed mid-month)

viscid jungle
#

ahh yeah not good for us and here's why (but thanks for flagging!) -

we really just charge and ship on ~3 month intervals. we send women menopause treatments (its actually kind of interesting, story for another time i suppose). so in a scenario like this they want to switch from a pill form to a patch form, or increase their dosage, or similar.

for example they got a .5mg dosage 2 months ago, theyve been using it and not feeling much better, so they request a 1mg instead. we pass that to our doctor network in order to get a prescription, then either right away, or on their next regularly scheduled cadence, or at a particular date (picture a datepicker), they should just get charged and shipped for the new product

#

the fact that they were 2 months in at the point in time we switch them doesnt really matter at all

civic nimbus
#

Oh, okay I think I get it now. Because you are shipping a new product you just need to charge for the cost of that product, not a difference (since it isn't like you get the old one back).

#

And I was just discussing hormone replacement therapies, small world

viscid jungle
#

boom exactly. i suppose you could make an argument to consider some sort of proration / split amount charge for both line items in this switch use case but hoo boy that's complicating things

#

oh interesting! yeah my founders and the chief medical officer are advocates for hormone treatment. their take is that there was bad science in the early 2000s that needs reversed, completely overstating risks of breast cancer (but of course, women should get their mammograms..)

civic nimbus
#

Yeah, I get it. Since it's a new material good being shipped it's not like they just upgraded a service

viscid jungle
#

yeah

civic nimbus
#

Yeah I read an article in the NYTimes that basically said exactly that

#

(bad science made doctors scared)

viscid jungle
#

oh yeah we were in that 🙂 towards the end

civic nimbus
#

Nice!

viscid jungle
#

we got 1k customers in a week thanks to that article

#

we've been trying to catch lightning in a bottle ever since, but nothings really panned out to that extent

civic nimbus
#

Sounds like you need to beef up your billing scenarios 😆

viscid jungle
#

😄

#

well, im talking your ear off. where did we land? i guess i'll say im available as a resource to you guys, and id love to talk through what we're planning to do with someone on your side just to make sure i've got my head on straight - i mean, i think i do, but its situations like the top of the thread here that give me pause

#

maybe im overstating things but i think somebody could make a killing right now doing content marketing simply writing a blog article walking an end user through stripe subscriptions/proration/billing anchors/schedules/all the rest

civic nimbus
#
  1. I will put in a request for a default configuration for the Update Subscription form in Stripe Dashboard
  2. I think ensuring in your code that "proration_behavior": "none" is set on every update request should ensure this does not happen.
  3. Agree and we are working on docs that are more targetted. Currently we split between high level business cases and low level coding in the same doc and it's not the right approach.
viscid jungle
#

you rock! thank you for talking me through all of this

civic nimbus
#

Happy to do it, that's why we're here 🙂

modern thornBOT