#brandan_best-practices
fickle plumeBOT
đ 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/1428026400106876948
đ 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, 16 hours ago, 45 messages
fallen timber
Some background on our system:
Users register for our application via the mobile app and we send the information server side to stripe and a customer is created, a payment intent is setup. Users are able to obtain usage fees, lost item fees, etc since we essentially have a rental program. So say a user looses an item and we go into our admin web app and charge them a lost item fee using a payment intent confirm = true, so no pre-authorization is required.
The concern and what I am trying to figure out is the best way for us to be able to reconcile these incomplete transactions for our connect accounts. The last thread I had left off with this from the stripe team:
"If you charge them through the dashboard, you will probably run into the same issue since 3DS is necessary in order to validate the Payment Method.
Is this only about the open charges for the lost item fee you were mentioning? And how many are we talking about?"
My respose to that is that we have ~57 of these transactions, I do not have the total amount just yet but it's enough that we need to figure out how to reconcile these until we build in our 3DS solution. The previous stripe team member we talked to said that the stripe documentation for migrating from Charges-> PaymentIntentsAPI does not explicitly say that we needed to build out a 3ds solution and so we have this scenario that we are trying to work through.
noble spade
Yeah if 3ds is required on a payment intent really the only way forward is to bring the customer on session for them to authenticate the transaction
Do you have an example payment intent id in this state so I can get a better understanding of your flow
fallen timber
yes absolutely, I can send you a few - they are across a few different connected accounts!
fallen timber
there are 57 separate payment intents facing this issue
pi_3S4YPVFnU643nNHf1HT06fTX
pi_3S59lSFnU643nNHf0VzEfsyW
pi_3S4aJ7FnU643nNHf0E8fWewY
pi_3S4xWIFnU643nNHf0AyrApAs
Here are just a few, I've compiled an excel sheet and it appears the majority of the ones that had issues are via MasterCards but there are a couple VISA & Discover cards as well.
I know what we ultimately need to do and our development team is going to work on doing the 3DS implementation but I am hoping to work through a solution in the interim to help out merchants (connect accounts) reconcille these transactions.
Appreciate your help looking into this!
noble spade
Ok so it looks like you create the card by creating a token first
That's not ideal
That will increase the liklihood that future payments require 3ds
Instead you'd need to use a setupintent: https://docs.stripe.com/payments/mobile/set-up-future-payments
So that'll reduce this issue going forward if you implement that
Now as far as how to resolve the open issue with incomplete payments, you'll need to bring the customer online to confirm the payment intent with them on-session (in the app or on your site)
Because they're the only ones that can auth the transaction
fallen timber
Few questions. Can we use payment intents with the setup for future usage - off sessions which will also reduce the issue going forward?
If our mobile app doesn't currently have 3DS setup does that mean there is no way for us to reconcile these funds? When the users does the first transaction most of our payment intents are created using an automated process overnight for usage fees, lost item fees, etc or via a manual charge of the user via our admin web app we have. We don't really have a way to have them go through a 3DS? Would this be something that could be done manually via the dashboard or something?
noble spade
Can we use payment intents with the setup for future usage - off sessions which will also reduce the issue going forward?
yes that would work as well if the customer is in the app for the first payment so they can auth the 3ds transaction. otherwise, if you are collecting card details without processing a payment you should use a setupintent.
If our mobile app doesn't currently have 3DS setup does that mean there is no way for us to reconcile these funds?
Yeah you'd need to either have a website or app to bring customer back online to confirm the payment intent and complete 3ds. 3ds is a key component with payment intents so you really need to build out a flow for this.
Would this be something that could be done manually via the dashboard or something?
No 3ds is something the customer needs to complete/authenticate.
fallen timber
So if we built out 3DS and had the user in the app and forced them to update their credit card information would that initiate 3DS if there was a pre-authorization? If these users completed 3DS for a new payment intent would that retroactively work for these other ones or would each payment intent need to somehow be re-iniated? We do have a failed transactions workflow that we possibly could try to force these payment intents to get back into the 3DS flow?
Also, since we are on NET MAUI we have to build c# bindings for the Stripe iOS/Android SDKs manually - can this be done without the SDKs (the 3DS flow that is) and how challenging is that to do as an interim step until we can port over the SDKs?
noble spade
So if we built out 3DS and had the user in the app and forced them to update their credit card information would that initiate 3DS if there was a pre-authorization?
What are you doing when you update their credit card information (what api calls)?
If these users completed 3DS for a new payment intent would that retroactively work for these other ones or would each payment intent need to somehow be re-iniated?
It's possible each one would need it again. It's reall up to the banks. You could reduce the liklihood of this by passing setup_future_usage=off_session in the payment intent so that the attached payment method is set up for future usage properly.
We do have a failed transactions workflow that we possibly could try to force these payment intents to get back into the 3DS flow?
They currently are in a requires_action status. That means all you need to do is confirm the payment intent client side with customer on session so they can auth the transaction.
Also, since we are on NET MAUI we have to build c# bindings for the Stripe iOS/Android SDKs manually - can this be done without the SDKs (the 3DS flow that is) and how challenging is that to do as an interim step until we can port over the SDKs?
Yes there is a workaround for this. If you pass return_url when confirming the payment intent on your server, you can get a bank redirect url for the 3ds authentication. You can send that to your customer to authenticate the payment: https://docs.stripe.com/payments/3d-secure/authentication-flow#manual-redirect
You could reduce the liklihood of this by passing setup_future_usage=off_session in the payment intent so that the attached payment method is set up for future usage properly.
Also I want to be a bit more clear about this. You only would want to pass this param once on the first transaction (if card details weren't collected via a setupintent). Because if you pass it for every transaction, then that actually increases liklihood of 3ds
fallen timber
Let me take a look at our update cc methods quick and double check exactly what we are calling when we update the cards when we have pre-auth turned on in our system.
I'll read through that work around documentation - thanks for sharing.
So to make sure I understand how the off session should be used. Users will register in our system and purchase with the payment intent having the off session flag added, after that we do not want to be using that flag going forward? Say the user then updates their credit card, we would need them to have that off session flag again correct and they would also need to do 3DS again?
noble spade
From what little I understand about your integration you really should build with setupintents
Because if the customer isn't in the checkout flow when you're processing payments, then you should collect their card via a setupintent and it will be set up properly. No need to pass setup_future_usage on a payemnt intent later
And when updating card info, you'd just use a setupintent again for that
Passing setup_future_usage=off_session is useful for these cards in your integration that were not collected via a setupintent
If you pass that when confirming the payment intent, then they'll be set up properly
But going forward, for the future, it sounds like setupintents are the best fit
fallen timber
So to confirm our integration, users register in our system via mobile app and we collect payment right then and there for the first purchase. Users can buy more passes in our mobile app at anytime. Our admin web app can manually charge/refund users and there is automated processes that will charge usage fees, lost item fees etc. Would that still all be setup intents? I guess my understanding would be since we collect payment each time it would be paymentIntents?
Given the documentation from stripe was ChargesAPI-> PaymentIntentsAPI we followed that to go through updating our integration
noble spade
Ah yeah if you are charging them when they're in the checkout flow then paymentintents
And if it's a new payment method, you'd want to pass setup_future_usage
If all they're doing is updating the payment method in the app without a charge, then that's when you'd use setupintent
fallen timber
Sounds good, I guess really the only time we charge not during a checkout flow would be those automated processes that run nightly for usage fees and then if we have to do a manual charge for a lost item fee or something like that. But it sounds like since we aim to collect funds at the time we initate that charge it should still be payment intents?
If all they're doing is updating the payment method in the app without a charge, then that's when you'd use setupintent
Would this require 3DS though? I still need to take a look at our update methods and what it's doing via stripe I just haven't had a second to do that yet, but will shortly
noble spade
But it sounds like since we aim to collect funds at the time we initate that charge it should still be payment intents?
Yep
Would this require 3DS though? I still need to take a look at our update methods and what it's doing via stripe I just haven't had a second to do that yet, but will shortly
Yes setupinetnts and payment intents + setup_future_usage commonly/very frequently require 3ds
If you're using payment intents and setupintents your integration should be able to handle 3ds
I wouldn't even recommend switching to those apis if your integration can't
fallen timber
Yeah the stripe docs weren't explicit in saying our integration required a 3DS flow when moving from charges -> payment intents. When talking with the stripe team yesterday they said they were going to make that more clear in the docs as they agreed it was not clear. We are already on payment intents now so we just have to work with where we are at
noble spade
Yeah makes sense
So yeah I would say your 2 options are to build 3ds into your app and bring those customers back into the app to authenticate those payment intents
Or confirm them with return_url so that you can send them redirect links
And actually give me a few mins to test: Or confirm them with return_url so that you can send them redirect links to make sure this is doable
It should be but i want to be 100%
fallen timber
That would be great thanks
I think if we can do an interim solution of doing the return url and manually have 3ds be handled via a webview for these and then our long term goal is using the stripe sdk to handle things automatically and likely use the stripe payment sheet in the apps. Let me know when you are able to confirm those things - thanks!!
noble spade
Yep it works just tested
So all you need to pass in the confirm request on your server are the payment intent id and a return url
And that will return a response with the 3ds url in it
And how you want to deliver these 3ds urls to your customers is kind of up to you
You can email them, surface them in a web portal, etc
fallen timber
Let me read through these docs and see if I have any questions to confirm implementation
fickle plumeBOT
fallen timber
So if we follow the confirm a payment intent docs and supply a return url back to our application the payment intent object that returns will have the next action object with the redirect url which is the bank card, we pop that up in the web view in our app. I think this makes sense.
To summarize:
Interim solution, somehow make users come back to our app likely through our failed transaction workflow and force users to confirm the payment intent again with the ability to have 3DS completed.
We need to only use setup future usage off session on the first time charges of a card.
For updating credit card information we would need to make sure that we have them complete 3DS at that time? If they do not have to be charged at that time we would need to have some way to listen if the payment intent needs action and have them complete 3ds in some way before we can charge them.
fallen timber
Ok so it looks like you create the card by creating a token first. That's not ideal. That will increase the likelihood that future payments require 3ds
You mentioned this a while back in the discussion, if we should not be creating a card via a token first are you saying that we should be passing in an object instead of a token? In the stripe docs it looks like the example is showing a token the same way we are doing it? https://docs.stripe.com/api/cards/create
noble spade
For updating credit card information we would need to make sure that we have them complete 3DS at that time?
You can't make sure of this. 3DS is requested by the bank. There's always the possibility that future transactions require it whether or not you set up the card correctly. That's why it's crucial for your app to be able to support 3ds
Creating a token is the legacy way to do that
Recommend just following our mobile accept a payment guide for how this is supposed to work with payment intents: https://docs.stripe.com/payments/accept-a-payment?platform=ios
fallen timber
We do not have the ability to use the Stripe iOS SDK since it does not support .NET Maui - we have to use the payment intents API server side for .NET
noble spade
The above guide creates payment intents serverside
I don't know about .NET Maui so can't speak to how that's supposed to work
fallen timber
This was discussed previously in the thread - my question still remains though. In our Admin web application how are we supposed to handle potential 3DS when we do automatic charges for usage fees, lost item fees etc.
fallen timber
So if a user never decides to come back online then it's a loss for the connect account? Bad actors could steal a rental item and then we go to charge them, 3DS then kicks in and they never complete it?
noble spade
Yep
If the transaction requires 3ds
3ds is unlikely for future offsession transactions though
Provided you set up the card properly
fallen timber
Ok, so unlikely if we set the card up properly.
So since we are in NET maui we don't have access to the stripe payment sheet. So via API only what is the recommended way to set up the card during user registration to ensure that it's set up correct (aside from having off session and 3DS flow built in, as discussed that is something we know we will have to do)
noble spade
If accepting payment setup_future_usage=off_session in payment intent
fallen timber
yup I understand that part. But you said creating the card via a token is not the recommend way to do that. So is it that we should move away from the CardService and start using the CustomerPaymentSourceService to create the payment methods (via passing in the card details, or can a token still be used there?)
noble spade
If you can't use the payment sheet you have to do it the way you're doing it
There's no harm in doing it that way as long as you pass setup_future_usage=off_session in the payment intent creation request
And the customer is still in the app to complete 3ds if necessary
fallen timber
Gotcha ok, so no need to migrate away from how we create the cards themselves, but just ensure we have the setup_future_usage=off-session along with the first payment intent.
Do you have a recommendation for when updating a users credit card? Is there an endpoint that can update the card and handle 3DS at the same time?
noble spade
Depends what you are updating. Is it just expiration date? Or a new card number entirely? Because you can't update a card's card number. An entirely new payment method needs to be created
And you should use a setupintent for that
fallen timber
yes it would be a new payment method getting updated - so if we did say use a setup intent for that since it would be charged at a later time how should 3DS be handled there? Say they update their payment method today, and get charged by our automated process in 5 days and it triggers a 3DS?
noble spade
3ds should be triggered by setupintent if required
There's always a small chance the future charge would require it though
fallen timber
So when updating the payment method we would have a setup intent which if 3DS were required would be triggered at that point when the user is still in the app to do the 3DS
noble spade
yes
fallen timber
Ok this is super helpful. So sounds like we want to set up our payment intents with this future usage and use setup intents to handle 3DS while we have the user to do the interaction on the mobile side. Doing so will mitigate any future payments having issues with 3DS that are initiated w/o user interaction such as our automated usage fees, or manual charges for lost items. Since it is not 100% guarenteed that 3DS wouldn't be triggered by those we would likely want to listen via a webhook from Stripe if the payment requires action and possibly temporarily block the user from making additional purchases until they can resolve 3DS via some sort of flow in our mobile app?
noble spade
Since it is not 100% guarenteed that 3DS wouldn't be triggered by those we would likely want to listen via a webhook from Stripe if the payment requires action and possibly temporarily block the user from making additional purchases until they can resolve 3DS via some sort of flow in our mobile app?
Yes you'd want to do this for any declines as well
That's the thing with off-session payments they might not go through for any number of reasons
Also reminder to only pass setup_future_usage for the initial transaction
fallen timber
Right! That makes sense. I think I have most of the information I need. I am going to start architecting this out to slot in with our integration. Once I pull that together is that something I could start a new thread and just have a stripe dev give a gut check that the integration looks correct?
noble spade
Yeah if you share context and code snippets we can do that
fickle plumeBOT