#cfbo

1 messages ยท Page 1 of 1 (latest)

rustic trench
atomic gale
#
  • My application subscription flow (intended): a user can sign up to the free version (identity created in AWS Cognito). Then they can upgrade to PRO from their profile page.
  • If no UserSubscription record exists, then there is a subscribe button allowing. When they click, a checkout session is created, which is carried out by the stripeCheckout lambda, which is also responsible for creating a basic UserSubscription where some initial stripe information are persisted (stripeCustomerId, stripeProductId, stripePriceId, stripeCheckoutSessionId).
  • The stripeWebhook receives events from stripe.
  • When the checkout session completes, the webhook receives a customer.subscription.created with status incomplete: it will retrieve the UserSubscription via graphql and persist some information (currentPeriodStartDate, currentPeriodStartDate, stripeSubscriptionStatus)
  • If the payment is successful, from what I understood there should also be a customer.subscription.updated with status active. Similarly to the creation event, the webhook will retrieve the UserSubscription and update some info (most importantly it will update the status).
  • the business logic in my application will take action based on the UserSubscription for a given user. It will also consider the PRO version active when the stripeSubscriptionStatus is active
#
  • The application also uses the Customer Portal (redirect) to allow users managing their subscriptions
rustic trench
atomic gale
#

Yes

#

I have been through all of that

rustic trench
#

is there a specific portion which you need more clarification on?

atomic gale
#

I was hoping to have a bit more direct feedback

#

It's a bit complex

#

also

#

the point is I am still not sure if I need all the events

#

If I could do only with customer.subscription.created, customer.subscription.updated, customer.subscription.deleted

#

or not

#

based on my internal model

#

From what I understood, the design/solution is not unique

#

I guess it depends on specific needs, internal application design,etc.

rustic trench
#

It definitely does depend on your specific needs etc.

The advice which I can provide is that you would need to consider each use case / scenario for your application and then decide how you can achieve that.

For example, like how you've already identified that you would need a customer.subscription.created event to log certain details into your database.

atomic gale
#

Thanks for your help. Yes I understand. Ok let's put it like this. I was trying to write down my actual application needs and details so that I could validate into more detail if my design makes sense, or whether I am clearly missing something.
Maybe I am asking too much, I wasn't sure which kind of assistance you guys are allowed to provide ๐Ÿ™‚

#

What I would say is, if and when there is time, I would be more than happy to discuss through some details, that's it. If not possible no worires

rustic trench
#

i think it would help if say you had a specific scenario e.g. I want to be informed of when my customer cancels a subscription -> we can give suggestions.

A high level overview is difficult to provide advice on because there's just so many possibilities and it depends on your business use cases. Our documentation probably explains it even better than what we can do over discord for a high level overview

#

but please do reach out if you have issues or questions anytime, we'd try our best

atomic gale
#

Thanks. From the documentation I see the following

#

My question is: from your experience, do you think it is strictly needed to listen for all the events mentioned there, or is it enough to listen for the events I mention above?

#

Where my use case is the one described above

#

I just want to be able to manage PRO access to my application

#

Anyway, it's fine. I could go into more details if the discussion allows it. Otherwise let's keep it like that. thanks

rustic trench
#

ah, in which case, no you wouldn't need to listen to all those events. Specifically to manage PRO access to your application, i would say customer.subscription.update -> to check that status : active (and allow access), and customer.subscription.deleted -> to stop access once the subscription is deleted

atomic gale
#

Ok thanks. I'll try like that then. Do you know what are the scenario when customer.subscription.deleted is sent?
I have seen it being sent for example when I manually delete a customer from stripe

#

But in my case, from the application, I don't think it happens

#

because for in the user portal options I have set that the recurring payment should be cancelled at the end

#

I am not sure if at the end of that month (after the user cancelled a subscription "at the end of the month") I will also receive a deleted event

#

Also, I have read about the fact that events are async

#

Is there a chance that a customer.subscription.created (status incomplete) event arrives after the customer.subscription.update (status active)?

rustic trench
#

if you cancel a subscription, you will also receive a customer.subscription.deleted event

atomic gale
#

even if you select at the end of the billing period? I thought I tested it and didnt see it

#

will try again

rustic trench
#

yes, it's possible that you may receive one event before the other. tl;dr : you should not rely on events to be delivered in a particular sequence

atomic gale
#

then my design won't work I think

#

at the moment I don't have an idea on how to solve that async problem

rustic trench
#

in that scenario where you choose to cancel at the end of the billing period customer.subscription.deleted event will only be sent when the subscription is cancelled at the end of the billing period -> does this make sense?

atomic gale
#

what I have is something like that

atomic gale
#

the deleted event to be sent at the end, when the sub actually expires, is that right?

atomic gale
# atomic gale

that's unrelated to the deleted event, it's going back about async events handling

#

that's all I do right now

rustic trench
#

yes, the deleted event will be sent at the end, when the sub actually expires

atomic gale
#

about the async events, any advice?

rustic trench
#

onesecond let me think about it for a bit

atomic gale
#

from a design point of view

#

ok

rustic trench
#

@atomic gale to clarify, are you using Stripe Checkout with cards only?

#

or are you accepting async payments as well?

atomic gale
#

you know, I am not sure actually... where should I check that?

#

from the stripe dashboard?

#

configuration

#

?

rustic trench
atomic gale
rustic trench
#

yup, so you're using card only

atomic gale
#

async payments would be like bank transfers?

#

ok I have seen the list.. ok let's say I am using cards then

rustic trench
#

yep, bank transfers are considered async methods

#

so since you're using cards, cards are a synchronous payment method

#

what i would suggest you do in this case, is to listen for the checkout.session.completed event

atomic gale
#

in the webhook right?

rustic trench
#

yep, hmm, let me check if the subscription start and end dates are included there as well

atomic gale
#

also, not sure about cards with weird behaviour like ones listed in testing section of stripe docs

#

Maybe that is handled by the checkout session events, not sure

#

like.. for any cards that is failing in some way then I would't receive a checkout.session.completed event... maybe!

#

Wait...

#

I have recurring subscriptions

#

so checkout events are not enough I think

rustic trench
#

recurring subscriptions will charge the card setup during checkout

atomic gale
#

man.. it's tricky ๐Ÿคฃ

rustic trench
#

if payment fails, there is a setting in Stripe which will send them an email to ask them to update their billing details

atomic gale
#

ah, that's good to know

#

ok so which events are you suggesting to listen for then?

#

the checkout.session.completed

#

and payments?

#

and no subscribption events?

rustic trench
#

i assume you need to store the subscription start and end dates for the cycle?

atomic gale
#

yep

#

as suggested in many examples, the application logic would use these dates saved in the application storage (dynamoDB in this case) to establish if the subscription is "active"

#

now in the design that I have now, I would also have looked to the subscription status, which would have been updated by subscription events

#

but if I scratch the subscription events in favour of the other ones, than not sure

#

I think we are a bit back to the start.. there are many events and many potential flows. Ideally, I would have thought that if one is purely interested to subscriptions, than they could just listen to subscription events..

#

And potentially it works, it's just I am not sure about async

rustic trench
#

@atomic gale give me a few moments, i'll get back to you once i test it out

atomic gale
#

ok great thanks man

#

I'll be also doing some test

rustic trench
#

@atomic gale sorry about all the confusion here, i think invoice.paid would work better since it has the details you're looking for

#

ignore what i said earlier about using checkout.session.paid

atomic gale
#

ok thanks, so to summarize.. the list of events to list for would be:

#

invoice.paid

#

and that's it?

rustic trench
#

customer.subscription.deleted

#

so invoice.paid would allow you to track that the subscription has been created/paid for that cycle

#

but you would also want to track when the subscription is cancelled

atomic gale
#

Ok thanks for the feedback. I am thinking. Something I didn't mention is that I have a product with 2 prices. But I don't think that changes anything.

rustic trench
#

yep, it probably doesn't

atomic gale
#

I may not allow switching price until the end of the cycle

#

Ok.. I will try this out. I'll come back to you. Thanks for the help in the meantime ๐Ÿ™‚

rustic trench
#

Hope you have a great day and please don't hesitate to reach out in case you have any other questions!