#xarm

1 messages · Page 1 of 1 (latest)

jovial ruin
#

so it's not a server side redirect, but instead Stripe will send an invoice to your customers

feral flicker
#

Hi @jovial ruin thanks for the link

#

Yes indeed that is the issue, so is the only way by sending them an email to the hosted page?

jovial ruin
#

hmmm, let me take a look and see what can be done

feral flicker
#

thank you!

#

I'm getting a bit dizzy because I was not able to use the customer portal due to some limitations. So I was recommended to use checkout for first payment and for upgrades this hosted invoice method. It does concern me as well if that would be strange for users to get an invoice in a scenario where they are just paying for a SaaS, so I wanted it to be immediate redirect. Although, if this is too hacky in terms of potential issues, would be good to know as well.

#

thanks in advance

jovial ruin
#

@feral flicker when you update a subscription, what you can do is to expand the latest_invoice parameter too

cURL example

curl https://api.stripe.com/v1/subscriptions/sub_KC6yNDCEOgGjWO \
  -u sk_test_...: \
  -d proration_behavior=always_invoice \
  -d expand[]=latest_invoice \
  -d quantity=3

It'll return a response that contains hosted_invoice_url and you would probably be able to link/redirect your customer there

feral flicker
#

thank you @jovial ruin . Is this something you think overall would be a reasonable flow? What would be the status of the subscription of the user does not pay that invoice immediately after redirect? With the checkout session, I guess it's straightforward because in my application I would not update the subscription unless checkout is complete, however with invoices would it be different or awkward?

jovial ruin
#

hmmm, actually if the user already has a default payment method and the collection method is charge_automatically, we would attempt to charge the default payment method automatically upon upgrade.

The scenario which you would need to handle is in case automatic charge fails at the point of upgrade. I mean, it sounds reasonable to me, i can't think of any reason off the top of my head to not use the method you suggest.

#

but definitely test it out first to make sure it works well for you

feral flicker
#

Sorry just to add, I was planning on adding a free subscription when users first sign up, so in theory they would always be upgrades. I was suggested a couple of different things so not sure about that approach

jovial ruin
#

i think there's a couple of approaches. Technically, since it's free, do you really need to create a "free" subscription also?

feral flicker
#

I was suggested that as a good option to have it all in Stripe

#

but it's not a hard requirement from my side

jovial ruin
#

this all really depends on your requirements. I'm a bit baffled as to why a free subscription is required, when it's....free

feral flicker
#

I guess it was suggested to track both free and paid subscriptions for some reason

#

but I can forget about that. Although, technically a user could join a paid plan, and then change to free, then back to paid. or upgrade from one paid to another paid plan

#

so I need to cover those scenarios regardless in some way

#

whichever would be the most straighforward, without using customer portal unfortunately

jovial ruin
#

i assume all users who register for your app have access to the free services - is that right?

feral flicker
#

yep

jovial ruin
#

in which case, if the user is on a paid plan, cancelling the paid plan would implicitly mean that the user is back to the free plan

feral flicker
#

so if a user goes from paid to free, in Stripe, I cancel the subscription, right?

jovial ruin
#

in your use case, yes

feral flicker
#

and then if they go back to a paid, I send them back to a checkout session?

jovial ruin
#

yep!

feral flicker
#

and it would be a new subscription

jovial ruin
#

yes, that's correct

feral flicker
#

ok, what about from one paid to another paid plan

jovial ruin
#

that would be an upgrade or a downgrade, and that's where what we talked about initially comes into play then

#

assuming the customer already has a card attached, and the subscription is charge_automatically - if the card is valid, it'll automatically charge. If the card is invalid, we'll automatically send that invoice to the customer, you can also display the hosted invoice page.

downgrades are a bit special though, but we can discuss that slightly later.

#

i hope the hosted invoice page idea works for you though, cause the alternative is slightly more complicated

feral flicker
#

if the hosted invoice page was a fallback for failed payments, I think that would be fine

#

the charge_automatically, is that something I can set and users cannot unset?

#

I guess I'm wondering, if they can somehow unset, then I still need to cover for that

#

or would that also fallback to the hosted invoice?

jovial ruin
#

yep, it's something you can set and users cannot unset. My internet connection is a bit slow right now, I'll pass you the link to that parameter once the docs load for me

feral flicker
#

thank you. You mentioned downgrades was trickier, how so?

jovial ruin
#

what is your expectation when the user downgrades a subscription? Do you prorate and refund them the difference?

#

or you only allow them to downgrade at the end of the billing cycle? so there won't be any proration involved

feral flicker
#

With a downgrade there wouldn't be a refund just no charge next cycle

#

if downgrade to free, although could downgrade to a cheaper paid plan as well

#

but also would be starting next cycle

jovial ruin
#

if i understood you correctly, you won't allow user to downgrade in the middle of the cycle. They can only downgrade at the end of the cycle?

e.g. if i were a customer and my plan was 1 - 31 dec, you won't allow me to downgrade on the 15 dec, i would only be able to start on my lower plan on 1 jan

feral flicker
#

yes, I would like to give them a refund but I don't make the rules 😀

#

so basically a downgrade would mean next cycle would be the cheaper plan, no refund

#

is this simple to do in Stripe?

jovial ruin
#

alright, this makes everything simpler then. It would be complicated if there're refunds and prorations involved

feral flicker
#

with upgrades there would ideally be prorations though, does that complicate things?

jovial ruin
#

nah, you would invoice them automatically so that's fine

#

let me check on what needs to be done to downgrade and get back to you

feral flicker
#

great thank you

jovial ruin
feral flicker
#

great thanks

#

regarding payment methods, if you don't mind another question

#

if the user wishes to change payment methods, does this open a can of worms? Or I'm wondering if with that one thing I could point them to the customer portal

jovial ruin
#

yep, it's the ideal use case for Customer Portal

#

Your logic may be a bit complicated if you allow the user to upgrade in the middle of the cycle and allow prorations for upgrading

#

you're going to have to evaluate before hand if it's an upgrade or downgrade

feral flicker
#

yeah if it's just having to evaluate that I think I can manage

#

So for downgrading, if it's to a free plan, I cancel subscription on Stripe, if it's to a cheaper plan, I can make the change on the backend with the flag you mentioned, no need to send them to any Stripe hosted page right?

jovial ruin
#

yep, if it's to a cheaper plan, you don't need to send them to any Stripe hosted page

feral flicker
#

thanks again for all the details answers btw very helpful

jovial ruin
#

you're welcome! Billing is really complex so feel free to reach out again if you have questions or encounter any issues

feral flicker
#

thanks much appreciated

#

I'm wondering if you don't mind another Q, if for any reason I can't use customer portal for payment method change, what would you recommend there as a general pointer?

jovial ruin
#

simply attaching the card to a customer does not mean that it's the default payment method. You need to set the newly created payment method on invoice_settings.default_payment_method to ensure that the automatic charges work

feral flicker
#

great thanks for the pointer

#

you've been really helpful thanks. I guess I'll need to make sure I'm listening to all the relevant webhooks as well

#

will do some research tomorrow, thank you!

dapper basin
#

@feral flicker what limitations did you encounter with the billing portal?

feral flicker
#

Hi @dapper basin , basically I have a per set subscriptions model. Similar to Snyk, the subscription is for an org. The plans are 0-5 users, 5 - 10 users, 10-15, etc... I wasn't able to limit to only those intervals in the upgrade section of the customer portal, there was only min and max if I recall correctly

dapper basin
#

Ah ok interesting, I checked out the Snyk page and saw the example within the team tier. A workaround could be to create a separate product for each of those tiers

#

Then you could use the price_id on the backend to lookup a static mapping of how many seats are in each product

jovial ruin
feral flicker
#

@dapper basin thanks, I had considered this early on and can't remember off the top of my head reason to avoid that method. Might have been still how that would have been presented to the user on the customer portal, and it not being ideal. Thanks for tip though!

#

@jovial ruin thanks for the follow up. I just wanted to double check regarding your last messages, is this related exclusively to changing payment method? And if so, if I can use the customer portal for this particular feature, then I can forget about Stripe Elements right?

#

thanks again for your help

feral flicker