#johan
maiden trench
dull rampart
You can use SetupIntent to collect the card and perform 3DS once, then use the collected PaymentMethod inside the SetupIntent to create multiple Subscriptions
lusty breach
if the status of the subscription goes to "requires_action" we then display the stripe modal to complete the 3ds challenge using the stripe.confirmCardPayment(clientSecret) for the confirmation in the client. how can we do this with multiple clientSecret? Since we're going to assign multiple subscriptions as listed here https://stripe.com/docs/billing/subscriptions/multiple-products#multiple-subscriptions-for-a-customer but it does not explain the process of verification
Yeah we currently have in place this too and when creating the subscription we attach the payment method to the subscription like this: default_payment_method: paymentMethodId. the problem is that that payment method was already stored and if you want to attach it to a new subscription it will ask for 3DS challenga again
So our flow is:
- Request setupIntent to server
- Store payment method using the setupIntent response data
- Retrieve payment method during the subscription purchase
- Select payment method and purchase subscription
- stripe.confirmCardPayment if subscription status comes back as "requires_action"
that works perfect but how do we do this multiple times now? we want to offer subscriptions bundles
dull rampart
On step 5, are you seeing it requires action again? Despite collected by a SetupIntent? Did the SetupIntent trigger 3DS?
lusty breach
yep because is a different transaction. the first transaction is to store the payment method then the second one is to create a subscription using the payment method previously stored
The setupIntent does trigger a 3DS to store the card
and then the subscriptions.create returns a status of "action_required" that requires another 3DS (2)
We understand and from there it'll be only one 3DS since the payment method was saved. But what if we offer a bundle of 3 subscriptions and these subscriptions have a default_payment_method attached in it that require 3ds. we don't want our users to complete this challenge 3 times
we want to do if once if you get me?\
dull rampart
Yes I understand you. When you create the Subscription using the PaymentMethod collected from the SetupIntent, did you specify off_session = true?
dull rampart
Yes, it indicates this will create the Subscription when the customer is offline, so more chance to not require 3DS again
lusty breach
okay I understand but not sure if this would resolve my issue with assigning multiple subscriptions?
I just assigned two subscriptions with the off_session set to true and I had to 3DS twice.
dull rampart
Which card have you used? A Test card?
lusty breach
yep, since we're based in Europe we need to test all our integrations with 3DS cards. We use 4000000000003220
Are you still with me?
dull rampart
Yes but that's weird. Do you enable any Radar rule that specifically tell to 3DS everytime?
lusty breach
it's nothing to do with radar tbh. it's that specific test card that trigger the 3DS automatically.
dull rampart
Radar rule can cause that indeed. Do you have the Subscription Id?
lusty breach
dull rampart
2 Subscription Ids you mentioned
lusty breach
yep
sure
actually no because I just console.log the paymentIntent obj
would paymentIntent id work?
pi_3NZojmBA7fXUxoGN0cJ5RUdQ
and
pi_3NZojpBA7fXUxoGN0VqViP9c
let me know if you need the subscription id and I can trigger another api calls
dull rampart
https://dashboard.stripe.com/test/payments/pi_3NZojmBA7fXUxoGN0cJ5RUdQ I don't see this PI has 3DS history?
lusty breach
because I didn't complete it
both returned status: 'requires_action'
which means I need to 3DS both
dull rampart
I don't see it on the log (you can open above link in your Dashboard) It only says the PI was succeeded
and it succeeded with 4242 card
lusty breach
oh sorry my bad I have shared the wrong pi ids
pi_3NZoW6I59pLpXCHE16kwZPsy
pi_3NZoW3I59pLpXCHE113yhB1l
my bad sorry about that
dull rampart
Np and looking..
Okie I think this card simulates one scenario which is uncommon, but can happen in real life, that a specific card was marked by its issuer bank that it needs 3DS everytime
It should be uncommon, but unfortunately yes you would need to 3DS and confirm it whenever it's required, including creating multiple Subscription
You can "work around" by create a real Subscription in Stripe (one time 3DS) then map with multiple logical "Subscriptions" on your own system
Nothing else I can think of unfortunately
lusty breach
ah this is going to be really hard to maintain. I don't like that last approach :/
can you ask your team and see if there are other workarounds?
dull rampart
Sure, but unfortuantely this is something on the issuer bank control, and you can't prevent it to happen in 100%
Your integration would still always needs to ask 3DS when they requires it (or they are regulated to require it)
lusty breach
another alternative would be a subscription with multiple prices right?
I guess I can manage each price from a subscription independently and remove any of them if necessary
would this approach be recommended?
dull rampart
Yeah but careful to turn off proration when you add or remove a Price.