sid_billing-reason

[kindred seal]

👋 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/1237037218565197835

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[marsh basalt]

Hi there 👋 I'm not sure how you're making the update requests to handle the change in members and change in tiers, so I'm not exactly sure how to differentiate between those two types of changes.
But, the billing_reason on the Invoice object should help you differentiate between a subscription_update and subscription_cycle:
https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason

[kindred seal]

sid_billing-reason

[high hare]

Thanks Toby,

We will have api endpoints such as:

• addMember
• upgradePlan

The billing reason is helpful, but it wouldn't help me in determining whether the update was a subscription upgrade or a new member addition

Heres some more context:

I’m working on an application that has workspaces. A person can create or join multiple workspaces. Payment details should exist on the workspace rather than the user, so when someone creates a workspace, it creates a stripe customer and we store that on the workspace.

On the backend, we have a single product with three different pricing tiers - “free”, “starter” and “pro”. The pricing tiers determine how many credits they are awarded each month. When someone is added to the workspace, the quantity of the subscription items is updated in the subscription, they pay a prorated amount for to the new user and the new user gets the prorated amount of credits, e.g. if they add a user 50% into the billing cycle, the workspace admin will pay 50% of a single monthly subscription and the new user will receive 50% of the credits. If the admin upgrades the plan 50% into the billing cycle, they will pay the prorated rate and each team member will receive the prorated amount of credits.

My problem is that i’m not sure how to handle this, because through the webhooks we wouldn’t be able to tell when:

1. A new member is updated (so that we can award the new user their credits)
2. The workspace has been upgraded (so we can award all users in the workspace their prorated credits)
3. The existing subscription has been renewed (so we can award all users there monthly credits)

[marsh basalt]

True, maybe you'd rather listen for a Subscription related Event for those, so you can use previous_attributes in the Event to see what changed on the Subscription object?

Something like customer.subscription.updated?

[high hare]

We wouldn't know if the payment went through though, correct?

This might be ok on something like netflix where you either allow / deny access based on subscription tier, but here, we are awarding them credits

[marsh basalt]

Let me see if pending updates could be useful here, where the updates don't take effect unless the payment for the update is successful.

[high hare]

I'm questioning if i'm going about this in a non-standard way though, as I can't find any resources. What is the standard approach for this type of flow?

[marsh basalt]

We don't really have guidance for a standard flow here, because the credit provisioning logic is all on your end and specific to your business needs.

The biggest limitation with pending updates is going to be it not being supported if you're accepting bank debit payment methods. Otherwise I think this may help:
https://docs.stripe.com/billing/subscriptions/pending-updates
Using that I'm fairly certain you could just listen for Subscription update Events, making it easier to see exactly what changed in the Event directly.

[high hare]

The flow would be quite generic:

• Seat based pricing (I can find this online though)
• Action rather than entry based flows where subscription renewal leads to an action rather than a status

[high hare]

Do the subscription.updated webhooks only run after the invoice has been paid?

I can't see that stated in the doc

[marsh basalt]

I believe they're going to be generated any time the Subscription object is updated, not only when the payment succeeds. You'll want to also pay attention to the pending_update hash in the Subscription object and include it in your logic if you go down this path.

If it's populated, the update was not successfully made yet. When you see it transition to being empty, then you can see what changed with the Subscription when those updates were applied.

[high hare]

Is the state captured from the time it was created or the time just before the invoice was paid?

(1) subscription updated -> pending payment (2)-> completed

Is the prev state at point (1) or point (2)?

[marsh basalt]

For which Event? There would be two generated there.

[high hare]

The one where the payment is confirmed

[merry citrus]

👋 stepping in as toby needs to step away

Sounds like you are looking into using Pending Updates here?

For a Sub update

[high hare]

We have workspaces that can have X number of members and a selected subscription tier which determines the number of credits a user will be given each month.

I'm having trouble determining when to award the members the credits through webhooks because we can't work out:

1. Whether the invoice was due to a subscription upgrade
2. Whether it was due to a new seat added
3. Whether it was due to a renewal

I feel like i'm going about this the wrong way though, open to alternative suggestions on doing this the standard way

I'm not sure pending updates is the solution here because i'm not sure when the subscription state is captured in the event, it sounds as though it will be once it is no longer pending which is a problem because it means we can no longer work out what caused the change (e.g. someone could have left the organisation so the line item quantity wouldn't change)

[merry citrus]

I'm not sure I understand the last thing you are stating

With customer.subscription.updated there will always be a previous_attributes hash

That would indicate what changed

So you can always know what happened

[high hare]

But when is that captured?

Because if its before it becomes non-pending, it will be old state

Eg

Say someone is added to the organisation, we will be able to figure this out by looking at the quantity of subscription items being 1 higher than the previous. But if this state is captured before it becomes completed, someone could have left the organisation, making the quantity cancel out with the updated