#erick_best-practices

1 messages · Page 1 of 1 (latest)

slim tigerBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1228362232211964035

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

languid bearBOT
royal palm
#

Hello

mystic ledge
#

Good morning!

royal palm
#

Can you clarify a little here. You say:

For example, if they purchase an extra year of data at a special price, we want to be able to insert that into their subscription schedule then as a paid product and push their renewal date off a year.
So in this case, they already paid separately and you want to provide them an extra year of the Subscription free, yes?

mystic ledge
#

No, we want to direct them to Stripe to pay for an extra year, and then have that push their renewal date off a year.

royal palm
#

Ah and you don't want to update the Subscription until after they have paid?

mystic ledge
#

Or Stripe could update the subscription at the time they pay - that would be 100% fine.

#

If there was a product we could create that they could purchase and it would push their renewal date off a year, that's great.

royal palm
#

Well the Price you use determines the billing cycle, so if they are currently on a yearly Price then you could upgrade them to a 2-year Price which would simulate what you are doing

#

The other thing to do here is indeed to use a trial period

#

So after they pay you just put them on trial until you want them to start paying again

mystic ledge
#

What would we direct them to stripe to buy?

#

Can we create like a dummy product that has no effect on their subscription?

royal palm
#

Yeah you could certainly do that -- you could just take a one-off payment

mystic ledge
#

but we would still do that after taking a one-off payment, correct?

royal palm
#

No, the Pending Update would mean you would actually upgrade the Price on the Sub and attempt to charge your user that way. Then if they successfully complete that update you could set up your trial period but if they don't complete that payment then nothing would happen to the Subscription.

#

It is just an alternative to taking the payment separately from the Subscription

#

Same idea really though

mystic ledge
#

In this case, I don't want to update the subscription at all. I just want to push out their expiration date. I still want their subscription to renew at one of a set number of subscription prices.

royal palm
#

Yeah okay then the easiest way imo is to take the payment separately and then just put the Subscription on trial.

mystic ledge
#

That's what it sounds like. Since we already handle trial behavior, that seems like perhaps the easiest lift.

#

Thanks for your help. I'll go down this route and I'll circle back if I run into issues. Based on the plan, though, I don't expect any. I appreciate it!

royal palm
#

Sure thing!

mystic ledge
#

Sorry, I'm going to ask a follow-up question. If we charge them as a one-off product and extend their free trial, how does that affect revenue reports? Will it look like we have less ongoing revenue than we actually do?

royal palm
#

Hmm I don't really know much about how the revenue reports are calculated as we just focus on the API, but yeah I would assume that is the case.

#

If you want a 100% answer on that I'd recommend checking with our Support team or testing it out in test mode

#

Not sure there would be a way to have it be considered recurring revenue without the payment being associated with an Invoice for a Subscription

mystic ledge
#

if I did that, though, it would basically cancel the current subscription and create a new one? So then we would have to do some math to understand how much time is left on their current subscription and to add the proper price for payment, and then make sure that their renewal is set up back to one of our standard subscriptions?

#

or it would alter the current subscription and swap out the price for a custom price? I'm concerned it would end up canceling the time left on their existing subscription and just setting their renewal date one year out

royal palm
#

No, if you want to go that route I'd use Pending Updates where you update the Subscription to a Price that charges the amount you are going to charge for the covered period

#

Then if that payment is successful you would update the Subscription again to revert to the previous Price and use a trial period to delay charging again until your desired date

#

If the payment fails the Subscription just auto-reverts back to its previous state

mystic ledge
#

So we would end up using the trial period anyways

royal palm
#

Yeah a trial period is really the only way to arbirtarily shift an ongoing-Subscription's billing cycle anchor

mystic ledge
#

👍

#

it sounds like the main difference between the two methods is that one method changes the members subscription state after the purchase, giving us a marker on their subscription that basically indicated that we have a pending update to make, which is to put them on the trial and change their renewal back. the other way, we have to track the purchase ourselves and know whether or not we've fulfilled the one-time purchase by applying the change to their subscription

royal palm
#

Yep pretty much

#

One will involve an actual Invoice

#

The other wouldn't

#

I mean... you could also create an Invoice for the one-time payment if you wanted, but it wouldn't be associated to the Subsription (otherwise that would mess with the state of the Subscription)

mystic ledge
#

so it sounds like if we go with the one-time payment, if there's any sort of problem communicating back to our server that the payment has been made, the customer would have to contact us so we could fix it manually

royal palm
#

Hmm not sure what you mean by:

if there's any sort of problem communicating back to our server that the payment has been made

#

You would use Webhooks for fulfillment

#

Nothing should be relied upon from your frontend

slim tigerBOT
mystic ledge
#

Sorry, I haven't looked through the documentation yet for understanding how to validate one-time purchases.

royal palm
#

Mostly you just rely on the payment_intent.succeeded Webhook

mystic ledge
#

Right now, when people log into our site, or when they hit the landing page on our site after purchase, we pull their account information from stripe and synchronize their subscription status.

royal palm
#

Ah interesting

#

You don't use Webhooks at all

#

Since you provide an online product only accessed through your site

#

Well yeah in this case you really would want to set up Webhooks to be able to handle the one-time purchase otherwise you are right that you could totally miss it (you never want to rely on client-side actions since the Customer could always complete payment but disconnect prior to reaching any code that relays things to your backend)

#

For these one-time payments you could set metadata on the PaymentIntent to indicate the purpose of the payment

#

Then when you receive the payment_intent.succeeded Event you check the metadata on the PaymentIntent and if it is the metadata you set for this one-time payment you trigger your Subscription update

mystic ledge
#

How does the webhook work in development mode when I'm running on my local machine?

#

Sorry, I'm sure there's documentation about that somewhere and I don't need to ask you here.

royal palm
#

You can forward from the CLI to test locally

mystic ledge
#

I also don't know that I have the time right now to convert us to using webhooks... is it possible to call into the API to verify a one-time purchase?

royal palm
#

If you go that route you will want to decide on the maximum amount of time that the customer has to complete that one-time payment

#

So you know how long to poll the API for if you don't receive a response from your client

mystic ledge
#

That makes sense. I'll have to go down this route for now. I think the webhooks is going to be a heavy lift because I'm not even set up with the CLI. There's a lot about Stripe that I don't have my head properly wrapped around.

royal palm
#

I actually think the Webhook is less work overall and much less fragile. But up to you