fyre_invoice-smartretries

[fast anvil]

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

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

[little remnant]

Hello, can you tell me more about your subscription setup here? Is this your dashboard settings that are moving the subscription to past due? My understanding is that that would happen after your retry schedule has already completed and I am not immediately aware of a grace period beyond that but am looking

[blissful jungle]

Thanks! I'm trying to collect some more information about what the intended behaviour is here. From what I understand, we're looking to have a certain grace period and final end date after the payment fails. For example:

• Apr 13 - successful payment
• May 13 - failed payment, while retry schedule is followed, wording to the customer: "Payment declined, your access ends on May 15" (or whatever the configurable grace period is).

After some more thought, I guess this is essentially the retries (they should just maintain access as long as retries are happening). Looking at the retry schedule docs, I see there are dates for next_payment_attempt, but is there any such data on when the final payment attempt would be? Or is that calculable in any way?

[little remnant]

Gotcha, I forget how to tell if the last attempt has happened but am looking into it. I don't think there is a way to get that timestamp from us when the invoice is first created with either setup. With the fixed schedule we'll only show the next attempt time, with smart retries the times will change dynamically I believe. It is also possible for the retries to end prematurely in either case if we get a decline code that indicates we shouldn't try again (like card stolen)

[little remnant]

The next_payment_attempt timestamp will become null after the final retry from your schedule. So I think paying attention to that field should be sufficient here.

[blissful jungle]

Gotcha, thank you!