#heka6
1 messages · Page 1 of 1 (latest)
Hello 👋
Can you share an example payment where you saw this?
I wasn't aware of idempotency key conflicting with 3DS
not really conflicting
it is just that if I create a payment intent with a key being: "ABC123" and payment fails
then if I resubmit a payment with the same key, I will get the same fail
which is normal
but i want to enable retries
but want to block double payments
Here is a failed intent
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
my idempotency key was: '15491ed2-4c91-4c13-a62b-422aeb04076d-xyqzbA'
so now let's say customer tries again with a new card
my idempotency key being a compiste between merchant ID - order ID
new intent will fail too
because I use the same key
normal
When you say enable retries, you're creating new PaymentIntents
You should really just attempt to confirm the same PaymentIntent instead
I wanted to know if there was a way to prevent payment to be taken twice for the same key, but allow retries
Here I was creating a new one indeed
can we search intents per idempotency_key?
so if the key exists already we confirm>
?
or should we store that?
elsewhere
You can store it on your end I believe. there's no way to retrieve the PaymentIntents using that.
What happens is when you make a request to stripe with an idempotency key, I believe we store that for upto 24 hours before pruning. This allows us to handle duplicate requests.
So if you make a request with the same key again, you receive the same cached response as the initial request (so you're not actually attempting a new payment if you re-use the same key, its the same decline from before)
It works exactly as it should. I am just trying to kill 2 birds with one stone...
not sure I will find a way without storage
I'm confused as why do you think it is preventing retries.
You created a PaymentIntent, provided a payment method server-side and attempted to confirm it which failed and PaymentIntent transitioned to requires_payment_method.
In order to retry, you don't really create a new PaymentIntent again right? You instead would need to call /confirm with the same payment method OR bring the customer back on session and confirm with new PaymentMethod information client-side
For the retry I was creating a new one
if we confirm with new PaymentMethod information client-side, we still can't use the same idempotency key
but with my logic it would be the same
but I just made tests from simple python calls
I will deep dive
if we confirm with new PaymentMethod information client-side, we still can't use the same idempotency key
Why exactly? as far as I know, client-side SDK doesn't really let you configure idempotency key
correct
the idempotecy would be set backend
again
no prob if we confirm the previous intent
the issue comes from the fact we create a new one I think
so you are correct
I will check this
I was just trying to find a way out without changing this
kind of quick win
thanks a lot