RFC: Overhauling solidus_stripe

[elia]

Problem

The current implementation is very old:

• It's jQuery based
• it's solidus_frontend based
• it's supporting 3 types of integrations + configurations with a high number of total combinations
• no support for non-credit-card payments (e.g. ApplePay, etc)

Proposal

We want to overhaul the extension and at the same time drop support for the legacy frontend, moving to a more scaffolding based installation (vs. view/controller inheritance).

Ruled-out approaches

• We considered updating the existing extension to work with SSF first, and then cleaning it up, but we concluded that the effort would have increased
• We considered cleaning up the extension before adding to SSF support, and then switching to the Payment Element, but that too would have needed more effort
• We considered starting with Stripe Checkout, but that would have disrupted the current setup too much (maybe can be a feature added in the future)*

Plan

• [ ] Start from scratch using the current extension only as a reference and cherry pick code (vs copying everything and then cleaning up)
• [ ] We want to start from the Payment Element which comes with support for multiple payment methods, while still working well in the classic step-based checkout featured in SSF (vs. switching to the fully external Stripe Checkout)
• [ ] The new implementation will be tested with the approach featured in https://github.com/solidusio/solidus_paypal_commerce_platform/pull/166 with a full-fledged dummy-app

---

*Stripe Checkout is an extremely optimized checkout solution and we might want to add support to it in the future. Since it includes a lot of new required functionality (webhooks, possibly syncing Product and other information with Stripe) we considered this out of scope for the overhaul.

[elia]

In case external payments will need additional support from routes (e.g. ApplePay/GooglePay allowing to change the address) that will be dealt with in further versions.

[elia]

After a live discussion on this with a few core-team members from @nebulab no objections were raised, closing and proceeding to create more detailed issues.