listeningglass_unexpected

[bleak kestrel]

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

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

[scenic plover]

Setup. We migrated 158 active subscribers from a third-party billing system into native Stripe Subscriptions on May 5. Each sub created via POST
/v1/subscriptions with: customer, items[0][price], billing_cycle_anchor set to a future timestamp matching the customer's historical billing
date, proration_behavior=none, default_payment_method (legacy card_* ID, verified retrievable as a PaymentMethod),
payment_settings[payment_method_types][]=card, plus metadata. All 158 created successfully, status=active, billing_mode.type=flexible. API
version: 2026-04-22.dahlia.

Expected behavior per docs. The billing-cycle docs state that billing_cycle_anchor in the future combined with proration_behavior=none defers
invoice generation until the first billing period. At the anchor, a subscription_cycle invoice is generated. Per the invoice object docs, an
invoice with auto_advance=true is attempted approximately 1 hour after the invoice.created webhook.

Observed behavior. On 2026-05-06 at 06:00 UTC, the first two billing_cycle_anchor moments hit. Both subscriptions correctly generated
subscription_cycle invoices with status=draft, auto_advance=true, billing_reason=subscription_cycle, collection_method=charge_automatically,
automatic_tax disabled. Both invoices sat in draft status for over 5 hours with attempted=false and attempt_count=0. The auto-finalize never
fired. We voided them manually at the 5-hour mark to prevent any double-charge risk while we investigated. Reference invoices:
in_1TTyY3AxuIySbsxlH9kwE4QS and in_1TTyWZAxuIySbsxlhuZoAgB6. Account: acct_19gE7NAxuIySbsxl.

Pattern across the account. The same Stripe account has older subscriptions in classic billing_mode that have been auto-finalizing
subscription_cycle invoices reliably for years (90+ paid renewals examined, all finalize at exactly 1 hour 1 minute after creation, paid_at
within seconds of finalized_at). Every recent subscription on the account, including these migrated subs, is in flexible billing_mode. We have
zero observed cases of a flexible-mode subscription_cycle invoice auto-finalizing on this account. The one flexible-mode invoice that paid was a
subscription_create via Checkout, which paid immediately at session completion and never traversed the auto-finalize-after-grace path.

Experiment running tonight. Three subs anchored at 2026-05-07 06:00 UTC to isolate which fields trigger this behavior. (1) A fresh sub on the
account with no payment fields set on the sub; customer's invoice_settings.default_payment_method has a modern pm_*. (2) A migrated sub with
default_payment_method cleared to null (payment_settings cannot be unset via API once set). (3) An untouched migrated sub as control. Will share
results in this thread tomorrow.

The question. Does flexible billing_mode handle subscription_cycle invoices generated from a deferred billing_cycle_anchor +
proration_behavior=none differently from classic mode in a way that prevents or significantly delays auto-finalization beyond the documented
1-hour grace? If yes, where is this documented or how should this configuration be done correctly? If no, this looks like a structural issue
affecting 162 active subscriptions on our account worth roughly 15,000 USD monthly recurring revenue.

Happy to share additional invoice IDs, request IDs, or full subscription configurations on request.

[atomic totem]

Looking into the examples

In https://docs.stripe.com/invoicing/integration/workflow-transitions#finalized:

We wait 1 hour after receiving a successful response to the invoice.created event from all listening webhooks before attempting payment. If we don’t receive a successful response within 72 hours, we attempt to finalize and send the invoice.

Take in_1TTyY3AxuIySbsxlH9kwE4QS as an example, one of the Webhook endpoint didn't acknowledge 200 status code for its invoice.created event: https://dashboard.stripe.com/acct_19gE7NAxuIySbsxl/events/evt_1TTyY4AxuIySbsxlH5D5TpGK

This was the reason why the invoice didn't finalize after ~1 hour.

This is the same for invoice.created event for in_1TTyWZAxuIySbsxlhuZoAgB6: https://dashboard.stripe.com/acct_19gE7NAxuIySbsxl/events/evt_1TTyWaAxuIySbsxlNb4Gthcf

Since Stripe didn't get successful response from all Webhook endpoints, the invoice will only be finalized automatically after 72 hours

[bleak kestrel]

⛔️ Stripe developers have stepped away for a short while

Please leave your questions here, and we’ll respond as soon as we're back! If you need help urgently, you can contact Stripe support for help.

[scenic plover]

▎ Confirmed via the event log (pending_webhooks=1) and a 404 probe of the URL. The legacy 2017 webhook endpoint at tomhegna.com/webhooks/stripe
▎ was installed by our previous billing system back when they integrated Stripe; the URL stopped responding when we cut over to a new domain
▎ config last week. Deleting the endpoint at 11:46 PM ET tonight. Three subs are anchored at 06:00 UTC to verify the fix. Will update tomorrow
▎ with results. Thank you for the fast and accurate diagnosis.