#rovarma

1 messages · Page 1 of 1 (latest)

silent nightBOT
tribal shell
cinder wigeon
#

yep, hold on

#

oh sorry, not that one

#

this one: req_vf5VpvR9AfhIH4

#

if you look in the subscription in question, you'll see that there's a 50% discount coupon applied as test (this is all in test mode)

devout bane
#

Can you send me the actual body you get back from that call? (Unfortunately bodies of get requests aren't logged in a way where I can see it here)

cinder wigeon
#

I'm not sure if I can, I'm using the C# SDK

#

so I only get the parsed object back

#

will have a look..

#

actually, aside from the preview being wrong, it seems this is just broken in general

#

I just tried to see what would happen if I completed the payment anyway. In my test case I'm going from 1 -> 2 seats. The preview for that is incorrectly showing 0 for all amounts, but if I continue with the update anyway, I can see an invoice is created with a zero total

#

see in_1M5Vl8By4su9ppSNu1YTfsTs

devout bane
#

That is strange. Thanks for the ID, still catching up on some other threads but will be able to check it out in a minute

cinder wigeon
#

so the flow of events in my test case was:

  • purchase single (1) seat without any discounts applied @ 289 / seat. This was done a while ago (on Oct 20), I'm just reusing an existing test account
  • Apply a 50% discount through the dashboard to the subscription (sub_1Lv0VUBy4su9ppSNUNHXu0Je)
  • Attempt to add a single (1) seat to the subscription via our custom UI. This should be prorated based on the current date (Nov 18), with the customer being charged immediately
  • This results in the preview returning zero for all totals in the preview
  • And going through with the subscription update (i.e. 1 -> 2 quantity) results in a zero invoice being actually generated for this update by stripe, so the customer is not charged at all
devout bane
#

Hey apologies but I am still looking in to this. The new Invoice showing the same results as the upcoming invoice endpoint is a good sign that this is a more genral subscription behavior question. Still looking and will get back with what I can find

cinder wigeon
#

yes, I thought so too. Are coupons supposed to work with subscriptions like this? The dashboard interface seems to indicate that it is, but it's hard to believe that something as basic as updating quantity would be broken when combined with coupons.

devout bane
#

And so the end goal is to charge the user for half of the seat that you are adding basically?

cinder wigeon
#

not specifically, the 50% is just a test discount I'm trying out here

#

the idea is:

  • the customer has already purchased a subscription in the past with a number of seats (without coupon)
  • they'd like to add more seats and we've negotiated a discounted rate with them. We know Stripe has support for tiered pricing, but we don't normally offer that to users, so we haven't set that up.
  • Our thinking was that we could just apply a coupon for the discount we've negotiated to their existing subscription and that they could then add the seats they need via our normal interface. The thinking being that stripe would charge them <normal prorated price> (they are in the middle of their subscription period) - <discount> and then on the next billing cycle they would just be charged full price - discount
#

(where discount is a percentage of whatever the normal price is of what they're purchasing)

devout bane
#

Gotcha

#

So I think I know the issue you are running in to but am not immediately sure how you can best get around it.

Basically, when you update a subscription and prorate it, Stripe checks what the user has already paid, and what they will owe, and then lines them up against each other. Here, the user has already paid 1x the seat price, when upgrading Stripe sees that the user will owe 1/2 of 2x the seat price, which is of course 1x the seat price, which the user has already paid.

#

So the goal is that the user pays for 1/2 of the seat price (prorated for how far along in the year we are). I am trying to think of the way to get the discount and the proration out of conflict here

cinder wigeon
#

okay, so are you saying that this is basically an unfortunate choice of 50% as a discount price?

#

and that any other discount would basically work?

#

(and also not exactly doubling the amount of seats in my test case I guess...)

devout bane
#

That depends on your goals. If you do want that initial yearly subscription to be discounted as well, then this behavior should line up with what you are trying to do. If you want to keep all the funds from that initial yearly payment and charge 50% or whatever on the new seat, I think that will take some more code to get the correct behavior

cinder wigeon
#

no, I think I understand now and I think this behaviour is fine

#

I don't know if you could really do anything else thinking about it some more, because on the next billing cycle the discount would apply over the full amount anyway

#

so what you're basically doing is:
current: 1 * 289 (paid)
new: <new seats> * 289 * (1-discount)

so in this case that's

current: 1 * 289
new: 2 * 289 * 0.5 = 289

so the invoice comes down to 289 - 289

devout bane
#

Exactly. So this is a result of 2 * .5 - 1 = 0 basically

#

Good to hear that that behavior is actually fine here!

cinder wigeon
#

good to hear and I feel a bit silly now 🙂 thanks for the help!

devout bane
#

No worries at all, there is a reason that that behavior confused me for a while too. Prorations are just weird to wrap your mind around sometimes

cinder wigeon
#

yeah 🙂