#lliu_unexpected
worn idolBOT
đź‘‹ 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/1331676297084014722
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
lime raven
Hi there! It sounds like you're relying on search results to make deduplication decisions, which is a risky idea because of the freshness of the search data: https://docs.stripe.com/search#data-freshness It can take some time for the data to get into the search results.
obtuse knot
Thanks
lime raven
You're very welcome!
obtuse knot
We use Strip Elements in the browser to for checkout.
The following is our current checkout flow:
After a user’s attempt to join a subscription plan, our service created the following:
A customer to represent the user.
A customer session of type “purchase”.
A subscription record with a tax included price and “incomplete” status.
Our service returns the following back to the browser:
The ClientSecret from the customer session.
The ClientSecret from the payment intent of the latest invoice of the newly created subscription
In the browser, the customer session client secret and payment intent client secret are used as part of the config to boot strap stripe.elements
With this flow, to show Stripe Elements in the browser, a “incomplete” subscription is required on the browser page load. If the user decides to withdraw from the checkout or simply navigates away from the page, the “incomplete” subscription record is then cancelled.
What that means a customer can have many “canceled” subscription records but only a few of them really are canceled by user’s intension.
Wondering if there is a better way to create subscription record?
lime raven
That seems like a reasonable approach; why are you considering alternatives?
obtuse knot
Wondering if there is a way to create subscription record and after the first successful payment intent.
For example,
- Create a payment intent for regular purchase
- After the payment intent is successful create a subscription record and attach the successful payment intent to the first invoice of the subscription record.
lime raven
There is, but it's not necessarily the recommended integration path.
Are you using webhooks to decide when to provision and deprovision service to the Customer? https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements#provision-access
What exactly are you trying to accomplish by doing the payment first?
obtuse knot
so that we do not create "cancelled" subscirption records without user's intentions.
lime raven
If the user didn't pay for it, then it's their intention to cancel, right?
Why don't you want the cancelled ones there?
obtuse knot
By our definition, a cancelled subscirption is a subscription that is cancelled after it was once in "active" status.
lime raven
Ok gotcha. You can find out why a Subscription was cancelled in the subscription.cancellation_details.reason property: https://docs.stripe.com/api/subscriptions/object#subscription_object-cancellation_details-reason
obtuse knot
That property would not work for our cases, cause all those subs cancelled because the user decides not to go through the purchase would be "cancellation_requested" which cannot be used for cases where subs were once active but requested to be cancelled by users.
lime raven
Ahh gotcha. You could specify the details of the cancellation when you cancel it: https://docs.stripe.com/api/subscriptions/cancel#cancel_subscription-cancellation_details
And you could then use that to filter your subscriptions.