#felix_unexpected

1 messages · Page 1 of 1 (latest)

still ospreyBOT
#

đź‘‹ 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/1334256702974984263

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

inner edge
#

Hello, do you have the ID of the subscription that this happened with? (sub_123)

fallen delta
#

Hey Pompey, sure: sub_1QkPLEFGsUkmOd7KX4u46p1L

inner edge
#

Still piecing this together, I do see that the invoice was created by the user changing their plan through the portal and that that is inline with your billing portal config that has proration_behavior='always_invoice' for subscription updates. Have to hop to other threads but am still figuring out what happened with the payment when the invoice finalized

#

Oh sorry I see now, the payment is still in a processing state. This is expected behavior but let me see if I can find it documented. If/when the payment succeeds it will go back to an active state. If it fails I think it should be treated like a normal payment failure. Trying to find if we have a recommendation, if I remember correctly it may be that you retrieve the payment intent to check its status if the PM is a type where its intent can go processing

fallen delta
#

Thanks, i am really confused about what past_due is supposed to be and why it is put into this status here. If a new subscription is created with that PM, it is imidiatly active, even though the payment intent is still processing. I was expecting the same behaviour here.
Another question: Since the user did not see the successfull activation, he did a new activation and created a new subscription, also with SEPA. Hoewever now we have a double booking and both payment Intents processing. Is there a way to cancel a pending sepa payment?

inner edge
#

Double checking but I don't think so unfortunately. I think you will have to wait for it to finish and then refund one of those payments. And yes, I was surprised for the same reason when I first found out about this behavior. Still confirming that from our docs too

fallen delta
#

Thanks for checking.
For the future, I will change our code to see past_due as a valid state for providing access. If I am not mistaking, if the payment intend finally fails (goes from processing into a failed state) the status of the subscription will change again and not remain past_due, correct?

inner edge
#

That would depend on your subscription settings on your account but yes, if a failure would normally move the subscription to some other state for you, a failure on one of these payments should act the same.

#

Also I reached out to my colleagues to confirm my memory that this is expected behavior. The server has been a bit busy so I haven't had much luck when searching

fallen delta
#

With subscription settings you mean, how we provision access to our service? If yes, than this would be correct as we want to provide acces even though an async payment method is still pending

inner edge
#

I was more referring to the settings on this page for managing failed payments for subscriptions. It looks like retries can only happen for Card and ACH. So for SEPA I think if the payment fails we will immediately do what you have set for "Subscription status" -> "If all retries for a payment fail"https://dashboard.stripe.com/settings/billing/automatic

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

fallen delta
#

Ah amazing that helps a lot. So I can choose the state it transitions to and I also see "keep in past due" here. It also gives me the option to choose between canceled and unpaid. Currently we have this set to cancelled but as this as caused confusion, I would actually move this to unpaid as this makes it easier to distinguish between failed payments and normal cancellation for our analysts. Do subscriptions in the unpaid status behave the same as cancelled ones? Meaning they do not renwe into new cycles, etc?

inner edge
#

The invoice will still cycle and create new invoices, but payment isn't attempted on the new invoices and I believe they go into unpaid immediately.

The latest invoice hasn’t been paid but the subscription remains in place. The latest invoice remains open and invoices continue to generate, but payments aren’t attempted. Revoke access to your product when the subscription is unpaid because payments were already attempted and retried while past_due. To move the subscription to active, pay the most recent invoice before its due date.
https://docs.stripe.com/billing/subscriptions/overview#subscription-statuses

fallen delta
#

Ah I see, however given what we just discussed about the update with sepa payment, this doc page says something different or am I misunderstanding?
For past due it says "Payment on the latest finalized invoice either failed or wasn’t attempted..." given that documentation I would expect the subscription to be incomplete, as it says "Subscriptions can also be incomplete if there’s a pending payment and the PaymentIntent status is processing.""
Or am I misreading this?

#

(Sorry for going back and forth, I am just trying not to mess something up with handling the subscription statuses if I allow access for past_due subscriptions)

still ospreyBOT
inner edge
#

You are reading that right. What might be happening is that it was expected (if unintuitive) behavior for the first invoice to behave differently from subsequent invoices, but my colleagues and I are still having trouble confirming one way or another. Our SEPA Subscriptions doc doesn't mention this status, but it also makes this a bit confusing because it also confirms that we don't do retries. But because this payment hasn't failed yet, it shouldn't be doing anything related to your failed payment behavior yet.

Assuming the initial payment succeeds, the state of the subscription is active and no further action is needed. When payments fail, the status is changed to the Subscription status configured in your automatic collection settings. You should notify the customer on failure and charge them with a different payment method.
Note
SEPA Direct Debit payments are never automatically retried, even if you have a retry schedule configured for other payment methods.
https://docs.stripe.com/billing/subscriptions/sepa-debit?platform=web&payment-ui=direct-api#manage-sub-status

fallen delta
#

It is good to hear, that you are also confused. I was already doubting myself.
That is actually a really important point. We have just started using stripe and we do not yet have the first sepa based subscription hit the first cycle. If all subsequent invoices cause the subscription to go past_due until a sepa payment either succeeds or fails, this is really important to know for me to handle this state correctly, as a Sepa payment takes up to 14 days to complete, I would not want all these subscriptions to be inactive for that time every cycle

inner edge
#

Okay, I found confirmation on how this works, it turns out that this is only the behavior for invoices that come from subscription updates. So the expected behavior is:

  • For the first payment and recurring payments, we will go straight to an active state when the payment intent goes into a processing state.
  • For invoices created by an update to the subscription, the subscription will go into a past_due state.
    You can differentiate between these by checking the billing_reason property on the invoice. It will be subscription_update that indicates that it was created by an update.
fallen delta
#

Ah, good to have a confirmed behaviour!
Question on that: What webhooks are recommended to listen to in order to reconcile the subscription?
There are many ways to get subscription creation and update info. Currently we listen to subscription.created, subscription.updated and invoice.paid or invoice.payment_failed webhooks. If we need the billing reason to determine the correct status, we would probably need to reconcile subscription based on invoice events alone. Are there best practices for how to do this?

inner edge
#

Unfortunately not, it looks like this only generated a customer.subscription.updated and a payment_intent.processing event when it happened. There wasn't a failed payment so we didn't generate an invoice.payment failed event. So the pure API way to do this is if you get a customer.subscription.updated event with a past_due status, retrieve its latest_invoice while expanding its payment_intent property. If the invoice's billing_reason is subscription_update and the intent's status is processing then it is an instance of this behavior.

fallen delta
#

I can see in evt_1QmftiFGsUkmOd7KJHS5aBdE a new invoice with the billing reason subscription_update was created so maybe listening to new invoices would do the trick? The payment was not failed in this case so providing access would have been the right thing to do

bold sequoia
#

Hi, taking over as my teammate needs to step away

#

Let me catch up

fallen delta
#

Hey pgskc, to reiterate:
We had a customer wo subscriped to our free plan und then upgraded to a paid plan through the stripe customer portal. Since he used the SEPA debit payment method (which is async), the subscription was directly put into past_due status.
We found out that this is actually the inteded behaviour and now I am trying to figure out how to correctly reconcile webhooks and provide users access to our system.

bold sequoia
#

Yeah, I think that would make sense. I would recommend building that logic and testing it on your end to confirm

fallen delta
#

Currently we do the following:
Listen to subscription.created, subscription.updated and subscription.cancelled webhooks for getting changes on the like user cancellation, subscription updates and the subscriptions status. The question is whould we rely on invoice.created events to create and update subscriptions on our end or use the specific subscription webhooks. Are there any best practices?

bold sequoia
#

There is not an explicit recommendation I could suggest without testing this fully. This is why I recommend that you test this first and ensure that you're fully covered

fallen delta
#

Okay, thank you. One more quick thing to clarify: there is also a checkout session completed event. I saw some docs use that for provisioning and some use subscription.created. Is there a reason to use checkout session completed if we are not using one time payments?

bold sequoia
#

If you're not relying on it cirrently, you do not need to add this no

fallen delta
#

Understood and with the invoice.created event, the doc here (https://docs.stripe.com/billing/subscriptions/event-destinations#events) suggests that stripe waits for successfull webhook responses to this event beforefinalizing the invoice? Does that also mean, that the payment is deplayed? So If a customer uses the checkout for example with a credit card, and the webhook delivery fails, would stripe then wait before actually collecting the money?

Using event destinations with subscriptions

Learn to use event destinations to receive notifications of subscription activity.

bold sequoia
#

Yes, that is right.

fallen delta
#

Is it valid to use that for final validation that the customer can be charged or to abort the subscription and charge, before money is collected?

bold sequoia
#

Are you able to reword the above please? I do not fully understand what it's asking

fallen delta
#

My question is, if it is a valid pattern to use the fact, that the webhook for invoice.created is awaited before actually chargin the customer to do a final check on our side if the purchase can be executed or to potentially cancel it during that webhook, as no money has yet been transferred

still ospreyBOT
last haven
#

Hi hi! So this is still about SEPA DD mid-payment causing Subscriptions to shift into a past_due state, ya?

fallen delta
#

More or less, we shifted towards how to update the imlementation but after the last question I think we are all set

#

In Any case, thank you so much for the support! That did help a lot

last haven
#

So you're good to go? You are of course welcome to return any time and we're happy to continue the conversation, but is there anything more we can help with for now?

fallen delta
last haven