#Reduviidae
potent frigate
near obsidian
Does that make sense? It just seems like it would be possible for a bad actor to create an inconsistency between the cart state from when the PaymentIntent was confirmed on the front-end, by quickly submitting another request before the back-end receives notice of the payment intent being successfully processed.
magic oriole
It depends on how your system is set up. I personally wouldn't build anything that relies on the state of a cart after the submission of payment details. I would just cache the cart as an object in the database along with the relevant customer information and then clear their cart for them in the browser
near obsidian
When you say you "wouldn't build anything that relies on the state of a cart after the submission of payment details" are you referring to front-end, back-end, or both? I'm mostly focused on the backend, so I am already storing the cart in the database.
sage ermine
You want to "commit" the cart as the point when you confirm the payment for the specific amount of the total of the cart items
Ideally your UI would block any front end changes to the cart after the customer clicks "buy" until the response is received, etc
near obsidian
To be a little more clear, this is the sequence I'm imagining
I'll admit, for the final change of the cart, I'm considering someone intentionally trying to cause issues, using manual requests (eg, through cURL) to circumvent front-end validation.
sage ermine
Then I'd say you should discard those, but thats up to you
When the confirmation happens you can also signal your server to "lock" your order/cart abstraction
(or just before calling the confirm method)
near obsidian
Hmm, okay, that makes sense.