#luanvdw-subscriptions

1 messages · Page 1 of 1 (latest)

keen tendon
#

Hi there!

#

Can you share the subscription ID (sub_xxx)?

elder cargo
#

Sure thing;

#

sub_1LBGJiIhnflvQVbiePwP859p

#

Thanks for having a look

keen tendon
#

Thanks! Give me a few minutes to look into this.

elder cargo
#

Thank you, much appreciated

elder cargo
#

If you need any other information please feel free to ask?

errant crow
#

Apologies, soma had to step out and I missed this thread for a bit. Looking in to why this subscription is working like that

#

Not immediately sure why this PI is in that state but I am still digging. So every subscription that you are creating like this is showing this behavior?

elder cargo
#

Thanks!

#

In Dev, all is working as expected but in Prod this seems to be the case

#

All subscription flows in prod are in this state of payments not being completed

errant crow
#

Can you send me the ID of a test mode subscription as well for comparison?

#

As far as I am aware they should work the exact same here if they were set up the same

elder cargo
#

So we updating a few things at the moment to try and get to debug this,

In dev we have it failing now as well. Here is a subscription id I can share with you

#

Here is a payment id, pi_3LBIGrIhnflvQVbi2NzdCJig

#

sub id

#

sub_1LBIy3IhnflvQVbiKzPWYAKD

#

this is in test mode 👆

#

Some context as to our process;

  1. We are allowing a user to save a card for future usage with setupIntents (and Stripe elements on the UI)
  2. We then want to charge a user (as a result of a different flow)

In step 2, the charge is not actually taking place on the users default payment method. It says requires_confirmation

I am assuming this is because of 3DS but should step 1 not take care of 3DS so that future payments are "pre approved"

errant crow
#

I actually don't think 3DS is the culprit here. requires_action is the status of a payment intent when it needs 3DS approval, requires_confirmation means that there hasn't been an attempt to charge the payment intent yet

#

I am assuming this is because of 3DS but should step 1 not take care of 3DS so that future payments are "pre approved"
Kind of. Setting up a payment method with a setup intent and then creating a subscription later can often mean that you aren't asked for 3DS auth again but banks can ask for it on any payment. In fact, if you are always going to create the subscription right after collecting the payment method, it is usually better to not use a setup intent at all, create the subscription, and have your customer enter their details to pay that first payment intent

#

I have reached out to my colleagues to look in to this further. Not seeing anything immediately that would cause this to happen

#

Wait. I misread the status of the payment intent. This is requires_action so it is because of 3DS

#

For future reference, if you are making the subscription while the user is not currently on session, you can pass off_session: true which makes the bank asking for 3DS confirmation again much less likely. If the user is on session you are expected to present the user with the 3DS auth page if the bank asks https://stripe.com/docs/api/subscriptions/create#create_subscription-off_session

Stripe API reference – Create a subscription – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

elder cargo
#

Thank you for all of the additional information, so in order to have a 3DS enforeced upfront, it is generally better to use a payment intent rather than a setup intent

#

since with a setup intent on production (even tho I know I have 3DS on my card) the stripe elements in the UI is not triggering it

#

Is there a way to enforce that 3DS pop up in Stripe elements?

errant crow
#

It depends on how you are doing it. If you are allowing the user to set up their card and then make the subscription at a later date, setup intent is the way to go. I admittedly missed that prominent detail when I typed up

#

Elements should trigger it. Does this happen in test mode when you use one of the cards that always triggers 3DS?

elder cargo
#

So that is exactly what is taking place then

We are using setup intents to capture the card
And the capturing a payment at a later stage

On dev, setup intents triggers 3DS with the Stripe test cards
On prod, with my own card it is not being triggered

errant crow
#

Gotcha. Yeah banks can choose to request or not request 3DS setup at any time which can often have unexpected results. If this works in test mode then you should be good on the initial setup in live mode

#

It sounds like the subscription creation is the place where there may need to be some adjustment. Basically, if the subscription is created as the result of some button click by the user, you will want to check if that first payment intent goes to requires_action and if so present the user with the 3DS dialogue.
If the user is not on your app/site, you can use that off_session parameter I mentioned which makes 3DS less likely (though not impossible, so you will want to turn on our 3DS emails or otherwise set something up to reach out to the user and ask them to go through 3DS auth again)

elder cargo
#

Thanks! Seems like to cater for the inconsistency of when 3DS will be asked and when not, a few additional fallbacks will need to be implemented.

Basically, if the subscription is created as the result of some button click by the user, you will want to check if that first payment intent goes to requires_action and if so present the user with the 3DS dialogue.

Would this "present the user with the 3DS dialogue" be done through Elements?

warm nest
#

Hi there 👋 jumping in as my teammate needed to step away.