#lil_payment-3ds

1 messages · Page 1 of 1 (latest)

empty hearthBOT
#

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

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

bitter tartanBOT
#

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.

plush night
#

@candid finch it depends a lot on how you have integrated in the first place. But if you use Checkout or one of our UI elements such as CardElement or PaymentElement then it all automatically happens.
The easiest way to know is to try in Test mode as the developer and use our test card numbers: https://stripe.com/docs/testing#regulatory-cards

#

lil_payment-3ds

candid finch
#

Ah, I see... we use the payment element, so I suppose it could happen. I'll test with them and see what happens

#

Thank you

plush night
#

sure thing!

empty hearthBOT
candid finch
#

On a subscription renewal payment what's the procedure for giving the user the ability to authenticate the 3ds card payment?

tired hearth
candid finch
#

When a user signs up for a trial subscription we use a setup intent, and when we get an update for payment_method.attached we set it as the default payment method for the customer, is there some flag to pass when setting it as the default that says we want it to be for future payments?

Is there anyway to do this on a standard payment_intent that is the initial payment for a subscription as well?

tired hearth
#

A Setup Intent will automatically flag the Payement Method as one you can use for future payments

candid finch
#

We set setup_future_usage as off_session shouldn't that work?

tired hearth
#

It should, yes

candid finch
#

Unfortunately it seems to not be handling it properly then

#

One sec and I can send the invoice id

#

in_1PpvetF0GkWPNQzKAJoo00tC

#

Here's the payment intent on the invoice that we get back when we retrieve invoices and expand the payment_intent

📎 message.txt
tired hearth
#

What did you do to set this up? I see that it's tied to a Subscription, but I don't see the request where you set it up for future usage. Do you have a request ID?

candid finch
#

req_2CU5IUEbOougIi

#

Looks like setup_future_usage actually wasn't passed

#

Although I don't see an option for that when creating a subscription

#

Note this subscription didn't go through the trial flow, so they didn't go via setup_intent, but rather by creating a subscription and then paying in the ui with the client_secret from the payment_intent

tired hearth
#

You would want to use Setup Intents for Subscriptions, since the initial payment is going to be created by the Subscription already. So, if you create a payment Intent before creating a Subscription, you'd essentially be double-charging the customer. Not sure if that addresses your question though

candid finch
#

Just to clarify we have 2 flows possible

  • Trial subscription
    • We use setup_intent
  • Non-trial subscription
    • We create a subscription and use the payment_intent it creates to collect the first payment
#

In trial flow once the payment_method is attached we recognize that the user is trying to initiate a trial subscription so we set the payment method as the user's default method and create the trial subscription.

In the non-trial flow we create the subscription, then return the client secret, once the user pays we get the payment_method.attached event and append it as the default payment method to the customer object

#

Is it possible when creating a subscription in the non-trial mode to specify that whatever payment method is attached will end up being used off_session? I feel like that would be the default because pretty much all future payments will be off_session

tired hearth
#

In the non-trial flow: are you using the Payment Element to charge the Payment Intent that's created by the Subscription?

candid finch
#

Correct

#

We are

#

I went through the 3ds flow and clicked the option to authenticate the 3ds payment when it was shown

#

First payment succeeded, but then the renewal payment is saying requires_action

tired hearth
#

Which test card did you use?

candid finch
#

Oh, I think I used always auth... that would explain it, right?

tired hearth
#

Yup, that would do it. You'd want to use "Authenticate unless set up": 4000002500003155

candid finch
#

But if a user was to enter a card that had that setting (always authenticate) on a subscription we would have to prompt them to authenticate on all subsequent renewals, right?

#

I didn't see any detail in the payment_intent that had a link or anything to do that, so I do wonder how we handle it

#

The authenticate unless setup worked as expected btw

tired hearth
# candid finch But if a user was to enter a card that had that setting (*always authenticate*) ...

That basically doesn't exist. I've never heard of a card that always required authentication. That being said, it is possible for the bank to require 3DS again later on, so you would want to setup a webhook endpoint that listens for Subscription events and can detect if a Subscription's payment method needs authentication again (this should be very uncommon)

https://docs.stripe.com/billing/subscriptions/webhooks

Using webhooks with subscriptions

Learn to use webhooks to receive notifications of subscription activity.

candid finch
#

Maybe I'll just leave it unhandled for now, but what would the flow look like for the re-auth?

#

We get a webhook saying they need to re-auth, then what? How do I prompt the user to re-auth?

tired hearth
#

You get a webhook that says authentication is required and then you prompt the customer to reenter the payment flow and reauthenticate their card.

#

This is incredibly uncommon though, so mostly you'll never see that happen and if you do, you can just send them back to the payment form to add their Payment Method again

candid finch
#

Ok, got it. Would it suffice to open a payment element with the client_secret from the requires_action payment_intent?

tired hearth
#

Yes, exactly

candid finch
#

Ok, great! You're the best

#

Thanks so much for the help. It's really appreciated

tired hearth
#

Sure thing! Happy to help

candid finch
#

Unrelated, but is it possible to set a subscription schedule to release after it applies a phase's updates?

tired hearth
#

Sort of. A Subscription Schedule's phases will only accept Unix timestamps, so you would have to create some automated system that detects when the update occurs and subsequently update the Subscription Schedule with a new phase that starts immediately after the update

#

So it's possible, but will require a lot of custom code to implement

candid finch
#

Just to give some context, I only do this for downgrades so we don't have to refund/run a balance with users and it only ever has one extra phase to switch the subscription tier at the end of the current period.

Would it be possible to set the end_date of the phase to like 1 minute after it starts and then have the end behavior be release, in which case the subscription schedule would update to the new level, then release 1 minute later

empty hearthBOT
candid finch
#

Or would that undo the change of the subscription tier?

tired hearth
#

I don't see any reason why you couldn't have a short phase like that, unless an Invoice is going to be drafted and left in open for 1 hour (which Stripe does by default on Subscription renewals). In that case though, you could just manually finalize and pay the invoice immediately before updating the phase.

I would highly recommend testing this with Test Clocks though, as there may be some default behavior I'm not thinking of

candid finch
#

Fair enough, jw if it's a possible way to handle it! Thanks again

tired hearth
#

Sure thing!