#miketimturner-paymentmethod
burnt peak
hi! in general the default_source field is legacy, and it's not compatible with the current API object for cards(which is PaymentMethods pm_xxx). It's best not to use it at all.
wild path
OK so I should use the invoice_settings.default_payment_method instead?
because when I change it to a pm where the id is pm_xxxx it doesnt have this field filled
burnt peak
OK so I should use the invoice_settings.default_payment_method instead?
only if you're using subscriptions. But if so, yes
wild path
So what if the field is not filled?
Is there an endpoint to get the actual default PM as shown on the customer dashboard?
burnt peak
So what if the field is not filled?
the way it works for subscriptions is :
we look at the following in order to decide what to charge :
invoice.default_payment_method
subscription.default_payment_method
subscription.default_source
customer.invoice_settings.default_payment_method
customer.default_source
if all of those are null then the payment fails
burnt peak
Is there an endpoint to get the actual default PM as shown on the customer dashb...
as far as I know the dashboard shows customer.invoice_settings.default_payment_method
wild path
Will all new cards have an id of card_xxx
Am I seeing inconsistencies due to using the test cards?
burnt peak
Will all new cards have an id of card_xxx
it depends how you create them
most of our current integrations create PaymentMethods pm_xxx (Checkout, PaymentElement, the mobile SDKs)
so the short answer is probably no. card_xxx is legacy, default_source is legacy
you only have card_xxx if you have legacy code in your system creating them or you're working with customer objects created in the past
burnt peak
Am I seeing inconsistencies due to using the test cards?
possibly! I have no idea what you're using or what test cards you use so it's impossible for me to say unless you can share context
if you're using test cards like tok_visa (instead of what you should use, pm_card_visa), those create legacy card_xxx objects yes, so maybe it's that.
wild path
No legacy code here. I originally added a declining card from here https://stripe.com/docs/testing#declined-payments which gives it an id of card_xxxx as I have setup a webhook to updated my local payment methods it brought this into my app
burnt peak
could you share an ID so I can look at your account? like the actual card_xxx ID.
burnt peak
yeah so you created in this request using /v1/tokens, https://dashboard.stripe.com/test/logs/req_bwYBQZfLquJHqz , which is a legacy API
burnt peak
same API yes
wild path
When I create it from my app it gives me an id of pm_1KlBgMCj4QBUyD0zTl6o1krf
burnt peak
I don't know what the dashboard does, maybe there's a flow somewhere in it that uses that legacy API. Shouldn't be but wouldn't suprise me
burnt peak
When I create it from my app it gives me an id of pm_1KlBgMCj4QBUyD0zTl6o1krf
makes sense
wild path
OK let me delete my cards and add them through my app just to rule out any issues
When I add both cards through the API it gives me pm_xxx identifiers which both provide me with the default_payment_method prop so looks like the dashboard is to blame. Thanks
burnt peak
cool!