#zerg
misty urchin
Can you share the subscription id where you're seeing this happen?
hollow forge
Sure! sub_1N8NK1JdX8lIDNiaVMDELF06
misty urchin
Since the default PM is coming from invoicesettings.defaultpaymentmethod, it's not expected that you'd receive customer.subscription.updated
There's nothing that will change on the subscription
So there's nothing to update
hollow forge
Ah, so detaching the PM from the customer doesn't necessarily detach it from the subscription?
misty urchin
Well it was never attached to this subscription
The only place you're specifying the default PM is on the customer object
timid trailBOT
hollow forge
Interestingly an invoice for that subscription was paid, so I assumed it used the PM I attached to the customer (that somehow propagated to the customer's subscriptions?)
misty urchin
Yes that's correct
We note the order in which we search for a PM here: https://stripe.com/docs/api/subscriptions/object#subscription_object-default_payment_method
hollow forge
Cool, thanks. What is the best way of "cleaning up" the payment method associated to the customer/subscription? I would like to ensure the customer is not charged once it is removed (equivalent to deleting the payment method on the dashboard).
misty urchin
Why not cancel the subscription?
hollow forge
A use-case for not cancelling the subscription is when the user added the wrong payment method but removed it to add a new one, which the customer intends to do so before the subscription ends, but then forgets to do so
In another words, I am testing how fiddling with payment methods affects the customer's subscriptions
So in this case, I expect the subscription to be cancelled due to no payment as a side-effect rather than cancelling it directly. (which I managed to reproduce through the dashboard, so I was hoping to code it).
misty urchin
So you want them to be able to have a subscription for free if they forget to add a PM?
hollow forge
No, quite the opposite, I was hoping to receive a subscription updated webhook as past_due so I can disallow access until the payment is sorted, at least until enough payment retries were attempted and the subscription cancels
misty urchin
Oh well that will happen when subscription attempts payment during the next cycle
If you remove the customer's default PM and it's not replaced, then payment will fail on the subscription and it will go to past due
hollow forge
That is exactly what I am trying to do! So performing a PaymentMethod.detach() will remove the default PM or I should set it to null on the customer as well?
misty urchin
Yeah so if you detach it from the customer it will no longer be set as the default
Since PM's that are detached aren't usable
Something important to note is what we outline here: https://stripe.com/docs/api/subscriptions/object#subscription_object-default_payment_method
ID of the default payment method for the subscription. It must belong to the customer associated with the subscription. This takes precedence over default_source. If neither are set, invoices will use the customer’s invoice_settings.default_payment_method or default_source.
So really you need to make sure a PM isn't set in all of those places
But depends on your flow
Like there may never be a case in your integration where all those are set, but it's important to note