#heka6

1 messages · Page 1 of 1 (latest)

tender narwhalBOT
proper drift
#

Hello 👋
Can you share an example payment where you saw this?
I wasn't aware of idempotency key conflicting with 3DS

gloomy aspen
#

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

#

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

proper drift
#

When you say enable retries, you're creating new PaymentIntents

You should really just attempt to confirm the same PaymentIntent instead

gloomy aspen
#

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

proper drift
#

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)

gloomy aspen
#

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

proper drift
#

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

gloomy aspen
#

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

proper drift
#

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

gloomy aspen
#

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