xblackshadow_api

[little yoke]

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

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

[vagrant cairn]

Your expectation here would be to charge £30 on 24/7, and then keep the billing anchor on 29th and not charge again until 29/8?

Which is tricky as the upgrade on 24th would reset the billing anchor to that date going forward, which means for a monthly price it'd always be 24th

[limpid dirge]

Yep, we want to add the remaining days to new plan instead of prorating

[vagrant cairn]

Hence why a trial period is often used to shift the anchor as required

[limpid dirge]

But using trial period charges the customer on the next invoice (29/7) instead of charging immediatly, ikr?

It would not matter for a weekly plan because we already have a 7 days refund period. But if a customer wants to upgrade from 6 months plan to yearly plan after using the 6 months plan for only 1 day the system will create a trial period for nearly 179 days to the next invoice

[vagrant cairn]

Yeah I mean what you want just isn't natively supported easily – there's no concept of 'adding on days to period' as you describe it. You need to shift the anchor and the only way to do that is via an additional period where you don't bill them (hence the trial period)

You could inverse it so you charge them the full monthly amount on 24th and then make a subsequent call to apply the trial period post update to fix the anchor back to 29th