The various places where we "reset" an order to cart state if a checkout submission does not succeed are an artifact of the process-all-the-steps-at-once approach of the current checkout.
We need to separate some of these bits to make them easier to call in different contexts. Also there's some weird stuff happening here with the controller being passed in to the service, and it seems like a code smell to me...
StripeConnect has been replaced by StripeSCA but some people still use
the old StripeConnect. Let's prevent people from creating deprecated
payment methods before migrating existing data.
params[:token] and session[:access_token] are only really used in the context of guest users in the customer-facing parts of the app. Here the user should be fully authenticated already to view the page. There aren't any URL that point at this controller which append a token to the params.
There seemingly shouldn't be any case where this controller actually receives a token param. There's only one place that creates urls that direct to this controller (Stripe authorization emails), and they do not attach any kind of token to the URL.
If the user is not logged in here (or doesn't have an access_token in their session), they get asked to log in.
Note to future devs: see previous commit for additional context.
There are 4 or 5 different places in the app where we reference a :token and params[:token] for completely different purposes (they're not even vaguely the *same* token).
This is an attempt to clarify the places in the app where we use params[:token] in relation to *orders*, for allowing guest users (who are not logged in) to view details of an order they have placed (like after checkout completion), and differentiate it from the various other places where params[:token] can actually be used for something entirely different!
The (potential) unhappy code path here was raising an error which would not be explicitly handled, and would in theory not return a useful message / response.
The checkout was holding a lot of responsibility for knowing which kinds of payment gateways are available and how to initiate the process of redirecting to the external payment page (if needed). This was being hidden somewhat by the way the logic was tucked away in services.
PaymentMethod objects now know whether or not they require an external payment process, and know how that process should be started and how to build the required URL.
So we can now *ask* any payment method if it requires external payment processing or not, and *tell* it to start the process and return the relevant URL (if needed).
This construct was previously used in Spree to switch out the user class with a dummy class during certain tests. We don't use this any more, so it's just mess.
🔥
