Поток платежей в Magento


Я работаю над внедрением нового платежного модуля для Magento и хочу понять основную концепцию этой логики. Я знаю, что мне нужно расширить от Mage_Payment_Model_Method_Abstract или любого из его дочерних классов, но моя проблема заключается в том, когда использовать и как использовать методы захвата и авторизации в моей модели. Например, если я разделю весь процесс на следующие шаги:

  1. пользователь приходит в корзину и выбирает, скажем, какой-то способ оплаты, который является ворота.
  2. система перехватывает запрос, собирает все представленные данные и отправляет пользователю url шлюза.
  3. пользователь размещает свой заказ (или отменяет) на сайте шлюза, который отправляет информацию о ней в мой магазин.
  4. мой магазин делает еще несколько изменений в заказ с полученными данными и сохраняет заказ со статусом завершено или отменено.

где в этих шагах мне придется использовать методы авторизации и захвата ? Я бы цените, если кто-то может объяснить мне, что такое авторизация и захват?

1 67

1 ответ:

вот как я всегда понимал концепции, и что вам нужно знать, чтобы реализовать платежный модуль в Magento. Ответы на ваш конкретный "где это происходит" выделены жирным шрифтом ниже, хотя это не так просто, как вы надеетесь.

операции с кредитными картами до интернета, кирпича и миномета были двухэтапным процессом.

во время продажи, когда продавец взял кредитную карту потребителя для покупки, они скользили по ней через точку устройства продажи, которое будет звонить в центральный офис кредитной карты и спрашивать "является ли эта карта авторизованной для этой сети, и является ли линия доступного кредита этого конкретного потребителя достаточно большой, чтобы позволить эту покупку".

если покупка была принята (в отличие от отклонена), плата была названа уполномоченный. Потребитель заберет свой товар, а система точки продажи/кассовый аппарат отметит, что сделка была санкционирована. Затем, в конце концов в тот день, или в конце недели, в какой-то другой заранее определенный регулярный график, или когда владелец решил прекратить пить, торговец пойдет, хотя все их разрешенные квитанции и отправить другое запрос в центральный офис в захват средства от уполномоченный сделки. Захват средств-это то, что помещает деньги на счет продавца.

это все еще модель, используемая большинством шлюзов, и является доменом модель, что Magento Inc. выбрали для реализации свои платежные модули.

то, как все должно работать,когда потребитель достигает последних шагов проверки в такой системе, как Magento, Magento выдает запрос на авторизацию API шлюза. Если транзакция прошла успешно, заказ принимается в систему, и уникальный идентификатор из запроса на авторизацию сохраняется. Далее, когда товары потребителя отгружаются, владелец магазина использует Magento админ, чтобы создать счет-фактуру. При создании этого счета выдается запрос на захват (с использованием идентификатора магазина, возвращенного из запроса на авторизацию). вот где эти вызовы методов выдаются в Magento.

однако, все становится сложнее, потому что каждый платежный шлюз интерпретирует эти понятия немного по-разному, и каждый торговец интерпретирует их "не захватывать, пока мы не отправили" обязанности по-разному. В дополнение к описанному выше сценарию , платежные модули имеют значение конфигурации системы, известное как Оплата. Это может быть установлено в Разрешить Только, который будет реализовывать поток, описанный выше. Он также может быть установлен в авторизация и захват, который будет как авторизовать, так и захватить платеж при размещении заказа. Он получает даже больше запутанный, потому что, хотя метод называется Authorize и Capture, текущие версии Magento будут выдавать только захват запрос при установке в этом режиме (по крайней мере для Authorize.net), и Authorize.net будет, внутренне, оставить запросы на захват в авторизованном, но не захваченном состоянии в течение большей части дня. Как Magento обрабатывает заказы и платежи и счета-фактуры-это одна из областей кодовой базы, которая сильно меняется от версии к версии.

Итак, идея системы платежных модулей Magento заключается в том, чтобы защитить вас от кластера F--- это программирование логики платежного шлюза. В вашем authorize метод выполните вызов API авторизации вашего платежного шлюза (или выполните любые проверки и логику, которые вы хотите выполнить на этом этапе). Этот способ передает объект платежа и сумму. Если вы запрашиваете / выполняете свою логику и определяете, что она недействительна по какой-либо причине, вы создаете исключение с

Mage::throwException('...');

это говорит Magento, что авторизация не удалась, и он будет действовать соответственно (показывать сообщение об ошибке и т. д.). В противном случае можно задать элементы данных для объекта оплаты и выпуск а

return $this;

члены данных-это то, что вам понадобится позже, при захвате платежа. Что приводит нас к capture способ вашего платежного модуля. Этот способ также отправляет объект оплаты и сумму. В этом методе вы выдаете запрос на захват. Объект оплаты будет иметь cc_trans_id элемент данных

$payment->getCcTransId()

что позволит вам выдать захват против вашего шлюза. Это один из элементов данных, за сохранение которых вы отвечаете 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 для любого

  1. захват предварительно авторизованной транзакции
  2. немедленного захвата

надеюсь, что это поможет, и удачи!