#bhavesh_code
1 messages ยท Page 1 of 1 (latest)
๐ 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/1484229768730906775
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
This problem is not with trial starts, but when they try to renew their subscription.
My estimate is that collecting payment in Turkish Liras might be the issue?
Hi ๐
Sorry I'm having trouble wrapping my head around the question. You are saying the Customer is asked to authenticate even after saving a payment method?
Can you share an example Checkout Session ID where the customer's payment method was saved and then was later asked for re-authentication?
yes! one moment!
quick question where can i find this for a customer and would payment id suffice ?
You should be able to find these in your developer logs in the Stripe dashboard
If you have a Payment Method ID that could get me started
here you go sir : pi_3TCSjPBon7ihbjxp33wKBydK
Okay for this payment intent I can see the user never successfully authenticated. The Payment Intent remains in a state of requires_action
But you are saying that, when the user initially signed up for the Subscription, they did go through 3DS?
interesting, looking at the events there is something I might be doing wrong
so the setup succeeds
but they are not verified !
Can you copy ID for that setup intent and paste it here as text?
That's not what I asked for but I can use it
seti_1TBNGeBon7ihbjxpK2pazu27
Okay so this user did authenticate with 3DS
Yeah, difficult to put my finger on it as this is happening with turkey exclusively.
Well any card issuer can request 3DS authentication any time for any reason
We can try to dig into how you can minimize it but there is no way to avoid it entirely if the issuer wants to force it
Once you get a Payment Intent with a status of requires_action, the next step is to bring the customer back to your website and have them re-authenticate
yeah makes sense!
So I see that, once the free trail was over, we attempted to charge the Customer and we got that requires_action status
yep!
We retried the payment automatically (Stripe does this by default)
Then you (or someone else) attempted to manually pay it through the dashboard
But this didn't work because the payment intent needs authentication from the Customer
So...do you have a website that customers come to?
so it's a whatsapp chatbot, i can send the link to the hosted portal to them!
so i tried a fix today
Setup: Force 3DS via request_three_d_secure: 'any' on checkout for TR(this was manual), then a webhook immediately resets it to 'automatic' (after 3ds) on the subscription so renewals use the MIT exemption.
Testing: Use card 4000 0025 0000 3155 to simulate
was able to replicate the pattern and also solve this!
but in test mode
Okay so you mean you just tested this flow and resolved it?
yes i mean i found a way to replicate the real life error in test mode this was the closest i got
so tried the fix and requested manual collection still requested 3ds (at this point I think banks are screwing with us! )
In order to ensure your integration can support an issuer requesting 3DS again, I think you should also do some testing with card 4000002760003184
3184 almost never honours MIT exemption or saved payment right? I did try it and in this case I think a good dunning flow would help!
3184 will always require 3DS for every transaction
So it's a good way to test that your integration can support when issuers require this
yeah I did test that card as well!
Final question (just for my friend) is there any obvious problem with the stripe setup that is directly causing this ?
Let me walk through the process one more time, starting with the Checkout Session you create in this request
yes!
hello! fyi i'm taking over for my colleague, gimme just a bit to catch up
sure, I am still here ๐ถ
ok sorry about the delay... the server got pretty busy all of the sudden but i am focused on this thread now
no worries!
ok, sorry still wrapping my brain around the question as it's a bit of a tricky thread ๐ just to make sure i fully understand your current question, are you wondering if something about your current setup is increasing the likelihood that some customers are needing to re-authenticate with 3Ds after the subscription has already started?
yes!
applied a fix to change the 3ds required to automatic post trial start and before the next invoice is generated (but can hamper with payment collection if the requesting bank only requires 3ds enabled requests? )
i'm not seeing anything obvious that you could improve, but to be honest while my team is pretty good with technical implementation know-how we are less well versed in the arts of optimizing things like decline rates and 3Ds auths
but can hamper with payment collection if the requesting bank only requires 3ds enabled requests
can you explain what you mean by this?
so we had an issue with turkish debit cards which were not able to start a trial without explicitly forcing 3ds (since stripe radar though 3ds is not required for that card), in the process this 3ds manadate trickled down into invoices as well, now what i did is did this post request to change the 3ds setting from any to automatic using subscriptions endpoint : payment_settings[payment_method_options][card][request_three_d_secure]=automatic
sorry if this is confusing super bad at explaining
no i think i get the high level of it at least
i at least understand the workaround you implemented, but i guess i am confused by
turkish debit cards ... were not able to start a trial without explicitly forcing 3ds (since stripe radar though 3ds is not required for that card)
this request is an example of this flow not working for a customer, right?
it looks like in that example you are forcing 3ds
yes! here we are enforcing!
but here for example cs_live_a1PDynBlTpM8LFocUm8IG7oVkdH7LYRikjIPkOKm6AruP2ADPhdIjd7M3S we can see the fix
we can see this along with another one failed outright (leading to the same problem we had previously that these fail outright and were fixed with enforcing 3ds)
I think there might be no problem (atleast obvoious one) with the code and that the banks might be messing up things!
yeah the code looks fine to me too
thanks for helping tho! have a good day!
hold up, still looking at things
(to be clear you are welcome to leave whenever, i just want to see if there's anything else i can do to help you ๐ )
nothing as of now, since this is a developer chat would not want to ask support questions (especially about banks! )
ahhh i was wondering why the charge occurred 3 days later and it looks like that's just from the 3 day trial period
i was missing something obvious
yes!
ok yes, i don't think there's anything your integration is doing wrong here
perfect i am gonna screenshot this sentence haha!
if you want you can try chatting with https://support.stripe.com/ to see if they have suggestions for reducing the occurrences of subsequent 3ds challenges, but like my colleague suggested earlier you will definitely want to have a flow for bringing users back online to complete authentication if and when it is required
will do! thanks!