#crawl-sub-upgrades

1 messages · Page 1 of 1 (latest)

mystic emberBOT
cold merlin
#

In terms of whether you need user consent - that depends on your business model and would be something you need to decide on your end

craggy verge
#

Ok

#

Is this only for the same product with different price ?

#

Or I can change the subscription of a user (to a completely different product)

#

(And we're trying to do pro ration too)

mystic emberBOT
#

crawl-sub-upgrades

cold merlin
#

It can be for different products and different prices

craggy verge
#

@glossy plover will continue from there

mystic emberBOT
glossy plover
#

@cold merlin Thank you very much for assisting us in this issue.

As @craggy verge mentioned, we are in the process of implementing an upgrade/downgrade logic within our system. Right now we have various Stripe products corresponding to different subscription tiers in our application. Our objective is to enable users to seamlessly upgrade or downgrade their subscription tier with a simple click, transitioning immediately while applying proration for charges. Our current approach involves using the Stripe Checkout API; At signup, We provide clients with a Stripe Checkout, allowing them to proceed with the purchase. However, when the user attempts and upgrade/downgrade, we want to switch the subscription (product) to the new one, apply any proration if applicable, and apply the new subscription immediately. Could you kindly guide us on the best approach here? Should we consider transitioning to using payment intents instead of checkout? If further clarification is needed, please feel free to ask. Thank you.

cold merlin
#

You can continue to use Checkout for the initial Subscription creation - you'll just need to implement a separate flow to support upgrades (using the docs I linked you to earlier)

craggy verge
cold merlin
#

Correct

craggy verge
#

What if we want to avoid links, and make the changes per user request directly from our API

The client will prompt a confirmation modal, and once confirmed our api do the job and switch the product while having the correct pro ration

cold merlin
#

Sorry let me be clear - for Subscription updates you can't do those through Checkout. You can do those through the API w/ the confirmation modal you're describing

#

Checkout would only be for creation

glossy plover
#

Thank you - In other words (and technically speaking) we need to transition towards using payment intents for subscriptions updates?

cold merlin
#

Yes (although I wouldn't really call it transitioning towards Payment Intents - you're simply transitioning to using the Subscriptions API directly)

glossy plover
#

This makes sense. To confirm our understanding:

  • For the initial subscription creation, we have the choice to use either the Checkout API or the Subscription API. Regardless of the choice, the ultimate outcome should be the creation of a new customer on Stripe, associated with the purchased subscription.

  • On subscription updates, the process involves presenting the user with available subscription tiers. Once the user selects a tier, we use the Subscription API to generate an intent. The client secret and other information are then sent to the client app, where Stripe's library is used to confirm the purchase. Subsequently, we perform the subscription update on the backend as mentioned in the docs you provided earlier.

Please confirm if this accurately captures the intended workflow.

keen thistle
#

That all seems correct to me, yes

glossy plover
#

@keen thistle Thank you so much for your assistance.

On a different note, and regarding discounts. In our business model, we occasionally do discounts to our subscription tiers. I'd like to inquire if Stripe coupons are the only way for implementing discounts? Ideally our goal is to apply a discount percentage to the original price of the subscription tier at checkout time. We typically store these discount percentages in our database and we'd want to know if we can apply these percentages directly at checkout without creating a coupon for it. Is there a recommended approach or alternative method for achieving this within the Stripe framework?

craggy verge
keen thistle
#

I'd like to inquire if Stripe coupons are the only way for implementing discounts?
You can also create negative invoice items on the Invoice for your Subscription, which essentially adds a credit/discount to one invoice. Coupons are better for discounts that are intended to exists through multiple Subscription billing cycles

#

Which one you choose is largely a matter of taste/preference

#

Can the backend send the update with stripe api directly?
That depends on what you're updating. Anything containing raw payment credentials has to be done using a client library. All other updates (for the most part) can be done server-side