When an admin creates an order, then AmendBackorderJob is called which
can also trigger a new backorder if needed.
This means that we are not creating backorders via subscriptions any
more. It has never been requested and we can bring that back if needed.
Therefor, for the right controllers, simply implements:
```
include WhiteLabel
before_action :hide_ofn_navigation, only: [:show, :edit]
```
This is mort robust, since we're working in a controller level, not parsing URLs...
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...
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).
The code here runs from a callback which was originally designed to make sure the checkout page was set up correctly in the "normal" checkout workflow. It wasn't really designed to be run when the page is being loaded a second time due to the user being redirected back from Stripe (with SCA). The things it's doing here are necessary in the former case, but a really bad idea in the latter (potentially messing up the order's ship and bill addresses in certain cases like guest checkout).
A little micro-optimisation: `@order.checkout_allowed?` requires a database query, whereas `@order.completed?` does not. So in cases where the order is completed we can return early here before hitting the database.
