ご返信ありがとうございます！

> よくある決済の流れとしては、ShoppingController::checkoutの後に
> クレジット情報の入力画面を表示しているのではないかと思います。
> （ECCUBE上にはステータス：決済処理中の受注データが登録される）

おっしゃる通り、たしかによく見かけますね。
EC-CUBEの処理を(決済処理中として)全て完了させてから
クレジットカード番号の入力を行うのですね。

うーん、、、
在庫を確保してから、ユーザー操作(クレジットカード番号入力)が入ってしまうと
そこで操作を止められると、在庫が減ったまま受注が完了しない状態になってしまうので
在庫の少ない商品の取り扱いにおいては辛いかなーという気持ちがありました。

ただ、468様からいただきましたヒントによって、当初考えていた
ShoppingController::checkout処理のエラー時に、決済処理をrollbackするアプローチが現実的ではないことがわかりました。
ありがとうございます。

まだ実装していないので、本当にできるかはわかりませんが
今回利用する決済サービス「Stripe」においては、クレジットカード情報を事前に(Stripeの)Customer情報に結びつけて
カード情報をStripe上のID(カードトークンと呼称します)として取り扱うことができる機能があることがわかりました。

これによって、下記のようなフローでユーザー操作を挟ませずに、決済処理が完了できそうです。

1. 注文確認画面でクレジットカード情報を入力してもらい、サーバーを介さずに事前にStripeのCustomerに関連付ける
2. カードトークンをOrderに保持
3. ShoppingController::checkout が正常終了したEventで、カードトークンで決済処理を実行する

※ ShoppingController::checkout が正常終了したEventについては見つかりました
- EccubeEvents::MAIL_ORDER (リダイレクトを挟まない分、こちらが適切かも)
- EccubeEvents::FRONT_SHOPPING_COMPLETE_INITIALIZE

一旦このアプローチでの実装を試みてみます。
ご相談に乗っていただきありがとうございました！