Documentation for the standard checkout flow is provided. How does this change when using Stripe payment intents particularly in regards to the expectations of the order state machine? It seems the intention of stripe payment intents is to: 1. Create the intent on the backend 2. Pass the intent secret back to the frontend 3. Frontend attempts to confirm and charge the intent to Stripe directly. 4. Backend receives webhook for charge success.. 5. Anyting else (attaching payment method to customer to make reusable), etc.. How does this work with the standard Solidus state machine? When the payment is in the order transitions to the payment state, is an intent automatically created? What is the role of the confirm state? How payment intents changes the standard flow might be good to list in the documentation for the solidus_stripe gem.

Might be a question for @elia!

Thanks for the ping @alessandro 🙏 @Kevin I this was confusing to me as well initially, but I think it can be clarified if we think of fulfillable orders those that were both “completed” and have no outstanding balance. The checkout process kind of fakes the need for a payment but technically an order could complete without one. If the payment fails then the order will keep having an outstanding balance and the order won’t be fulfillable. The extreme cases of this include banking related payments that can take several days before providing an answer. Hope this covers the initial questions, otherwise I’m happy to go into more detail 👍

Thanks for the feedback @elia. What scope do you typically use for determining if you should fulfill an order in this case? Additional questions, are there any limitations to which digital wallets can be used with the Stripe Web Elements payment element when using stripe_solidus with the two-step confirmation flow which the documentation says it's set up for by default?

From the code I think the scope would be

Spree::Order.where(state: 'complete', payment_state: 'paid')