プラグイン > 開発について > 購入フローのerror, rollback処理はどこに実装するのが適切でしょうか |
開発について
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
sheep |
投稿日時: 2021/11/7 15:42
対応状況: 解決済
|
半人前 登録日: 2018/8/12 居住地: 投稿: 14 |
購入フローのerror, rollback処理はどこに実装するのが適切でしょうか [EC-CUBE] 4.1
こんにちは。 現在決済プラグインを独自で制作中です。 [実現したいこと] ShoppingController::checkout において validate, apply, checkout と処理が流れていきますが この流れの途中でエラーが発生した時に、独自のrollback処理を実装したいです。 クレジットカード情報をサーバー経由させないように 注文確認画面のsubmit(注文確定)のタイミングで、下記のような流れで処理を行おうと考えております。 1. 外部決済サービス(Stripe)のAPIを利用して、仮売上として売上を立てる 2. EC-CUBE注文確認画面をsubmitする(ShoppingController::checkoutが実行される) 3. 手順2でエラーが起きた際に、手順1の仮売上をキャンセルする(Order情報があればキャンセル手続きができます) [試したこと] ShoppingController::errorのイベントである「EccubeEvents::FRONT_SHOPPING_SHIPPING_ERROR_COMPLETE」では cartServiceからOrder情報が取れないので、適切ではなさそうでした。 では、PurchaseProcessorを実装して、rollback関数に実装すれば良いのかな?と思ったのですが 例えば在庫が足りない時などには、このrollback関数に辿り着く前に、購入手続きのwarningに戻ってしまいます。 では、ItemHolderValidatorを拡張して、handle関数に実装すれば良いのかな?と思ったのですが 在庫が足りない時には、StockValidatorのhandle関数が実行されるだけで、自作のItemHolderValidatorのhandle関数は実行されませんでした。 私の想像できる限りのことは試したつもりですが、、、、、 正解に辿り着けなかったので、もし知見を持った方がいらっしゃればと質問させていただきました。 何卒、よろしくお願いいたします。 |
468 |
投稿日時: 2021/11/8 10:28
対応状況: −−−
|
神 登録日: 2008/10/26 居住地: 投稿: 3217 |
Re: 購入フローのerror, rollback処理はどこに実装するのが適切でしょうか 他社決済プラグインの仕様を確認されてみては如何でしょうか?
よくある決済の流れとしては、ShoppingController::checkoutの後に クレジット情報の入力画面を表示しているのではないかと思います。 (ECCUBE上にはステータス:決済処理中の受注データが登録される) 一旦、在庫を確保してからクレジット入力を行う形にする事によって 決済後の在庫不足を防ぐ仕組みになっていると予想します。 このフローを変えるのはプラグインだけでは難しいのではないでしょうか?
|
sheep |
投稿日時: 2021/11/8 17:46
対応状況: −−−
|
半人前 登録日: 2018/8/12 居住地: 投稿: 14 |
Re: 購入フローのerror, rollback処理はどこに実装するのが適切でしょうか ご返信ありがとうございます!
> よくある決済の流れとしては、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 一旦このアプローチでの実装を試みてみます。 ご相談に乗っていただきありがとうございました! |
468 |
投稿日時: 2021/11/8 19:09
対応状況: −−−
|
神 登録日: 2008/10/26 居住地: 投稿: 3217 |
Re: 購入フローのerror, rollback処理はどこに実装するのが適切でしょうか >在庫を確保してから、ユーザー操作(クレジットカード番号入力)が入ってしまうと
>そこで操作を止められると、在庫が減ったまま受注が完了しない状態になってしまうので >在庫の少ない商品の取り扱いにおいては辛いかなーという気持ちがありました。 ここについてはお店の扱う商材や形態によるところがありますので何とも言えませんが 余計なトラブルを避ける形にしているのだと思います。 例えば、高級ブランドバッグの中古品を販売しているようなお店で お客さんが10万円の金額を決済した後、在庫が無い事が発覚し後からキャンセル処理を行った場合、 ショップには売上は入ってきませんが ショップから決済代行会社への10万円×数パーセントの手数料の支払いは発生する事になると思います。 (利用するサービスや契約次第とは思いますが よくあるサービスだと決済時に手数料が発生すると思います) 滅多に発生しない事かと思いますが その辺りが許容できるかどうかという事になるかと思います。
|
sheep |
投稿日時: 2021/11/8 20:16
対応状況: −−−
|
半人前 登録日: 2018/8/12 居住地: 投稿: 14 |
Re: 購入フローのerror, rollback処理はどこに実装するのが適切でしょうか ご返信ありがとうございます。
前回の私の投稿の意図が分かりづらく申し訳ございません。 468様のおっしゃる通り、在庫がない時にエラーになることは必須だと私も考えております。なので、ShoppingController::checkoutが正常終了してから決済処理を行うことにも同意です。 その上で、 checkout正常終了後にクレジットカード情報を入力するフローに進むとユーザー操作が間に入ってしまって、サイト離脱等により在庫が余計に減ってしまうリスクがあるため、避けたいと考えています。 (Stripeの機能により)事前にクレジットカード情報は入力してもらっておいて(そのクレジットカード情報はStripe側に保存してある状態で)、checkout正常終了後のEvent内で決済の完了まで処理を終えることができれば、ユーザー操作が間に入らないため、余計な在庫減少のリスクを最小限に抑えることができるかもしれない、という期待を胸に実装を進めてみます、という意図のご返信でした。 |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |