#lucas-subscriptions-questions

1 messages · Page 1 of 1 (latest)

lusty mica
#

Hi there!

#

Reading

junior raft
#

👋 so for point 1 we do have this feature in our product already. You can listen to the invoice.upcoming Event which tells you about the next invoice ahead of the next period. You can configure it in the Dashboard here: https://dashboard.stripe.com/settings/billing/automatic
You'll see that we also support sending those emails to the end customer for you automatically

#

For #2, this is unfortunately really hard to do with Billing today. There is a tight coupling of the Subscription's period and when the Invoices are created/paid and what period those represent

wispy olive
#

hello - thanks! that looks promising (invoice.upcoming) -

  1. can I customize the days, or am I restricted to 7/15/etc?
  2. can I make more than one?
junior raft
#

restricted right now to the exact number of days, and you can only have one. The rest you have to build yourself with your own cron job

#

So if you want a Subscription to be for September 1st to October 1st, it can only charge on September 1st. You can't have it "charge on August 23"

#

This is unfortunately a hard limitation and likely why they used the trial "hack" (which is definitely not good)

wispy olive
#

gotcha. is there a better slightly less hacky route you'd recommend? like setting the billing_cycle_anchor?

junior raft
#

I think you need to decide what is the most important overall: charging 7 days in advance (and fine with the Invoice reporting the wrong period) or having the Invoice report the correct period (and fine with not charging in advance)

#

You won't be able to get both today

wispy olive
#

what are the implications of the invoice reporting the wrong period ?

The big drawback to not charging 7 days in advance is that we want to collect payment and ship well before the medical supply runs out, and we'd rather rectify failed payments at that time too, so I think the former is the right move for us, but want to make sure I understand the risks/repercussions

#

follow on question if that's the right move - rather than using trial period, it feels like i would need to make the first recurrence period n-7 days, and the rest can be n days - basically, shifting the first period slightly shorter

#

the prescription refills are definitely more of a "timed charge" compared to like a "first of month to first of month" or "prorated billing access to a resource" sort of recurring charge

junior raft
#

Yeah basically the Invoice would have August 23 - September 23 as the period

#

or you'd build your own Invoice/reporting/email instead

#

And I definitely understand, it's similar to like BlueApron and such, where you don't ship until you're guaranteed the payment has gone through so you want to charge ahead of shipping to have the right inventory

wispy olive
#

yep, exactly

junior raft
#

My read is that the payment has to be on the right cycle, so on August 23 or September 23 and that's what matters the most to you

#

So I'd focus on that, I'd have my subscription anchored to that date and drive the payment behaviour

#

and separately I'd do my own invoices

wispy olive
#

thanks! i'll look at the Subscription api and see how to alter the billing cadence to suit our needs (rather than abusing trial_period) and go from there