#daisdead
zenith dune
hello! 😄
somber edge
Hi 👋 can you tell me more about what your flow does for customers that already have a default Payment Method set up? Are you creating a Subscription and noticing that the first Invoice is automatically paid using the default payment method?
zenith dune
Are you creating a Subscription and noticing that the first Invoice is automatically paid using the default payment method?
In cases where we do create anincompletesubscription during checkout - yes, we're noticing this exact behavior
And example of how a customer may already have an existing payment method on file is:
- purchasing a subscription
- churning
- purchasing a new subscription (at this point there is an existing payment method)
somber edge
Can you share an ID of a Subscription where you saw that behavior, should start with a sub_ prefix, so I can take a closer look at your flow?
zenith dune
Give me a few moments please to get you an ID
I think this one should do sub_1NH4kGD0tZaJVqhDC9SdB564
somber edge
Hm, I'm seeing that the Invoice was paid using the 4242 test card in this request:
https://dashboard.stripe.com/test/logs/req_a1tlfIb9qaDmMG
It doesn't seem to use the card that is currently saved as the Customer's invoice_settings.default_payemnt_method
zenith dune
Are you able to view this Loom? It captures what behavior we're looking to address
https://www.loom.com/share/bdba820470074a1495e9f176f1e13e32
Invoice was paid using the 4242 test card
Yeah this was not the payment method inputted during checkout
oh my apologies, this is the subscription to be examined
https://dashboard.stripe.com/test/subscriptions/sub_1NGrymD0tZaJVqhD27IArGF2
somber edge
I can't, I don't have a Loom login.
The first Invoice for that most recent Subscription, was paid using the Payment Element and the 0446 test card, that is shown in the confirmation request for that intent:
https://dashboard.stripe.com/test/logs/req_FR1b8qrEXfD07y
It does not appear to have used the Customer's invoice_settings.default_payemnt_method.
You can compare the ID of the Payment Method on the Payment Intent associated with that Invoice, and the ID of the Customer's invoice_settings.default_payment_method to confirm those IDs do not match.
zenith dune
I guess is what the suggestion is here is that we need to delete previous payment methods if we want to attached a new payment method to be used for this subscription purchase?
somber edge
Oh oh, is it the recurring payments that are the concern, not the first payment?
zenith dune
It's all payments? Not sure if that makes sense but the first invoice (and subsequent subscription renewals)
perhaps it may be helpful to step back, (ignore this, if you think we're onto something)
given our scenario if our existing payment methods, how do make any new payment methods the new default? and secondly, when tied together with a checkout UX, how do we ensure the subscription points to that particular payment method
somber edge
If you want the new Payment Method to be the default for the Customer, you update invoice_settings.default_payment_method
If you only want it to be the default for a specific Subscription, then you update default_payment_method on that Subscription object.
zenith dune
I see - that makes it a little tricky in our scenario given that we create the incomplete subscription first before collecting the new payment method which would always look for existing payment methods upon creation if I understand correctly
somber edge
Sorry, I still feel like I'm missing something. So far all of the Invoices I have looked at have looked like they are being paid with the card number that is being put into the Payment Element. What are you seeing that is leading you to believe otherwise?
zenith dune
Sorry for the confusion! I think it was unhelpful on my part to link you a customer account that is continually being tested on - give me a few more moments to hopefully provide an isolated environment?
somber edge
Sure
turbid swallowBOT