The state should have changed in the database if the payment was processed successfully, and the memoized version here will not know that without a reload.
If the page is reloaded after the payment has already gone through, we can skip the processing and give a non-error response; the payment is already completed and Stripe's response confirms it was successful.
When we're fetching the payment intent via PaymentIntentValidator in StripeSCA#purhcase (to capture it), we want it to fail loudly if it's not in "requires_capture" state. We're now also re-using the same PaymentIntentValidator service to check if payment processing was *successful*, in which case we need it *not* to fail loudly if the state == "succeeded", eg != "requires_capture".
This makes them more changeable and robust. Ruby will raise
NoMethodError on typos while it'll silently create a new ivar without
us noticing. Also, in my experience, a reader method gives more room to
future refactorings and eases testing because methods are easier to
stub.
The controller already does so, then, we can pass it to the service and
avoid that extra round-trip to the DB and save some memory. Spree::Order
is a rather bulky object (God object code smell perhaps) and it'll
surely make a difference.
