#tounka
surreal flower
Nothing automatic, but you can certainly build this yourself.
What do you mean by "once their subscription expires" exactly?
surreal flower
Yep, so in those cases you can use the events to take any action you like to restrict access
Note you could also configure automatic payment retries & cancelation after those fail, and just use the cancelation events if you like
But that's up to you
smoky moss
where can i do automatic payment retries? and in what scenarios does it make sense to do that
surreal flower
See here about payment retries: https://stripe.com/docs/billing/revenue-recovery
It includes a link to dashboard settings to manage failed payments
For example, maybe a card is declined with insufficient funds. Do you want to cancel them right away, or wait and let the payment try again in a couple of days?
smoky moss
when i activate live mode, will all my setting from test mode be 1:1 or can i use different settings, and urls?
surreal flower
Most subscription settigns are global, applying to both live and test mode
to test behaviour with different settings I recommend creating a separate test mode only account
candid anchorBOT
smoky moss
so have two stripe sccounts?
what about settings for things like links to the customer portal and callbacks, webhooks etc
wheat orchid
Hi there 👋 taking over, as my colleague needs to step away
I'm not sure what you mean by your question. You can test all those things a myriad of different ways. Settings in the Dashboard usually apply globally, but there are specific API parameters or configurations that you use to dictate the behavior on a per-request basis.
smoky moss
for example, in my test env, i would want my STRIPE_SUCCESS_URL url to be checkout.test.billing.com but in production i want it to be checkout.billing.com is it possible to do this?
wheat orchid
Yeah, that's possible. You would just need a way to know whether it was a test or live event at the time of creation. You set the return url when you create the Checkout Session
smoky moss
what do you mean by "You would just need a way to know whether it was a test or live event at the time of creation"
wheat orchid
Well, if you set return_url on the Checkout Session when it is created, then you could choose to set it to either checkout.test.billing.com or checkout.billing.com depending on if you used your test mode API key or your live mode API key
smoky moss
right, that was a bad example. in the stripe console for my customer portal, i'm using checkout.development.domain.com and for prod i plan to use ``checkout.domain.com`
wheat orchid
I'm not sure what the point here is. The workflow is the same
smoky moss
the difference is my development site will be interacting with my all things dev
not sure what you're getting at
wheat orchid
"the difference is my development site will be interacting with my all things dev"
What does this mean?
smoky moss
my app is deployed in two environments. if i'm interacting with my site that's in our dev env, idk if i'd want the portal to be linked to the same portal my real users use
dev site -> click on customer portal -> view portal with the dev url
prod site -> click on customer portal -> view portal with the prod url
wheat orchid
I'm not sure what you mean by "linked" since one request goes to live and one goes to test based on which API key you use, but if it's less complicated, you should just create 2 separate Stripe accounts