#luanvdw-subscription-3ds
1 messages ยท Page 1 of 1 (latest)
Hey! The recommended way is outlined in our integration guide. You confirm the Setup/Payment Intent on the initial invoice with Stripe.js: https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements#complete-payment
Thank you for the response ๐
I need to ask upfront if you need to step away soon and or if you have the the time needed to help navigate what feels like an endless amount of paths in creating subscriptions. I feel like my use case is a straight forward one that gets confusing fast when trying to retro fit it to the journeys explained in your documentation and examples on GitHub.
Can I explain my use case to you? ๐
Sure, go ahead
Thank you ๐
From the link you shared. Step 1, 2, 3, 4 is done
We are now in a world where I want to subscribe the user to a paid plan (so one, when the initial invoice will have to be paid)
stripe.subscriptions.create({...})
The plan is $19 / month , so I need card details
In order to;
- capture payment details
- charge the card obtained from these payment details
- deal with 3DS (extra steps)
I need to access the client_secret on the paymentIntent from the subscription object that was created in the previous step.
To be at this point the subscription needs to have been created. Meaning it is now in Stripe... but it is still inactive as we have not yet received a confirmed payment to activate the subscription
So what I would like to confirm is 2 fold (apologies if my initial question around 3DS was misleading)
- In capturing the payment details with elements from the client secret... will Elements cater for any 3DS steps (if required) at this point ?
- With Elements, the act of confirming the payment is not a Server side process and Elements takes care of this through its own security that has been baked into Elements. As such, will payment failure of this initial invoice also be treated through Stripe Elements? or is the only way to deal with failed payments to do so through webhooks?
I need to access the client_secret on the paymentIntent from the subscription object that was created in the previous step.
The Payment Intent is actually on the Invoice object.
To be at this point the subscription needs to have been created. Meaning it is now in Stripe... but it is still inactive as we have not yet received a confirmed payment to activate the subscription
Yep, that's the default behaviour.
- In capturing the payment details with elements from the client secret... will Elements cater for any 3DS steps (if required) at this point ?
Yep, that's whatconfirmPaymentdoes. It'll handle the auth flows for 3DS if requested.
- With Elements, the act of confirming the payment is not a Server side process and Elements takes care of this through its own security that has been baked into Elements. As such, will payment failure of this initial invoice also be treated through Stripe Elements? or is the only way to deal with failed payments to do so through webhooks?
It depends on the type of payment method used. If a card, any failure/decline would be synchronous. However with some LPMs (like banking debits) failures can be asynchronous (days later) so you'd be expected to handle that with webhooks yes.
It depends on the type of payment method used. If a card, any failure/decline would be synchronous. However with some LPMs (like banking debits) failures can be asynchronous (days later) so you'd be expected to handle that with webhooks yes.
At this point I am 100% willing to just limit it to cards for simplicity.
In doing that, if I understand correctly then
const {error} = await stripe.confirmPayment({
elements,
confirmParams: {
return_url: "",
}
});
if (error) {
// Any error that took place during payment
// insufficient funds
// card has been blocked
} else {
// Your customer will be redirected to your `return_url`.
}
In the if(error) part, we will be able to capture the various error states (whilst the payment form is still rendered and the user can say... enter different card details)
Am I understanding this correctly?
Yep, exactly! With cards it will be an instantaneous decline that you can display to the user on the front-end
and so the return_url + else {...} in the above snippet is only needed to accommodate for paymentMethods over and above that of cards.
Or do they have other relevance as well?
return_url is always used unless you set redirect: 'if_required': https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-redirect
Note: Setting if_required requires that you handle successful confirmations for redirect-based and non-redirect based payment methods separately. When a non-redirect based payment method is successfully confirmed, stripe.confirmPayment will resolve with a {paymentIntent} object.
Thank you!
Here is the part that confuses me.
By default, stripe.confirmPayment will always redirect to your return_url after a successful confirmation
So at this point, we are successful meaning no errors. So if I understand correctly the return_url is purely to facilitate payment methods that require intermediary redirects such as "iDEAL or Afterpay Clearpay" in which case if something went wrong we will have the paymentIntent and we can again renderElemens with the secret on the paymentIntent and let them use a different card.
Is my understanding of the redirect part on .confirmPayment({...}) correct?
No, it'll always redirect there even in cases of card payments
If you don't want than, then use redirect: 'if_required'
and in using if_required
it will facilitate payment methods that require intermediary redirects such as "iDEAL or Afterpay Clearpay" in which case if something went wrong we will have the paymentIntent and we can again render <Elements /> with the secret on the paymentIntent and let them use a different card, for example.
Yep, exactly!
And in a successful payment case, with if_required you'd end up in the else block here (and can control what you want to do next):
if (error) {
// Any error that took place during payment
// insufficient funds
// card has been blocked
} else {
// Your customer will be redirected to your `return_url`.
}
This has helped me answer the questions I needed. Thank you very much for taking the time to do so ๐
np!
This has been tops! Enjoy the rest of your day / night.