#jbuck-webhook-brittle

1 messages ยท Page 1 of 1 (latest)

vast summit
#

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

cloud marsh
#

I guess brittle is the wrong word. But creating a subscription, then changing core attributes like the cycle date and collection method seems risky?

vast summit
#

what seems risky?

cloud marsh
#

The flow - as suggested here would be:

  1. user gets redirected from my app to the checkout link
  2. user completes checkout, which creates a subscription to a single line_item/price with some unknown default subscription settings?
  3. webhook event fires
  4. my API changes the anchor dates and collection methods

is that correct?

vast summit
#

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

cloud marsh
#

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

vast summit
#

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

cloud marsh
#

I am using code to generate the checkout

#

stripe.checkout.sessions.create

vast summit
#

sure, but the 2parameters you mentioned can't be controlled today

cloud marsh
#

Got it - is there any plan to support better subscription-customization via checkout sessions?

vast summit
#

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

cloud marsh
#

Hm not sure i understand what you mean RE the collection_method, could you rephrase/elaborate?

vast summit
#

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

cloud marsh
#

Ahh - no im looking to keep charge_automatically - so as long as thats the default, Im good ๐Ÿ‘Œ

vast summit
#

Ah gotcha yes it's always the default

cloud marsh
#

awesome, thanks!

vast summit
#

of course! Anything I can help with?

cloud marsh
#

Posting a separate question/topic in the main channel

vast summit
#

no please

#

just ask here, you already have a thread

#

cc @cloud marsh

cloud marsh
#

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

vast summit
#

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 the billing_cycle_anchor you defined

cloud marsh
#

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?

vast summit
#

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 offers current_period_start and current_period_end which 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 the current_period_end which is all based on when the Subscription was created (and whether or not you passed/set billing_cycle_anchor

cloud marsh
#

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?

vast summit
#

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

cloud marsh
#

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?

valid rain
#

Hi there ๐Ÿ‘‹ taking over for @vast summit

Give me a couple minutes to get caught up.

cloud marsh
#

No rush - thanks

valid rain
#

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.