numair_api

[abstract geode]

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

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

[red viper]

We have a flow where customers add their cards to Stripe, and later, when they make a purchase, we store the payment_method ID. During order processing, we charge the customer's card using this stored payment_method ID. This works well for most customers since their cards do not strictly require 3D Secure (3DS).

However, we are facing issues with customers whose cards strictly require 3DS. When we attempt to charge these cards later, the payment fails because it requires the customer's authentication at that moment. We definitely create the SetupIntent during card storage with off_session properties, but this does not work for cards where 3DS is strictly required by banks—when we later create the PaymentIntent, it re-asks for 3DS authentication.

To handle this scenario, we want to implement a workaround specifically for these customers. Our idea is to create a PaymentIntent (PI) with manual capture at the time of checkout, only for customers whose cards strictly require 3DS. Then, during order processing, we would capture the payment instead of creating a new PaymentIntent.

The challenge we are facing is how to detect if a card strictly requires 3DS. We don’t want to move all customers to this new flow—only those whose cards require 3DS enforcement. We know that Stripe provides information on whether a payment method supports 3DS, but we need to determine whether 3DS is strictly required for a given card.

The only reliable solution we found is to create a $1 PaymentIntent with manual confirmation at checkout to check if 3DS is required. If 3DS authentication is triggered, we know the card requires it, and we cancel the PaymentIntent.

Our questions:

Is there a better way to determine whether a card strictly requires 3DS before attempting a charge?

Is our workaround (creating and canceling a $1 PaymentIntent) the best approach, or is there a more efficient method?

We definitely want to avoid reaching out to customers again for 3DS authentication during order processing. Instead, we'd like to collect their input only once during the initial checkout.

Would appreciate any guidance on this! Thanks.

[unique kayak]

You cannot get around the fact that their issuing bank may request 3DS on any charge at any time for any reason on any card that is capable of 3DS, so you need a way to get them back on your site to handle that.

[red viper]

@unique kayak If we continue with our current approach—creating a Payment Intent (PI) with a manual charge of $1 to detuct if bank requires 3ds, would there be any negative impact on our Stripe account? In cases where the bank strictly requires 3DS, Instead of storing the customer’s payment method to charge later, we create a PI that we can capture later.

Could this approach to detuct 3ds harm our account health, or should we continue using it?

[unique kayak]

That's probably not a great idea, and it doesn't solve the problem you're trying to solve either since you still need to have the ability to bring them back online to deal with the 3DS authentication.

[red viper]

@unique kayak In this case, we were thinking that since we are creating the Payment Intent, users will confirm the 3DS during the checkout process. I assume that when we later capture the PI during order processing, it does not ask for 3DS again.

[unique kayak]

Your assumption is not correct.

It may or may not, but the point is the probability is > 0.

[red viper]

@unique kayak Oh, So if I understand correctly, even if we create a Payment Intent to capture later and the user confirms 3DS, it may still require 3DS again during capture.

What would be the best approach to handle this?

[unique kayak]

Yes, correct. You can handle it like this: https://docs.stripe.com/billing/subscriptions/webhooks#additional-action

Wait, no.

Why are you doing separate auth and capture?

[red viper]

@unique kayak We are essentially a custom products company, and we don’t want to charge customers at checkout. For 95% of customers, we successfully charge their payment method during order processing, and it works smoothly. However, for the remaining 5%, we encounter issues with 3DS authentication, which we are currently discussing.

To address this, we want to implement a workaround for these 5% by pre-authorizing the amount and later capturing it during order processing. If we’re unable to process the order, we would simply void the Payment Intent (PI).

[unique kayak]

Oh ok. If you've captured it, the auth step will not require additional 3DS.

But again, any time you try to charge a 3DS card, it may require you to bring the user back to authenticate it, so you still should have that flow available.

Gotta run but my colleague can help further.

[red viper]

@unique kayak Makes sense to me, thank you. The way we handle these 5% of users during checkout is by creating a Payment Intent (PI) with a manual $1 charge. Based on the response, we determine whether the customer’s card requires 3DS. From there, we decide whether to proceed with our initial flow or create a separate PI for the customer.

I just want to know—is there a better way to detect whether a bank requires 3DS?

[latent hill]

There is not, the issuing banks make these decisions.

[red viper]

@latent hill Makes sense. If we just continue with our current approach, could it harm our Stripe account in any way?

[latent hill]

What is your current approach? There is so much context here that I want to ensure that we're both on the same page before I can properly respond.

If this 'The way we handle these 5% of users during checkout is by creating a Payment Intent (PI) with a manual $1 charge. Based on the response, we determine whether the customer’s card requires 3DS. ' is what you're referring to.. Please note that at a later charge, the issuing bank might require 3DS. In that case, you'd bring the customer back on session to complete 3DS

[red viper]

Yes @latent hill, that makes sense. That’s why I’m thinking of creating a pre-authorised PI for these customers which we can just capture. We can reach out to customers in case captures re-require the 3Ds.

We just wanted to know if creating a $1 PI for every customer and later cancelling it (Just to detect 3ds) could cause some negative impact on our Stripe account?

[latent hill]

Yeap, that is not recommended at all

You charge the customer, and the on the next payment if the issuing bank asks for 3DS, you collect that

[red viper]

@latent hill Considering our case below, what would be the best approach you suggest we can take here?

We are essentially a custom products company, and we don’t want to charge customers at checkout. We charge them later during order-processing. For 95% of customers, we successfully charge their payment method during order processing, and it works smoothly. However, for the remaining 5%, we encounter issues with 3DS authentication.

[latent hill]

So with the 5%, you bring them back on session and handle 3DS

[red viper]

@latent hill Is there any other approach where we don’t have to have customers return for sessions?