#Ben

1 messages · Page 1 of 1 (latest)

livid fossilBOT
white radish
#
  1. Depends. requires_action status denotes that 3DS/auth was requested from the bank. There's no parameters you can pass to enforce a 3DS requirement (only by setting up Radar rules).
sweet geyser
#

Wut,
by your docs -
trigger 3DS manually, set payment_method_options[card][request_three_d_secure] to any when creating or confirming a PaymentIntent or SetupIntent

So having that any value should indeed enforce 3dsecure if the card supports it, isnt it?

#

When you set request_three_d_secure to any, Stripe requires your customer to perform authentication to complete the payment successfully if 3DS authentication is available for a card. If it’s not available for the given card, the payment proceeds normally.

#

@white radish tagging as I forgot to reply in my response

white radish
#

Please don't @ me, it's pretty busy and there are other users. I'll respond when I can

#

Ok, I misspoke. passing payment_method_options[card][request_three_d_secure]: 'any' will force status: 'requires_action' yes. Which means it requires explicit confirmation client-side

sweet geyser
#

Ok, so my initial questions remain.
If you may please look through them when you get the time. thanks.

white radish
#

After the above, a webhook will be received with the Charge object, with a final status of either -
succeeded OR failed
Failed will have failure_code and failure_message
There'll be no Charge object created on that initial authentication attempt/PI creation.

What happens if the user fails the 3d secure validation? will I receive a webhook with a new 3dsecure url for the customer to use?
You'll need to bring them back on-session and attempt re-confirmation, capturing new payment details if required. There's no Stripe URL to just send them to no, but you can configure emails with hosted pages I believe.

#

Not sure what you mean by 'all scenarios'?

sweet geyser
#

If that's ok I'd like to reassure question number 1.

  1. Having the parameters I mentioned, the only two status code possible are -
    requires_action if 3dsecure is supported by the card or processing if it ain't
    Is that correct? I want to make sure I'm covering any edge case before deploying to production.

  2. I know there will be no charge object creation on the initial PI creation, that is why I'm referring to the Webhook (callback).
    After creating and confirming a PI, a Webhook is received that includes the Charge object, correct?
    the Charge object will have a final status of either -
    succeeded OR failed
    Failed will have failure_code and failure_message
    Is that correct or are there additional possible values knowing my order of actions.

  3. As our platform supports multiple processor providers, we aren't using any of Stripe client libraries. everything is managed on our end.
    After creating a PI It has a NextAction with a Url for the stripe 3dsecure operation, already got that covered by your docs.
    My question is, and its what I can't test. what happens if the customer fails the 3d secure test? what type of webhook callback will I receive so I'll know to reconfirm his payment intent in order to receive another nextAction URL.

jade rapids
#
  1. it will never be processing, cards do not enter the processing state
#

2 sounds fine I guess

#

its what I can't test. what happens if the customer fails the 3d secure test?
you can completely test that. When you redirect to the next_action.redirect_to_url.url, there's a button to click there to simulate failing the authentication, which will test exactly what you want and show you what happens to the PaymentIntent

sweet geyser
#

Oh that's odd, when I click the next_action.redirect_to_url.url it automatically redirects me to the redirectUrl Iv'e configured on my end, I can't see the page you linked above.
I'll look into your testing docs again.

jade rapids
#

do you have an example PaymentIntent pi_xxx where that happens?

sweet geyser
#

Yes, using that card-number : 4000000000000002
Can't remember where I took it from tbh... but if it doesn't support 3dsecure, shouldn't it not return a value in the next_action.redirect_to_url.url field?

Using the always_authenticate test card from your docs works as youv'e shared so I'm able to test what I wanted.
So if I fail the 3dsecure process, the webhook includes a payment_intent object, with status of requires_payment_method
and the last_payment_error.code is payment_intent_authentication_failure 👍🏻

Thanks a lot for your time.

jade rapids