#lolztheoreo_unexpected

1 messages · Page 1 of 1 (latest)

sonic leafBOT
#

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

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

celest rapids
#

Can you share some IDs please, mainly the sub_xxx ID and related invoices

bleak geyser
#

Payment ID: pi_3PhrLyAaUXuXv6pv1LKjdOOi

SubscriptionId: sub_1Phq7XAaUXuXv6pvFDB9qT5w

#

invoiceId:

in_1PhrLyAaUXuXv6pvtcMgqdVr

celest rapids
#

Important to note that we prorate to the second, so whilst your dates are accurate and account for the exact amount the 8% exclusive tax rate is nudging them higher than the expected amounts

bleak geyser
#

hmm, so it's actually a tax calculation issue? Because with the tax rate not changing, I would expect to see the same refund as initially paid given the timestamp matches down to a second?

#

I'm assuming I might have to change my implementation to instead cancel the subscription entirely and re-open a new one.

But given our system is built on this upgrade implementation I would rather not have to do that

celest rapids
#

Hmm, actually I think there's a discrepancy in the timestamps:

  • proration_date: 1721779200 (2024-07-24 01:00:00)
  • period end/start: 1753350239 (2024-07-29 10:43:59)

That accounts for a larger time fraction to multiply against the original $195 of unused time

bleak geyser
#

Is this avoidable? I'm calling my initial subscription creation with
backdate_start_date: 1721779200,
billing_cycle_anchor_config: {
day_of_month: 24,
month: 7,
},

#

Will the period start always be at the point of creation, and therefore this behaviour is unavoidable?

celest rapids
#

Alluded to here:

Another way to think about the calculation is to look at the backdated start date as the original start date and the beginning of the first full billing period as an updated start date.
https://docs.stripe.com/billing/subscriptions/backdating?dashboard-or-api=api#backdating-no-charge:~:text=Another way to think about the calculation is to look at the backdated start date as the original start date and the beginning of the first full billing period as an updated start date.

Backdating subscriptions

Learn about backdating subscriptions.

bleak geyser
#

hmm, okay. It's looking like it will be much simpler then for me to recreate things as a brand new subscription.

Unless I'm missing something, just to add, I have found it really challenging trying to work with a subscriptions flow which has a fixed billing period.

E.g we have 3 tiers of pricing, whenever a user upgrades they pay full price and it will still expire at the end of the fixed billing period

#

I do think the behaviour I shared has an issue also, as being $0.50 out is definitely unusual, and I would expect it to behave as I have detailed

#

If you have any suggestions to get the exact amounts reflected in the invoice, I'd really appreciate that

celest rapids
#

Where is the $0.50 you referenced? I've explained why it's not exactly $195 and is $195.22 credit instead (because of the timestamps and how we calculate proration, and how backdated start dates don't affect the actual billing period dates)

#

Ah, the $450.50. And that's because of the same timestamp issue – you're calculating proration to a date that differs to the actual billing period