#Mike M-pi-3ds-reattempt
rigid tinsel
Thanks, taking a look
rigid tinsel
Looking at that PI you shared, there's no follow-up attempt to re-confirm the PI after failure. Just another PI creation request using the same idempotency key (https://dashboard.stripe.com/test/logs/req_V4rPa8Cdw53JRL)
next trout
There should have been. Give me a moment...
You're right; I've got a logic error in my code. So, I should be able to reconfirm using the original payment method and then try the process again, right?
Also, can you confirm that I can get a 3DS auth request at any tine, even for a card that has been put on record using a SetupIntent?
(It required a 3DS auth, which the user passed)
rigid tinsel
Yes, exactly. You'd re-attempt confirmation (not sure how you're doing that) passing the Payment Method again. PIs are just a state machine that facilitate payments, their only terminal states are succeeded or canceled
rigid tinsel
Also, can you confirm that I can get a 3DS auth request at any tine, even for a ...
Yep, totally plausible that the bank requests auth/3DS for a charge even though the payment method was previously authenticated
Are these on/off-session payments? Is there a particular reason why you're creating a Setup Intent first?
next trout
Yes, exactly. You'd re-attempt confirmation (not sure how you're doing that) pas...
Yup, just verified that. thanks
next trout
Are these on/off-session payments? Is there a particular reason why you're creat...
Card is on record to facilitate easy payments for my customers, as they are expected to make lots of little payments over time.
Customer is on session
So I can ask them for auth
rigid tinsel
But are they providing their payment details upfront, or just during that initial payment?
next trout
Upfront
I need to verify their billing address from the credit card. It's a long story!
rigid tinsel
Have you instead considered utilising the setup_future_usage parameter during the initial payment? https://stripe.com/docs/payments/save-during-payment
next trout
In any case, I think I'm nearly there. It's a complex flow, moving between UI and back-end but I need to cope with 3DS coming up at anytime.
next trout
Have you instead considered utilising the `setup_future_usage` parameter during ...
Yes, doesn't work for multiple reasons but thanks for bringing it to my attention. In any case, later transactions can still require auth in the same way once the details are stored.
Let me take a crack at pulling this all together and I'll come back if I'm still struggling...
rigid tinsel
Sure, np!
next trout
Hi @rigid tinsel
Is there any way to check if there is an existing PI using the idempotencyKey?
If not, I will have to write the PI ID to my database, which is state I'd rather not store
It seems that if you create a PI using the same idempotencyKey, you write over the last_payment_error data, so you cant see that it failed previously
rigid tinsel
There is not, no. Generally your idempotency keys should be unique per API request (and inherently per object, too)
next trout
Really? I was using that idempotencyKey to make sure I don't bill someone twice for the same product, which sounds wrong now. Is the idempotencyKey meant to guard against network retries only?
Do PaymentIntent objects live forever once they've been created?
rigid tinsel
Yep, it's to protect against multiple charges (mostly) in event of an API issue: https://stripe.com/docs/idempotency
next trout
🤦♂️
"Do PaymentIntent objects live forever once they've been created?" <-- So, really, I need to store this somewhere to access the Stripe state machine?
rigid tinsel
Do PaymentIntent objects live forever once they've been created?
They do, yes. Their only terminal states are succeeded or canceled: https://stripe.com/docs/payments/intents
rigid tinsel
"Do PaymentIntent objects live forever once they've been created?" <-- So, real...
Well, that depends. What exactly are you trying to prevent?
next trout
Good question. It's back the the drawing board; let me have a think first...
(But in general, things like a user hitting the refresh button on the browser and losing the state)
rigid tinsel
At what stage? The checkout?
next trout
Yes, although we don't have a traditional checkout, with shopping trolley, etc. Users click a button to pay and complete 3DS if they have to.
Since this is an async process, I need to hang on to the PI ID until it completes or fails. A user can wander off and return at any time...
rigid tinsel
What's the objection to just creating a new PI?
Otherwise yes you'll likely need to persist that PI in state somewhere