#john-a_docs
somber swanBOT
👋 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/1285331821801902081
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
meager topaz
What's the basic workflow/best practice on how to do this?
Looking in to this. I forget if subscriptions themselves have a setting for this but will double check. One way to do it would be to create a SetupIntent apart from your subscription and wait until that is successfully confirmed before creating your subscription.
Will Stripe stop spammers from creating multiple subscriptions that use the same payment method?
As far as I know we don't have an automatic setting to detect this and delete new subscriptions based on card number. For this, what you can do is check the fingerprint of newly saved cards and see if you have already encountered a card with the same fingerprint.
https://docs.stripe.com/api/cards/object#card_object-fingerprint
Will entitlements work as expected?
I am not immediately sure what you mean by this. Can you go in to a bit more detail on this question?
olive lily
While starting a free trial without a payment method lets your potential customers try your product or service faster, it can also allow spammers to create lots of fake customers, usage, and subscriptions.
From your docs, that's exactly what we're trying to avoid 🙂 So two main problems we want avoid -- #1 spammers/bots creating lots of accounts, signing up for free trials without any payment methods #2 spammers/bots creating lots of accounts, signing up for a free trial with one single card across all accounts
Entitlements
In the "require payment method for free trial" use case, we'd expect an entitlement to not be added to a customer until they have added a payment method when starting their free trial.
meager topaz
For #1, I am not finding any settings on the subscription itself, so I think going the SetupIntent route that I mentioned is the way to go.
Same with #2 and my fingerprints suggestion.
Catching up on how our entitlements work again. Somehow I just completely blanked on that offering
olive lily
Thanks, but oof. Free trials for subscriptions is...super common, pretty much every major subscription service out there offers them.
We may have to look at other options if this isn't a simple to set up thing. I took a look at SetupIntent docs, right off the bat I'm not sure how we "transition" a customer's SetupIntent into a subscription. Is user interaction required to do that, or can we do that completely via api? With a SetupIntent, will the "checkout" page make it clear that the user is setting up a free trial for a subscription that will start in X days if they don't cancel?
meager topaz
Oh are you using Checkout? I think I assumed you were using a custom page. By default Checkout will require a card before starting a subscription
olive lily
Sorry, yes we're using checkout
Although we were planning on moving to a custom page in the future, so that's a bit worrisome. But when generating the checkout link, we simply add trial_period_days and then if and only if the user enters a payment method, the subscription with free trial period will begin I assume?
We can manually test the entitlements stuff but I always like to have firm documentation on how that will work
somber swanBOT
meager topaz
we simply add trial_period_days and then if and only if the user enters a payment method, the subscription with free trial period will begin I assume?
Correct. Just tested this
Although we were planning on moving to a custom page in the future, so that's a bit worrisome.
This is not a difficult flow to implement for a custom page. You would basically save a user's card with a SetupIntent and then immediately after it succeeds you would create a Subscription and pass the ID of the saved PaymentMethod as the default for the subscription.
https://docs.stripe.com/payments/save-and-reuse?platform=web&ui=embedded-form
https://docs.stripe.com/api/subscriptions/object#subscription_object-default_payment_method
Does that make sense? Happy to go in to more detail, it is a lot to take in at first. Checking in to the entitlements again
olive lily
Yeah just one question for future when we do set up a custom page -- we save the user's card, create a subscription and pass the id of the saved card to that. Easy enough.
We can do the "start subscription with that card" piece without the user's interaction?? We're a legit company and wouldn't ever charge our customers without their knowledge but it seems like lots of nefarious companies could abuse that!
meager topaz
Correct, SetupIntent then trialing subscription is actually what Checkout does behind the scene.
We're a legit company and wouldn't ever charge our customers without their knowledge but it seems like lots of nefarious companies could abuse that!
When the user saves their card with you via a SetupIntent, the explicit idea there is that they are saving their info with you to be charged later, in this case while they are not around. My knowledge is more API oriented, so I am less sure of the specifics of our anti fraud measures around merchants here but we do have measures in place to detect and prevent merchants from abusing their customers like that. Our support team may be able to tell you more if you reach out https://support.stripe.com/?contact=true.
There are a wide array of legitimate use cases for charging users offline after they have saved a card with you so the trust from the banks and Stirpe does have to start somewhere. There are other payment methods that have further restrictions, like having to describe the exact amount and frequency of payments upfront, but that is not the case with cards.
olive lily
There are a wide array of legitimate use cases for charging users offline after they have saved a card with you so the trust from the banks and Stirpe does have to start somewhere
Very true. Makes sense, thanks