#brandan_3ds-saving-payment-methods
inland adderBOT
👋 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/1429851268356116631
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- brandan_best-practices, 4 days ago, 96 messages
- brandan_best-practices, 5 days ago, 45 messages
bold needle
Summary:
We have recently update from ChargesAPI->PaymentIntentsAPI using the .NET Stripe package. We currently do not have the ability to use Stripe iOS/Android SDKs in our mobile app since it is using .NET MAUI. We have to start handling 3DS authentication. Within the last week I have worked with Stripe devs to understand more about what we needed to do and implement. I have a high level diagram that I've but together of all of our payment flows and as suggested by Stripe devs we could reach out and someone could take a look and let us know if anything stood out to them. The diagram is in this thread.
Thanks!
Given we can't use the SDKs we have to handle the webviews, redirects, etc on our own. The confirm endpoints for stripe .NET do not allow app redirects (have to be https), so we will use a basic redirect page we host to handle that (I've already POC'd this and it worked as expected). We just want to get a gut check if this looks fine for manually handling the 3DS flow - we eventually are going to use the Android/iOS SDKs but that is a longer term goal and we need to manually do things given our current tech stack. (All payment processing right now is handled server side using .NET Stripe package)
pseudo quiver
Hello, that diagram makes sense to me. I think the one comment I have is on the "Off Session usage" note in the lower left. There are actually two parameters at play here, one that you will want to send on intents where you are saving a new card, and another one that you pass when confirming subsequent intents when the user is off session.
You may have already been clear on that, but its a bit ambiguous and I've seen this confusion before
bold needle
Could you explain these two parameters here given the flows in the diagram? I want to be sure I understand that a little more, I'm only aware of the off-session parameter for the first time payment intent (during creation)
pseudo quiver
Yep yep, just didn't want to type five paragraphs at once as I may be known to do 😅
bold needle
haha, no worries - thanks!
pseudo quiver
So the first param is the one you are talking about setup_future_usage which tells Stripe to save any new payment method to the customer and prepare it to be used when the customer isn't around (setup_future_usage: 'off_session').
But then on the payment intents you create later, when confirming them you want to pass the off_session parameter to tell Stripe that the user is actually off session for this payment. (off_session: true). Both the create and confirm calls have this parameter.
bold needle
Okay that makes sense, I will add that detail to these flows. The setup_future_usage:'off-session' only applies to the very first payment intent during creation, any future payment intents will just need the off_session:true flag.
How does this compare for when we update the users credit card (w/o charging them, ie. setup intents). When doing the setup intent each time the user updates their credit card in their profile would we need to do the setup_future_usage:'off-session' since it would be a new/updated card each time?
inland adderBOT
pseudo quiver
Two good points, setup intents actually don't have this concept, they just always set up for future usage that may be off session. So neither of those parameters are needed there.
For payment intents, yes you only need setup_future_usage when trying to save a new payment method. Though now that I think about it means that you will also want to add that to your off session payment intents if they get a decline and the user is adding a new PM to retry with. So like if you get a decline, update the payment intent to add s_f_u before the user puts in new card details on your page.
bold needle
Right, that second part makes sense, any time the user uses a new card during a purchase it will have the s_f_u on it. But just updating a payment method via their profile or something is where we use the setup intent which we don't need any parameters becuase setup intents automatically assume the future usage. To confirm though, for a setup intent if it requires 3DS it will trigger it at that time right? So user updates their card, we send off the setup intent (assume bank requires 3DS) then we'll prompt them for it and go about the flows.
pseudo quiver
Yep exactly!
bold needle
Awesome! I think only 1 last question, when the stripe hook url for the authorization is completed (regardless of success or failure) do you know if that gets passed back so we can check the status/action of the pi or do we need to make another call to get the pi status?
cerulean depot
Hello 👋
I'm stepping in as my colleague needs to go.
I'm not sure I follow what you are asking. Are you referring to the webhook event that is delivered to your endpoint URL? Or the API response returned by Stripe.js on the client-side?
bold needle
more so the response when 3DS is completed, ie we display the 3DS auth using a webview and the link we get in the redirect_url action from stripe. Once the users completes the auth and we redirect back to the app, does stripe pass along the auth result? or do we need to make a call to stripe to get the current status of the pi
cerulean depot
Hmmm... so you are not using Stripe.js to handle the redirect? You are doing this with your own code?
bold needle
Correct, stripe .NET does not allow app urls for the redirect they have to be https so we cannot do a proper app redirect given the restriction of the net stripe endpoint
So we have to spin up a basic web page to pass as the return url to stripe and then when user completes auth it redirects to our custom page which redirects them to the app
cerulean depot
In that case I recommend retrieving the Payment Intent via the API and checking the status. That is the most fool-proof and the best source of truth.
bold needle
Sounds great, thanks!
I think that's all I needed, everything else looked good to Pompey in our diagram for the approach to handle 3DS! I appreciate it!
cerulean depot
Awesome 🎉 I'm glad we were able to answer all your questions.