#bondsmith_unexpected
sand moatBOT
đ 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/1338967788852871200
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
lime sand
Hello
Are you asking when the verification is pending? Like for the flows like microdeposit?
grizzled token
Yes
lime sand
I don't believe you can cancel/delete the objects while its still pending. As far as i know, once microdeposit verification time expires, the payment method just exist as a zombie object which can't be attached/used in any sort of way. So you can just ignore it afaik..
grizzled token
Thanks @lime sand, I was able to do so through the Dashboard but not when using Sessions:
I ran the flow through the Dashboard by manually registering the US Bank account and I was able to cancel the Setup Intent via CLI which ultimately removed the Payment Method.
I believed I should be able to do the same thing when it is being registered through the Checkout Session.
The platform I'm adding the functionality in has a limitation of 1 payment method so the zombie object would block clients from being able to register a payment method.
Currently, only 10 consecutive invalid microdeposit verification requests are effectively closing the Setup Intent
Cancel Setup Intent API Docs: https://docs.stripe.com/api/setup_intents/cancel?lang=node
These link to the Expire Session Docs https://docs.stripe.com/api/checkout/sessions/expire?lang=node
But I can't exprie the Checkout Session either
lime sand
It's possible that dashboard does things differently compared to how checkout handles it. We don't always have feature parity between dashboard and the APIs (like Checkout)
The platform I'm adding the functionality in has a limitation of 1 payment method so the zombie object would block clients from being able to register a payment method.
Can you clarify what you mean by this? If the Payment Method is not associated with a customer, then that shouldn't be considered as a valid payment method right?
grizzled token
When the customer enters the information in the Checkout Session and returns to our Web App he sees the Payment Method information in the PENDING_VERIFICATION status in the Account Settings UI
This is the same behaviour you see in the Stripe Dashboard where even if the Payment Method is not officially attached to the Customer, it does show up in the UI
If the account in our app has a Payment Method that has not been cancelled or deleted, he cannot register another one
If the Payment Method is verified, I can remove it by calling detach. However, if the Payment Method has not been verified, it cannot be removed because of the errors in this post.
It would basically be un-removable
lime sand
is that payment method returned when you List a customer's payment methods?
https://docs.stripe.com/api/payment_methods/customer_list
grizzled token
It does not return with that call
I relate them via the Setup Intent entity which has the Payment Method ID and the Customer ID which I believe is the same thing the Dashboard uses to show it
I can't have more than one Payment Method/Setup Intent going for the Account on my end but I can't kill the Setup Intent via API if it is created through the Checkout Session
I need to surface the pending verification Payment Method in the UI so that they can submit a call to verify microdeposits from there
sand moatBOT
primal tangle
Hi, taking over for a teammate who needs to step away. Let me catch up
grizzled token
@primal tangle no worries! Thank you!
primal tangle
Yeah, what you're trying to achieve is not possible. You would use the SetupIntents integration: https://docs.stripe.com/payments/save-and-reuse instead.
Out of curiosity, how are you pulling 'I can't have more than one Payment Method/Setup Intent going for the Account on my end'? Where are you looking?
grizzled token
I have event carried state transfer through webhooks where I save Payment Method info and Setup Intent info so that I can associate the Payment Method to the client via the Setup Intent data in my DB
If I were to perform the same via Stripe API I would fetch Payment Methods, if none are returned, fetch Setup Intents for the customer that are in progress
If any value is returned to the Front End the customer is blocked in my UI from registering a new Payment Method
I have a "Remove Payment Method" button that was mean to detach a Payment Method or cancel a Setup Intent but it is not possible it seems
primal tangle
No, not with Checkout Sessions
You could use the direct integration via teh Setup Intent
grizzled token
I think I will have to fire invalid verify micro-deposits on a while loop when they click the button until it errs as it is the only alternative to end the Setup Intent at the moment
primal tangle
That does not seem like a great experience, and I highly recommend using https://docs.stripe.com/payments/save-and-reuse so you have more control over this
grizzled token
Yes, that is an alternative but we specifically wanted to not deal with the compliance of colecting and registering the payment method ourselves
primal tangle
Are you saying that you are collecting the card details on your end and want to pass that to Stripe on the server-side only?
I'm a but confused because Checkout is compliant
grizzled token
Do you think there could be an adverse effect of failing to verify these accounts? Might they be blocked if they want to be used in the future?
Yes, I mean that the alternative you sent is outside of the Checkout and we would have to deal with compliance
Which is why we opted for the Checkout Session
primal tangle
I can't speak to that, you might want to check with support on that. I could see that issuing banks might noy like that, yeah
grizzled token
Alright, so that is an interesting one.
Instead of using Checkout Sessions, we use Stripe Elements which are compliant and we don't have to handle user's Payment Info data correct?
primal tangle
When you said 'compliance' I thought you were referring to handling raw pans. That call out is talking about something else
You're right, if that is not something you'd want to handle Checkout seems to be the options. Or, you would change the way you look at payment methods. You allow adding a payment method until you can confirm that the payment method is verified
grizzled token
Yes, or I disconnect the Payment Method in my DB and not Stripe and just leave it as a Ghost Entity on Stripe for ever after
primal tangle
Yeah
grizzled token
@primal tangle Thank you for the alternatives and explanations. I'll discuss with the business and see what will be viable
primal tangle
Sure!