#ironbeard_api

1 messages ยท Page 1 of 1 (latest)

ionic boneBOT
#

๐Ÿ‘‹ 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/1397999523984441374

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

tardy path
quasi brook
#

Interesting. So one subscription could have two products with the same frequency (annual) but different billing_cycle_anchors?

#

When was mixed-interval announced?

tardy path
quasi brook
#

Oh, yeah just saw that too

#

I think the thing we want to avoid is someone buying the $150 newsletter and then immediately "upgrading" to the $2,000 "all regions" data and not paying for a year (but having access to the data). So upgrades must be paid immediately, hence always_invoice+now.

#

So, is there a way to prorate one item (newsletter) to avoid this?

tardy path
#

Ooo

#

One sec.

quasi brook
#

(looking at flexible billign docs now, that wasn't available when I first made my integration)

tardy path
#

I think you likely will either need to prorate the "data charge" and leave the billing cycle anchor the same, or else use two subscriptions here - I don't think there's a way to pull off what you want to do without causing over- or under-charging.

quasi brook
#

I'm trying to remember the justification for moving the billing cycle anchor.

#

If we keep the billing cycle anchor fixed, the customer still has an immediately due invoice if they upgrade, right? e.g if they sub to the newsletter for $150 on Jan1st, and then on Dec31st they want to upgrade to the data at $2,000---

Oh, that's what it was! Previously, the prorate would only charge them 1 day of the $2,000, and then on Jan1 they'd owe $2000 + $150 (but they could cancel before they pay the $2150).

Is this still how the prorate would work if billing cycle anchor was fixed?

tardy path
quasi brook
#

but if I prorate the data plan, then they could ostensibly pay just for a single day of the data, right? e.g. ugprade on Dec 31st and the proration would calculate one day of $. Then they could download the data and cancel the plan before the billing cycle anchor of Jan 1st.

I think, due to the nature of being a SaaS, that we always need to collect the full amount of the data plan up front.

Or could I generate an invoice for the full amount that would then get applied as a proration the following day. E.g on Dec 31st they pay $2,000 but then on Jan 1st they only have $150 + a little extra due, that covers the following entire year?

ionic boneBOT
tardy path
#

So sorry.

Yes you're correct, but then when the subscription renews, they'd pay the $2000 + $150.

Any other option is going to result in over- or under-charging I think - except for what you're currently doing.

quasi brook
#

You're fine ๐Ÿ™‚

#

Could I make a one time charge of $2,000 when they upgrade and do it in a way where they'll have some credit when the subscription renews?

#

e.g. they pay $2,000 on Dec 31st, and then on Jan1st when they subscription updates (newsletter + data), they have $2,000 - 1day of credit applied to the invoice?

jolly badge
#

๐Ÿ‘‹ taking over for timebox, just getting caught up.

ionic boneBOT
quasi brook
#

No rush from me, just didn't want the bot to close this bc inactivity:)

jolly badge
#

I'm just trying to think if any of these work arounds are actually simpler than having two Subscriptions.

ionic boneBOT
quasi brook
#

thanks ๐Ÿ™‚

digital iris
#

Hello, apologies for the delay. Yeah I think that one off invoice items would be one of the more straightforward ways to do this if you are sticking to one subscription. You could maybe use the preview invoice endpoint to see how much would be credited if the newsletter was cancelled for the rest of the cycle and then credit for that when making the update that resets the biling cycle anchor.

Do you have any questions around the various options that have been proposed here?

quasi brook
#

If I prefer to have a single subscription (that could potentially contain both a newsletter and data), is it possible for me to create a single Invoice when some wants to add Data to their subscription in a way that 2) Charges the full amount for the data immediately and 2) provides the subscription with credit when the cycle repeats?

e.g. user pays $150 on Jan 1 2025, for newsletter, then Dec 31 2025 they pay $2,000, and then on Jan 1st 2026 their subscription renews but it only costs ~$155.48 (e.g. 150 + 2,000/365). Then one more year later on Jan 1st 2027 it'd be 150+2000?

#

The idea being they pay for the full cost up front, but when their subscription updates on Jan1 2026, they only need to pay for the extra day at the end of 2026

digital iris
#

Trying to rephrase that to see if I understand. So they pay 2000 on Dec 31 and are essentially credited for 364 days, then on Jan 1 they pay for just 1 day of that year essentially?

quasi brook
#

I think so. The idea being, that on Dec 31 they're paying for a full year up front.. and when the subscription renews, they only owe the difference of the 1 day at the end of the following year that they didn't cover

digital iris
#

Gotcha, and you want to do this without resetting the billing cycle anchor. I am trying to think of the best way to do this parameter-wise with the API. Immediately invoicing but charging the full price is tricky if you aren't resetting the cycle.

quasi brook
#

Right, if we reset the cycle then the prorating prevents them from paying the full $2000 right?

#

If we reset the billing cycle and make them pay the entire invoice up front, then they're paying twice for the newsletter (assuming they had newsletter and then added data). I would want them to only pay the added price up front (aka the data)

digital iris
#

If you reset the cycle you would be charging the full $2000 but you are right that the issue with that is that they're paying for the full newsletter amount again too. You can mitigate that if you want by crediting for the already paid for time on the newsletter (so in your example credit for the remaining 1 day of newsletter for the current cycle and they pay for 364 days along with the new data subscription).

For what you laid out with keeping the cycle the same, I think the best way to do this would be with two subscription update calls. Our default proration behavior can't do what you want because we would try to credit for the amount already paid for data so far. So I think you'd want to make one update call with proration_behavior='always_invoice' and use add_invoice_items to create a one time $2000 item. This charges them immediately but the subscription is still on the old data plan, so once you see that the invoice from that first update is paid you can then make an update that actually swaps the data price ID and use add_invoice_items to create the credit item that you want to.

ionic boneBOT
quasi brook
#

I think I understand. So only have one subscription per customer. In the event that they are adding to their subscription, I update the subscription(?) with "always_invoice" and "add_invoice_items", which will add the $2000 to the INVOICE but not the SUBSCRIPTION.

Then, when the payment is confirmed, I can make a second update to the subscription and add the data price to the subscription items and I can also add a credit using add_invoice_items?

digital iris
#

Exactly! That is the most straightforward way to do this as one subscription.

quasi brook
#

Thanks, I think that sounds good. I need to look more into add_invoice_items, but it feels right.

I hate having to worry about edge cases that will never happen lol

digital iris
#

Definitely a good one to have recognized though! And glad we could find a decent workaround

quasi brook
#

Thanks for your help ๐Ÿ™‚