#cristian_paymentintent-paymentmethod
dapper cragBOT
👋 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/1286094141733863438
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
faint tulip
cristian_paymentintent-paymentmethod
(looking)
Okay so this is expected but weird. That PaymentIntent was paid with a "legacy object" called a Card object card_123456. And it was paid with some legacy approaches (to be compatible with legacy integrations).
So it is possible for payment_method: null to happen and if you look you have source: 'card_1234' set in that PaymentIntent
deft goblet
That is in prod
faint tulip
Yes, what I said is the same for prod?
deft goblet
Yea, the problem we are facing is this isolated payment intent in production
faint tulip
Sure I'm just explaining this is totally normal. This is due to something you did. It also didn't just break, that was 3 weeks ago right?
Overall, the behaviour is normal and is due to something you did
deft goblet
Just looked in our codebase and we dont have any tests or anything like that using that card_1234...
faint tulip
My guess is that this Customer had default_source: 'card_1234' set and did not have any invoice_settings[default_payment_method] and so that's the normal behaviour
deft goblet
Sure I'm just explaining this is totally normal. This is due to something you di...
Yeah I just noticed
faint tulip
That card_1234 was attached when paying an Invoice. Are you maybe using the Hosted Invoice Page?
deft goblet
My guess is that this Customer had `default_source: 'card_1234'` set and did not...
but how would this customer have card_1234 in production environment?
faint tulip
Ah looks like you did this manually in the Dashboard. Look at https://dashboard.stripe.com/logs/req_ZXdVDnPnYSmTb0 that's what created that legacy Card
deft goblet
That `card_1234` was attached when paying an Invoice. Are you maybe using the Ho...
yes we are using the emails you guys send (hosted by Stripe) to handle payment failures, expirations etc
deft goblet
Ah looks like you did this manually in the Dashboard. Look at <https://dashboard...
I dont see the card_1234 thing
should we remove that payment method and try to add it again?
faint tulip
sorry what don't you see? In that exact log the parameters passed source: 'tok_123' and the response has id: 'card_1234'. Do you see that?
And you can delete the card sure but if you add it again by hand in the Dashboard it will still be a legacy object
Also that Customer has a different card added already using the PaymentMethods API when I look at it internally
deft goblet
Hmmm no?
deft goblet
"source":
"tok_1OZKAuABXGXXXXXXXXXX",
faint tulip
those are the parameters. Look at the response
deft goblet
card_1OZKAuA#############
faint tulip
yep so that is the response, that shows the object we created which is our legacy API because it was done by hand in the Dashboard
deft goblet
got it, so card_##### is the old API, and pm_###### is the new API
What should we do in this case?
Where a payment intent does not have a payment method, if we receive an event like that from you guys
Is there a way to convert from Source to Payment Method or only removing the payment method and adding again?
faint tulip
It's a bit more subtle than this really. Technically legacy objects just work with the PaymentMethod API. If you all the Retrieve PaymentMethod API with that id it will work and give you a PaymentMethod
deft goblet
so if the webhook event from payment intent we receive has a null payment method we just use the source instead?
and calling the payment method API with the source id will work?
faint tulip
yeah
Basically what I recommend is to add some fallback logic where if you get payment_method: null just look at source and see if it has an id and it should work with the PaymentMethod API
It's a weird "compatibility" logic we added for old integrations and you hit it because of the Dashboard flow you used
deft goblet
that makes sense
does the payment method API return the same contract regardless if a pm or source id is provided or should we guard against the different structure of sources?
faint tulip
yes that's how we built it.