#Andreas

1 messages ยท Page 1 of 1 (latest)

dull garnetBOT
timid copper
#

Hi there ๐Ÿ‘‹ I don't believe so. I just double checked the parameters available inside of subscription_data when creating Checkout Sessions and did not see anything related to prorating or changing the initial billing cycle anchor.

If your goal is to discount the initial payment, then you may be able to accomplish that by adding a Coupon to the session via the discounts parameter.

obsidian dust
#

Thanks! Unfortunately my reason for wanting to do this is that we want to do usage based billing at the end of the month, so we don't want the user to be billed mid-month, but instead have them pay their flat fee for either half a month or 1.5 months in that case.

timid copper
#

Our usage-based Prices are billed in arrears, so they won't charge an amount up front during the Checkout Session. You could add a one-time fee to represent the part that you do want your customers to pay when first signing up, but if your goal is to set the billing cycle anchor to a specific date then you will need to update the Subscription after it's created anyway (or use a trial period to set when the billing cycle anchor will be).

obsidian dust
#

Right, sorry. I might need to add some context.

Our setup is as follows:

You create a subscription for a plan (say $99/month), and additionally a usage based subscription that includes 1000 free entities/month, which charges at $0.015/unit after the 1000 have been exhausted.

We only tally the usage on the 2nd of the month, and want all future billing events to happen on the 5th (to allow a grace period where we can do corrections if any issues arise on our side).

So if I sign up for our subscription on the 15th of the month, my billing date will always be the 15th, which will not match up with our usage calculations.

Therefor I want the user to only pay for the remaining days of the month (15th - End of month), for their $99/month plan, and then next time we bill them (on the 5th of the following month) we bill the usage since Month 1, 15th to Month 1 31st, + $99 for the subscription on Month 2.

Does that make sense?

timid copper
#

Gotcha that makes sense, but sounds a bit too complex to neatly model using Checkout Sessions.

An option you can consider, is using a Checkout Session in payment mode to collect payment for the initial prorated amount, and use payment_intent_data.setup_future_usage to optimize the customer's Payment Method for future off session usage. Then you could create the Subscription server-side according to your needs, and pass it the ID of the Payment Method that was created to use as its default payment method for paying the generated Invoices.

obsidian dust
#

Hm yeah, that was what I had researched my way to myself too. Sounds like the way to go then. Thanks for the input! ๐Ÿ™Œ

timid copper
#

Any time! Good luck and feel free to reach out if anything gives you trouble while you're setting that up.