Andrzej

[faint bridge]

Hi 👋
We recommend confirming directly on the client-side using this approach:
https://stripe.com/docs/payments/save-and-reuse

And when we receive a card_declined message from the bank we include a decline_code that should indicate the reason the card was declined so you can take action based on that.
https://stripe.com/docs/error-codes#card-declined

[true crescent]

Thanks 👍 So since confirming on the client is recommended then it is also considered OK (security wise) to send send a setupIntentId to a signup endpoint on my server?
That list of error codes is huge. Is there any guide/dictionary telling which codes we should treat as "hard declines"? (to not attempt another charge)

[faint bridge]

That's just the error code, the decline_code is what you'll want to examine.

Your server creates the Setup Intent so it should already have the ID

[true crescent]

The list of decline codes https://stripe.com/docs/declines/codes is still quite long 🙂 I was hoping for a shortcut.

Yes server creates it, but to know that ID on the signup call I'd have to store that in session (which could be a problem if I have multiple servers) or create a nonce and store it in the database on my own.

[daring silo]

👋 stepping in as Snufkin needs to step away

Yeah using cookies here is mostly the recommended way to handle the user and sign up flow

There isn't a shorter doc for decline codes.

[true crescent]

Ok got it. The only quick way out I can see is confirming the setupIntent on the server then, but I am guessing it is a problem because client might need to take additional steps (3DS, verification code etc.). Correct?

[daring silo]

I don't really understand. Why can't you confirm on your client?

[true crescent]

I can, and that's what I started with. Just looking for the optimal and secure flow. The problem: either I need to pass the setupIntentID to signup call (which feels a bit insecure - someone could try to steal/guess the setupIntentId to signup with someone else's card) OR I need to store that setupIntentId in session/DB. Session is problematic in multi-server environment and DB is just additional overhead. You say cookies is recommended, that basically means the session, am I right?

[daring silo]

How are you going to store the user without a DB? You are going to just lean on Stripe objects and metadata? And, can you explain more what you mean with "someone could try to steal/guess the setupIntentId to signup with someone else's card"? How would accessing the SetupIntent ID itself allow someone to access another customer's card details?

[true crescent]

I didnt say I dont have a DB. In my current setup I collect user payment details which are tokenized into a nonce (by the payment provider) which I can use just once in my signup endpoint. Then I create user in my DB and the nonce identifies the credit card - so I can create customer, payment method etc. with the payment provider and then bind it with my user. If I open up the signup endpoint to accept a setupIntentID (instead of a nonce or some kind of on-time-use secret) then it opens an attack vector. Attacker won't access any card details but potentially he could create an account with that setupIntent as payment method (unless I additionally validate it). So basically a nonce is more secure, that's why I though about using client secret in the signup endpoint. That's at least how I see it and am seeking advice on how to solve this best.

[daring silo]

Ah okay I see, you are multiprocessing it sounds like

[true crescent]

Sorry, I need to run. Will this thread live until tomorrow so I can take a look if there are any updates?

[daring silo]

You can pop back in tomorrow and continue discussing — someone on my team will be around. Overall my recommendation is to use your database here.