#levanto_subscription-events
sturdy lionBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1216910654879957052
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
sick micaBOT
swift rivet
levanto_subscription-events
@lilac mortar I'm afraid there isn't just one Event, there are many separate Events each for their own use-case(s)/goal(s)
See https://docs.stripe.com/billing/subscriptions/webhooks
sick micaBOT
lilac mortar
I was expecting it, I guess what I'm having trouble is to understand the key steps of the whole process of keeping the subscription status in sync between the 2 databases (my app, and stripe account). For example:
- A new user subscribes for the first time with the subscription plan's Payment Link
- With their payment, will a customer be automatically created in my stripe account? (I'll assume it does to continue the next steps)
- An webhook is sent to my application endpoint with the status of the payment so I can handle the result for my application
- In case the payment was successful, I should then update the subscription status of the user on my app database (how do I know which user it was based on the payment data?)
- I then must have another endpoint to receive webhooks for renews or stopped payments to handle the result for my application (again, how would I know which customer is which user on my database?)
- I imagine that with every renew I should also probably check for upgrades or downgrades of the subscription status, is that correct?
stoic flume
A new user subscribes for the first time with the subscription plan's Payment Link
With their payment, will a customer be automatically created in my stripe account? (I'll assume it does to continue the next steps)
Yes, it will create a new Customer, unless you're passing in an existing Customer id - you can do so with the Buy Button : https://docs.stripe.com/payment-links/buy-button#pass-an-existing-customer
An webhook is sent to my application endpoint with the status of the payment so I can handle the result for my application
In case the payment was successful, I should then update the subscription status of the user on my app database (how do I know which user it was based on the payment data?)
You typically wouldn't know. If you want to link a Customer to a User in your own DB, you should implement Checkout Sessions instead where you can explicitly pass in a Customer ID : https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer
I then must have another endpoint to receive webhooks for renews or stopped payments to handle the result for my application (again, how would I know which customer is which user on my database?)
Same answer as previous question
I imagine that with every renew I should also probably check for upgrades or downgrades of the subscription status, is that correct?
I'm not sure i understand what you mean by this? Are you using the Customer Portal to allow your customers to upgrade / downgrade their subscriptions?
lilac mortar
I've checked about Checkout Sessions before, but the way they relate with Payment Links is a little bit confusing.
A basic checkout session has 4 attributes: a line_id with the price_id of the subscription product, the mode (subscription, in my case), and then success/failure urls.
- How would I know the Customer ID before it being created on the case of first buyers? (did you mean User ID?) (I'm separeting User ID as id on my db, and Customer ID as id on Stripe Account) (what is the appropriate way to keep track of them? User ID within Stripe Account or Customer ID within User?)
- Considering it has no reference for my Payment Link, it will open a different page?
- Considering a Payment Link already has a "after payment" display and the Checkout Session has a success/failure url, does it mean that "after payment" won't display anymore? (I just want to show the "after payment" and let them go back or close the window on their time)
- Considering Checkout Sessions are used for payments, how would that work as a way of receiving webhooks of renew status? Also, since I'm receiving an event about a customer, it would not be possible to pass in a Customer ID like I would when the user initiated the action from inside my application
About upgrades/downgrades, my app has 3 subscription plans: Silver, Gold, Diamond.
I imagine it should be possible for them to change plans at some point.
stoic flume
How would I know the Customer ID before it being created on the case of first buyers? (did you mean User ID?) (I'm separeting User ID as id on my db, and Customer ID as id on Stripe Account) (what is the appropriate way to keep track of them? User ID within Stripe Account or Customer ID within User?)
You would be expected to create the Customer ID first. I assume the customer would login to your site before attempting to buy something. So you would link the Customer ID, to your own User ID. Unfortunately, I don't understand the second part of this question what is the appropriate way to keep track of them? User ID within Stripe Account or Customer ID within User?
Considering it has no reference for my Payment Link, it will open a different page?
It depends if you're using the hosted Checkout page or embedded Checkout page : https://docs.stripe.com/payments/checkout/how-checkout-works
Considering a Payment Link already has a "after payment" display and the Checkout Session has a success/failure url, does it mean that "after payment" won't display anymore? (I just want to show the "after payment" and let them go back or close the window on their time)
If you're using the hosted Checkout page, you're expected to build your own success page : https://docs.stripe.com/payments/checkout/custom-success-page. If you're using the embedded Checkout page, you can choose not to redirect : https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-redirect_on_completion
lilac mortar
ok, so the Customer ID inside stripe should be the same as the User ID from my app?
stoic flume
no, Stripe's Customer object has it's own ID
you can choose to pass in metadata on the Customer as a way to identify which User ID it belongs to
It's up to you to write to your own DB, to ensure your own system is aware of that linkage
Considering Checkout Sessions are used for payments, how would that work as a way of receiving webhooks of renew status? Also, since I'm receiving an event about a customer, it would not be possible to pass in a Customer ID like I would when the user initiated the action from inside my application
Checkout Sessions are used to allow Customers to subscribe to a Subscription also : https://docs.stripe.com/api/checkout/sessions/object#checkout_session_object-mode. You receive webhooks the same as if you were to use Payment Links.
you might want to go through this document : https://docs.stripe.com/billing/subscriptions/webhooks
I don't understand this part : Also, since I'm receiving an event about a customer, it would not be possible to pass in a Customer ID like I would when the user initiated the action from inside my application
you can take a look at the quickstart guide to see how Checkout works : https://stripe.com/docs/checkout/quickstart
lilac mortar
I'm imagining that between the 2 options (User ID inside a Stripe Customer Metadata, or Stripe User ID inside a User on app's local db), one is more appropriate than the other. Do ou suggest it doesn't really matter and I should just go with which I prefer best?
stoic flume
you should have both
lilac mortar
oh ok, this solves part of my questions
The other thing is, if I'm understanding it correctly, Checkout Sessions and Payment Links have similar functionalities but are completely independent and do not mix with each other
stoic flume
Payment Links use Checkout Sessions under the hood
Payment Links are mainly to allow you to have a single link to easily collect payment
lilac mortar
hmm
but how does the "after payment" display that Payment Links has work with Checkout Sessions?
Would checkout Sessions just automaticaly redirect to the url parameter setted, before the after payment display?
stoic flume
Payment Links was originally built as a no-code solution, it was only later that it was expanded to support creation etc via the API
Checkout Session users have a development team / developer, and the expectation is that they are able to create their own success page, that also allows for greater customization / processing
yes, Checkout Sessions would redirect to the success URL upon payment completion
lilac mortar
ok, so in summary, even though Payment Links automatically creates Customers upon payment, and have a "after playment" display included, If I want to have the subscription status of my users locally synced with the customers in the stripe account (which I imagine every application with subscription limited access needs), I can not use Payment Links and should use Checkout Sessions, creating the Customer beforehand and having to create a success/failure page as well (just because I need a customer reference)?
stoic flume
like i mentioned previously, you could theoretically use a Buy Button also which allows you to pass in an existing Customer id : https://docs.stripe.com/payment-links/buy-button#pass-an-existing-customer
you would still need to create the Customer beforehand
but if not, then yes, you would want to use Checkout Sessions instead
lilac mortar
oh, a Buy Button at least takes care of not having to create redirection pages
stoic flume
you can try it out and see if it works for you
lilac mortar
it's the middle ground, seems the best solution after all
stoic flume
it has it's own limitations e.g. a frequent feedback that i get is that folks want to be able to adjust the size of the button (but it's not possible at the moment)
lilac mortar
damn .-. I was actually expecting I could style it anyway I wanted
stoic flume
anyway, play around with it and see how it goes, maybe the customizations that we allow might be sufficient for you
lilac mortar
ok, about the case of renews, It's just a matter of creating a webhook and updating the subscription status locally, right?
stoic flume
at a high level, yes
lilac mortar
and the last thing, how should upgrades/downgrades of subscription plan be handled?
allow the user to pay for alternative plans and cancel the current one immediately?
stoic flume
that's really up to you / your business model. More importantly, how are you planning to allow Customers to upgrade/downgrade? Are you planning to build that functionality, or use the Customer Portal?
you don't have to cancel the old Subscription, you can upgrade/downgrade the existing one : https://docs.stripe.com/billing/subscriptions/upgrade-downgrade
lilac mortar
I understand that the dynamics of this vary from applications and their preferences, but at the same time I imagine the Stripe may have some restricting "rules" due to the way it works that limits how it has to be done (or something related to the nature of subscriptions).
In my case I have a subscription page any user can access at any time and select a subscription plan that immediately opens the Checkout page, the only rule that came into mind is not let them resubscribe manually, so the subscription button for their current subscription plan will be innactive. But I wonder If due to some nature of Stripe Subscriptions I would have to add some rules to the other plan's buttons as well
hm, ty for the link, this downgrade invoice creditting worries me a bit
stoic flume
I'm not quite able to link what you mentioned to upgrading / downgrading. Based off what you just said, it sounds as if you're only going to allow a customer to subscribe to one Subscription at a time. So how do they upgrade/downgrade? What limitations do you want to impose?
lilac mortar
yeah, at first I was ok to let them upgrade/downgrade at any moment, as long as they are paying again for every update, but considering that downgrades in the middle of a subscription period might be considered subject to refund adjustments, It will be better to only allow downgrades after the end of the subscription period
tecnically wouldn't be a downgrade, more like a new choice hehe
stoic flume
downgrades and upgrades in the middle of a subscription period will prorate by default (unless you're using metered pricing in which case, there's no prorations). It sounds like you don't want to have to perform a refund (in case there's extra money leftover after the proration) which is fair
lilac mortar
hm I guess it's better to simply disable the subscription buttons while the account is not back to free status then
stoic flume
if you want to downgrade after the end of the billing period, you're going to need to look into Subscription Schedules
lilac mortar
oh, schedules are a good alternative
stoic flume
If you're planning to allow them to update (without cancelling the original subscription first), you'll want to go through https://docs.stripe.com/billing/subscriptions/pending-updates
lilac mortar
but I'll start with the bare bones first, and later add it
stoic flume
in case you haven't seen this yet, you can use test clocks to mimic the passing of time : https://stripe.com/docs/billing/testing/test-clocks
