При выполнении действия "Списать средства" в плагин оплаты не передаются данные о самом заказе Принято

1

Если не ошибка, то скорее пожелание доработки. При выполнении действия "Списать средства" (id CAPTURE) в плагин оплаты не передаются данные о самом заказе (хотя по комментам к waIPaymentCapture вроде как должны передаваться).

Доработки кода описал тут https://github.com/webasyst/shop-script/pull/306

В Github иногда теряется, поэтому дублирую ;)

4 комментария

  • +1

    В таком виде это использовать нельзя и даже опасно. Доступность изменения суммы списания должна проверяться приложением через атрибуты плагина оплаты и его методы. Если плагин не ожидает данные о заказе, то он никак не сможет проверить сумму, а при получении уведомления о списании оригинальной суммы заказ не сменит статус из-за расхождения сумм и дальше из приложения сделать возврат средств покупателю корректно не получится.

    Ну и передавать в плагин надо в обобщенном формате waOrder, учитывая валюту заказа и валюту платежа.

    • +1

      Так... перечитал несколько раз... Что-то сложно написано. По предложениям.


      > В таком виде это использовать нельзя и даже опасно

      Плагин оплаты ничего не может поменять в такой реализации. Он только читает дополнительные данные.


      > Доступность изменения суммы списания должна проверяться приложением через атрибуты плагина оплаты и его методы.

      Это "идеальный вариант" или где-то так реализовано? Сейчас, на сколько могу понять, магазин не проверяет "доступность изменения суммы списания", а просто говорит "списывай давай".

      > Если плагин не ожидает данные о заказе, то он никак не сможет проверить сумму, а при получении уведомления о списании оригинальной суммы заказ не сменит статус из-за расхождения сумм и дальше из приложения сделать возврат средств покупателю корректно не получится.

      О чём и речь! Сейчас никакой плагин оплаты фактически не может сравнить ту сумму, которую он ставил на холд и ту, что есть в заказе в момент списания. И при подтверждении подтвердит сумму по умолчанию. Это та сумма, которая была поставлена на холд.

      А значит в ситуации "холд - редактирование заказа - подтверждение" спишет ту сумму, которая была изначально. И заказ не перейдёт в статус "Оплачен" поскольку изначально сумма отличалась от той, что сейчас.

      В описании интерфейса, между прочим, сказано, что параметр order_data должен быть:

      interface waIPaymentCapture
      {
          /**
           *
           * @param array [string]mixed $transaction_raw_data['order_data']
           * @param array [string]mixed $transaction_raw_data['transaction_type']
           * @param array [string]mixed $transaction_raw_data['customer_data']
           * @param array [string]mixed $transaction_raw_data['transaction']
           * @param array [string]mixed $transaction_raw_data['refund_amount']
           */
          public function capture($transaction_raw_data);
      }

      а ещё transaction_type, customer_data и, внезапно, refund_amount.

      > Ну и передавать в плагин надо в обобщенном формате waOrder, учитывая валюту заказа и валюту платежа.

      Звучит логично :) Но ведь сейчас вообще ничего не передаёте.

      • +2

        refund_amount должно было сразу же насторожить - в текущей реализации для этих методов передаются только данные транзакции (из таблицы wa_transaction). Описания передаваемых параметров исправим.

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

        Так что придется немного подождать, пока будет реализована возможность частичного списания в приложении корректно.


        • +1

          Оно и насторожило :) я понял, что копипаста, но order_data, в принципе решило мою проблему.

          Как разработчик плагинов оплаты я готов внедрить двухстадийную оплату в свои плагины. Поэтому я за всяческий движ в этом направлении.

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

          На очереди Liqpay и оплата частями Приватбанка, но тогда подождём корректной реализации со стороны приложения.

          Добавить комментарий

          Чтобы добавить комментарий, зарегистрируйтесь или войдите