#Doctor Warg-subscription-3DS

1 messages ยท Page 1 of 1 (latest)

robust elmBOT
spare kettle
#

Hello ๐Ÿ‘‹
Can you expand a little bit more on your use-case?

#

as well as how exactly your integration handle pre-auth?

low ledge
#

Hi! Our current flow is a slightly modified version of the example code as seen here: https://stripe.com/docs/payments/save-and-reuse, where our main changes has been to also attempt to "end the trial" of a supplied subscription once the pre-auth has been done and the new payment method has been attached to the customer.

#

In actual code, what we do is in the handling for setupIntent.status === 'succeeded' is to update the customer to use the payment method as default for invoices, as well as update the user's current subscription and set trial_end: "now", and gracefully handle any errors by re-setting trial_end to what it used to be.

spare kettle
#

Gotcha. Just to clarify,
1/ You have a subscription (with trial) created for a customer
2/ You're creating a separate SetupIntent for the customer in order for them to provide a payment method

low ledge
#

Correct!

spare kettle
#

As far as I know, creating a separate SetupIntent might trigger another 3DS check

low ledge
#

We handle the 3DS-check on entering payment info, but we'll try to use the existing SetupIntent to see if that solves our problem.

#

Worth mentioning is that our pass-fail-pass-fail pattern is new since yesterday, last friday we had a full set of passes ๐Ÿ™‚

spare kettle
#

Is this for live mode or Are you seeing this in test mode too?

low ledge
#

We haven't rolled out to prod yet, so we're still only using test mode

spare kettle
#

Gotcha. What test cards have you tried so faR?

low ledge
#

We're replacing our non-3ds compliant checkout flow, so we've mainly been using 4000 0025 0000 3155

spare kettle
#

Gotcha. yeah that one shouldn't trigger 3DS auth check again after it has been setup for off-session usage.

low ledge
#

I've been keeping an eye on the logs in our Stripe-dashboard and the requests seem equivalent as far as I can see, no indication if it'll pass or fail before the actual invoice payment attempt

spare kettle
#

Right, what error messages are you seeing when it fails the atttempt?

low ledge
#

The payment fails (silently) and the subscription's status stays as past_due. In the "normal" case, the payment succeeds and the subscription's status becomes active.

spare kettle
#

huh interesting, can you share the subscription ID?

low ledge
#

Here's one of our test subscriptions: sub_1LuEzMARR0tw1j6xmzPbQp2Q

#

and here is one where I manually changed the subscription back to trial and our checkout flow worked properly: sub_1LuEnDARR0tw1j6xdzgKdDVT

spare kettle
#

yeah I think it boils down to the payment method requiring to go through additional 3DS check but since the invoice payment attempt is happening asynchronously, the customer at that point won't be around to go through the 3DS flow and authenticate the payment.

low ledge
#

That does track, but since we confirm the SetupIntent before we reach that stage in the process, and it does give us a status of succeeded after having the user validate 3DS, and we do set that as default for invoices for that user, it seems like it shouldn't?

#

and it also seems strange that I can predict the outcome given the status of the last attempt ๐Ÿ™‚

spare kettle
low ledge
#

we'll see if that works better, it's a good change regardless.

spare kettle
#

๐Ÿ‘

#

Doctor Warg-subscription-3DS

low ledge
#

Alright, using the pending_setup_intent on the subscription did not seem to help at all. We'll spend some time during the workday tomorrow to port over our new flow to use PaymentIntent instead, seeing as we want to charge our customer right away (once they initiate the transition to a paid subscription) and that'll simplify our flow overall.
Thanks for your time, I'll drop back in tomorrow if we encounter any issues! ๐Ÿ™‚

spare kettle
#

Ah okay! Good luck ๐Ÿ™‚
Happy to help