Implement support for deferred PaymenIntent confirmation

[elia]

Summary

Fixes #209, Fixes #185, Fixes #190

This PR improves the payment process by replacing the double flow of Payment Intent/Setup Intent with a Payment Intent flow in a specific scenario described in the Stripe documentation:
Build a two-step confirmation experience

With the new approach, the two-step subdivision achieves the following issues:

• The creation of the Stripe payment method remains in the payment step (as before)
• The Payment intent creation will be invoked during the confirm step rendering.
• The payment authorization occurs when the order is submitted on the confirm page.

The benefits of this update include:

• Removing compromises in the payment intent flow that previously required "skipping" the confirm step due to the premature authorization executed in the payment step.
• Aligning the authorization process with the Solidus checkout flow.
• Removing the authorize and purchase methods from the gateway, as they are no longer needed.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[waiting-for-dev]

So much simpler!

[codecov]

Codecov Report

Merging #249 (1cab1dc) into master (7396336) will decrease coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #249      +/-   ##
==========================================
- Coverage   99.79%   99.77%   -0.03%     
==========================================
  Files          25       24       -1     
  Lines         487      442      -45     
==========================================
- Hits          486      441      -45     
  Misses          1        1              

Impacted Files	Coverage Δ
app/models/solidus_stripe/gateway.rb	100.00% <ø> (ø)
app/models/solidus_stripe/payment_method.rb	100.00% <ø> (ø)
lib/solidus_stripe/testing_support/factories.rb	100.00% <ø> (ø)
...p/controllers/solidus_stripe/intents_controller.rb	100.00% <100.00%> (ø)
app/models/solidus_stripe/payment_intent.rb	100.00% <100.00%> (ø)
...lates/app/views/checkouts/payment/_stripe.html.erb	100.00% <100.00%> (ø)
...tes/app/views/orders/payment_info/_stripe.html.erb	100.00% <100.00%> (ø)
lib/solidus_stripe/engine.rb	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Outdated

[kennyadsl]

Maybe spotted a method that we are not using, other than that, 👍

[waiting-for-dev]

Thanks, @elia & @rainerdema! ❤️ Left one concern about the removal of the gateway methods.

I'm also wondering if we need the SolidusStripe::PaymentIntent model at all. It's not needed from the webhook handlers, as the response_code is filled on payment intent creation. Can you help me understand? Is it only needed in the case a user refreshes the confirm page?

[elia]

I'm also wondering if we need the SolidusStripe::PaymentIntent model at all. It's not needed from the webhook handlers, as the response_code is filled on payment intent creation. Can you help me understand? Is it only needed in the case a user refreshes the confirm page?

@waiting-for-dev sorry, I merged before replying to this question. And yes, it's there to ensure we have a single payment intent for each order. As you pointed out there might be indirect ways to do the same through Payment#response_code but as we discussed when we introduced the class this way it should be more reliable.