#jenn

1 messages · Page 1 of 1 (latest)

crude yewBOT
light tide
#

Just curious, why don't you want the subscription object created? This isn't really possible

silver cosmos
#

If a customer gets all the way to the payment form and then abandons their cart, then we'll have a record in Stripe of these incomplete subscriptions, which is fine. But then if they come back again to check out (with the same subscription or a different one), we then want to manually go through and cancel out these previous subscription attempts. I know they will automatically expire in 24 hours, but we're trying to keep the data trail tidy as we go. We're also then saving each incomplete subscription to our own database on subscription.created, which means our internal database will need some additional data to know which ones are valid. Again fine, but wanting to make sure this is required.

For context, we're switching from Stripe Checkout to a fully onsite checkout flow, and Stripe Checkout calls subscription.created and subscription.updated immediately one right after the other, after the customer has paid, which doesn't seem possible to replicate through the API. So we're needing to change our internal implementation based on the event behavior changing.

light tide
#

Got it

#

There's some workarounds. Like you could use a SetupIntent to collect payment info and then create the sub with the set up payment method behind the scenes. This is not recommended though. There's potential for the first payment to fail when you create the subscription server-side so you'd need to bring the customer back online to fix the issue

silver cosmos
#

I see. Yeah, we'd love to follow the recommended paths!

light tide
silver cosmos
#

Yes, that's what I've done. I was hoping there was some way to more closely mimic the exact order events happen in Stripe Checkout, but it sounds like that isn't possible via the API?

light tide
#

Not unless you go the setupintent workaround

silver cosmos
#

Gotcha. Ok, thanks for your help!