私は Magento の新しい支払いモジュールの実装に取り組んでおり、このロジックの背後にあるコアコンセプトを理解したいと思っています。Mage_Payment_Model_Method_Abstract またはその子クラスのいずれかから拡張する必要があることはわかっていますが、モデルでキャプチャ メソッドと承認メソッドをいつどのように使用するかが問題です。たとえば、プロセス全体を次のようにステップに分割するとします。
- ユーザーはショッピングカートにアクセスし、ゲートウェイとなる支払い方法を選択します。
- システムはリクエストをインターセプトし、送信されたすべてのデータを収集し、ユーザーをゲートウェイ URL に送信します。
- ユーザーはゲートウェイ サイトで注文 (またはキャンセル) を行い、その情報が私のストアに送信されます。
- 私のストアは、受け取ったデータを使用して注文をさらに変更し、注文のステータスを完了またはキャンセルして保存します。
これらの手順のどこで、authorize および capture メソッドを使用する必要がありますか? authorize と capture の意味を説明していただけるとありがたいです。
ベストアンサー1
ここでは、私が常に理解してきた概念と、Magento で支払いモジュールを実装するために知っておく必要があることを説明します。「どこでこれが起こるのか」という具体的な質問に対する回答は以下に太字で示されていますが、期待するほど単純ではありません。
インターネットが普及する以前は、実店舗でのクレジットカード取引は 2 段階のプロセスでした。
販売時に、販売業者が購入のために消費者のクレジットカードを受け取ると、そのカードを POS デバイスに通し、クレジットカードの中央オフィスに電話をかけて、「このカードはこのネットワークで承認されていますか。また、この特定の消費者の利用可能な信用枠は、この購入を許可するのに十分な大きさですか」と尋ねます。
購入が承認された場合(拒否された場合ではなく)、料金は認可された消費者が商品を受け取ると、POSシステム/レジが取引が承認されたことを記録します。その後、1日の終わり、1週間の終わり、その他の事前に決められた定期的なスケジュール、またはオーナーが飲酒をやめると決めたときに、商人は承認された領収書をすべて確認し、別の中央事務所に依頼する捕獲からの資金認可された取引。資金を獲得することで、販売者の口座にお金が入金されます。
これは現在でもほとんどのゲートウェイで使用されているモデルであり、Magento Inc. が支払いモジュールに実装することを選択したドメイン モデルです。
物事が進むべき道は、消費者が最終チェックアウトのステップに到達したときMagentoのようなシステムでは、MagentoはゲートウェイのAPIに承認リクエストを発行します。トランザクションが成功すると、注文はシステムに受け入れられ、承認リクエストからの一意のIDが保存されます。次に、消費者の商品が発送されると、ストアのオーナーはMagento管理者を使用して請求書を作成するこの請求書を作成すると、キャプチャ リクエストが発行されます (承認リクエストから返されたストア ID を使用)。Magentoではこれらのメソッド呼び出しが発行される場所です。
しかし、支払いゲートウェイごとにこれらの概念の解釈が少しずつ異なり、販売業者ごとに「出荷するまでキャプチャしない」という責任の解釈が異なるため、状況は複雑になります。上記のシナリオに加えて、支払いモジュールには、支払いアクション設定できるのは承認のみは、上記のフローを実行します。また、次のように設定することもできます。承認とキャプチャ注文時に支払いを承認し、キャプチャします。もっとこのメソッドは Authorize and Capture と呼ばれていますが、現在のバージョンの Magento では、このモードに設定されている場合にのみキャプチャ リクエストが発行され (少なくとも Authorize.net の場合)、Authorize.net は内部的にキャプチャ リクエストを 1 日の大半にわたって承認済みだがキャプチャされていない状態のままにするため、混乱を招きます。Magento が注文、支払い、請求書を処理する方法は、バージョンごとに大きく変わるコードベースの領域の 1 つです。
Magento の支払いモジュール システムの背後にある考え方は、支払いゲートウェイ ロジックをプログラミングするという Cluster F--- からユーザーを保護することです。authorize
メソッドでは、支払いゲートウェイの承認 API への呼び出しを実装します (または、この時点で実行したいチェックやロジックを実行します)。このメソッドには、支払いオブジェクトと金額が渡されます。リクエスト/ロジックを実行して、何らかの理由で無効であると判断した場合は、次の例外をスローします。
Mage::throwException('...');
これはMagentoに認証が失敗したことを伝え、それに応じて動作します(エラーメッセージを表示するなど)。それ以外の場合は、Paymentオブジェクトのデータメンバーを設定し、
return $this;
データメンバーは、支払いをキャプチャするときに後で必要になるものです。これは、capture
支払いモジュールのメソッドにつながります。このメソッドにも支払いオブジェクトと金額が送信されます。このメソッドでキャプチャリクエストを発行します。支払いオブジェクトにはcc_trans_id
データメンバーがあります。
$payment->getCcTransId()
これにより、ゲートウェイに対してキャプチャを発行できるようになります。これは、 に保存する責任があるデータ メンバーの 1 つですauthorize
。コードでキャプチャが失敗したと判断された場合は、例外をスローします。それ以外の場合は、 ですreturn $this
。
authorize.net 支払いモジュールには、これがどのように実行されるかを示す良い例があります。
app/code/core/Mage/Paygate/Model/Authorizenet.php
例えば、このcapture
方法のこの部分を考えてみましょう
public function capture(Varien_Object $payment, $amount)
{
if ($payment->getCcTransId()) {
$payment->setAnetTransType(self::REQUEST_TYPE_PRIOR_AUTH_CAPTURE);
} else {
$payment->setAnetTransType(self::REQUEST_TYPE_AUTH_CAPTURE);
}
$payment->setAmount($amount);
$request= $this->_buildRequest($payment);
$result = $this->_postRequest($request);
//...
ここで、キャプチャ メソッドは支払いに があるかどうかをチェックしていますcc_trans_id
。結果に応じて、anet_trans_type
次のいずれかに設定されます。
self::REQUEST_TYPE_PRIOR_AUTH_CAPTURE
self::REQUEST_TYPE_AUTH_CAPTURE
この値は、APIリクエストオブジェクトによってAPI呼び出しを送信するために使用され、
- 事前承認取引のキャプチャ
- 即時捕獲