#jarrett
1 messages ยท Page 1 of 1 (latest)
No you would not pass a payment_method to confirmPayment via Stripe.JS. Can you tell me more about what you are trying to do?
And you can't have a PaymentMethod without knowing its type ๐
we store payment methods for existing customers in our system
when you update a subscription in our system you can choose an existing payment method
additionally, this is the same page to resolve unpaid subscriptions
so we may have a payment intent already
I really hope you guys add support for existing payment methods on customers soon to Payment Elements
Yeah we are working on adding that
For now, you would just create/confirm a PaymentIntent server-side
You don't use Stripe.JS for this at all
until the payment intent needs customer action
Right, then you would pass the client_secret to the frontend and use confirmCardPayment or whatever method is correct for the type of PaymentMethod you are confirming that requires action
what about the situation where i have a subscription that is unpaid
i tried updating the subs default_payment_method
but then I just get an error when trying to confirm the payment intent that it has no source
do you have to manually update subs payment intent?
You do the exact same thing that I stated above for an unpaid Sub
You would only have to update it if you are going to use a payment_method_type not already set on the PaymentIntent
Ah actually no
You just pass payment_method_types when you confirm
You don't have to update at all
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Maybe I'm not explaining myself properly
I have a subscription that is currently unpaid
Lets say the card is expired
I want to update it with a new payment method
I already have that payment method on the customer.
What is the proper flow for that
I would've assumed I update default_payment_method on the subscription
default_payment_method will be used for future automatic confirmations
If you have an open invoice that is out of retries then you need to manually confirm its PaymentIntent yourself
Using that new PaymentMethod you want to attempt to charge
ok, so in my two separate scenarios, what would my flow be?
- We have the user's card in Stripe already
- They want to add a new card
1/ You confirm the PaymentIntent server-side with the PaymentMethod you want to charge
2/ You present Payment Element and use confirmPayment client-side using the PaymentIntent's client_secret that you want to charge
It sounds so simple when you lay it out that way
until I try and integrate it all into one page
lol
lol
i forgot one more scenario. this page lets me update the subscription when it's in a good state. in that scenario if the customer adds a new card what am I suppose to do? I currently was creating a setup intent for that
I definitely understand the desire to handle this all through Payment Element
We are working on that!
Yep SetupIntent is correct if you are adding a new PaymentMethod but not charging it immediately
basically building an "edit subscription page" that lets you handle, change plan, update bad payment method, add new one, etc is a nightmare
lol
Yep I know there are a lot of flows you have to account for
ok i think I have some ideas. i'll get back to banging my head against my keyboard trying to hash all the scenarios out
oh wait, one other unrelated question
you know how setup intents have payment_method_details with a nested generated_sepa_debit for things like iDEAL or Sofort
are there any other payment methods that do this sort of thing
for something besides generated_sepa_debit
Yep they should, and no only those bank redirects that create SEPA Debit
Hmm actually let me double check
just confirming, there is no other payment methods that I have to dig into the latest attempt to find the actual payment method
Yeah just Bancontact, iDEAL, Sofort