Assess the current store credit flow

[chrean]

@rainerdema has some thoughts on how to improve the current store credit flow, which seems to be suboptimal.
He will document his ideas and share with the team.

[rainerdema]

Introduction

This document addresses the current store credit flow in Solidus and aims to propose improvements to enhance its functionality.

Assessment of the Current Store Credit Flow

I have identified certain areas of the existing store credit flow in Solidus that can be enhanced. The following points outline my thoughts on how the system could be improved. I will outline the current flow, discuss the existing issue, and present a proposed solution to address the problem:

1. Creation of Store Credits:

   • Store credits are currently included during the installation of Solidus through seeds.
   • The payment method associated with store credits is unavailable to both admins and users by default.
   • This prevents the method from appearing on the payment page and eliminates the need for a dedicated template.

2. Control and application of Store Credits:

   • Users do not have direct control over their store credits.
   • Store credits are automatically applied to orders based on availability for each user.

3. Handling orders with Store Credits:

   • Partial Coverage: When store credits only partially cover an order, the remaining amount can be paid using an alternative payment method.
   • Full Coverage: No other payment method is required with orders that are entirely covered by store credits:
     • Currently, these orders are automatically paid through a payment method called StoreCredit, which creates a separate payment record.

4. Issue with $0 Orders (Full Coverage):

   • The current flow presents a limitation where orders with a total amount of $0, covered solely by store credits, cannot be completed.
   • However, it should be noted that this limitation arises when the payment methods do not allow $0 payments (for example Stripe).
   • In general, we can notice that this specific issue is primarily occurring with Stripe, as we need to initialize elements required for rendering the payment method UI and pass the order amount to them. If the order amount is 0, it prevents the completion of the checkout process. In other cases, the payment method must be selected and filled in during checkout, but it will be invalidated when store credits are added to the order.
     Here is the point: Why do I have to select another payment method in general if store credits fully cover the order?
   • Additionally, skipping the payment step altogether with payment_required? is not a viable solution since it is necessary to authorize store credits and transition the payment state from "checkout" to "pending." This step ensures that the store credits are allocated for the specific order and cannot be used for other orders.

5. Proposed Solutions:

   • Short-Term Solution: In cases where store credits fully cover an order, no payment method should be selectable or visible. Instead, a note should be displayed to inform users that the order is fully covered by store credit.
     • This approach provides a temporary solution to the problem without requiring major changes to the payment processing flow.
     • By hiding the payment method selection, users will understand that the order is being paid solely with store credits.
   • Long-Term Solution: Enable users to choose whether or not to use store credits during the selection of payment methods.
     • Implementing a checkbox or toggle option in the payment method selection page will allow users to indicate their preference for using store credits.
     • If the store credits are not enough to cover the entire order, users can select an alternative payment method from the available options, as it currently happens.

These proposed improvements aim to address the mentioned issue and to improve the user-friendly experience for Solidus users.

cc @solidusio/core-team @solidusio/nebulab

[waiting-for-dev]

@rainerdema, thanks a lot for your investigation and your great distillation of such a complex process 🙌 Some questions to better understand:

Full Coverage: No other payment method is required with orders that are entirely covered by store credits:
Currently, these orders are automatically paid through a payment method called StoreCredit, which creates a separate payment record.

I'm a bit confused by no other payment method is required and a separate payment record. Do you mean there's also a second payment record with zero amount associated with another payment method? I think that's what you mean later when you talk about the invalidation of payment methods, right?

I completely agree with the proposed solutions. For the short-term solution, should we consider subscription scenarios, where we might still want to save payment method details for future payments, or should we leave it to the solidus_subscriptions extension?

[rainerdema]

Thanks for your questions @waiting-for-dev 🙏

Full Coverage: No other payment method is required with orders that are entirely covered by store credits:
Currently, these orders are automatically paid through a payment method called StoreCredit, which creates a separate payment record.

I'm a bit confused by no other payment method is required and a separate payment record. Do you mean there's also a second payment record with zero amount associated with another payment method? I think that's what you mean later when you talk about the invalidation of payment methods, right?

1. When I mentioned no other payment method is required and a separate payment record is created, I was explaining that when an order is fully covered by store credits, only one separate payment record is created for the StoreCredit payment method.

2. From what I remember, the invalidation of payment happens when a payment method is selected or filled during checkout, but the order is fully covered by store credits. Since the order doesn't require the created no-store-credit payment, the system invalidates it. This can be confusing, and it's one of the issues that can be addressed in one of the mentioned solutions.

For the short-term solution, should we consider subscription scenarios, where we might still want to save payment method details for future payments, or should we leave it to the solidus_subscriptions extension?

3. Regarding the subscription scenarios, while I don't have a strong opinion on this, I think it would be best to leave this to the solidus_subscriptions extension.

Moving forward, I will be opening dedicated issues related to the points discussed here.

[rainerdema]

Closing this discussion as the two issues related to the short-term and long-term solutions have now been created:

• Preventing available payment method rendering for orders fully covered by Store Credits #345
  
• Increasing user flexibility in Store Credit application during checkout #346