#ibgoldbergs

1 messages · Page 1 of 1 (latest)

balmy gateBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

meager sparrow
#

bismarck had to head out, but I an take a look!

restive pier
meager sparrow
#

Are you intentionally creating subscriptions that will cancel at the end of the trial if a payment method isn't provided?

restive pier
#

Yeah because if a payment method is not provided, we dont want the subscription to continue.

meager sparrow
#

Then unfortunately I think you're a bit stuck - if the Subscription has no payment method tied to it, then we believe the subscription will be automatically cancelled and there's no upcoming invoice to preview

restive pier
#

What is the point of setting subscription_trial_end === now then?

#

Do you have other ideas of how we can solve this problem of being able to display to a customer how much their invoice will be after the trial ends? It seems like a very basic usecase.

meager sparrow
#

I think that was just a suggestion to see if you could get around the error - but there really isn't any way around it if there's no PM on the subscription

restive pier
#

Here is our problem:

  • We have trialing subscriptions
  • After the trial ends, if a customer did not put a payment method on file, we should cancel the subscription
  • While on the trial, a customer should be able to put a payment method on file, and understand how much they will be billed upon trial end

I'd assume invoice/upcoming would be the way to handle this. Is there another way?

meager sparrow
#

You're right that typically I'd recommend upcomign invoices for this, but I think this is a bit of an edge case the team hadn't considered when building this feature. The only way I can think to get around this would be to update the Subscription temporarily set trial_settings.end_behavior back to create_invoice before generating the preview so that you get the correct upcoming invoice and then changing it back if the customer chooses not to pay

restive pier
#

Just a question about trial_settings.end_behavior

Am I right in thinking that if we create an invoice every time, the subscription will automatically cancel afer our past due behavior goes into affect? But the downside is that the subscription will be on the customer until that behavior runs its course?

meager sparrow
#

Yeah if you have dashboard settings to automatically cancel a subscription after all retries are exhausted (or other settings of that nature) then yes, you'll need to wait for the behavior to run it's course