#cho_best-practices
zinc carbonBOT
👋 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/1242475502938361896
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
quartz osprey
Hi there 👋 I'm not really sure I'm grasping what you're trying to ask.
frozen valve
Hello, allow me to provide context:
Our customers basically are buying ecommerce goods, physical goods.
We have them finish a setup intent and save their card.
Then we process their order and then charge them for it and then send them the good.
When we charge the customer, they're put on a subscription and then they get renewed every month
The issue is that if a payment fails, and it retries and expends all retry attempts it will move the subscription to cancelled
this increases the churn % (rate of subscription loss)
What is the best practice that we could do in order to avoid this?
So would this method work:
Instead of creating a subscription, create an invoice and then create a subscription once the invoice is paid ?
Or is there a better practice
quartz osprey
No, I would not recommend that path. The Subscriptions would still create Invoices, and then you'd have to suppress a lot of default behavior to avoid double charging your customers.
What are you looking to improve here? Do you not want the Subscription to cancel when payments fail? Do you want to change how many times you retry payments? Something else?
If you can help me understand what you're trying to do, I can help explain how technically to do that, that's what we specialize in here in this forum. However, I don't know what suggestions to make to minimize your churn rate for your market segment, that's not context I have.
We have several prebuilt features that are available for trying to improve renewal rates of Subscriptions, like emailing customers about failed payments, that you can see on this settings page:
https://dashboard.stripe.com/settings/billing/automatic
frozen valve
sorry I had to use the restroom, allow me to read
So we do not like the fact that our customers count toward the churn % when they do not pay us
Because we don't send the product out until they pay us for it first, but if we fail to collect payment, then they are considered MRR we "lose"
when we really never even lost any to begin with
we would like our MRR and Churn numbers shown by stripe to be more accurate is the goal
quartz osprey
Okay, so it sounds like your concern is about the prebuilt analytics in the Stripe dashboard. Unfortunately that isn't something we are familiar with in this forum, we specialize in helping developers work with our API and SDKs. You can reach out to our Support team to see if there is any insight they can offer, they typically know the dashboard better than we do:
https://support.stripe.com/?contact=true
If they don't have any suggestions, then it sounds like you'll need to being calculating your analytics on your own, using your desired logic.
frozen valve
oh I was trying to come up with a programmatic solution
Is there a way to consider subscriptions not as active until the invoice is paid?
quartz osprey
Not on a recurring basis
frozen valve
like a setting I can do during the creation of the subscription schedule
I only need it on the initial creation
quartz osprey
You could do it for the first period, but not for each subsequent period.
frozen valve
that sounds amazing
quartz osprey
Oh, yeah, you can use default_incomplete. But, I'd already expect you to be getting incomplete Subscriptions if your customer doesn't complete the first payment.
quartz osprey
Wait, so what payment is failing in your scenario?
Is it one of the recurring payments?
frozen valve
no
this thing you explained is perfect
because the payment failing is the
1st charge
we sell expensive items
So cards fail at times
And the subscription begins as "active" even if the payment is declined
Which I totally see why, if someone were to be selling a 'service'
I don't see the default_incomplete setting
quartz osprey
How are you creating your Subscriptions?
Because the expected return behavior for the Subscription creation endpoint is to return an incomplete Subscription if the first payment fails:
Returns
The newly created Subscription object, if the call succeeded. If the attempted charge fails, the subscription is created in an incomplete status.
default_incomplete is a possible value for payment_behavior when creating a Subscription:
https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_behavior
quartz osprey
Gotcha, those don't support payment_behavior, it's not possible to start an incomplete Subscription when using Subscription Schedules.
frozen valve
oh what
I do want to mention
I set collection_method to "charge_automatically"
however when I create the subscription I immediately charge the invoice
quartz osprey
Hm, actually, do Subscriptions go into an incomplete state if the first payment for a Subscription payment fails 🤔 sorry, second guessing myself on that.
Do you have an example Subscription from your testing, that you can share the ID for, where you saw this behavior?
frozen valve
like, I mentioned I have never seen the "incomplete" state. However from this screenshot of the API
it makes it sound like charge_automatically will automatically progress into the incomplete state
it might be that I have never seen it because I manually charge it
quartz osprey
I'm going to step through the flow and confirm how it behaves.
quartz osprey
Subscription Schedules create Subscriptions in an active state.
frozen valve
oh for real?
quartz osprey
Yes
frozen valve
So the reason we use subscription schedules in the first place is because
we have to apply a coupon during the first period and only the first period
I see a solution, but I really don't want to do it, it sounds like...
- Make subscription with coupon + price ID applied starting INCOMPLETE
- Turn subscription into subscription schedule using Subscription schedule API
quartz osprey
Why do you need the Subscription Schedule? Is it just for the Coupon? If so a one-time use Coupon should accomplish the same behavior.
quartz osprey
duration set to once:
https://docs.stripe.com/api/coupons/create#create_coupon-duration
frozen valve
I only need a one time use coupon
Okay
So if I may pick your brain for a moment
Right now I make subscription schedules from setup intents and then do stuff after I get the successful paid invoice
To migrate to the solution you've just told me
I would -> Instead of making a subscription schedule, just make a subscription with a coupon that has duration of once
Schedules & subscriptions aren't the same API/object so I'd have to change every instance in my code where I reference the subscription schedule API to be just subscriptions API ??
quartz osprey
Happy to help step through that. My thoughts would be:
- Create a Subscription
-
- set
payment_behaviortodefault_incomplete
- set
-
- apply your single-use Coupon (via
discounts.coupon)
- apply your single-use Coupon (via
- Use the first Invoice from that Subscription to collect payment method details and process the first payment.
frozen valve
fantastic, I'm in alignment with that
quartz osprey
Correct, they are different object types, and your code will need to be updated accordingly.
quartz osprey
Yup 😅 I'd suggest start small
Run through like one Subscription, and make sure it does what you're hoping, before you start changing too much.
Test Clocks can be great for helping test the full Subscription lifecycle and making sure you're happy with it:
https://docs.stripe.com/billing/testing/test-clocks