#dai-developers_api

1 messages · Page 1 of 1 (latest)

random robinBOT
#

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

📝 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.

brisk pollen
#

At the moment, the only situation I have been able to reproduce locally or in the test environment is when using a test card that does not support 3DS (378282246310005). In that case, the PaymentIntent status becomes requires_capture immediately after creation.

Are there any other situations where the PaymentIntent status could become requires_capture immediately after creation?

We have encountered cases in our production environment where the PaymentIntent status unexpectedly became requires_capture immediately after creation, and we would like to understand the cause and determine how to prevent it.

#

Additional Infomation:

  • "We create and confirm the PaymentIntent on the server side, and handle 3DS processing via a redirect to the return_url."
warped condor
#

Hi! Sorry to keep you waiting! Looking into it now.

#

You will only getrequires_action when a 3DS authentication is required.

Can I understand more about what are you trying to achieve?

#

If a payment method doesn't need 3DS authentication you will automatically get requires_capture.

random robinBOT
brisk pollen
#

What specific situations are considered payment methods that do not require 3DS authentication?

fair patrol
#

hello, taking over the thread as my colleague need to step away 👋 give me awhile to catch up.

#

Well..to answer the question directly first, sometimes the used payment method wouldn't require 3DS if it has been properly authorized for future off session usage [0].

But we need to be clear that merchants or Stripe does not control when 3DS happens, even for off session payments. Also, passing "request_three_d_secure": "any" in payment creation is only telling the network your *preference * for authentication. It does not guarantee authentication to happen. Customer's card issuer (e.g. banks) determines whether authentication is neccessary when the card is used — this is outside of merchants' or Stripe's control.

[0] https://docs.stripe.com/payments/save-and-reuse

brisk pollen
#

So, if I understand correctly:

There are cases where 3DS authentication is required and cases where it is not required.
When 3DS authentication is required, the PaymentIntent will always transition from requires_action to requires_capture.
When 3DS authentication is not required, the PaymentIntent will move directly to requires_capture without going through requires_action.

Also, the conditions under which 3DS authentication becomes unnecessary cannot be determined by either the merchant or Stripe.

Is my understanding correct?

fair patrol
#

When 3DS authentication is required, the PaymentIntent will always transition from requires_action to requires_capture.
Correction: When authentication is rquired, the PaymentIntent will transition to "requires_action" first. Once its successfully authorized, then it will transition to "requires_capture"

#

When 3DS authentication is not required, the PaymentIntent will move directly to requires_capture without going through requires_action.
This is correct, provided your PaymentIntent uses manual capture.

#

Also, the conditions under which 3DS authentication becomes unnecessary cannot be determined by either the merchant or Stripe.
Hmm..I wouldn't phrase it this way. But it essentially means merchants and Stripe does not fully control whther 3DS authentication is needed or not.

brisk pollen
#

I see.
Finally, I have one last question to confirm.

For payments that go through a frictionless flow, is it possible that the PaymentIntent status could be either requires_action or requires_capture at the time the PaymentIntent is created?

fair patrol
#

But whether a payment authentication goes through frictionless flow or not, it entirely up to the card issuer's discretion. And this is assessed on a per transaction basis. Merchant and Stripe does not decide this.

brisk pollen
#

in this scenario, yes, the payment can go into "requires_capture" straight away.
When we tested using the Stripe test card that triggers a frictionless flow (4000000032200000), the PaymentIntent status was requires_action immediately after creation. Because of this, we assumed that frictionless flows would always result in requires_action.

However, it seems that there are cases where the status can be requires_capture instead. Right?

fair patrol
#

I tested with the same test card and I was able to go through the frictionless flow

#

do you mind sharing the PaymentIntent ID with me? I can take a deeper look at it

brisk pollen
#

The PaymentIntent Id is pi_3TAPFQF0xJHccp7D0EKpJOAh.

fair patrol
#

It's likely because you are also passing setup_future_usage: "off_session",

#

Doing so is telling the card network "I will want to charge this card when the customer is offline in the future"

#

Hmm...I tested with SFU, but I was still able to go through the frictionless flow nonetheless

#

I noticed your setup is using the deferred intent flow as well

#

I manged to reproduce the same bahavior as you (I got "requires_action" during PaymentIntent creation while using 4000000032200000 too). It appears to only happen when you used the Deferred Intent Flow [0], where you create the Payment Method object before creating the PaymentIntent.

[0] https://docs.stripe.com/payments/accept-a-payment-deferred

#

If you create a payment intent first, then send the client secret to Stripe Element on the frontend, you may be able to go through the frictionless flow, which was what I did in my first test. You can try this if the purpose is to experience what the frictionless flow is like in a test environment.

#

That said, I do want to highlight that your real payment integration should be prepared to handle any kind of authentication flow, given that frictionless flow never guaranteed.

brisk pollen
#

I understand that frictionless flows normally result in requires_capture, and that the reason we see requires_action in our local and test environments is due to the Deferred Intent Flow.

The issue is that the behavior differs between our local/test environments and our production environment. In our code, when a frictionless flow occurs, the PaymentIntent status immediately after creation is requires_action in our local and test environments, but in production we have also observed PaymentIntents where the status was requires_capture.

Should we assume that requires_capture can also occur in the Deferred Intent Flow, and therefore write our code so that it can handle both cases?

warped condor
#

Should we assume that requires_capture can also occur in the Deferred Intent Flow, and therefore write our code so that it can handle both cases?
Yes, your code should be able to handle both cases.