バージョン選択

フォーラム

メニュー

オンライン状況

26 人のユーザが現在オンラインです。 (16 人のユーザが フォーラム を参照しています。)
登録ユーザ: 1
ゲスト: 25
umebius もっと...

サイト内検索

 > フロント機能 > 決済モジュール使用時の挙動について

フロント機能

新規スレッドを追加する

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
nanasess
投稿日時: 2010/10/15 10:59
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2127
決済モジュール使用時の挙動について
現在, ページ間遷移方法の改善を行っています.

http://svn.ec-cube.net/open_trac/ticket/783

これにより, ページの有効期限切れなど, 多くの問題が改善されると思います.

従来の実装では, 決済モジュールを使用した場合に, 以下のような問題がありました.

* 決済完了後, dtb_order テーブルにデータが登録されるモジュールの場合, 途中で離脱した場合など, 決済システムでは決済完了だが, EC-CUBE では受注が登録されない問題が発生する

* 受注の業務処理が抽象化されておらず, 決済モジュール側で独自に実装する必要がある
* 決済システムから EC-CUBE に戻る処理が考慮されておらず, 実装が困難

これらの問題に対応するため, 以下のような仕様を考えました.

■ 従来

 1. shopping/confirm.php で確認
 2. load_payment_module.php で決済モジュールの呼び出し
 3. 決済処理
    - 別サイトへ遷移する場合あり
 4. shopping/complete.php で購入完了
    - dtb_order へ登録
    - 受注メール送信など


■ 新仕様

 1. shopping/confirm.php で確認
 2. load_payment_module.php で決済モジュールの呼び出し
    - この時点で, dtb_order へ「購入情報を登録」する
 3. 決済処理
    - 別サイトへ遷移する場合あり
 4. load_payment_module.php へ戻ってくる
    - dtb_order を「購入完了のステータス」に更新
    - 受注メール送信など
 5. shopping/complete.php で購入完了
    - 購入完了画面の表示のみを行う


受注ステータスに「未決済」などのステータスを設け, 決済処理の前に dtb_order へ「購入情報を登録」しておくことで, 受注漏れを無くします.
load_payment_module.php で, 戻りの処理を考慮することにより, リンク式決済の実装を容易にします.
また, 受注の業務処理は, SC_Helper_Purchase クラスなどに抽象化し, 決済モジュール側で処理できるようにします.
shopping/complete.php には GET で遷移し, 購入完了画面の表示のみを行うのがポイントです.

ご意見, ご要望などありましたら, よろしくお願いします!
patapata
投稿日時: 2010/10/15 12:06
対応状況: −−−
仙人
登録日: 2010/7/7
居住地: 神奈川県
投稿: 502
Re: 決済モジュール使用時の挙動について
あまり深くまで理解していませんが・・・

1.
決済画面にて×ボタンで強制終了された場合、判別する手段を設けないと厳しい気がします。

たとえば、
・決済画面への遷移で、ユニークなパラメータをセッションまたはDBに保持
・決済完了時、load_payment_module.phpでパラメータによる一致の確認
とか?セッションは危険かな・・・

2.
購入完了のステータスが未決済なものをいつ削除するか?
セッションエンド?管理者まかせ?期間指定?
↑未決済ステータスの受注として残すのであれば、カード決済等で
かなり頻発するように思うのでコレ重要です。

未決済として最終的に残すものは、決済完了時にエラーが出たときのみ。後は、なるべく削除って形にもってかないと、わけわからなくなる恐れがあるかと。

3.
懸念:購入完了ステータスの追加により、他の関連モジュールの改造と足並みを揃えないと、未決済のものをSELECTしまくるんじゃないかなぁ?とか・・・

4・
トランザクションの対象はどこからどこなのか?
(ちょっと気になります)
nanasess
投稿日時: 2010/10/15 15:16
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2127
Re: 決済モジュール使用時の挙動について
ご意見ありがとうございます.

引用:

patapataさんは書きました:
あまり深くまで理解していませんが・・・

1.
決済画面にて×ボタンで強制終了された場合、判別する手段を設けないと厳しい気がします。

たとえば、
・決済画面への遷移で、ユニークなパラメータをセッションまたはDBに保持
・決済完了時、load_payment_module.phpでパラメータによる一致の確認
とか?セッションは危険かな・・・


決済サイトによっては, ユニークなパラメータを保持できない可能性もありますので, 厳密な判断は難しそうです...

引用:

2.
購入完了のステータスが未決済なものをいつ削除するか?
セッションエンド?管理者まかせ?期間指定?
↑未決済ステータスの受注として残すのであれば、カード決済等で
かなり頻発するように思うのでコレ重要です。

未決済として最終的に残すものは、決済完了時にエラーが出たときのみ。後は、なるべく削除って形にもってかないと、わけわからなくなる恐れがあるかと。


cron が使えないサーバーも考慮する必要があるので, 管理者まかせにするのが現実的かと思います.

引用:

3.
懸念:購入完了ステータスの追加により、他の関連モジュールの改造と足並みを揃えないと、未決済のものをSELECTしまくるんじゃないかなぁ?とか・・・


2.5 で, 従来の決済モジュールは使用できなくなりますので, 新しい仕様で再構築することになります.

引用:

4・
トランザクションの対象はどこからどこなのか?
(ちょっと気になります)


次画面や決済サイトへの遷移を跨ぐ排他処理は, あまり現実的ではないので, 1画面単位と考えています
patapata
投稿日時: 2010/10/22 22:41
対応状況: −−−
仙人
登録日: 2010/7/7
居住地: 神奈川県
投稿: 502
Re: 決済モジュール使用時の挙動について
決済モジュールの動作について。
少しもぐってみて、早急な対処が必要なことがわかりました。

1. shopping/confirm.php で確認
 →ユニークパラメータを保持
2. load_payment_module.php で決済モジュールの呼び出し
 →1で保持した、パラメータの整合をチェック
  →DBに仮登録
   →可能であれば決済処理にユニークなパラメータを送信
3. 決済処理
- 別サイトへ遷移する場合あり
4. load_payment_module.php へ戻ってくる
 →1で保持したユニークパラメータを返せる場合は、その整合をチェック
→ユニークパラメータを返せない場合は、新たなユニークを発行
→決済処理のパラメータの整合をチェック
5. ????.php
→4で保持しているユニークパラメータの整合をチェック
  →DBに本登録・受注メール送信
6. shopping/complete.php で購入完了
- 購入完了画面の表示のみを行う(失敗も含めて、購入処理としての結果を表示する)

また、1〜6の流れ全てで、前回ページURLが正しいかの整合を行う。

このくらいやらないと片手落ちになるかと。

また、仮登録としてのDB保存は、既存dtb_orderテーブルにステータスを追加するのではなく、新たにテーブルを作成し、本登録としてdtb_orderをそのまま流用すれば、別途関連モジュールとの整合が取りやすいかと思われます。

いかがでしょうか?
nanasess
投稿日時: 2010/10/25 10:02
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2127
Re: 決済モジュール使用時の挙動について
ご意見ありがとうございます!

引用:

patapataさんは書きました:
決済モジュールの動作について。
少しもぐってみて、早急な対処が必要なことがわかりました。

1. shopping/confirm.php で確認
 →ユニークパラメータを保持
2. load_payment_module.php で決済モジュールの呼び出し
 →1で保持した、パラメータの整合をチェック
  →DBに仮登録
   →可能であれば決済処理にユニークなパラメータを送信
3. 決済処理
- 別サイトへ遷移する場合あり
4. load_payment_module.php へ戻ってくる
 →1で保持したユニークパラメータを返せる場合は、その整合をチェック
→ユニークパラメータを返せない場合は、新たなユニークを発行
→決済処理のパラメータの整合をチェック
5. ????.php
→4で保持しているユニークパラメータの整合をチェック
  →DBに本登録・受注メール送信
6. shopping/complete.php で購入完了
- 購入完了画面の表示のみを行う(失敗も含めて、購入処理としての結果を表示する)

また、1〜6の流れ全てで、前回ページURLが正しいかの整合を行う。

このくらいやらないと片手落ちになるかと。


できれば厳密にチェックしたいのですが, 厳密にすればするほど, 環境によっては単純に動かなくなるので難しいところです.
決済モジュールを設置するのが技術者の方ばかりなら良いのですが, そうではないので...

また, 前回ページの URL チェックは, ブラウザの「戻る」ボタンとの整合性が難しいので, 「自サイトか否か」のチェックくらいが良さそうです.

引用:

また、仮登録としてのDB保存は、既存dtb_orderテーブルにステータスを追加するのではなく、新たにテーブルを作成し、本登録としてdtb_orderをそのまま流用すれば、別途関連モジュールとの整合が取りやすいかと思われます。

いかがでしょうか?


dtb_order_temp とは, また別にテーブルを作成する感じでしょうか?
patapata
投稿日時: 2010/10/25 12:34
対応状況: −−−
仙人
登録日: 2010/7/7
居住地: 神奈川県
投稿: 502
Re: 決済モジュール使用時の挙動について
引用:

できれば厳密にチェックしたいのですが, 厳密にすればするほど, 環境によっては単純に動かなくなるので難しいところです.
決済モジュールを設置するのが技術者の方ばかりなら良いのですが, そうではないので...

厳密にできていないものを安易に設置ができてしまう方が問題だと思われます。

引用:

また, 前回ページの URL チェックは, ブラウザの「戻る」ボタンとの整合性が難しいので, 「自サイトか否か」のチェックくらいが良さそうです.

ブラウザの「戻る」は、厳密な処理をする場所では鬼門です。
こういった重要な箇所の場合、「戻る」は無効とさせていただく方向のほうが安全ですので無理に対応する必要はないかと思われます。
むしろブラウザの「戻る」チェックをして、「戻る」を使用した場合、無効処理に流した方がよいかと思われます。

ユーザにとっても運営者にとっても、購入処理というのは一番重要な箇所です。安全性がなによりも問われ、利便性の考慮は、二の次でよいと思われます。

引用:

dtb_order_temp とは, また別にテーブルを作成する感じでしょうか?

そういえば、既にありましたね。存在を忘れてました。
それをもう少しうまく利用すれば、仮にステータスを追加する場合でもdtb_order_tempの方に追加し、完了ステータスが立っているもののみdtb_order,dtb_order_detailに流してあげればいいのではないでしょうか?
nanasess
投稿日時: 2010/10/25 23:25
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2127
Re: 決済モジュール使用時の挙動について
引用:

patapataさんは書きました:

厳密にできていないものを安易に設置ができてしまう方が問題だと思われます。


おっしゃる通りなのですが, このあたりの方針に関しては株式会社ロックオンさん判断ですね...

引用:

ブラウザの「戻る」は、厳密な処理をする場所では鬼門です。
こういった重要な箇所の場合、「戻る」は無効とさせていただく方向のほうが安全ですので無理に対応する必要はないかと思われます。
むしろブラウザの「戻る」チェックをして、「戻る」を使用した場合、無効処理に流した方がよいかと思われます。

ユーザにとっても運営者にとっても、購入処理というのは一番重要な箇所です。安全性がなによりも問われ、利便性の考慮は、二の次でよいと思われます。


デフォルトで戻るボタンを無効にしてしまうと, それによる機会損失が計り知れませんので反対です.
もし無効にしたい場合は, 個別のカスタマイズで対応するなり, パラメータ等で対応するのが良いと思います.

引用:

そういえば、既にありましたね。存在を忘れてました。
それをもう少しうまく利用すれば、仮にステータスを追加する場合でもdtb_order_tempの方に追加し、完了ステータスが立っているもののみdtb_order,dtb_order_detailに流してあげればいいのではないでしょうか?


2.4.x までで問題となっていたのは, dtb_order_temp と決済サイトにはデータが登録されているが, dtb_order には登録されないという NG パターンです.
これを防ぐためには決済サイトに遷移する前に dtb_order へ登録されることが求められています.


----------------
大河内健太郎(Kentaro Ohkouchi)
EC-CUBE公式エバンジェリスト
スキルニル株式会社

EC-CUBE1系2系長期サポートホスティングサービス CUBE Lab
https://cubelab.info/

patapata
投稿日時: 2010/10/26 14:03
対応状況: −−−
仙人
登録日: 2010/7/7
居住地: 神奈川県
投稿: 502
Re: 決済モジュール使用時の挙動について
他はまぁ置いといて・・・

引用:

2.4.x までで問題となっていたのは, dtb_order_temp と決済サイトにはデータが登録されているが, dtb_order には登録されないという NG パターンです.
これを防ぐためには決済サイトに遷移する前に dtb_order へ登録されることが求められています.

あまり上げたくは、なかったですが認識が甘いと困るので、・・・現在問題となってるのは、

この辺りと
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=6128&forum=10&viewmode=flat&order=ASC&start=0

http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=5641&forum=2&viewmode=flat&order=ASC&start=10

この辺り
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=5554&forum=9&post_id=26617#forumpost26617

場合によっては、これもかなり危険かと・・・
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=6859&forum=5&post_id=32881#forumpost32881

どれも重要な信用問題です。
nanasess
投稿日時: 2010/10/26 15:21
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2127
Re: 決済モジュール使用時の挙動について
r18871 で, 決済モジュールを使用した場合は, 「決済処理中」というステータスになるよう修正しました.

http://svn.ec-cube.net/open_trac/changeset/18871

また, 決済サイトから load_payment_module.php へも戻ってこれるようにしたので, 決済モジュール側での実装により, 従来の問題の多くは解決可能と思います.


----------------
大河内健太郎(Kentaro Ohkouchi)
EC-CUBE公式エバンジェリスト
スキルニル株式会社

EC-CUBE1系2系長期サポートホスティングサービス CUBE Lab
https://cubelab.info/

スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ


 



ログイン


EC-CUBEペイメント

公式ストアEC-CUBE4系デザインテンプレート続々リリース中

統計情報

総メンバー数は70,505名です
総投稿数は100,697件です

投稿数ランキング

1
seasoft
7333
2
468
2922
3
AMUAMU
2712
4
nanasess
2127
5
umebius
1931
6
yuh
1612
7
red
1437
8
h_tanaka
1076
9
tsuji
926
10
fukap
907
11
shutta
835
12
tao_s
793
13 ramrun 789
14 karin 689
15 sumida 641
16
homan
633
17 DELIGHT 572
18
patapata
502
19
flealog
485
20 tonton 437


ネットショップの壺

EC-CUBEインテグレートパートナー

Copyright© EC-CUBE CO.,LTD. All Rights Reserved.