#jds_api

1 messages ¡ Page 1 of 1 (latest)

crude anvilBOT
#

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

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

modern gale
#

hi there!

#

cus_Gs85otocR07qEW doesn't have a default_payment_method set. however it has a default_source

#

note that source is the old way Stripe used to save payment information

wet wolf
#

I ended up nulling out the default_payment_method on that customer, since I figured it was a weird one-off. Here's another example: req_Cwp52O2RPzwmou

#

That customer has a default payment method of pm_1O0ibfFiV4PKnUattZoa98jT , but that payment method doesn't seem to be attached to that customer

modern gale
#

what do you mean by "that customer"? cus_I6aHLGSPih8ma8?

crude anvilBOT
wet wolf
#

correct

#

cus_I6aHLGSPih8ma8 has a default payment method pm_1O0ibfFiV4PKnUattZoa98jT, but pm_1O0ibfFiV4PKnUattZoa98jT isn't associated with cus_I6aHLGSPih8ma8

sage crow
#

I don't see where that PM is saved on that customer at all. It was 'consumed' without attachment on a payment

Where do you see that it's set as a default?

wet wolf
#

From Stripe::Customer.retrieve('cus_I6aHLGSPih8ma8') -

#<Stripe::Customer:0xbba70 id=cus_I6aHLGSPih8ma8> JSON: {
  "id": "cus_I6aHLGSPih8ma8",
   ....
  "invoice_settings": {"custom_fields":[],"default_payment_method":"pm_1O0ibfFiV4PKnUattZoa98jT","footer":null,"rendering_options":null},
sage crow
#

Hmm, that is weird

wet wolf
#

We've recently switched away from sources to using payment methods, but these bad default_payment_methods pre-date the switch. I wonder if they result from customers paying an invoice on a stripe hosted page, rather than on our own website. Before a week ago, we'd never set default_payment_method on a customer - it'd always be default_source.

sage crow
#

Potentially, yes. Some hosted surfaces will set default PMs like that. But in the examples you've given, I see no record of default_payment_method ever being set. It's baffling

wet wolf
#

Fun. It's only 6 customers out of several thousand, I wonder about just nulling out default_payment_method on them.
Do you think trying to charge one of those payment methods would succeed, or are they effectively useless?

sage crow
#

The one example I checked had been consumed so can't be charged again. Which is why you don't see it 'attached' anymore, but we should of unset the default_payment_method property too

#

I'd just unset them like you describe

wet wolf
#

OK, will do. Shall I report it somewhere if I see it happening again? They ones I saw were all created Sept-Nov 2023, so maybe it was an old bug that got fixed.