#Jasondeveloper-card-paymentmethod
1 messages · Page 1 of 1 (latest)
Hello! Can you give me the ID of a Customer that uses your existing/old method so I can see exactly what's going on?
699db064-e3f3-4e32-b88c-a0edb3c4e60c
I need the Stripe Customer ID, which should start with cus_.
that is the stripe customer Id
Alternatively you could provide a Payment Intent ID (pi_) associated with one of the Customers in question.
Ah, I guess you're using custom Customer IDs. I can't look those up, so I'll need a Payment Intent ID instead.
Sorry for the misunderstanding!
Thanks! Looking, hang on...
This is the error we get when trying to charge a paymentIntent with just the customer Id. (created by setupIntent)
You cannot confirm this PaymentIntent because it’s missing a payment method. You can either update the PaymentIntent with a payment method and then confirm it again, or confirm it again directly with a payment method..
The default_source property on Customer is a legacy field that isn't compatible with Payment Methods. If you're switching to Payment Methods you would need to either use invoice_settings.default_payment_method instead, or keep track of the "default" on your end or in metadata.
If you're not switching to Payment Methods and continue to use legacy Card objects they can be set as a Customer's default_source, but the Setup Intent will not do this for you, it's something you would need to do as an extra step in your code.
To clarify, even if you specify the Payment Method as the Customer's invoice_settings.default_payment_method that will only work for Invoices. You would still need to specify both the Customer ID and Payment Method ID for Payment Intents.
Our recommended integration pattern is to use Payment Methods and specify both the Customer ID and Payment Method ID when using Payment Intents.
Ok - we didn't want to store two tokens to make a charge. I guess we have no option.
Thanks for the clarification on legacy vs Payment Methods!
No problem!