#samcic.

1 messages · Page 1 of 1 (latest)

deep ibexBOT
gritty solstice
#

hello 👋
can you share the example subscriptions?

zinc spruce
#

sub_1OZcpXIFJIf4TtR8VS8E6VMY

#

relevant request for updating the subscription is req_0THomobbqMhIXK

gritty solstice
#

I feel like this comes down to the fact that any existing discounts are applied when proration is calculated, the discounts don’t affect the resulting proration line items.

deep ibexBOT
zinc spruce
#

Just trying to parse your answer. When you say "when proration is calculated", do you mean both the (1) and (2) proration items ("unused" and "remaining"), or just one of them in particular?

static forge
#

👋 taking over for my teammate! Give me a minute to catch up

#

I'm trying to reproduce this as I think the issue here is the once restriction

zinc spruce
#

i.e. the request was just for updating a subscription (changing an item quantity) during a running billing period. Why didn't the duration="once" coupon persist on the customer after this request and eventually get applied on their next (upcoming) invoice in full? That seems to be what the Stripe docs suggest the behavior should be

#

From the API docs: duration="once"...

Specifies how long the discount will be in effect if used on a subscription. "once" = "Applies to the first charge from a subscription with this coupon applied."

Here the word "charge" seems a bit ambiguous. Does "charge" mean just a single proration item in the context of the request in question?

https://docs.stripe.com/api/coupons/create#:~:text=Specifies how long the discount will be in effect if used on a subscription. Defaults to once.

static forge
#

I'm trying to trace the history of this subscription to understand how the duration comes into play. I see the discount was added to an Invoice Item, not the customer or the subscription

zinc spruce
#

In request req_SKZkEV0T6jht48 it seems the discount was added at the customer level though right?

#

The two relevant events for the creation and deletion of the customer discount are evt_1OZcqDIFJIf4TtR8wlElkfaV and evt_1OhYfHIFJIf4TtR8vFNulm8X

#

...the latter of which was caused by the update to the subscription (req_0THomobbqMhIXK)

#

both refer to the same discount id, di_1OZcqCIFJIf4TtR8bfUDuyhW

#

so I can't see how this has anything to do with a discount applied at a subscription-item level

static forge
#

Let me take a step back to make sure we're on the same page. We're looking at Subscription sub_1OZcpXIFJIf4TtR8VS8E6VMY. The quantity of one of the subscription items in Subscription was updated in req_0THomobbqMhIXK, with create_prorations. This update resulted in two new Invoice Items for the two prorations: a credit for unused time and a charge for remaining time.

#

Is the question why the discounts hash is null for these two invoice items?

zinc spruce
#

Thanks....no, the question is why the "remaining" time proration has a discount (47.5%) but the "unused" time one doesn't.

Normally we see that discounts are applied to both "unused" and "remaining" proration items.

#

...and I guess another related question is: Why did the discount fall off the customer after this request? It's like Stripe "applied" the duration="once" discount to just one of the proration items, then said "I've applied the discount once, now I'll remove it from the customer". That behavior doesn't really agree with the docs on how duration="once" coupons work however.

static forge
#

Gotcha, thanks for clarifying

#

Normally we see that discounts are applied to both "unused" and "remaining" proration items.

#

Do you have an example invoice where discounts were applied to both proration items?

zinc spruce
#

Sure, give me a minute

#

in_1OCMqwIFJIf4TtR8nQHolcGM

#

In this example we see that the "remaining" and "unused" proration item pairs (that are auto-generated by proration_behavior="create_prorations" subscription-update requests) both have the customer's current discount applied to them.

#

In the case of this invoice I've just pasted, the customer's discount is a "forever" discount, but I can't see why the "once" discount from our original customer should differ at the level of proration items, considering that "once" discounts should also be applied to a single full "invoice" (per the Stripe docs)

#

I have to run soon...do you know if I'll see your response if I log back in here tomorrow?

static forge
#

We don't keep threads open but I have an update

zinc spruce
#

ok

static forge
#

req_SKZkEV0T6jht48 is where the coupon was added to the customer. The coupon was added after the Subscription was created but before the Subscription was update. This means the Subscription was created at the full price but the next update that was made pulled in the coupon on the customer.

#

This is why the credit for the unused time doesn't have a coupon (the customer didn't have a coupon when the unused time was charged for) and the debit for the remaining time does (because the coupon is in fact on the customer at the time of the update)

#

Let me know if this makes sense!

zinc spruce
#

Hmmm...but if I apply a coupon to a customer, even after their subscription is created, that discount will of course be applied on their upcoming invoice. So, hypothetically speaking, if we didn't make that request to update the item quantity, their full upcoming invoice amount would be reduced by 47.5% right?

#

(actually ignore that...I think I'm now getting confused with the non-proration items for the next billing period)

#

ok, I have to run, leave this with me.

Your comments were helpful and I'll do some more testing/reproducing of this case tomorrow and reach back out if anything's still unclear

#

Thanks!