#Fluffy-sub-trial

1 messages · Page 1 of 1 (latest)

midnight brook
#

Hi there! Give me a moment to look at the best way to do this.

rocky salmon
#

Thank you

midnight brook
#

So mostly this will be dependent on your Subscription Settings for exactly how it would work, but assuming you move Subscriptions with a failed payment into past_due then you would collect the new PaymentMethod from the customer and then you would grab the PaymentIntent client_secret from the PaymentIntent associated with the most recent invoice on the Subscription and confirm that PaymentIntent client-side with stripe.JS. If that payment then succeeds, you update the customer's default payment method for future invoices.

#

Ah I forgot you mentioned billing_cylce_anchor... in that case you can update the Sub to reset the billing_cycle_anchor and turn off proration so that they aren't charged again

rocky salmon
#

Hmm, more complicated than I expected... Our subscriptions use most default settings, and I can confirm their status moves to 'past_due' after the trial expires. Most interactions with Stripe API occur on the backend (Python/Django). On the client side, we use a mostly unmodified version of Stripe's example code here:

https://github.com/stripe-archive/set-up-subscriptions/blob/master/client/script.js#L92

In that example code, it looks like references to latest_invoice and payment_intent are based on a subscription instance which is returned from the create_customer endpoint on the server: https://github.com/stripe-archive/set-up-subscriptions/blob/master/server/python/server.py#L57

#

In this case, it sounds like we need to create a dedicated server endpoint that gets the customer's latest subscription from Stripe and returns that instead of creating a new one around line 57.

Assuming can retrieve and provide the latest_invoice and payment_intend to the client, it's unclear what else needs to be done on the client side.

#

I was thinking the simplest solution might be something like the customer provides a payment method from the client. On the backend, we:

  1. Set the new payment method as the customer's default.
  2. Modify the existing subscription setting billing_cycle_anchor=now
    2.5) Might add 1-2 more arguments to step 2 to let Stripe know the subscription is being restarted.

Is it necessary to pass the last_invoice's payment_intent back to the client for additional processing there?

midnight brook
#

Well if you'd rather just restart a new Subscription without a trial that is another option for sure.

#

You will just have some extra data from the old Sub.

#

But the process is more or less the same as starting a new Sub if you want to use the current one... just instead of grabbing the initial Subscription invoice, there will be a new latest_invoice that you need to retrieve (as the initial one will have been from the trial)

rocky salmon
ornate geyser
#

bismark had to step out so I'm taking a look. Have you been able to test that code out? I think you may also have to manually make the Invoice.pay call on the latest invoice

rocky salmon
#

Thanks for the help. I haven't tested the code. The initial question was what steps are necessary to activate a customer's trial subscription after it expired (past_due) with no payment method added, given that they've now added a payment method with the intention of starting the paid subscription.

#

I thought it might be as simple as adding the new payment method as the default and letting Stripe know the subscription is restarting, but bismark suggested additional processing is needed on the client side with the latest_invoice and payment_intent. Not sure why that is, but taking your word for it that Stripe needs that information, I tried drafting the example server-side endpoint there keeping it as simple as possible.

#

If I understand correctly, the Stripe-related calls on the draft server-side endpoint look like what you'd expect, but might be missing a manual call to pay the invoice?

ornate geyser
#

Those calls seem fine to attach the payment method, set it as the default, and reset the billing cycle.

#

And yeah that will probably be necessary. The subscription's status is typically based on the status of its latest_invoice and I don't think resetting the billing cycle will cause us to retry the payment. So you will probably want to make this call after setting the default source https://stripe.com/docs/api/invoices/pay

rocky salmon
ornate geyser
#

Yes, that function handles what happens a scenario where the invoice payment requires the user to re-authenticate with 3DS

#

Or rather, if you try to pay the invoice and the payment intent's status goes to requires_action, you will need them to do the 3DS flow again

rocky salmon
#

Do you know if there's example code available that shows the recommended best practices for this flow?

It sounds like if the server-side tries to pay the invoice and succeeds (status does not go to requires_action), then the client side probably needs a different flow. If the server-side tries to pay the invoice and the response status is requires_action, then we know this already when passing the subscription back to the client, and the client-side code should probably be different than the initial example.

Customers not having smooth & predictable payment experiences is a problem we'd love to avoid, and it's one that is difficult to test manually since it requires having test subscriptions in the past_due state which in our case takes a 7-day delay. I could create a temporary/fake subscription with a 1-day trial period to try getting faster access to past_due subscriptions, but even then having to wait 24 hours to test and troubleshoot isn't ideal, and the testing flow ideally includes checking for the 3DS case even in the event the server-side triggers the invoice payment as you suggested.

There's pretty much nothing unique or heavily customized about our flow here. It'd be great if Stripe has example code that covers this case that we can know follows Stripe's best practices.

rocky salmon
#

I have to step into a meeting in a few minutes, just want to say thanks again for the guidance above. Can't say I'm totally confident I understand how Stripe handles this situation yet, and if Stripe offers any definitive code samples on how to handle this common scenario I'd love to see Stripe's example. If not, I can try to keep testing on my own.

ornate geyser
#

Apologies for missing your followup here for a bit. Checking in to if we have a sample for manually confirming a subscription's payment intent now.

#

You should be able to do this and give your users as consistent of an experience as possible.

rocky salmon
#

Thank you -- I'll check this out!

#

Re - "Checking in to if we have a sample for manually confirming a subscription's payment intent now." if you find a sample you can point me to it'd be much appreciated.

snow swallow