daisdead

[vale bane]

👋

[frosty elm]

Hello!

[vale bane]

Can you tell me more about what you are looking to understand exactly?

In terms of when a session is completed you should be using Webhooks

That way if the customer does drop off after initiating the confirmation but before the promise resolves you will still be able to accurately handle fulfillment

[frosty elm]

Yep - drop off to be exact in the scenario

In our integration; we give new customers a 2 week trial to a "premium" plan once they sign up. We offer "add-ons" in addition - our situation is that if the user goes to checkout and selects "add-ons", we modify the trialing subscription, however if they drop off their subscription still has those add-on products

[vale bane]

The "add-ons" are paid or part of the trial?

[frosty elm]

to be paid for at checkout - not a part of the trial

[vale bane]

Will your customer use these add-ons immediately?

Like as soon as they add them and complete Checkout do they need to be able to use the add-ons? Is it software for example? Or is this something where it is okay to wait a minute or so for the add-ons to become "active"

[frosty elm]

With a purchase, correct - their access should begin immediately (it is software)

the result of the purchase to clarify:

• will result in their trialing premium plan to rollover to active once the subscription trial completes
• access to add-ons, if any, purchased during the same checkout flow

[vale bane]

Gotcha then you want to basically do a combination here.

You want to first see if the client-side confirmation promise resolves

If so, you can give immediate access and update the Subscription

Otherwise, you want to wait for a successful Webhook

When that Webhook comes in you check if you already updated based on the client-side actions. If so, ignore the Webhook.

But really you should not make any changes to the Subscription before either the promise resolves or the Webhook arrives

[frosty elm]

I see - just for clarify which webhook events in this case are you referring to listen to? payment | setup intent success?

[vale bane]

Well most likely yes but actually this is a bit different if you are generating the PaymentIntent due to a Subscription within Stripe.

How do the "add-ons" work exactly?

Are they different Prices that you are adding to the Subscription?

[frosty elm]

the premium plan, and each add-on are different products in Stripe; which there may be different prices but I don't think prices themselves should effect anything to the original quesiton/scenario

we have our business logic that to have access to an add-on you must have a premium product access as well so our checkout flow is more revolving around the premium product purchase +/- add-ons

[vale bane]

Okay so in this scenario there is no actual change needed to the amount of the checkout session that is occurring.

[frosty elm]

Okay so in this scenario there is no actual change needed to the amount of the checkout session that is occurring.
Correct - the concern here isn't regarding the prices we show or total subscription amounts

It more of "you should not have access to this because you did not complete checkout and authorize payment"

[vale bane]

Okay then yeah my above answer is correct and yes you can listen for payment_intent.succeeded or setup_intent.succeeded

[frosty elm]

Sweet; yeah you're suggestions are clear to me! And your comment of:

But really you should not make any changes to the Subscription before either the promise resolves or the Webhook arrives
Makes a lot of sense in retrospect of our implementation 😅

[vale bane]

Glad to hear it 🙂

[frosty elm]

Let me get back to the team on this and if anything; i'll reach our in this discord again