#smitit1999_unexpected

1 messages · Page 1 of 1 (latest)

jade girderBOT
#

👋 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/1488040715115040820

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

unborn rover
#

hello! gimme a while, taking a look

unborn rover
#

When you set pause_collection with behavior: void on a subscription, it doesn't only affect newly generated invoices. Stripe has background processes that periodically check on invoices that still need action, such as invoices awaiting a payment retry after a failed attempt. When one of these processes picks up an existing open invoice and sees that the subscription now has pause_collection: void, it applies the void behavior to that invoice as well.

In your case, the invoice was open with a failed payment and waiting to be retried. When the background process came around to advance it, it checked the subscription's pause collection setting, saw behavior: void, and voided the invoice instead of retrying it.

Our public docs don't currently document this behavior, and I'll pass on the feedback to get this clarified.

Unfortunately, I don't have a great workaround for this. The best option I can suggest is to set auto_advance: false (docs) on the open invoice(s) before setting pause_collection: void on the subscription. This keeps the invoice(s) out of the background processing pipeline that would otherwise void it.

One thing to keep in mind though: when/if you're ready to collect on that invoice later, I wouldn't recommend relying on setting auto_advance back to true. Stripe's retry/dunning schedule has a defined window, and if that window has already elapsed, re-enabling auto_advance won't restart the dunning cycle or trigger new automatic retries. Instead, you should collect payment on the invoice manually via the API (POST /v1/invoices/{id}/pay).

torn nest
#

Okayy, thanks for the explanation, will try with setting auto advance as false and then see if that fixes it

unborn rover
torn nest
#

Sure @unborn rover . Actually, I noticed that this particular invoice - in_1SwKfWA5BZ3mzPMyvmhnXJSL had auto_advance set to false

#

So it shouldn't have happened right?

unborn rover
#

auto_advance was only set to false after payment was attempted and failed and the invoice voided

torn nest
#

I can see it was set to false on Feb 2nd (Ref - req_2VNIlz6uo1sx6f) whereas the payment attempt and invoice void happened on 26th March

unborn rover
torn nest
#

Could you let me know how? Because from the API, I don't think we set auto_advance back to true explicitly

unborn rover
#

hmmm, so it looks like when a payment attempt happens on the invoice and the payment intent goes into a state like requires_action or processing, Stripe can automatically reset auto_advance back to true as part of processing that payment. That's what happened on March 27 - the payment attempt reset auto_advance to true, and once the invoice was back in the automatic processing pipeline, it got voided because of the pause_collection: void setting on the subscription.

I'm going to DM you with a link to create a support ticket, once you write in, we can look into if there's any feature we can enable on your account to respect the auto_advance: false setting (once it's been set) and not automatically flip it back on during a payment attempt

jade girderBOT
#

Hello @torn nest, we have sent you a direct message, please check it at https://discord.com/channels/@me/1379347120661729301

  • 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
torn nest
#

Thanks @unborn rover