jshmc | Stripe Developers | Page 1

last gazelleBOT Feb 6, 2024, 3:47 PM

#

jovial stag Feb 6, 2024, 3:49 PM

#

Hi there 👋 my first suggestion would be to check and ensure that Link is enabled as an available payment method within your Invoice template settings:
https://dashboard.stripe.com/settings/billing/invoice?tab=general

If it's enabled there, can you share the ID of a request where you're seeing that error that I can take a closer look at?

teal furnace Feb 6, 2024, 4:01 PM

#

Ooh, interesting! It wasn't turned on there – have done so now, will give it a whirl!

#

Hmm, no dice. Additionally, when the customer tries to manage their subscription via the Billing Portal, they see this:

jovial stag Feb 6, 2024, 4:05 PM

#

Sounds good! It can be a bit tricky that automatic/dynamic payment methods for Subscriptions use a subset of the payment methods enabled for dynamic payment methods in general and those enabled via the Invoice template settings.

teal furnace Feb 6, 2024, 4:05 PM

#

I wonder if it's related?

jovial stag Feb 6, 2024, 4:05 PM

#

Do you have specific object/request IDs I can look at?

teal furnace Feb 6, 2024, 4:06 PM

#

Sure, that billing session I just created to get that error message was bps_1Ogr80GUhjX199TJN9DBA9ee

jovial stag Feb 6, 2024, 4:12 PM

#

Hm, I think that might be because the Subscription was created before the payment method settings were changed. Do you see the same issue for a new Subscription? Looking to see if that can be updated in parallel.

#

Are you able to make an update request for the Subscription to adjust the payment_settings.payment_method_types so that it includes link?
https://stripe.com/docs/api/subscriptions/update#update_subscription-payment_settings-payment_method_types

teal furnace Feb 6, 2024, 4:16 PM

#

Yeah – that's fixed it. Are we gonna have to make that update for all existing subs with a link payment method attached?

jovial stag Feb 6, 2024, 4:21 PM

#

Hm, wait, you were able to set a link Payment Method on the Subscription, before the Subscription was set up to accept link Payment Methods?

teal furnace Feb 6, 2024, 4:23 PM

#

Yeah, that's what's kind of baffling

#

The subscription was created with no payment method, the user's been through a cardless trial, subsequently added a payment method (which is a link) via the billing portal, been charged a few times, but now whenever they / we try to update the subscription it fails

jovial stag Feb 6, 2024, 4:27 PM

#

Are you able to reproduce that behavior in testmode?

teal furnace Feb 6, 2024, 4:28 PM

#

I can give it a whirl

#

Yeah this is baffling – in test mode payment_settings.payment_method_types just gets set to null. I wonder if this is because the subscription was set up when we were passing payment_method_types into the Stripe Checkout / Billing Portal creation process

#

Presumably it would be safe to just set it to null for every subscription to have it use the defaults?

last gazelleBOT Feb 6, 2024, 4:41 PM

#

jovial stag Feb 6, 2024, 4:42 PM

#

I'm not sure offhand. I'd still like to know the exact steps taken to get Subscriptions into this state, as it sounds like it may be undesired behavior on our end.

teal furnace Feb 6, 2024, 4:44 PM

#

Is there anything I can do to help with that? Afraid the best I can do is look through the request logs for the subscription to piece things together as I can't currently get a subscription into this state in test mode.

#

D'oh! Found the smoking gun. We were explicitly setting the payment method types on subscriptions on creation until a few months ago

jovial stag Feb 6, 2024, 4:47 PM

#

Ahh gotcha. I'm still curious why we would let you add a link payment method, and then not error until a later update. I'll want to take a closer look at the steps leading up to that.

hasty seal Feb 6, 2024, 4:49 PM

#

I'll leave that one to you @jovial stag since it's Link specific and you're digging into a potential bug

jovial stag Feb 6, 2024, 4:57 PM

#

Can you help me understand what actions the customer took in the portal? Stepping through the history of things, I think I'm seeing:

the customer already existed
they had a Subscription that already existed
the Subscription was paused
a Portal Session was created for the Customer, where they encountered the error

I want to make sure I understand so I can start stepping through this flow to see if I can replicate this behavior.

teal furnace Feb 6, 2024, 5:04 PM

#

So as I understand it, I think what's happened is:

We create a subscription server-side when the customer signs up to the application, with a trial_period_days of 14, trial_settings.end_behavior.missing_payment_method of pause and payment_settings.payment_method_types of ["card"]
At some point before the trial ends, the user goes into the billing portal and adds a link payment method
Payments succeed, even though the payment_method_types is set to card, but the subscription can't be updated either by us via the API (e.g. to update quantities), or by the customer from the billing portal (e.g. to move to a different plan)

jovial stag Feb 6, 2024, 5:11 PM

#

Gotcha, that didn't line up with the random sample I grabbed, let me take a closer look at the objects associated with the portal session you shared.

#

Yup, that seems to align with what I'm seeing now. Thank you for walking me through that, working on testing replicating that now.

jovial stag Feb 6, 2024, 5:40 PM

#

Sorry, it's taking me longer than I expected to step through this, and I still have a ways to go. I think at this point the approach you have is going to work for recovering your Subscriptions, and the changes you made adjusting how they're created previously should avoid new Subscriptions from being impacted. I think I have everything I need at this point to keep digging into this on my hand and report it to the appropriate teams.

#jshmc