cosoare

[spice pagoda]

Personally I would say that is not the case since each PaymentIntent is unique, so as long as TLS is enabled, an attacker would not be able to tamper with someone else's payment
Not necessarily true. With the pi_foo_secret_bar and your pk_xxx key (which is accessible client-side), a malicious party could attempt payment confirmation.

The worst an attacker can do is call our API to generate PaymentIntents.
If that's the case then you have bigger issues as they'd have access to your secret key.

Which is why we don't recommend logging/storing the PI secrets and only persisting them in local state

But it's integral to a custom payment flow that the pi_foo_secret_bar is sent back to your client-side code, yes. Nothing alarming about that in itself

[stiff orbit]

Thank you for the reply. Let me try to answer per message:

[stiff orbit]

Unless we log the pi_foo_secret_bar or expose it to the world, the client would be the only person to have access to this key, unless their browser has been tampered with (ie. a key logger exists). Correct?

[stiff orbit]

The Secret key would be stored as an ENV variable, how would they have access to the key?

[spice pagoda]

They shouldn't, but you said 'worse case they call the API to generate Payment Intents', which is only possible with a secret key (not a publishable key).

[spice pagoda]

Correct, yes.

[stiff orbit]

Sorry, I meant they call our API, say POST /payment-intents (which on the backend uses the SK to call Stripe to create a PI)

[spice pagoda]

Does that clear up any confusion?

[stiff orbit]

It does. Thank you