#brandan_best-practices

1 messages · Page 1 of 1 (latest)

ruby thicketBOT
#

👋 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/1427741349268033597

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

light egret
#

Questions:

  1. We have a handful of incomplete payment intents that show they tried to initiate 3DS but it was not completed. What are the options for our connect account users to resolve these incomplete transactions?
  2. Can we somehow get around requiring 3DS until we have built in the 3DS flow?
  3. We are using a .NET Maui project and have to work on creating C# bindings for the Stripe iOS SDK so we can utilize the Stripe 3DS flow in the sdk. We are looking for guidance on how to handle this in the interim while we work to get this 3DS flow working.
  4. How does Stripe know if the payment is initiated by the user via mobile app to prompt them for 3DS vs if we initiate a payment via our admin application to do a charge - would that also require 3DS?
sinful lodge
#

Hello

1/ There's not much the merchants (Connected Accounts) can do aside from having their customers re-attempt that PaymentIntent by having them come back to the website/application

2/ 3DS isn't always something you can control unfortunately. The issuers can trigger 3DS verification anytime so your application needs to handle it

3/ How exactly are you handling payments in the iOS SDK? Are you using PaymentSheet? If so, 3DS is handled automatically. If not, the other option would be to redirect the user to a webview/safari/browser window to complete 3DS

4/ It depends on a few things. Are you saving these PaymentMethods? If so, are you using SetupIntents API or something else?

ruby thicketBOT
light egret
#

3 - We are handling payments server side using the .NET PaymentIntents API. Which is why we are encountering this problem, we did not have this issue on the ChargesAPI which 3DS was not really something that was handled on that API from my understanding.

4 - We do save the payment methods, we use the PaymentIntentsAPI.

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 $100 lost item fee using a payment intent confirm = true, so no pre-authorization is required. Could this result in a 3DS situation? Are we not supposed to use PaymentIntentsAPI for those scenarios?

Things are a little fuzzy with us running into the 3DS scenarios and how we are supposed to handle that in cases where there isn't user interaction with the charge.

Appreciate your help!

slow jungle
#

👋 Hi, changing of the guard, so i'll be jumping in.

light egret
#

Our end goal is to start using the Stripe iOS SDK and likely use a payment sheet, to allow 3DS to be handled automatically. Given we use .NET MAUI the Stripe iOS Sdk cannot just slot in nicely, we have to create the bindings for C# to get things working which will take some time.

We are looking for:

  1. if there is anything we can do in the interim to help our merchants (sounds like not much can be done, maybe a manual charge via stripe dashboard?)
  2. We want to ensure we set things up correctly for both the mobile 3DS but also if we have to make charges using the administrator web app how are we supposed to handle 3DS scenarios? Since we have a nightly process that runs to do usage fee charges, lost item charges etc. I am concerned we are going to run into 3DS issues when we attempt to collect those funds?
slow jungle
#

Are you using setup_future_usage when saving the Payment Method?

light egret
#

Currently we are not using that setup_future_usage when saving the payment method.

slow jungle
#

Strongly recommended if you may need to re-charge the user again when they aren't present.

light egret
#

That's great to know, so that is something in the immediate we can do to help with these charges ending up in an incomplete status!

#

That sounds like it is still possible for it to end up requiring 3DS, even if you have it set to 'off-session'?

slow jungle
#

It's still technically possible because the issuer can ultimately require at their discretion.

#

In practice though it's not very common, as we've essentially requested from the issuer an exemption for future charges.

light egret
#

Gotcha - super good to know. Thank you!

#

So for our mobile app that ultimately sends the paymentIntent for the first time charge server side, if we set it to off-session could that also reduce the chance of 3DS? Or do those first time charges always need to be able to handle 3DS? Since we allow some merchants to use pre-authorization I'm trying to figure out the best way for us to handle this in the interim while we work on getting a Stripe SDK C# bindings ready to be able to use the payment sheet

slow jungle
#

off-session won't do anything to reduce chances for the first transaction.

#

I think the best solution here would be to use Setup Intents for pre-authorization. https://docs.stripe.com/api/setup_intents, essentially a 0 dollar payment intent meant for collecting prior authorization for future usage.

#

The user will need to be present during the Setup Intent, but no charge has to occur at that moment.

#

Then when the first charge occurs, you've already requested the 3DS exemption.

light egret
#

Our pre-authorization is usually for $1-50 or so dollars and the payment intent is typically confirmed within a few minutes of pre-authorization.

#

Ultimately is sounds like there is nothing that can be done for the first time transaction 3DS in our current situation. What we can do immediately is add the off-session to the payment intent to help with future charges and getting flagged for 3DS.

Our options for 3DS for our mobile transactions would be to move to the Stripe iOS SDK and use a payment sheet to allow 3DS to be handled automatically, or handle it manually on our own (more difficult?).

Would that be an accurate summary?

Another question for those transactions that are currently stuck in the 'incomplete' status — anything that can be done for those so our merchants can reconcile funds?

ruby thicketBOT
slow jungle
#

I think that summary would be accurate

#

For the incomplete, I think bringing the user back to the site to pay is the really the only way as Hanzo pointed out.

light egret
#

Since these were via our mobile app (NET Payment intents API) it probably would make more sense for us to try and charge them via our admin site no? Given we don't have 3DS at the moment I think the only way we could attempt would be to recharge them in some other way?

#

and then these incomplete charges would have to be canceled manually?

keen spindle
#

Hi there,
taking over for my colleague who had to step away. Give me a sec to catch up.

light egret
#

sounds good, thanks!

keen spindle
#

When you say try and charge them via our admin site, what do you mean?

light egret
#

We have a mobile app where users can initiate purchases. We also have an admin web app that is used to charge/refund users.

keen spindle
#

Ok so app and admin serve different puposes inside your integration, correct?
Are you using any of our mobile SDKs for the mobile app?
The problem I see with charging them through the admin app is that the 3DS flow will get triggered again from my understanding, since it isn't handled in the first place during Payment Intent creation.

light egret
#

Yes they serve different purposes! We are not using an SDK at the moment because we are on .NET MAUI which Stripe does not have an SDK for so we have to handle all our payments using the .NET PaymentIntentsAPI. We are likely working toward moving to a stripe SDK but it requires us to create c# bindings which will take time to get that setup - and at that point we would likely use the payment sheet so it would handle 3ds automatically.

#

That is my concern as well with charging via the admin app but we are trying to find a way to help merchants (connect accounts) reconcile these transactions. Do you have any ideas of how that could be done?

keen spindle
#

Let me think for a moment. Because from the top of my head I am not sure there is a good way of doing this.
Either way you would need to build out some integration for the user to come back to run through 3DS. 🤔

light egret
keen spindle
light egret
#

SCA impacts many European payments, but we are in the US 🤔

Screenshot_2025-10-14_at_4.23.53_PM.png
keen spindle
#

Yeah you are right. It's not very explicit. That doc references the guide how to migrate to Payment Intent API: https://docs.stripe.com/payments/payment-intents/migration
and explicitly calls out 3DS here: https://docs.stripe.com/payments/payment-intents/migration#:~:text=the webhook handler.-,Now that you have migrated%2C use the test cards in the following section to verify your upgraded integration handles 3D Secure authentication.,-Access saved payment

However, right now I don't see a way around creating some Payment UI that will handle 3DS for you. It would either be your app, which I understand is not immediately possible, or create a web accessible page.

light egret
#

Fair, that it calls out we should have tested that 3DS would work. It's not super explicit - could maybe suggest to make that more prevalent in the docs!

Might be the same answer, but would it be different if we manually charged them via Stripe Dashboard outside our system? I'm just trying to figure out how we can get these funds since we likely won't ever have any way to get user interaction on these transactions.

#

I appreciate you & your teams help explaining in more detail what is required to handle this and potential solutions for the incomplete transactions! This conversation has been really helpful in just understanding this more and the best way to handle both areas where we can initiate paymentIntents.

I will be heading out shortly for the day, will this thread remain active to pick back up with someone in tomorrow at the start of the day to continue asking questions or will I need to submit a new request to continue talking with someone?