Security reinforcement on Order::recalculate() - Add Event before beforeCompleteOrder to allow custom validations before payment

[francoislevesque]

We built a custom ShippingAdjuster to get live rates accross multiple carriers. Almost all actions on a Cart invovles a recalculation. To speed things up, we used an intelligent caching solution to avoid fetching the same live rates multiple times.
However, if the shipping address is changed, or if our cache expires (which happens after 2 weeks in our case), the recalculation process calls our live rate API again. Moreover, simply adding an item to a cart takes around 10-15 seconds since it calls the adjust() method...

To avoid this issue/latency, we only want to fetch live rates at specific moments: after entering the shipping address, after chosing a carrier and after completing a payment. We added an hidden input on these specific steps to perform a live rate API call. This is a solution proposed by the excellent package by Verbb : https://github.com/verbb/postie (see: https://verbb.io/craft-plugins/postie/docs/setup-configuration/manually-fetching-rates)

shipping.twig

<form method="POST" accept-charset="utf-8">
  {{ csrfInput() }}
  {{ actionInput('commerce/cart/update-cart') }}
  {{ redirectInput('shop/checkout/payment') }}
  
  <input type="hidden" name="refreshLiveRates" value="1" />
   ...
</form>

ShippingAdjuster.php

private function getLineAdjustment(Order $order, LineItem $lineItem, Variant $variant): ?OrderAdjustment
{
    $refreshRates = Craft::$app->request->getBodyParam('refreshLiveRates', false);

    if (!$refreshRates) {
        return $this->getCachedLineAdjustment($order, $lineItem, $variant);
    }

    return $this->getNewLineAdjustment($order, $lineItem, $variant);
}

This works, but is not secure. In theory, a malicious user could remove the refreshLiveRates input to keep using old shipping rates, or event worse, complete an Order withtout rates.

We tried validating the presence of rates on LineItems using beforeCompleteOrder, but this event is fired after a payment attempt was made, so this is not ideal.

We are completely bypassing ShippingMethods, thus using requireShippingMethodSelectionAtCheckout wont work for us.

Proposed change

Option 1) Adding an Event right before the payment attempt. Somewhere around PaymentController@actionPay line 363. Adding an event in a controller might not be the cleanest solution though...

Option 2) Adding some kind of flag on the order. For example: $order->willBePaid, or $order->beforePayment, etc.

I understand my proposed changes may be useless. If there's already a solution to my problem, some guidance will be greatly appreciated!

Thank you!