#beast-subscription-integration
compact glen
beast-subscription-integration
- I would say no unless you plan to have multiple Products/Prices per Subscription and need to handle complex updates
- That Event is sent every time a new period starts which is useful. It's also useful to detect changes you didn't expect such as someone doing something in the Dashboard. I would recommend writing some code to look at that Event but it's not required
- Hard to say honestly. I would do custom Prices for this and track this logic on my end
fickle kettle
for 3. is there any advantage / disadvantage to add the custom prices on the existing product tier, or to create a new 'custom product' with all the custom prices on there?
compact glen
The Product is what's used to display what is being sold on Invoices and receipts and such. So I wouldn't do a "catch all Product" personally
fickle kettle
gotcha. And one thing I'm confused about is: Why do you guys recommend to provision access on checkout.session.completed? Because that event can fire even if they inputted the wrong details. Should I not just rely on invoice.paid to provision access?
compact glen
Because that event can fire even if they inputted the wrong details.
no it can't?
checkout.session.completed only fires after the Session completes which is when they enter payment details. For cards it's after the payment succeeds
fickle kettle
for failed bank payments*
fickle kettle
I can't use invoice.paid for banks? That event doesnt get fired?
compact glen
I never said you can't. You asked why we recommend an Event that doesn't work and I'm showing you it does work totally fine. If you prefer to use invoice.paid you can, I wouldn't
fickle kettle
Lol so the event works fine and docs say it works fine but devs here say to use something else 😂
so why wouldn't you use invoice.paid for banks?
not saying it's your fault btw but the stripe docs are p terrible imo
compact glen
I mean we have clear docs that says to use the Checkout Events. You said "this doesn't work" and I showed you it absolutely does if you read the docs that clearly say how to handle async payment methods.
Now you ignore those docs and prefer to use invoice.paid and you can if you want to. That's just not what we recommend
fickle kettle
ok
again, why do you not recommend invoice.paid for banks? What is a potential edge case here that invoice.paid fails to catch for bank payments but checkout.session.async_payment_succeeded handles correctly
compact glen
It's not really about edge-cases. It's about handling Checkout Events for the first payment as the customer went through Checkout and you should be fulfilling differently in that case such as storing Customer and Subscription information first for that first Invoice which you wouldn't do for the subsequent Invoices.
Most businesses would do a custom fulfillment on Subscription "set up"
compact glen
Conceptually invoice.paid works fine too in your case if you're already resilient to that and do something like "if I have never heard of this subs it's likely the first invoice" logic. Most people wouldn't
But I mean if you don't then you need to handle the whole "ignore the first invoice.paid Event since you process it during Checkout Events" it's kinda tricky to do this right
fickle kettle
Yeah no completely agree. I should use checkout.session.completed (and async events) to setup the subscription for the customer. Then invoice.paid to continue provisioning access.
I'm wondering, if we allow users to upgrade subscriptions within the app, should I be using invoice.paid to correctly update their db properties in the BE? Or should I use another webhook
compact glen
there are many Events, it really depends what you are trying to do, there's no "one size fits all" advice here
fickle kettle
Yeah that's why I'm asking you (the expert) lol. Correct me if im wrong, I think invoice.paid should be fine? Because for upgrades, we make the customer pay the prorated amount instantly (thus calling invoice.paid). For downgrades, it downgrades at end of billing cycle, which invoice.paid would subsequently get called and we can correctly provision
golden sentinelBOT
compact glen
then that seems fine yes
fickle kettle
coo - thank you man!
cool
is there a way to know in invoice.paid if it's the 'first' invoice being fired so 'do nothing'?
fickle kettle
beautiful
If I'm upgrading / downgrading subscriptions in the way i explained above (and I upgrade / downgrade them using subscription.update & subscription schedules), do I ever need to worry about updating the subscription ids in the backend? Or should they always be the same.
compact glen
always the same
fickle kettle
got it
I'm a little confused about this:
subscription_cycle indicates an invoice created by a subscription advancing into a new period.
subscription is set for all old invoices to indicate either a change to a subscription or a period advancement.
I'm confused as to when the billing_reason is 'subscription'? It also reflects period advancement?
compact glen
it's about old invoices right?
subscription is set for all old invoices to indicate either a change to a subscription or a period advancement.
fickle kettle
what classifies an 'old invoice'?
compact glen
An Invoice created in the past before we introduced that property.
so it's irrelevant to your situation where it's about future Invoices and you can use that property
fickle kettle
got it!