#cho_best-practices
1 messages ¡ Page 1 of 1 (latest)
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- cho_best-practices, 1 day ago, 85 messages
đ 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/1242928783414132836
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
You can't, and that wouldn't really make sense to retry those. A subscription is only incomplete if it requires a payment method or the transaction required authentication. Retrying the payment wouldn't make those succeed
I see, we wanted to do it that way because, if the subscription is considered active, and we get the smart retries, that subscription counts toward our MRR and Churn Rate
So we wanted to be able to try and start the subscription with the retries
Yeah not possible, unfortunately. You'd need the first payment to succeed first
oh, I see. Is there a workaround to increase the 23 hour period?
Why do you need it increased exactly?
Customer will be on-session for the first payment, right?
no customer is off-session
and we want to allow for automatic retries on the payment
because we sell a product, not a service
like we sell a tangible obejct at subscription
So how are you getting their payment info
setup intent
The customer fills out a form for what kind of like colors or things they want on their product
and then we have a person look over it and figure it out if its do-able before we charge them
Ah ok
yeah, our business model prefers not to place the charge as a statement until we confirm it's all good
We're looking for a way to get better numbers here so we're focused on that MRR/Churn number stripe displays
However due to the nature of "Incomplete" and "Active" subscriptions, we're facing this issue
There's not a way to increase that 23 hour window, but error_if_incomplete might be a better payment_behavior for you: https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_behavior
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Yeah, but the retries might not succeed necessarily. That's the problem
You'd get a 402 if the payment required 3ds auth here too
could you remind me what 3ds auth is?
That's why it's best to always collect payment details on-session when creating the sub
I was planning to just recreate the 14 day retry system on my side
You could have 3ds issues
You can, but if 3ds is the reason for the decline, it'll never succeed
it's usually insufficient funds
Yeah I mean up to you
yeah you right
I'm just warning you
it's up to my boss I guess, ty for sure
oh I see
well, our business model does not support collecting the payment on-session
However you would say that using 402 errors
if i listened for the 402, and then audited it to a cron job
that would technically be the same system?
not quite due to the 3ds issue i outlined
Normally when a subscription requires 3ds the customer is online to authenticate it
where do I visualize 3ds
3ds is required when the bank requires it
Idk we don't know much about the dashboard in here
We help with api/coding questions
oh
I see
my apologies
I just couldn't find 3ds
wait wouldn't we have equally as many
3ds issues right now?
since we don't charge on-session right now anyways?
Yeah
oh
then that's a risk we're willing to take
thank you for the warning though
it's out of my hands haha
No problem