#brometheus_subscription-refund
valid currentBOT
👋 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/1282809379300577342
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
crimson bramble
👋 hmm, it's actually a bit more confusing, looks like sometimes prorated refunds are against the last-paid invoice (and tax on that), and sometimes prorated refunds are based on the subscription's current details (basically, what the upcoming invoice would be)
but it's not obvious to me when one approach is used vs the other
Example https://dashboard.stripe.com/test/subscriptions/sub_1PxEqOBjIQrRQnuxEdkyaxGR
- $20/month subscription
- $2.07 tax added to last month's invoice (but not on the subscription)
- prorated refund is showing it will refund all $22.07 (so based on the last month's invoice)
Example https://dashboard.stripe.com/test/subscriptions/sub_1PxExKBjIQrRQnuxUgx7XSlT
- $20/month subscription, last month's invoice paid at this rate
- updated the subscription to $19/month
- prorated refund is showing it will refund only $19 (so based on the current subscription)
crimson bramble
on the Stripe Dashboard, in the "Cancel Subscription" popup window
for the second example (using current subscription price for prorations)
for the first example (using last paid invoice for prorations)
tame wing
Hold on, I think we're getting mixed up
For sub_1PxExKBjIQrRQnuxUgx7XSlT, I see the last paid Invoice was $20. This is for the period of September 9 - October 9. The Subscription update that was made after this Invoice was paid was made with proration_behavior: 'none', so the $19/month price will take effect starting 10/9. Canceling the Subscription today will prorate based on the price paid for the current period (September 9 - October 9)
crimson bramble
then why is the dropdown showing $18.99 instead of $19.99
I can update the price on the subscription again with no prorations and it'll affect this prorated refund amount it shows
I have another example I updated the price $20 -> $25 and it shows the prorated refund is $25 despite the last invoice being $20
tame wing
The dropdown is showing that if you cancel this Subscription now, you'll refund the remaining amount for the period. Since the customer already paid the full $20 price for September 9 - October 9, canceling now means they're owed <$20
The prorated amount is calculated by Stripe down to the second, which is why the amount will change
crimson bramble
right, I understand that the prorated refund price gets reduced over time, it seems like that part is working properly
just trying to understand whether the prorated refund should be on the last paid invoice or on the current subscription details & price because I'm seeing cases where it looks like it's using one vs the other
which - either a bug, or intentional with some logic somewhere that chooses which of the 2 approaches to use
tame wing
It's based on the last paid invoice
I have another example I updated the price $20 -> $25 and it shows the prorated refund is $25 despite the last invoice being $20
Can you share the Subscription ID?
crimson bramble
updated monthly price to $2.00 - prorated refund shows $2.00
still on https://dashboard.stripe.com/test/subscriptions/sub_1PxExKBjIQrRQnuxUgx7XSlT - just updated monthly price to $155/month
valid currentBOT
elder frigate
brometheus_subscription-refund
@crimson bramble I think there's a bit of a mixup here.
If you are on Price A and then you move to Price B, we forget all about Price A. At that point you are on Price B and any change (downgrade, upgrade or cancellation) would be based on Price B. Our API has always worked this way, we don't go and look back at past Invoices/payments for future proration.
With that said, I agree the UI is confusing here because it still references the last payment. This is partly because that feature is only available in the Dashboard as a quick way to refund the most recent payment and I think it doesn't handle well the case where you upgraded in the middle (with no proration).
I do think it's a bug and I'd recommend reporting it to our support team and they can help get a fix out in the future: https://support.stripe.com/contact
crimson bramble
OK, I think I follow. So if you've changed the price, then 1. prorated refund is based on the current price (x days of current billing cycle), and 2. "Last payment" refund isn't actually possible - just tried it and I get the following error message
elder frigate
correct though clearly the UI should warn you before it shows you something that errors (That's the bug)
crimson bramble
If you don't change the price, is prorated refund based on last invoice or current price?
elder frigate
I think we built this as a "quick way to refund something charged by mistake" but it's not compatible with a flow like yours. It definitely should handle it properly
crimson bramble
(they could differ in case line items were added to that invoice while in draft mode)
elder frigate
Proration is always based on current Price on the Subscription (extra line items don't matter at all)
crimson bramble
hmm, maybe a different bug then? In this case: https://dashboard.stripe.com/test/subscriptions/sub_1PxFSRBjIQrRQnuxDI0n0pG6
- Subscription price is $20 (no tax configured)
- Last invoice was $22 ($20 + $2 tax added while in draft mode)
- Prorated refund based off the $22
elder frigate
Yes that's possible. Sorry I rarely touch the Dshboard and I never expected them to show the proration for the most recent payment like that
crimson bramble
doesn't look like dashboard-only?
just called
stripe.Invoice.upcoming(subscription="sub_1PxFSRBjIQrRQnuxDI0n0pG6", subscription_details={"cancel_now": True, "proration_behavior": "always_invoice"})
and I see the same $22.05 would be refunded in this case
"subtotal": -1998,
"subtotal_excluding_tax": -1998,
"tax": -207,
"test_clock": null,
"total": -2205,
"total_discount_amounts": [],
"total_excluding_tax": -1998,
"total_tax_amounts": [
{
"amount": -207,
"inclusive": false,
"tax_rate": "txr_1PxFSRBjIQrRQnuxwNLtvXLd",
"taxability_reason": null,
"taxable_amount": -1998
}
],
so... it's pulling the tax rate off the most recent invoice but the price off the current Subscription?
we use this semi-complicated flow https://apidocs.anrok.com/tutorials/self-checkout/stripe-subscriptions#how-to-add-tax-as-an-invoice-subtotal for adding tax to the first invoice of a subscription, using tax-rates, where we create a short-lived tax rate that we reference in the subscription, then we remove that tax_rate after the subscription has been created
elder frigate
The part that is Dashboard-only is the refund part.
I don't fully get the rest that you are describing but you only gave a small part of the entire flow. Have you been able to cleanly reproduct in Test mode end to end with a clear script made with code?
crimson bramble
sounds like there are potentially a few bugs here on Stripe's side (some in Dashboard, some generally in the API) - I can try to create simple repros and submit as bug reports - what's the best way to submit a bug report?
Via chat with support?
elder frigate
I don't think there's a bug in the API so it might be a misunderstanding here more than anything. I just don't really follow your train of thoughts are you're deep in something but I only see 10% of the issue.
If you do have a clear end to end repro from the creation of the Subscription, the Invoice extra line item to the cancellation I'm happy to look though
I looked at that Invoice and the tax is included in that Invoice, it's not a separate line item like you were saying
as far as I can tell you put the TaxRate on the Subscription itself so it's normal that it's included in the proration
crimson bramble
happy to try to explain again - I have a subscription sub_1PxFSRBjIQrRQnuxDI0n0pG6 that followed this chain of events to get to where it is now:
- New 10.35% tax rate created
- Subscription created, with a $20/month price and this tax rate
- First invoice created for the subscription, invoice was properly $22.07 ($20.00 + $2.07 tax)
- subscription updated to have no tax rates
- I'm seeing when I call
stripe.Invoice.upcoming(subscription="sub_1PxFSRBjIQrRQnuxDI0n0pG6", subscription_details={"cancel_now": True, "proration_behavior": "always_invoice"})to calculate a prorated refund, it's showing proration with both base & tax portions being refunded. (Same sum as what the prorated refund UI shows)
Based on what you were saying, I would expect the proration to just be based on the current subscription, so not having a tax portion
elder frigate
Gotcha, thanks for laying it out this way
Based on what you were saying, I would expect the proration to just be based on the current subscription, so not having a tax portion
Tax is subtly different, similar to Coupons/Discounts where we look at how it was charged before. I missed you had removed that TaxRate (because internally I still see it).
Thinking about it, I'm not sure if tax calculation should be included here. My gut says it should not but the API seems to think otherwise.
Can you try canceling for real so we can look at the resulting Invoice?
(I'm working on a reproduction script in the meantime)
crimson bramble
yep! will do
in_1PxFSRBjIQrRQnux4FSWPFrs - it did do a prorated refund, applied it as a credit note on the prior refund, and prorated refund both subtotal & tax
Maybe the workaround on our side should be:
- If the subscription has no tax rate specified, and we would like to refund, then first edit the subscription to specifically set the tax rate we want to refund at
- Then execute the refund?
^ this is actually good behavior, I'm just seeing it inconsistently - I'm not seeing it happen in cases where the subscription itself never had a tax rate set, which is why I'm confused
elder frigate
I mean the CreditNote is your own code driving this right? We're only looking at the proration and the Invoice?
Sorry struggling to follow along at this point. Doesn't look like that Invoice comes from the cancellation itself (unless you did it in the Dashboard and not the API maybe?)
Okay in the meantime I have reproduced and I can see the TaxRate applying to the proration which doesn't make sense to me. Like I changed the quantity from 1 to 2 and it's refunding tax on quantity 2 that I never paid.
This does look like a bug at first read. It's plausible it's not and there's a reason though and I have just never seen this before.