#jbuck-webhook-brittle
1 messages ยท Page 1 of 1 (latest)
Hello! what exactly is brittle? Webhooks are the opposite of brittle, they guarantee you will get the information/event while the customer might never reach your redirect page
I guess brittle is the wrong word. But creating a subscription, then changing core attributes like the cycle date and collection method seems risky?
what seems risky?
The flow - as suggested here would be:
- user gets redirected from my app to the checkout link
- user completes checkout, which creates a subscription to a single line_item/price with some unknown default subscription settings?
- webhook event fires
- my API changes the anchor dates and collection methods
is that correct?
yes that seems correct. You can also handle this during the redirect. Just know you always need to webhook handler because some customers will close Checkout before the redirect is done
https://stripe.com/docs/payments/checkout/custom-success-page explains how to handle the redirect
Understood RE the callbacks. I was hoping there was a way to further-configure the subscription when i create the checkout session
Rather than having a second back-and-forth to reconfigure it
you can't configure everything in Checkout no so if you want to change the collection_method it has to be done with code for now. Same for the anchor dates
sure, but the 2parameters you mentioned can't be controlled today
Got it - is there any plan to support better subscription-customization via checkout sessions?
not in the near future. collection_method wouldn't make sense on Checkout since they are about sending an email and getting paid in the future which is the opposite of what Checkout is about in that case.
For the anchor date, it's something we want to do but no timeline
Hm not sure i understand what you mean RE the collection_method, could you rephrase/elaborate?
collection_method is charge_automatically by default. You're likely switching to send_invoice and that mode is more for B2B payments where you send them an email and give them 30 days to pay async, often via bank transfer
Ahh - no im looking to keep charge_automatically - so as long as thats the default, Im good ๐
Ah gotcha yes it's always the default
awesome, thanks!
of course! Anything I can help with?
Posting a separate question/topic in the main channel
Will do
I have some questions about reporting usage for a metered subscription. My billing phase is monthly, starting the 1st of each month, and i plan to run a nightly/earlyAM job that reports usage for the previous day. The subscriptions are set to charge_automatically
The timestamp field on the createUsageReport states:
This timestamp must be within the current billing period of the subscription of the provided
subscription_item
Im curious how the ends/starts of the month work. For this month - for example, the billing period would be Aug 1 - Aug 31. Sometime early AM on Sept 1, I will need to report Aug 31's usage. Will that invoice have already been charged?
Also - what timezone is the billing period anchored to? IE - how much time do i have to report this "last day of the month" usage so that its still in that months invoice
Sometime early AM on Sept 1, I will need to report Aug 31's usage. Will that invoice have already been charged?
yup that approach is impossible for the last day of the period. You need to find a way to report the usage before the end of that period
Also - what timezone is the billing period anchored to? IE - how much time do i have to report this "last day of the month" usage so that its still in that months invoice
There's no timezone per se, it's all UTC based and all up to the exact second of thebilling_cycle_anchoryou defined
Hmm so how is this typically handled? I obviously wont know the usage until afterwords - so how/when do I report the last day of the month? and when does it bill?
I obviously wont know the usage until afterwords
what is obvious about that? Most businesses who use metered billing do know and report the usage in real time
so how/when do I report the last day of the month?
You report it before the end of the period. That's the only way. Or you charge it in the following month
and when does it bill?
I worry you're misunderstnading what I said here. Our Subscription API offerscurrent_period_startandcurrent_period_endwhich are the exact Unix timestamps indicating when the Subscription's period starts or ends. It's not "August 31", it's a specific second during that day, defined by thecurrent_period_endwhich is all based on when the Subscription was created (and whether or not you passed/setbilling_cycle_anchor
Got it - so do people typically report usage per unit? In my case - the units are approx 5k per day - that seems like overkill to report per unit?
I guess a better question - to back up is - I want to bill for all usage within a 1 month span. What is the best way to structure that subcription and report its usage?
Got it - so do people typically report usage per unit? In my case - the units are approx 5k per day - that seems like overkill to report per unit?
They report per unit, or they have a cron job every hour or every minute. If they do it daily, then they know that the last day of report is shifted to the next month really
Understood
And (i think) lastly, if different customers are in different time zones, i would set their billing_cycle_anchor to be the start of the month (to the second) in their specific timezone?
Hi there ๐ taking over for @vast summit
Give me a couple minutes to get caught up.
No rush - thanks
If I'm understand correctly, the answer is: yes. All the timestamps used in the Stripe API are Unix timestamps so if you want everything to land on the start of the first day of each customer's respective month, then you'd need to convert whatever that datetime is to a Unix timestamp that's accurate to the second.