#Mathieu Ducrot-retry-invoice-payment

1 messages · Page 1 of 1 (latest)

languid roost
#

Hey there. You'd be attempting to re-confirm the associated Payment Intent on the Invoice

drowsy lintel
#

ok thanks very much for the reactivity i'll try that

languid roost
#

Sure, np!

#

You'll likely do this on-session if the user has just updated their payment method

drowsy lintel
#

it's on a page with payment element with js confirmSetup that call our backend to update the customer.invoice_settings.default_payment_method

i think it's best suited for our case to use the confirm API since we also do some cleaning (using detach) about the old payment method

languid roost
#

Why confirmSetup and not confirmPayment?

#

You have a Payment Intent right from the Invoice. So you can just confirm that whilst the user is on-session

#

Saves the risk if the bank potentially requesting auth again if you call via the server-side (then you need to bring your user back on-session)

drowsy lintel
#

i was planning to reuse our update route of update payment method, which can normaly be used at anytime, to also handle cases where we got payment failure.

But as you said it's more secure to directly use confirmPayment ?

#

Does that also mean that if we use this technique for first payment (payment element with setup intent) we also risk to encounter auth requesting issue ?

languid roost
#

I'm not sure I understand

drowsy lintel
#

can you explain what's the difference between using setup intent vs payment intent to collect payment method (since i can call confirm payment form the backend via API) ?

languid roost
#

Setup Intents are designed to collect and authorise payment methods for future payments – like there's no payment to process now. Then you can use the resulting Payment Method object that the SI creates for payments

#

In this instance, you have a Payment Intent (a payment to process now) and you want to capture payment details to complete that payment

#

So you bring your user on-session to your payment method UI, capture their payment details and confirm the Payment Intent (from the Invoice) in one interaction. This will also handle any auth deemed required by the bank (and optionally you can setup the Payment Method for future off-session payments - which is what the Setup Intent does)

#

Does this make sense?

drowsy lintel
#

What i don't understand is that on my use case we have subscription that are reccurent payment.
In our custom integration we start the subscription only if we first get the payment method via the setup intent. That because the payment intent need a subscription to be created.
But if the user don't set his payment method (like leaving the page) we are creating "empty" subscription and that not what we want.
We only want to have one subscription.
That why for now we alwsays use setup intent in our worklow

languid roost
#

Sure, that'll work. But your question was about the flow for failed payments (in which case there is a PI)

drowsy lintel
#

oh sorry there was a misunderstanding so i get it that it's best suited to use your technique for a failed payments (since at this stage we got the PI)

I just bounced on your remark to question about our integration workflow.
I was wondering if SetupIntent should be avoided for first subscription payment. Like if it's based about off-session then maybe we risk to have auth bank requirement ?

languid roost
#

You should 100% use a Setup Intent if you're capturing payment methods for future off-session payments (like a subscription), yes

#

confirmSetup will trigger the 3DS flow if requested by bank and your user can handle it there and then

drowsy lintel
#

phew ok so that was not a incomprehension from our side, thank you reassure me a lot

languid roost
#

Sure, np!

drowsy lintel
#

thanks for all your time and explanation helps a lot !