#tarjei_api
ocean saffronBOT
👋 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/1243531090342187058
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fiery marsh
hi! do you have the request ID req_xxx from that error?
But yeah generally what you should be doing is confirming the PaymentIntent of the Invoice that failed, on the frontend. That pays the invoice and saves the payment method used to the Customer object, and then you can set default_payment_method on the Subscription to it.
latent ruin
Hi, the request id is req_F8dquxnq177vk4
I'm not quite sure I follow, are you saying we can confirm the payment intent with the new payment method on the frontend?
fiery marsh
well in that example what happened is there were too many attempts to pay that same PaymentIntent, so it gets automatically cancelled as a fraud prevention measure, and then hence that error. I think in livemode we'd create a new PaymentIntent for the invoice and you would then start using that but that process doesn't happen in test mode.
fiery marsh
I'm not quite sure I follow, are you saying we can confirm the payment intent wi...
yes, and you should. Really I'd recommend never using invoice.pay()
the right way to do this is contact the customer to tell them the payment failed, and direct them to the hosted_invoice_url to pay there. Or build your own equivalent of that page by building a page that uses Elements to confirm the invoice.payment_intent .
latent ruin
ok, great, thanks for the suggestions!
ocean saffronBOT
latent ruin
Ok so the procedure as I've described it works now
we tried with a new customer
to avoid the cancelled payment intent
but it still doesn't work for a 3ds required card
when trying with the "42424 4242 4242 4242" card it works
but "4000000000003220" just gets declined without further message
for the future we will move to the way you are describing it but right now I need to get it to work with our current setup
the requeset id for the failing card is req_FMMvwVWCYrCoXK
any ideas why the 3DS required card would simply be declined in this scenario?
daring karma
Hey! Taking over for my colleague.
any ideas why the 3DS required card would simply be declined in this scenario?
Because you didn't authenticate it when first collecting it.
You can use SetupIntent to collect the payment method and use it for paying the invoice later
latent ruin
thanks
but the reason we're doing this is to avoid having two separate flows
we want to use the new payment method to pay the invoice explicitly and use Setupforfutureusage
this was recommended in an earlier discussion with stripe here
we're just looking to avoid a situation where we potentially end up with 2 consecutive 3DS flows
daring karma
we want to use the new payment method to pay the invoice explicitly and use Setupforfutureusage
What are you referring to exactly by sayingnew payment method?
latent ruin
So, the scenario is this
daring karma
we're just looking to avoid a situation where we potentially end up with 2 consecutive 3DS flows
With the flow I shared you mostly won't end up with 3ds flow. Unless if the bank issuer explcitly requested a new 3DS auth that (which neither Stripe or you have controle on that)
latent ruin
our customer is past due, and wants to update their payment method. Instead of first updating the payment method and then explicitly paying the invoice (which is far as I understand could potentially result in two 3DS flows) we're now trying to just use the new payment method to pay the invoice, and use setupforfutureusage
does that make sense?
daring karma
Instead of first updating the payment method and then explicitly paying the invoice (which is far as I understand could potentially result in two 3DS flows)
For the customer is a single operation, you just collect their PaymentMethod. And then in the background you use that invoice to pay their invoice.
latent ruin
yeah, that's what we're currently doing. We're just worried that the actual payment of the past due invoice will trigger yet another 3DS flow
are you saying that we have no possible way of making sure we avoid 2 consecutive 3DS flows?
I understand that it's an unlikely scenario, I just need to understand exactly what we need to prepare for
daring karma
no possible way of making sure we avoid 2 consecutive 3DS flows?
No. The bank issuer may still request another 3DS flow. You don't have control on that.
Bu in order to reduce the chance of triggering an additional 3DS, you should be using SetupIntent to collect the payment method and authenticate it (let the customer complete the 3DS if any) a
latent ruin
Ok
daring karma
and then in the background you pay the invoice