#empz_best-practices
idle basaltBOT
đ 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/1270084699594952848
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
stone perch
Forgot to mention that I'm using webhooks to create/update the subscription in my database.
paper heath
Hello can you send me an example ID of two subscriptions created that way? It was my understanding that we didn't create a new subscription until the info went through successfully but I'm happy to look in to this behavior
stone perch
This sections says to remount Checkout if the session is still open, but there's no way to pass any session to the EmbeddedCheckout component.
paper heath
Can you link me to that doc?
stone perch
sub_1PkUmLC7y2gAMQROPyYqKQXn initial failed subscription marked as "Incomplete"
sub_1PkVDcC7y2gAMQROKnZ9uZgg second checkout successful, new subscription created and marked as "Active"
paper heath
Thank you, checking in to thiese
In that doc, it passes the session's client secret as part of the options object:
const fetchClientSecret = useCallback(() => {
// Create a Checkout Session
return fetch("/api/checkout_sessions", {
method: "POST",
})
.then((res) => res.json())
.then((data) => data.clientSecret);
}, []);
const options = {fetchClientSecret};
return (
<div id="checkout">
<EmbeddedCheckoutProvider
stripe={stripePromise}
options={options}
>
<EmbeddedCheckout />
</EmbeddedCheckoutProvider>
</div>
)
}```Interesting, we don't seem to have that param in the js reference https://docs.stripe.com/js/elements_object/create_express_checkout_element
stone perch
Yes, but that endpoint creates a new session everytime
But even without remounting the component or anything. Just staying in the embedded form. Use a declined test card, immediately use a valid test card. This results in 2 subscriptions.
paper heath
Oh whoops also I was wrong, it is passing the fetchClientSecret function.
Yeah, I do see that the failed call created the subscription, unfortunately that does look to be expected behavior
I can file feedback about that but I think the advice would be to check the subscription status to make sure it is active before provisioning anything
stone perch
So what's the recommended approach here? Do I need to manually cancel "incomplete" subscriptions?
Yes, I'm doing that. That's not the issue.
Just that a lot of "incomplete" subscirptions are created for no reason.
paper heath
I agree, I am very surprised that that is the behavior. Let me see if I can find any more on this
stone perch
And are we sure that an incomplete subscription won't auto-retry after a while? That could lead to double-charging if the customer created another one with another card
At this point I'm thinking of adding a logic to the webhook to cancel all the "incomplete" subscriptions of a customer as soon as a new one "active" is created. Do you see any problem with this?
I'm assuming this behavior is the same whether we're using the Embedded form or the full Stripe-hosted page, do you know?
paper heath
Yep it does look like full page checkout does that as well.
I don't think the subscription will retry but am still checking on that
And that logic makes sense to me. Incomplete is only an initial status, so that should only cancel subscriptions that have never been active.
stone perch
There's no option to pass to the checkout session to tell Stripe not to create a subscription if the payment was not successful?
paper heath
Not as far as I can tell unfortunately