#LucaW-payment-method
calm halo
Hi 👋 do you have the request ID (req_XXX) from the request where you saw the returned error?
calm halo
Can you help me understand your flow a bit better? In the first two screenshots you're showing a setup intent, but in the last two you're working with a payment intent. When you tried confirming the payment intent it looks no payment method information was provided.
rustic heart
Alright, can I call you for faster communication ?
I do setup intent because there might be two transaction ( it depends if the user accept a checkbox on checkout page ) , so with setup intent I get only the first time the SCA modal to shows up.
In the last two screenshot I'm working with payment intent as you can see on the API call /subscribe on the response I get paymentIntentResponse
That's because on my server side I check if the subscription is not active then it returns too the payment intent on the response of api /subscribe
The endpoint /subscribe does this:
$subscription = \Stripe\Subscription::create([
'customer' => $customer->id,
'default_payment_method' => $token,
'items' => [
[
'price_data' => [
'unit_amount' => $monthlyAmount->asCents(),
'currency' => 'eur',
'product' => $product_id,
'recurring' =>
['interval' => 'month']
],
]
],
"application_fee_percent" => $totalPercentage,
"transfer_data" => [
"destination" => $partnerStripeAccount->getStripeUserId(),
],
"metadata" => $metadata,
"off_session" => true
]);
That's why there is a payment intent
calm halo
Gotcha, and where are you providing the payment method or payment method data for the payment intent?
rustic heart
The response of stripe.confirmCardSetup I get the payment method
Then I pass it to the endpoint /subscribe
paymentMethodId
paymentMethodId: "pm_1KLUDKD5S3Ge4mVNId9iSnaH"
It is the same payment method id of the /confirm response error
calm halo
Hm, so it's looking like that card was declined, but that doesn't seem like the result I'd expect. Let me see if I can spot why it didn't move to a requires_action state.
rustic heart
Before I was talking with Paul and he said the reason for this was because I set off_session => true to Subscription::create. But when I developed this flow some months ago ( November ) I did talk with Mike an engineer at Stripe. He told me that:
Hey Luca,
Thank you for the response and clarification. Apologies I initially missed the Connect aspect of your question.
As you are creating this PaymentMethod with a SetupIntent, you should be able to create both subscriptions with that PaymentMethod without necessarily needing to prompt the user to authenticate again. What will help here is specifying off_session: true​ in your subscription creation calls[1] to give yourself the best chance at not needing to authenticate again.
That being said, your integration should be able to handle cases where these set up or recurring payments require user action. Setting up cards as you are doing and specifying off_session​ for payments that are off session will mean that that should not happen often. That being said, it is ultimately up to the banks to decide whether they want to ask for authentication again. If you have not seen it, we have a quick guide on handling failed payments and payments that require further action here[2].
Let me know if you have any further questions.
Thanks,
Mike
calm halo
That is correct, but as the description of that test card is:
3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
I'd anticipate that you'd need to complete 3DS for the payment to succeed.
rustic heart
But the setup intent triggers a 3DS modal, isn't the same?
fiery glade
Hi LucaW taking over for toby here
With that test card, authentication will also be required on the payment itself. That test card is designed to require authentication every time it's used
Additionally, it's important to note the last paragraph of Mike's email: That being said, your integration should be able to handle cases where these set up or recurring payments require user action. Setting up cards as you are doing and specifying off_session​ for payments that are off session will mean that that should not happen often. That being said, it is ultimately up to the banks to decide whether they want to ask for authentication again. If you have not seen it, we have a quick guide on handling failed payments and payments that require further action here[2]. You have to be ready for authentication on each payment in the case that the bank wants authentication again.
rustic heart
Oh okay thanks, but why the card was declined?
fiery glade
toby and I are looking into this further now actually. Will get back to you in a bit
rustic heart
gotcha
hidden anvil
Hello! I'm taking over for @fiery glade. The behavior you're seeing is expected. When a payment requires authentication (like 3D Secure) and you've specified the transaction as off-session that means the cardholder is not present to complete the authentication challenge, so it's treated as a decline and the Payment Method is removed from the Payment Intent. The next steps are to bring the cardholder back on session and confirm the Payment Intent client-side, using either the existing Payment Method or a new one.
rustic heart
Oh okay can you leave this thread open? I will do some more tests tomorrow, just in case I need a little bit more of help
Thanks for the reply
hidden anvil
This thread will remain open for a little while, but if there isn't activity it will be archived. You can always ask for more help in #dev-help and request that this thread be unarchived though!
This documentation may also be helpful: https://stripe.com/docs/billing/migration/strong-customer-authentication#scenario-2
fiery glade
@rustic heart We can chat here again
rustic heart
Thanks for the re-opening
My mind is a bit clouded, I would like some explanations on how to best manage this flow. The main problem here is with 3D Secure Cards SCA modal. In my checkout flow I create a setup intent and then I use stripe.confirmCardSetup, after that I pass on my server the paymentMethodId to create a Subscription::Create, if the user check a checkbox then it created another Subscription::Create so in total 2 subscriptions ( I've removed off_session => true ).
Now I would like to know a flow that minimize the chances of 3D Secure Modal shows multiple times
When I test this flow with the card 4000002500003155, in total the 3D Secure modals appear 3 times ( one for stripe.confirmCardSetup, and other 1-2 times for the Subscriptions as the payment intent is on requires_action state.
When I test this flow with the card 4000000000003063, in total the 3D Secure modals appear only 1-2 time ( the times of Subscription create )
How can I optimize this flow?
fiery glade
Hey for those 2 payment methods, that's expected behavior. For the one ending in 3155, it will ask for authentication every time it's used on-session, but if off-session is turned on, it won't for the off-session payments. For the one ending in 3063, auth is only presented for the payment execution (for it to be successful), hence why it is presented on subscription creation.
As to how it can be optimized, that depends on your use-case
Turning off-session off is likely fine for you since your users will be on-session when the subscriptions will be created
But turning it off and minimizing auths on sign-up could also create problems with future charges, so you'd have to be able to handle those
Really it's up to you
One thing I did want to clarify, though, is why do you use a SetupIntent prior to creating the Subscriptions? Just trying to get a better understanding of your flow
rustic heart
I use SetupIntent for minimize the authentication asks every time
Also because ( If I'm correct, correct me if I'm wrong ) I create the subscription with off_session => false, that as you said can create problems with monthly charges of that subscription ( monthly subscription )
So SetupIntent should fix this issue in my point of view right?
I've one doubt, you said "For the one ending in 3155, it will ask for authentication every time it's used on-session, but if off-session is turned on, it won't for the off-session payments." Since I create the subscription without specifying off_session parameter ( so it's on_session ) , does this mean that next month the payment will require another 3d secure authentication ?
@fiery glade
wise blade
Subscriptions themselves do not have off_session or on_session parameter. I believe it is just the creation request and that specifies whether the user is on session to confirm the first payment
Catching up on the rest of the detail here but on session and off session are more about how invoicing for the subscription works than what you specify for that parameter
rustic heart
Alright
wise blade
In your 3155 example, it would depend on whether the subscription will charge the user automatically (then, off session) or if it sends them an invoice for them to pay manually (off session)
wise blade
For that test card it will not require 3DS because it is an off session payment
rustic heart
and on production ?
wise blade
That depends on what the issuing bank decides
For automatic charges, we would tell the bank that the charges are off session. From my understanding that typically means they are less likely to ask for auth but they always might
wise blade
Apologies for missing this, looking for the doc...
This doc shows the flow you will want. You create the subscription on the server side and then on the client side you confirm the client secret for the subscription invoice's payment intent https://stripe.com/docs/billing/subscriptions/build-subscription?ui=elements
No setup intent necessary, when your user confirms the Payment Intent client side, the Payment Method they use will automatically be attached to them. You can then set the Payment Method as the default for either the Customer or the Subscription https://stripe.com/docs/billing/subscriptions/build-subscription?ui=elements#default-payment-method