#jds_best-practices
granite viperBOT
đ 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/1362117047529636182
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
snow temple
Hi, CheckoutSessions allow you to create a subscription or collect payment method details. Once the subscription is created, you'd want to use CustomerPortal, https://docs.stripe.com/customer-management/integrate-customer-portal which allows your customers to manage their subscription. You can configure the specific price/product you'd want your customers to change to.
Alternatively, you can make calls on your server-side to change the price on the subscription: https://docs.stripe.com/billing/subscriptions/change-price
Let me know what specific questions you have after reviewing the above
peak pawn
Mm, I've been avoiding Portal because we already have that handled natively in our site, so bouncing customers to a third-party page seems like a downgrade.
The server-side approach might fit better with our current setup, but does feel like I'm re-writing a lot of the Checkout::Session stuff to do so. For example, our server-side code sets up an invoice (Stripe::Invoice.create_preview) showing the effect of switching your subscription, which I then need to present to the user, but the invoice you get from there is a different format to the invoice line items / tax rates / etc that you get from useCheckout(). And we normally let users change their payment method during the checkout process of changing their subscription, but then I guess I need to maintain both Checkout::Session for setting up new subscriptions, and CardElement along with our own custom invoice code for altering subscriptions
snow temple
After you create the subscription from the CheckoutSession, you can set that payment method as the default one on the customer: https://docs.stripe.com/api/customers/update#update_customer-invoice_settings-default_payment_method and then use that payment method details when you make the update on your server-side. I do not know what your flow looks like now. However, if the end customer wants to use another payment metod for the subscription update, I guess CardElement would work. Althought, I think CheckoutSession is Setup mode might be a good solution too.
peak pawn
Hmm, ok - thanks for the suggestions, I'll give them another shot.