#mesudev_api
nova pebbleBOT
👋 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/1230746587626737684
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
long cosmosBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- mesudev_paymentmethod-list, 5 hours ago, 36 messages
- mesudev_api, 6 days ago, 30 messages
gentle skiff
hello! We want to provide a way to add more than just once payment methods for our customers in our app. - i'm not sure i understood this sentence correctly, can you elaborate?
winter raptor
Sure, take the uber app as an example. It offers you to store multiple payment methods at the same time, and optionally switch among them for different payments. We want to offer the same. Consequently, we also want to permit the customers to delete currently stored payment methods, if they no longer want to use it for the app. And we wonder if stripe's API automatically prevents you from doing so if there are pending payments with the concerned payment method ? Or if that's on our end to verify?
gentle skiff
no, we don't automatically prevent you from detaching a card if there are pending payments. With regards to auth and capture, you can still capture a payment (assuming it was already authorized), even if the payment method is no longer attached to a Customer.
However, you may still want to keep the card attached, in case the capture fails for whatever (rare) reason. In which case, checking to make sure that there's no PaymentIntents with requires_capture makes sense
winter raptor
cheers! The way described above (to search for pending payments with the concerned payment method using https://docs.stripe.com/api/payment_intents/search and then scanning the results for the concerned payment method) is our proposed way, and you say it makes sense; do you may see any better / faster way to find out if payments are still pending with the concerned payment method ?
gentle skiff
i don't recommend using search for this use case since search can be delayed
winter raptor
hmm good to know; could you recommend something else instead?
probably the best way to go is in that case an internal payment intent ID -> payment method ID mapping in the own DB, together with the status of the concerned transaction, and check based on that one, to have no delays..
gentle skiff
hrm, we don't have an API endpoint specifically for what you're looking for. The retrieve all PaymentIntents API doesn't provide a parameter for status.
I guess taking a step back here, is there any business impact here really if the customer deletes their PaymentMethod and there's a pending payment (keeping in mind that you can still capture the payment)? In most cases, you wouldn't ship / provide a service or product till the payment is actually collected. If some rare issue crops up along the way, the customer can still add back their PaymentMethod again
probably the best way to go is in that case an internal payment intent ID -> payment method ID mapping in the own DB, together with the status of the concerned transaction, and check based on that one, to have no delays
yeah, this sounds like the best way to go about it to me too
winter raptor
hrm, we don't have an API endpoint specifically for what you're looking for. The...
hmm we're currently authorizing payments at the moment of booking and capturing after the service was provided, but that's actually as you say not really smart. Probably better to charge right before the service is provided indeed.
winter raptor
> probably the best way to go is in that case an internal payment intent ID -> p...
- that then
okok great, thanks! Your developer support is really excellent, by far makes Stripe beat every other PSP I know until now!
gentle skiff
hmm we're currently authorizing payments at the moment of booking and capturing ...
i think the flow you mentioned, authorize and then capturing in this case is correct and is the standard flow for most businesses
i was thinking that you might be providing some kind of product or subscription 😅
winter raptor
you say capturing only after the service is provided is the standard flow ?
gentle skiff
it really boils down to what industry and business you're in i guess
there's some cons to capturing first e.g. if the customer cancels at the last minute, you'll need to refund them, and we don't refund the Stripe fee
winter raptor
yeah for a variety of reasons we conciously capture after the service was provided. If it becomes a problem, I'll remember this discussion hehe