#dominikganic_best-practices
tardy stratusBOT
👋 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/1349353520897331293
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- dominikganic_unexpected, 2 hours ago, 33 messages
- dominikganic_best-practices, 16 hours ago, 29 messages
- dominikganic_unexpected, 1 day ago, 13 messages
unique crater
What's the object ID?
fast crest
One second I will reproduce it quickly and provide you all required neccessary id's 🙂 1 sec
unique crater
I just need the pi_xxx ID
But I think what you're describing is expected as we only allow for a certain number payment/confirmation attempts:
here is a variable upper limit on how many times a PaymentIntent can be confirmed. After this limit is reached, any further calls to this endpoint will transition the PaymentIntent to the canceled state.
https://docs.stripe.com/api/payment_intents/confirm
Which in effect applies to invoice payment attempts too
fast crest
Yes, that's correct, after a few failed attempts the payment intent has been canceled. The invoice remains open.
Now what I'm struggling is the best practice here. What should I do now to provide a good user experience?
Should I "void" or mark out of brand the current invoice, create a new one and let the customer pay it?
Or is there even a better solution exactly for this case?
unique crater
This is a recurring invoice attached to a sub, right?
fast crest
Yes! 🙂
unique crater
In that case, if the intention is to keep the subscription active the best approach is to mark the invoice as paid out of band and process a separate Payment Intent for the same amount if that makes sense
fast crest
Just for clarification:
- Mark the invoice as paid out of band: Is that ->invoices->markUncollectible()?
- Process a separate Payment Intent with the same amount: That means I should just create a new payment intent?
unique crater
That will keep the sub 'active'
You can then 'link' that adhoc PI with the invoice it 'pays' via metadata or something for reconciliation
fast crest
Hm I'm confused now a little bit.
When processing an invoice payment I currently do:
- Try paying the invoice in the default way
- When that fails, I will look up why. When user action is required, I will guide the user to the action.
- When it fails because the payment intent has a state of "canceled", should I now try again to pay it wiht "paid_out_of_band" set to true?
Btw. I should revert the path.
- Check if the payment intent currently requires action yes / no
- Check if the payment intent has been canceled -> when yes, pay the invoice with "paid_out_of_band"
fast crest
You can then 'link' that adhoc PI with the invoice it 'pays' via metadata or som...
When I link metadata to it, stripe won't notice that this payment intent is bound to the subscription right?
unique crater
- What is 'the default way'?
- Seems sensible
- Yes, that will mark the invoice as 'paid' regardless of the associated intent state
unique crater
When I link metadata to it, stripe won't notice that this payment intent is boun...
Correct
fast crest
1. What is 'the default way'?
2. Seems sensible
3. Yes, that will mark the invoi...
So, the invoice is "paid" because of "paid_out_of_band". My subscription will change from "past_due" to "active". But the user hasn't done any payment, that's not good right?
Is it a bad behavior to create a new invoice after "paid_out_of_band" was set to true on the recent invoice?
I'd like to remain the "past_due" status on it as we have automations set. Now it will break the automation and reset everything to "active".
unique crater
So, the invoice is "paid" because of "paid_out_of_band". My subscription will change from "past_due" to "active". But the user hasn't done any payment, that's not good right?
Sure, so you'd only do that when the payment for the ad-hoc payment is successful I guess
Is it a bad behavior to create a new invoice after "paid_out_of_band" was set to true on the recent invoice?
Not really, but it won't be associated to the sub and therefore won't transition the state
fast crest
So is there any way to create an associated new invoice for the subscription?
unique crater
Nope
fast crest
Ah I understand. I will pay the invoice with "paid_out_of_band" only when I've received a successful payment through a new payment intent with the same amount.
unique crater
Yes!