#guest123
unkempt violet
Can you share a payment intent id where this is happening
upbeat timber
pi_3Nl9PaJnsAXlefwu1iyDslSu
this is the one with null payment method ^
pi_3NkOb5JnsAXlefwu0gdiHuHq <- this is the initial payment intent that made the subscription active, for which I can retrieve its payment method
unkempt violet
Looking
digital pathBOT
brittle jetty
👋 hopping in here as well since codename_duchess has to head out soon
upbeat timber
Hey thanks, please let me know if any more info from me would be helpful
brittle jetty
So it looks like what happened is that when the payment metheod was changed, it was done by removing the Subscription's default_payment_method and setting a default_source instead. As a result, the payment has source set instead of payment_method
upbeat timber
ok interesting im not aware of the sources API
is that standard behaviour for the customer portal when changing payment method?
brittle jetty
Usually the customer portal would be working with payment methods, but for this specific subscription it looks like the default was changed on the dashboard, not through the customer portal
upbeat timber
ok gotcha thanks. So for users updating or adding a payment method via the customer portal in future, I can expect that I would receive a payment method not a source?
is it a source because it was added via the dashboard, or was it because of it being a test card ? I guess I want to know whether this will happen again and whether i need to handle it or not as my app was not expecting it so it caused an exception.
brittle jetty
I would expect customer portal to have a payment method
And the reason for it being a Source is because the Card was added to the customer in the dashboard AND set as the default in the dashboard.
The Dashboard has different logic since it has to handle a lot of legacy flows, so if it sees a Source object it'll set it as the default_source no matter what. If you had used the API to change the default instead you could used that Source as a default_payment_method