#Ender-3DS
cinder aspen
Hi @feral ether! Can you share a SetupIntent ID (si_xxx) and the corresponding PaymentIntent ID (pi_xxx) that failed?
feral ether
Sure! just one sec
cinder aspen
Note that with SetupIntent, when doing a PaymentIntent later, in some cases authentication may still be required. So you need to handle that case in your code.
As mentioned in the doc:
When an off-session card payment requires authentication, bring your customer back online to complete the payment.
https://stripe.com/docs/payments/setup-intents#increasing-success-rate-by-specifying-usage
feral ether
SI ID: seti_1KHojgEsIU1Kk7mLLlunwOxB
PI ID: pi_3KHol0EsIU1Kk7mL1bMuiszW
The test card is 4000000000003220
I'm looking at the link you sent
I'm not entirely sure if the card I'm using should fail for subsequent payments since it doesn't specifically say so in the docs (https://stripe.com/docs/testing#three-ds-cards)
Still, how should I proceed with a subscription based model when encountering these kind of cards? Should the customers manually authenticate every month?
cinder aspen
Can you try with this card to see if you are still having the issue? 4000002500003155
This card requires authentication for one-time payments. However, if you set up this card and use the saved card for subsequent off-session payments, no further authentication is needed.
cinder aspen
Oh, you are using subscriptions!
feral ether
However that card should work. The setupIntent is successful though, and the card is attached as default payment method for both the customer and the subscription
yeah I am 😄
more specifically the issue is occurring when upgrading from a plan to another
We perform the upgrade like this: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade
cinder aspen
So if I understand correctly:
- You create a subscription, and it works (it is active and the customer is charged)
- Later you try to change the plan of the subscription, and the payment fails?
Can you share with a subscription ID (sub_xxx) where this happened?
feral ether
Yeah exactly. The whole process is:
- Create a subscription, it works fine. While doing "confirmCardPayment" we setup future_usage to off_session
- Change plan, calling backend to perform the upgradePlan method as mentioned in the link above
This fails because the payment requires action from the user
sub_1KHoz0EsIU1Kk7mLytQu4M10
that's the sub ID
And here is the paymentIntent that failed:
pi_3KHozMEsIU1Kk7mL1b8SMq02
and, in case it helps, here's the previous successful setupIntent for that card 😄 :
seti_1KHozCEsIU1Kk7mL1dN7iBbU
cinder aspen
Got it, thanks! Discord is a little busy, so please give me some time to investigate.
feral ether
Of course!
plucky wing
yeah that's expected really, it's an on-session payment(creating/updating a subscription) and those don't get 3D Secure exemptions.
you can use the 3155 card and set it up and then payments that are off-session get exemptions from 3D Secure, but creating or updating a subscription are not off-session.
your integration seems very complex so I'm having trouble understanding what you do and why, but this is what fields like https://stripe.com/docs/api/subscriptions/create?lang=node#create_subscription-off_session and https://stripe.com/docs/api/subscriptions/update?lang=node#update_subscription-off_session are for, if you're doing the action in a context where the customer is not there, you can use those to test exemptions. If you're doing it in a context where the customer is there, then you do get 3D Secure requires and should handle it(it can happen in livemode too)
feral ether
Thank you for your answer! My use case is basically a 2-click plan upgrade where the user selects the plan, is shown the price differences, etc. and clicks confirm to perform the action
I thought that, since the card is already 3D secured authorised, the server-side plan upgrade would work
So, as I final question, do you think I should attempt to use those fields you linked to avoid the issue, or rather prompt the user for authentication on every plan upgrade/downgrade, despite being the same card? Thank you so much again!!
plucky wing
I thought that, since the card is already 3D secured authorised, the server-side...
only if you pass off_session on the update call so we know it's really server-side
by default we assume Subscription update calls are on-session since they'd be done from e.g. a self-serve customer management dashboard in your system ,but you can definitely use https://stripe.com/docs/api/subscriptions/update?lang=node#update_subscription-off_session here in that update call
plucky wing
So, as I final question, do you think I should attempt to use those fields you l...
if the changes are server side(driven by an action in your system or your employees), then you can use off-session. If they're not(driven by the customer doing something and they are present on your site at the time), then don't. In production maybe those payments will get exemptions, but we don't simulate that in test mode so they all do, you need to handle both cases. We only support this specific class of exemption for testing : https://stripe.com/guides/strong-customer-authentication#merchant-initiated-transactions-including-variable-subscriptions which is done by flagging the payment as off_session