rp

[half agate]

Hi there!

Not sure, give me a few minutes to look into this.

[grave igloo]

Thank you!

This is the request that originally created the subscription: https://dashboard.stripe.com/test/logs/req_SkaG4x8W9t8Gbj

The cancel_at property is set to july 1

But after creating a subscription schedule from the subscription, it added a second phase that ends Aug 1

[half agate]

Looks like you can start by creating the schedule, which creates a subscription. And then you can update that subscription with payment_settings.payment_method_types https://stripe.com/docs/api/subscriptions/update?lang=node#update_subscription-payment_settings-payment_method_types

[grave igloo]

Would that affect the first invoice thats created immediately?

[half agate]

Don't think so. However the first invoice of a subscription schedule is created in draft. So you can always update it if needed: https://stripe.com/docs/api/invoices/update?lang=node#update_invoice-payment_settings-payment_method_types

[grave igloo]

Hmm gotcha

It seems a bit undesirable though, if my server dies before updating the draft invoice, it'll get sent out with the wrong settings

Is there another way to achieve this?

[half agate]

You could also try to play with these settings, but not sure how they work with subscription schedule exactly https://dashboard.stripe.com/settings/billing/invoice

[grave igloo]

Ah unfortunately I need to set this per subscription

(We set the subscription price based on the selected payment method, so we have to set the payment method type per subscription)

[half agate]

Then your original suggestion might be the best one:

It seems like the only way to do this is to first create a subscription and set the https://stripe.com/docs/api/subscriptions/create#create_subscription-payment_settings fields, and then convert the subscription to a subscription schedule.

[grave igloo]

Could you help me figure out why creating the schedule using from_subscription changed the cancellation date?

It was originally July 1 when I created the subscription, then after I converted it to a schedule it got set to Aug 1

[maiden blaze]

Hi! I'm taking over from my colleague. Please, give me a moment to catch up.

We need to find out why was the second phase added.

[grave igloo]

thank you!

[maiden blaze]

When do you want the Subscription to start and end?

[grave igloo]

My ultimate goal is to have a subscription schedule with the allowed payment method types specified and 3 phases.

I thought I could create a subscription with a cancel_at timestamp specified, and then convert it to a subscription schedule with a single phase. Then upade the subscription schedule with the additional 2 phases.

However when I do the conversion, I'm not sure why it's adding a second phase immediately

I'd like the subscription to start immediately, and the end date would vary

[maiden blaze]

Could you try adding the other phases right away?

[grave igloo]

How could I do that?

[maiden blaze]

use from_subscription and phases parameters together when creating a Schedule.

[grave igloo]

The docs say:

from_subscription

Migrate an existing subscription to be managed by a subscription schedule. ...
When using this parameter, other parameters (such as phase values) cannot be set. 

[maiden blaze]

Oh, right, sorry for confusion.

[grave igloo]

Np

[maiden blaze]

Actually, this approach then seems better. You can listen to invoice.created webhook and update the payment_method_types on the Invoice. There's protections exactly against what you are concerned about. If your server dies, we will pause the finalization of the Invoice and retry sending the webhook notification.

https://stripe.com/docs/billing/subscriptions/webhooks#:~:text=If Stripe fails to receive a successful response to invoice.created%2C then finalizing all invoices with automatic collection is delayed for up to 72 hours.

[grave igloo]

Oh interesting, if our server doesn't respond to the webhook event Stripe will pause the finalization?

That's helpful to know, thank you!

I ran into an issue with testing where I couldn't update the subscription object while a test clock is advancing

Would this also be affected? i.e. if I advance the test clock, it'll result in creating an invoice and the webhook event being sent. If my webhook handler tries to update the invoice, would I get error saying "can't update invoice while test clock is advancing"?

[maiden blaze]

Yeah, that's tricky. You will need to advance to the time close to when the Invoice is created, but not too far.

I am actually thinking it might not be possible to test with test clocks.

[grave igloo]

Hmm gotcha

I would prefer to avoid that approach then, since it makes testing the integration quite difficult

I'm not sure how to test subscriptions thoroughly without using test clocks

[maiden blaze]

I don't think there's more straightforward ways to implement this. I will make sure though to ask the relevant team to add the payment_method_types param to Subscription Schedules too.

Oh, I got an idea. What if you save a Payment Method with a SetupIntent and then create a Subscription Schedule with the saved PM?

[grave igloo]

Thank you!

And ah, I'm not too familiar with SetupIntents yet, does a SetupIntent provide a way to collect payment info from a user? (simialr to the invoice hosted payment page)

[maiden blaze]

Yes, you can then save and reuse the Payment Method on the Customer object. I see a lot of companies using a similar flow even for immediate payments, e.g. you add a Payment Method to your account first and then click to checkout, like AirBnB or some airlines.

You can follow this guide to learn more: https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements

Are you collecting automatically or sending an Invoice?

[grave igloo]

We were planning to send an invoice first, and then once that saves their payment method update the subscription to collect automatically

And thank you! I'll look through that page