#staleriver_unexpected

1 messages Β· Page 1 of 1 (latest)

chrome hullBOT
#

πŸ‘‹ 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/1362207011189686372

πŸ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

graceful patio
#
  1. Set "Use Smart Retry policy for subscriptions" -> Retry up to x times within x weeks.

That explicitly says it's only for subscriptions, right?

#

What's the Invoice ID?

drowsy minnow
#

hmm but I've used and tested this feature pretty extensively in the past (though admittedly it was more than a year ago), so I'm pretty sure it used to apply for manually created invoices as well. We have a whole integration built around this so I was kinda caught off guard when it didn't work as I expected it to when I tested it recently.

Example test invoice is in_1REeYXIeqdRa1lgKOTKvQmO4

#

Just to clarify the sequence of events:

  1. I created that invoice above on 4/16.
  2. Payment fails for the first time.
  3. Move the test clock by 21 days (this is the setting we're using).
  4. Subscription remains in the past_due status and doesn't transition to unpaid <- this is the "unexpected" behavior
graceful patio
#

The Payment Intent on that Invoice is in a requires_payment_method state, and I think that's why it disabled automatic collection (which is why it didn't retry, and why it never transitioned - it never got through all its attempts).

drowsy minnow
#

hmm we're not using the Payment Intent API so I'm not too familiar with that particular status. I'll take a look at the documentation. That being said, nothing really changed on our end, so still confused as to why the behavior apparently suddenly changed πŸ€”

chrome hullBOT
drowsy minnow
#

What state would trigger automatic collection?

chrome hullBOT
sonic knoll
drowsy minnow
#

So I found an example on production that did behave as expected. This makes me believe that the issue is with the Stripe Test Clock.

Here is a manual invoice that first failed on 3/25. The final payment attempt happened 21 days later (which is the setting we have) on 4/15. The subscription also turned to unpaid on 4/15 as expected.

https://dashboard.stripe.com/invoices/in_1R6V0BIeqdRa1lgKHWcy3ePO

sonic knoll
#

okay, this is going to take a while for me to investigate, are you alright to create a support ticket and I'll get back to you on it after looking further into this?

drowsy minnow
#

Yes of course. How do I create a support ticket?

chrome hullBOT
#

Hello @drowsy minnow, we have sent you a direct message, please check it at https://discord.com/channels/@me/1362224554889449482

  • πŸ”—The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
sonic knoll
#

you should have received a DM with a link and the instructions πŸ˜„

drowsy minnow
#

Thank you!