Allow subscribers without stored payment methods to put the draft order through checkout

Problem/Motivation

For subscriptions that aren't standalone, the initial order triggers a sequence of creating a draft order, and later closing it and creating a new draft - the renewal.

It would be nice to allow subscriptions where the store does not need to have a stored payment method. Instead, when the current term of the subscription ends - or before, the user is directed to the checkout, to pay for the next term of the subscription. This is almost possible at the moment.

There are a few problems standing in the way of this:

• Issue 1. If you go through the checkout, paying by a new payment method, your new payment method will be ignored, in favour of the payment method stored on the subscription.
• If you previously deleted any recorded payment method, this will be NULL and you will experience errors during checkout as the payment method is de-referenced. This is a knock-on from Issue 1.
• Issue 2. Because the order is not being processed through cron, one the draft is completed, there is no refresh triggered, and consequently no draft is set up for the following period.
• Issue 3. Specifically, if you use Stripe as your payment gateway, if you are able to complete the order, you will find that despite having made a payment, and the payment being recorded, the order will be marked as 'needs payment'. This issue is not dealt with here.

Steps to reproduce

• As a logged in user, buy a subscription. Note the internal order_id number - i.e. the checkout order number.
• Having bought the subscription go to the URL /checkout/{order_id+1} . You will be viewing the draft in the checkout.
• Complete the checkout, noting the problems listed above.
• Delete your payment method from the first step, accessible from your user profile, to generate an error when going to the Review page.

Proposed resolutions

Issue 1 - checkout payment info is overwritten

Whenever the order is refreshed, as a recurring order, the payment method and payment gateway are reset using the subscription as the source, overriding any values set in the checkout.

src/RecurringOrderManager.php, in function refreshOrder, lines 105-112:

    $subscriptions = $this->collectSubscriptions($order);
    $payment_method = $this->selectPaymentMethod($subscriptions);
    $billing_profile = $payment_method ? $payment_method->getBillingProfile() : NULL;
    $payment_gateway_id = $payment_method ? $payment_method->getPaymentGatewayId() : NULL;

    $order->set('billing_profile', $billing_profile);
    $order->set('payment_method', $payment_method);
    $order->set('payment_gateway', $payment_gateway_id);

Proposed solution: Introduce a test to distinguish between recurring order refresh during checkout and other times, and do not alter payment method or gateway during checkout. More below.

The code would become something like:

   $subscriptions = $this->collectSubscriptions($order);
    $payment_method = $this->selectPaymentMethod($subscriptions);
    $billing_profile = $payment_method ? $payment_method->getBillingProfile() : NULL;
    $payment_gateway_id = $payment_method ? $payment_method->getPaymentGatewayId() : NULL;

    $order->set('billing_profile', $billing_profile);
    // When in the checkout, do not override user input with info held on the subscription
    if ($this->route_match->getRouteName() !== 'commerce_checkout.form') {
      $order->set('payment_method', $payment_method);
      $order->set('payment_gateway', $payment_gateway_id);
     }

Issue 2 - refreshing

A refresh is never triggered because the order is not in draft state, and cron checks for draft before enqueing the order for close and refresh.

Proposed solution:
When a recurring order is paid, through the checkout, enqueue a renewal.

Alternatively, and perhaps better because it would match the architecture for ordinary renewals, a cron task to find active subscriptions where there is no draft. For these a renewal would be enqueued. This also has the advantage that if the draft is deleted for other reasons, then a new one is created.

Remaining tasks

• Currently the refresh is decoupled from the route. Adding a direct check on the route works to decided between whether to override the order with subs data or not, but we have to pass in the RouteMatcher as part of the RecurringOrderManager set up. Instead we could add a parameter to refresh, to tell it to override payment method info or not, with a default of overriding, and instead make the OrderProcessor pass this info, and have that dependent. I think I prefer passing RouteMatcher into the service.
• Potential issue: someone uses the checkout at the same time as the order is automatically processed, if an existing card is on file. I don't think we'd get deadlock, but there might be some surprise for the user if they are in the checkout, and suddenly the order is complete. I think this can be dealt with in dunning email that the user sees - either don't link to checkout, or warn of a potential issue.
• I think we want to retain the billing profile on the subscription. I have not yet investigated.

User interface changes

None - the checkout is already available for the draft.

There is an Issue to make it not available to users, but that issue suggests it is available to all users on all orders. This is not the case for my testing.

API changes

TBD. Probably none.

Data model changes

None.