kwkwkwkwkw

[gusty reef]

Can you share the subscription ID (sub_xx)?

[thorny bone]

I am not sure if I can share the subscription ID, I will get back to you about that after I check with my company policy. Meanwhile, can you share on what I should check in the subscription?

[gusty reef]

If you follow this guide https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements to create subscription and make payment successfully with 3DS authentication, the subscription should be updated to active and its underlying invoice and payment intent should be paid and succeeded respectively.

Without the subscription ID (sub_xxx) with the behaviour that you mentioned, I can't provide any further information or reason why it's not working as expected.

[compact lily]

This thread has been archived. If you need help with anything else please ask in #dev-help or contact Stripe Support: https://support.stripe.com/contact

[thorny bone]

Hi

here's one of the affected subscription ID: sub_1NL2PDBoT4BLkOhvU737x0fF

[atomic pecan]

👋 let me take a look

The PI here hasn't been completed https://dashboard.stripe.com/test/payments/pi_3NL2PDBoT4BLkOhv1HWMl2yf

so there might be something on your frontend which didn't confirm it correctly

Could you share more about your integration?

[thorny bone]

Ok, please let me get back to you about the integration.

I'm not sure if this make sense. Normally, when there is no 3ds authentication involved, our integration use create subscription api that include the default_payment_method. We did not manually create any paymentintent.

Does this mean that we should manually create a payment intent and confirm it before creating a subscription?

When we were adding the payment method, we used the setupintent api.

[atomic pecan]

Oh no, your integration is in good starting shape. I didn't mean to change to create PI sepately.

However, when you create a Sub using a PaymentMethod previously collected by a SetupIntent, yet you can still see it requires 3DS, by listening to the payment_intent.requires_action event

That you know you still need to confirm it again, by presenting the customer your frontend and build a JS integration to call handleCardAction like this https://stripe.com/docs/payments/payment-intents/upgrade-to-handle-actions?platform=web#update-client

[thorny bone]

So in addition to the pop up modal that shows up for the user to put in the verification codes from their mobile phone, etc. We also have to confirm payment intent after the authentication is successful. Am I correct?

[atomic pecan]

"The popup modal" you refer to is when confirming SetupIntent?

[thorny bone]

Just a moment, I will capture a clip when we add a payment method for you to see.

I meant this modal in test environment. From what I understand, it will actually be website of the credit card's bank right?

[atomic pecan]

Yes correct. And it's on SetupIntent confirmation, right?

[thorny bone]

Yes

[atomic pecan]

Ok, here is the thing, even when SetupIntent triggered 3DS and customer has confirmed successfully (like this modal simulated), the Subscription could still ask for 3DS again. This is totally up to the card issuer and our test card may simulate the situation

When you build your integration, you need to be flexible at Subscription creation logic, always checks if it generate a PaymentIntent on requires_action or not. If yes, brings up your client and get authorized again

[thorny bone]

I see. Thank you very much for your help.

[atomic pecan]

For example https://stripe.com/docs/testing#authentication-and-setup withe the card 3184

This card requires authentication on all transactions, regardless of how the card is set up.

[thorny bone]

Ok. I think I can continue with my work now. Thank you very much for your support.

[atomic pecan]

np and good luck!