#alfredbuilders_api
hexed valleyBOT
👋 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/1412808196631826553
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
sinful dust
Yeah it's impossible to make this 100%
Because banks sometimes still require 3ds for off session charges even if the payment method was set up properly
But I can suggest the best way if the goal is to accept a deposit at the same time as setting up the payment method for future usage
You can create a checkout session in payment mode to collect your deposit and also pass: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-payment_intent_data-setup_future_usage to set up the payment for future usage
verbal pagoda
Yes, I already tried it, and unfortunately the first attempt of retrieving the deposit has failed (an authentication 3DS has been requested, but in this context, when there is a dispute with a customer, we do not want to go through an authentication as you can imagine, for obvious reasons)
Would it exist another way to deal with my use-case to retreive a deposit after collecting the customer's payment method?
sinful dust
What do you mean by retrieve deposit? I thought the initial checkout session is the deposit?
verbal pagoda
What I did is that the Checkout session is only a way for me to get the payment method,
Then, I use a PaymentIntent to get a 3€ fee - but of course, as you mentioned, the 3€ payment could be done through the checkout session in payment mode.
Then, if the manager of the apartment rental agency wants to get 100€ from the customer, because it happened a damage in the apartment, then we do not want to redirect the customer to a authentification page, since he should have already identified himself at checkout.
sinful dust
then we do not want to redirect the customer to a authentification page, since he should have already identified himself at checkout.
This is impossible to completely avoid
What I suggested is the best way that will most likely avoid it
But banks still sometimes want 3ds in future purchases
verbal pagoda
Alright, thanks for the precision
What do you think of doing a pre-authorization payment ? Meaning that we block funds from the customer, the time of the rental, then to give him back if there is no damage.
Just in case we want to project ourselves into this type of scenario, how could it materialize in Stripe? Just a PaymentIntent, that could be cancel and refund to the customer at the end if no damage detected?
Thanks for your support
sinful dust
How long is the rental?
verbal pagoda
It depends, but in average 4 days
I know there is a topic on >7 days or >30 days in some merchants sectors
sinful dust
I can't necessarily recommend refunding most transactions on your account
I don't know whether or not that could have impacts
But you could consider just placing a hold on the card if the rental period is short enough
And there's even an extended authorization for some cards and some mccs: https://docs.stripe.com/payments/extended-authorization
verbal pagoda
Yes, indeed, I already read that, and we envisaged it with the client, who actually has preferred the payment intent solution (but he did not know that we could face to a second authentication)
Thanks
I can't necessarily recommend refunding most transactions on your account
Why do you say that? Just because of the complexity to follow each transaction one by one?
sinful dust
I don't really know enough about refunds and compliance things so I would recommend checking with Stripe support on that
But there's a chance that flags your account for something
It could be suspicious to card networks issuers but i genuinely can't say for sure
hexed valleyBOT
verbal pagoda
Yes, for refunds indeed.
But for pre-auth transactions, I have an additional question, if we do this, the 3DS Secure could be required only at the checkout step logically?
violet coral
Hi there, I'm taking over from my colleague. Yes, logically 3DS could be required at the Checkout step.