#rodney_api

1 messages ¡ Page 1 of 1 (latest)

gusty gustBOT
#

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

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

wheat pebble
#

Hi there

#

Could you share the Subscription ID?

woeful robin
#

Sure, it's sub_1Q9eTHHu5QhcXEGNiSEJQYjO

#

To clarify, I don't think stripe did anything unexpected/behaved abnormally. I'm mostly wondering how we can solve this on our end for future scenarios like this

wheat pebble
#

Right, understood. I wanted to take a look at the timeline of this

#

I think one way to handle this is to keep track of the coupon's removal (by listening for customer.discount.deleted events) then keep track of any events related to the relevant Subscription

#

So, in this case, about an hour after we sent the customer.discount.deleted event (evt_1QhZOvHu5QhcXEGNquIZ60qW), we sent an invoice.created event (evt_1QhabqHu5QhcXEGNok6TZwx3). This is the first invoice after the removal of the coupon and, at this point in time, the Invoice was still in draft state

woeful robin
#

Could we cut an invoice upon receiving customer.discount.deleted which would be mostly representative (with the hour or so advertised buffer) and just apply a 100% off internal coupon or would that complicate the flow in cases where a subscription_threshold invoice wasn't created due to the coupon dropping off

#

I don't think/didn't see the coupons having any kind of "upcoming" event we could listen for before it drops off

wheat pebble
#

I'd wait for the invoice.created event for the relevant subscription and then inspect the discounts hash (to determine whether any discounts were applied) and the billing_reason to determine the reason for the newly-created invoice. In this case, it was subscription_threshold , so you can then decide if/whether to update the Invoice to add a one-off discount or how you want to handle this

woeful robin
#

is the subscription not updated when the discount falls off? I don't see a customer.subscription.updated event

#

Also just thinking in terms of not having more complicated invoice logic, would this flow work/be better:

  1. Customer creates "standard" subscription (no coupon). This is anchored to the 1st of each month
  2. Coupon is added to the subscription, create a subscription schedule to apply the coupon for 3 months and reset billing cycle anchor to be in-sync (using https://docs.stripe.com/billing/subscriptions/subscription-schedules/use-cases#upgrade-downgrade-coupons as an inspiration)
  3. Subscription schedule ends and the subscription is released back to a "standard" subscription with a billing cycle anchor on the 1st of each month
wheat pebble
#

No, I don't see one either

woeful robin
wheat pebble
#

In step # 2, could the coupon duration vary customer to customer?

woeful robin
#

oops didn't mean to reply there haha

#

was that discount on the customer or the subscription?

#

probably the sub based on the customer.discount.deleted event. nvm

woeful robin
woeful robin
wheat pebble
woeful robin
#

I guess I'm a little confused on how the repeating coupons are supposed to work on subscriptions. It seems like unless the subscription is created with the coupon already applied then there's always going to be some kind of synchronization issue? Removing the subscription schedule from the equation for now, is there a requirement that the billing cycle anchor config be removed/updated when applying repeating coupons on monthly subscriptions?

wheat pebble
#

"It seems like unless the subscription is created with the coupon already applied then there's always going to be some kind of synchronization issue?" - I don't quite follow this

woeful robin
#

As a really hacky solution we could just make the coupon duration 4 months to ensure customers get at least the full 3, but I'd imagine there's a better way to do things

woeful robin
# wheat pebble "It seems like unless the subscription is created with the coupon already applie...

So in the example subscription I sent over, the billing cycle is anchored to the 1st of each month but I think the coupon was initially applied on the 15th of October last year.

  • Invoice 1 (October 1 - October 31, billed November 1st) was covered (technically if there was usage from October 1 - October 15th that shouldn't have been covered, it would've been)
  • Invoice 2 (Nov 1 - Nov 30, billed December 1st) was covered
  • Invoice 3 (Dec 1 - Dec 31, billed Jan 1st) was covered
  • Invoice 4 (Jan 1 - Jan 31, Billed Feb 1st) was "covered" for the 15 days but once the coupon fell off it wasn't prorated in any way. So usage from Jan 1 - Jan 15th while the coupon was active became normally billed usage, which triggered the subscription threshold, since the user was expecting usage during that time to be free
#

It seems like unless the billing cycle of the subscriptions aligns with when the coupon is applied/falls off then you end up with a strange scenario, where ideally the coupon is really covering meter events that fall within its active window and the invoice only bills for usage that falls outside of that (either non-covered products, or meter events not within its start/end dates)

wheat pebble
#

Ah gotcha, I see what you mean.

#

The coupon will apply to the billing period so Oct 1 - 31 in your example and the only way to have it be applied starting on Oct 15 is to reset the billing cycle anchor, which you don't want to do in this case since you want customers to be billed on the first of the month

woeful robin
#

Yeah exactly. The additional free usage is less of a concern than invoice 4 where the customer is unexpectedly getting a large bill for usage they anticipated to be covered

wheat pebble
#

So you're okay with Invoice 4 being free in this case but Invoice 5 should not be free?

woeful robin
#

Ideally, usage within the time of the coupon is covered under the coupon and usage outside of it is not

#

But we get a lot less messages for additional free usage than being charged too much lol

woeful robin
wheat pebble
#

Right, exactly

woeful robin
#

Got it, thanks! I'll experiment but the schedule seems promising