#warren_webhooks
tough umbraBOT
👋 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/1364544739847835762
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
teal minnow
Can you share the Setup Intent that generated the payment method use to pay that invoice?
dry pilot
fyi, you can get the source from the event => src_1R4KD6J6lavNegVMK8dQxsiH and the seti from the source => seti_1R4KG6J6lavNegVMHb0I4XMZ
teal minnow
FWIW, what you describe is entirely possible despite saving/setting up the card previous. 3DS/auth is at the bank's discretion, we faciliate those requests when they're made
If you've set up a card/payment method for future usage, then we can apply for SCA exemptions but as stated, ultimately the bank can diregard those and require 3DS/auth regardless
Your integration needs to be able to handle those scenarios – bring the customer back on-session, re-confirm the invoice's payment with payment info and have them handle the challenge flow
dry pilot
So weirdly I don't see an event saying that 3DS was actually completed during card entry. So let's assume the bank messed up and is now asking for 3DS. How do we "bring the customer back on-session to re-confirm"?
teal minnow
Generally people would receive events like the one you shared, and communicate with the customer via email or your application and have them come back into a checkout flow to confirm the payment
We also have automated emails for this you can enable: https://docs.stripe.com/billing/revenue-recovery/customer-emails#failed-payment-notifications
dry pilot
we aren't using the stripe hosted page
can you share documentation on how to use the information in the event to complete this flow?
teal minnow
Not really any specific end-to-end documentation. I'm assuming you're using webhooks already, so:
- Receive a
invoice.payment_failed(or similar event) - Contact customer via email, and include a URL to a page in your site/app where they can confirm the payment
- On that page, build a UI to collect new payment info/surface saved payment info and use Stripe.js methods, like
confirmPayment, to confirm the intent and handle the 3DS flow
dry pilot
I want to use the next_action object from the requires_action event, can we do that
teal minnow
Not directly, no. As indicated it needs to be actioned with the SDK (Stripe.js)
dry pilot
how do we do that
teal minnow
Not really any specific end-to-end documentation. I'm assuming you're using webh...
I just explained
dry pilot
no, you explained how we collect a completely new card and correctly go through 3DS. We are already doing that. But if the bank is failing to issue a 3DS on the original card capture then we need to handle the next_action correctly here. Why is stripe sending us this event with next_action information if we can't do anything with it
teal minnow
Well you can simply re-confirm the intent assuming the payment_method field is still set and that'll use the existing card: https://docs.stripe.com/js/payment_intents/confirm_card_payment
Why is stripe sending us this event with next_action information if we can't do anything with it
The event payload just mirrors the object state at the time of the event. In this case, you're required to use the SDK as the default path
dry pilot
It looks like you are saying to do just this:`
stripe
.confirmCardPayment('{PAYMENT_INTENT_CLIENT_SECRET}')
.then(function(result) {
// Handle result.error or result.paymentIntent
});
but that documentation doesn't include any way to pass the information from the event
teal minnow
Yeah that's an integration detail. So you'd probably send an email with a URL that includes the Payment Intent's client_secret in it. Then when they open the URL you can use that URL param to pass to the function
dry pilot
we don't need to expose that client_secret because this is a subscription, so the user is always logged in, we can just fetch and return it from our API to the user to pass back to stripe.
We would likely pass the return_url and the off_session again, to make sure this verifies for all future subscription payments if it works.
Can you confirm, that if a Bank is doing the right thing here, that an unconfirmed 3DS card that now needs 3DS configuring the off_session and completing a payment intent would allow Stripe subscription created invoices to automatically complete without the user performing this action every time? Or do we really need force the user to create a new source?
teal minnow
I can't confirm that no, as I've explained we apply for SCA exemptions for recurring payments using saved/setup cards. Ultimately though the bank can, and do, still request 3DS/auth in some instances
dry pilot
sure, but what I want to confirm is, that in going through this process on the payment intent, does Stripe apply for the SCA exemption for all future card transactions?
teal minnow
Yes, we should