#jg-subscription-invoice

1 messages · Page 1 of 1 (latest)

stark elbowBOT
sinful panther
#

Hi there! Just so I'm clear, are you also using Subscriptions? Do you want customers to still be able to start a trial without providing payment details?

kind marlin
#

Hey, thanks a ton for the help. Yes, we're using subscriptions. And we still want to allow users to start a trial without providing payment information.

sinful panther
#

There's no need to render the PaymentElement since you won't be collecting payment details from the user at the same time

kind marlin
#

Thanks. I actually already read this. It mostly covers how to handle situations where the trial runs out.

#

I know we don't need to render the payment element when they sign up for a trial.

#

I'm trying to figure out how to upgrade them out of a trial.

#

Essentially allowing them to provide a payment method and pick a plan, then upgrading them to a paid plan.

#

I can't find an example of how to use the Payment Element to do that.

#

Are you still there?

sinful panther
#

Yep, sorry!

kind marlin
#

Totally fine. I appreciate the help. Just wanted to make sure you hadn't left.

sinful panther
#

This can get a little complicated so I recommend using Test Clocks to play around with it. You'll essentially want to use the subscription's latest invoice to render the PaymentElement, specifically the subscription.latest_invoice.payment_intent.client_secret

kind marlin
#

Okay, I can look at that. Is there a support doc that shows how to use the Payment Element to allow a user to update their credit card? That feels really basic to me, which is why I feel like I'm missing something.

#

And is it okay to use subscription.latest_invoice.payment_intent.client_secret even if the last invoice has been "paid" already since it was for a free trial?

sinful panther
#

Not exactly. You can use the customer portal to allow a customer to manage their saved payment methods (or add new ones): https://stripe.com/docs/customer-management

The general way to do this with the PaymentElement is to work with SetupIntents

sinful panther
kind marlin
#

Is this a complex use case? I feel like this is fairly common, but maybe I'm not thinking about it the right way.

#

We can also stick with the Card Element, but I thought that was deprecated.

sinful panther
#

I think it ultimately depends on what you want the customer experience and subscription behavior to be, which is why I recommend playing around with this a bit. Do you want a customer to be able to add a payment method while still on trial but keep the billing cycle unchanged?

sinful panther
kind marlin
#

Ideally, we want to keep the process exactly the same as it is now. When they're on a trial, they don't have any associated payment method. Then when they're ready to upgrade they pick a plan and input their credit card. When they submit the form it immediately updates their subscription and charges their card.

sinful panther
#

Then when they're ready to upgrade
Is this always at the end of the trial billing period? What happens if they never decide to upgrade?

kind marlin
#

No, they can upgrade at any time during their trial and many do. If they don't upgrade then they essentially stay on a trial forever, but we lock parts of the app after 30 days into the trial so there really isn't much they can do after 30 days even though the trial is technically 60 days.

sinful panther
#

Do you care to keep track of these trial subscriptions in Stripe? I ask because another way you can handle this is to provision access to your app and keep track of when this is so you can determine when to lock parts of the app. If/when they're ready to upgrade, create the Subscription object at that point in time. You could also backdate the newly-created Subscription but opt to not charge the customer for the time between the backdated date and the subscription created date: https://stripe.com/docs/billing/subscriptions/backdating?dashboard-or-api=api#backdating-no-charge

kind marlin
#

We would like to keep the trials in Stripe since that's what we're already doing. Is there really no way to use the PaymentElement with a subscription that doesn't capture the payment info right away? I'm feeling very confused because this seems like a common practice. Online tools often create subscriptions without taking payment info during the trial period. We're just trying to update to your newest tooling.

#

We already have this working with the CardElement, but I figured it would be even easier with the PaymentElement.

sinful panther
#

I guess this is where I'm confused: "use the PaymentElement with a subscription that doesn't capture the payment info right away". There's no reason to present a PaymentElement unless you're capturing payment info at that point.

kind marlin
#

Sorry I'm not being clear. We don't want to offer the payment element immediately, but when someone upgrades we want to use it to capture their payment information and upgrade them to a paid plan.

#

So the steps would look like this:

  1. User signs up for a free trial which creates a subscription in Stripe with no payment method
  2. User decides to upgrade and provides their payment info
  3. We use their payment info to charge their card immediately and update their subscription to the plan they chose

I'm struggling with how to use the PaymentElement for steps 2 and 3.

sinful panther
#

Got it. Since you want to charge their card immediately, I assume you're also cutting a new invoice?

kind marlin
#

Yep, you got it. We have these two lines in the subscription update right now:

'trial_end' => 'now', 'billing_cycle_anchor' => 'now',

sinful panther
#

perfect, okay. so since you're cutting a new invoice as part of this subscription update, you should be able to use subscription.latest_invoice.payment_intent.client_secret to render the PaymentElement

kind marlin
#

Do we need to first create a new invoice to do that?

#

How would you do that if you're not sure whether they're going to upgrade or not? I wouldn't want to create a new invoice if they aren't upgrading.

sinful panther
#

Updating the Subscription with trial_end: now and billing_cycle_anchor: now should create a new invoice. I assumed you'd make the call to update the subscription only if they're upgrading.

stark elbowBOT
kind marlin
#

It does create a new invoice, but in the past we added the credit card to their customer profile first. That way the invoice could be charged immediately.

viscid locust
#

jg-subscription-invoice

#

@kind marlin there are many different ways to use and integrate Stripe and we introduced new ones over time to meet new requirements such as doing 3DS as part of the first payment for example.

kind marlin
#

Thanks @viscid locust . Do you have a support doc that walks through how this process should work?

viscid locust
kind marlin
#

We're already using the old Card Element, but the process sounds very different. Do you recommend sticking with what we have, or migrating to the Payment Element?

#

We don't want to pour a ton of hours updating this if it's not really worth the time.

viscid locust
#

yeah that's what I was worried about

#

Switching is worth it but it's definitely hours if not days of work. So I'd stick with CardElement for now I guess

kind marlin
#

Got it. That's a bummer, but I appreciate you being up front. I had no idea the lift it would be to upgrade to the Payment Element.

viscid locust
#

Yeah just to be clear it doesn't really change much to my earlier advice

kind marlin
#

One more question for you. We're using an outdated version of even the Card Element that doesn't use Payment Intents.

viscid locust
#

ah so you use Tokens and Charges 😅

kind marlin
#

It says to only create a Payment Intent when you're exactly sure of the amount, but we're having people pick a plan and give their card details at the same time.

#

How can we make that work?

viscid locust
#

yeah you're really going too fast and skimming instead of carefully reading. There's a lot to an integration like this

kind marlin
#

Also, if you think we should be going a totally different route please tell me. I'm just struggling with next steps.

viscid locust
#

I really need you to be crisp about what you are doing. There are literall 10 or 15 ways to integrate Stripe for Subscriptions. And it's tough to help without knowing exactly what your code is already doing.
Like are you using PaymentMethod? Tokens? Sources?

kind marlin
#

All fair. It helps to know that there are a million ways to do this.

#

Right now we're using tokens to update the payment info.

viscid locust
#

My guess is you used to do this
1/ (client-side) collect card details with CardElement and get a tok_123
2/ (server-side) Attach that card to the Customer and get a Card card_123
3/ (server-side) Update the Subscription

kind marlin
#

Here's a line of code we use to attach the payment method to the customer:

$updated_payment_info['source'] = $_POST['stripeToken'];

#

Haha, you nailed the steps. That's exactly what we're doing.

#

I was hoping to modernize the approach, but it sounds like fully modernizing it would require us to completely change our process.

#

So now I'm wondering if we should just try to at least use the latest approach to working with the CardElement.

viscid locust
#

yeah so that's doable but you're going to end up with new objects and have to learn about PaymentIntent and all that. This is not going to be a 5 minutes fix, at least not that I can think of

#

I guess: why are you trying to change things if it works? All you need now is to collect card details the old way right?

kind marlin
#

Good question. You all had sent something out a long time ago about how our approach was outdated and needed to be upgraded.

#

We waited a long time to get into it and are now working on it.

#

Are you still there?

#

I really appreciate your help, but I've been on this chat for an hour and a half and need to head out.

viscid locust
#

Yes I'm here, you never really explained what you needed to do though

#

right now I'm kinda waiting to understand what you are blocked on. there are many ways to do this, what are you trying to fix?

#

I can't really know what email we sent you a long time ago 🙂

kind marlin
#

That's totally fair. You all basically emailed and said we shouldn't be using the Charges API any longer. So I'm trying to make sure we're using functionality that will work and also be supported.

viscid locust
#

Yeah so if you are trying to move away from the Charges API you do need to plan a couple of weeks of rewrite

#

you won't get away with a 15 minutes change

#

you can keep your front-end mostly as is but there's still a lot to change

kind marlin
viscid locust
#

kind of, this never touches subscriptions so it's only going to touch the surface of what you really need

#

Sorry not trying to be cryptic but you're not going to gain much if you do not plan to invest a couple of weeks rewriting most of it and in that case start with the brand new guides, integrate from scratch, get used to the concepts and then go back to your old code and port it

kind marlin
#

No no, I appreciate the honest take. I'll take a look at that guide, see what's possible, then determine the best next steps. Thanks a ton for the back and forth.

#

Have a good one and take care.

viscid locust
#

Please do come back when you start playing with it. It'll be a lot easier when you start really integrating and have concrete questions