Вирішення проблеми Інтернет-еквайрингу для онлайн-магазину на Magento 2 та платіжної системи LiqPay
8 Травня 2024
наступна статтяПро автопа: Олександр Кавюк, Magento 2 розробник з досвідом створення інтернет магазинів більше 10 років. Працював із різними платформами, що використовують РНР. Має досвід вирішення складних завдань, про які інші казали “це неможливо”.
Інтернет-магазин для покупця має бути зручним і водночас простим. Лише в такому разі онлайн шопінг принесе найбільше користі як клієнтові, так і власнику інтернет-магазину. За часи пандемії культура онлайн-шопінгу зазнала багатьох змін, а вимоги до інтернет-магазинів помітно зросли. Саме тому Ваш сайт сьогодні повинен мати всі можливості для зручної покупки, щоб витримати конкуренцію та примножити клієнтів. А з повномасштабним вторгненням рф стало зрозумілим, що популярна раніше платформа “1с-бітрікс: управління сайтом” більше не може бути використана для ведення онлайн-бізнесу. Детально про це розповідає стаття співзасновника Авіві Івана Бочарова “Збої, відмови та критичні ситуації: чому інтернет-магазинам варто відмовитись від російського ПЗ” на MC.Today та ще ряд статей у нашому блозі. Але сьогодні наша головна тема пов’язана з випадком саме у Magemto 2.
Чому важливий інтернет-еквайринг?
Інтернет-еквайринг є одним з важливих атрибутів будь-якого сучасного онлайн магазину. Завдяки йому, покупці можуть оплачувати товари або послуги безпосередньо на сайті, використовуючи свою банківську карту або електронний гаманець. Ця послуга дозволяє приймати банківські картки міжнародних та національних платіжних систем. Як і будь-яка готова послуга, інтернет-еквайринг передбачає наявність декількох учасників:
-
еквайр — юридична особа (зокрема банк), яка приймає транзакції від торговців та надсилає їх до відповідної платіжної системи;
-
банк-емітент — це банк, який випустив картку платника;
-
сервіс-провайдер — це онлайн-сервіс, який здійснює інтеграцію сайту інтернет-торговця з еквайром.
На практиці покупець для оплати замовлення переходить на безпечну сторінку процесингового центру, вводить реквізити своєї картки й оплачує замовлення. На сьогодні відомо безліч назв різних сервісів, тому наші клієнти обирають систему за власним бажанням та вподобаннями, як-то локалізація, комісії та інше. Для розробників важливим питанням є наявність API для інтеграції з інтернет-магазином.
Коротко про LiqPay
В конкретному випадку клієнтів Авіві, в якості сервісу інтернет-еквайрингу було обрано LiqPay — одну з поширених вітчизняних платіжних систем: дуже зручна в керуванні та інтеграції в велику кількість платформ. Розробники сервісу передбачили API для інтеграції з веб сайтами на Magento 2, тому на час планування проекту ніщо не передбачало труднощів.
Серед переваг цього сервісу можна відзначити багато варіантів різних способів оплати, доступних кінцевим клієнтам. Також LiqPay досить лояльний у плані комісій, що робить сервіс привабливим для власників інтернет-магазинів та сприяє популярності у світі eCommerce. Однак попри всі переваги не можна виключати приховані складності, саме з якими ми зіштовхнулися.
Проблематика
Сервіс LiqPay має гарно описане API і безліч модулів для інтеграції. На сайті нашого клієнта було встановлено розширення від LiqPay, сформовано всі потрібні доступи та зроблено налаштування. Взаємодія оплати відпрацьовувала згідно схеми, крім останнього кроку.
Проблема була із отримання Callback методу з інформацією про статус оплати, відповідно система сайту не знала, чи покупець здійснив оплату свого замовлення. Це призводило до критичних незручностей:
-
в покупців з’являються переживання за свої кошти;
-
страждає автоматика процесу, оскільки менеджери сайту не володіють інформацією про стан оплати.
З такою помилкою використання інтернет-еквайрингу абсолютно неможливе, тому цю проблему довелося вирішувати кастомно.
Дослідження та вирішення
Звичайно, найперше я перевірив усі запити, чи правильно передаються дані для Callback. Наступний крок — додали логування в місці, де маємо отримувати результат. В кабінеті платіжної системи, в логах про оплату бачимо, що дані надходять правильно і запит відбувається. Але від сайту отримуємо статус 400 ( bad request).
Дана ситуація наштовхнула на думку проаналізувати запити від LiqPay. І це було правильне рішення, адже стало зрозумілим, що в заголовку передається тип контенту “application/x-www-form-urlencoded”. В Magento 2 з коробки, WEBAPI_REST розпізнає наступні типи:
-
application/json;
-
application/xml;
-
application/xhtml+xml;
-
text/xml.
Будь-які інші типи призведуть до повідомлення про помилку.
Так, як на запити зі сторони LiqPay, ми вплинути не можемо, було вирішено кастомно розширити можливості штатного десерилізатора.
Створено модуль із відповідним методом:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
<?php namespace Vendor\ModuleName\Webapi\Rest\Request\Deserializer; use InvalidArgumentException; use Magento\Framework\App\State; use Magento\Framework\Phrase; use Magento\Framework\Stdlib\Parameters; use Magento\Framework\Webapi\Rest\Request\DeserializerInterface; /** * Class FormUrlencoded */ class FormUrlencoded implements DeserializerInterface { /** * @var Parameters */ private $parameters; /** * @var State */ protected $_appState; /** * FormUrlencoded constructor. * @param Parameters $parameters * @param State $appState */ public function __construct( Parameters $parameters, State $appState ) { $this->parameters = $parameters; $this->_appState = $appState; } /** * Parse Request body into array of params. * * @param string $encodedBody Posted content from request. * @return array|null Return NULL if content is invalid. * @throws InvalidArgumentException * @throws \Magento\Framework\Webapi\Exception If decoding error was encountered. */ public function deserialize($encodedBody) { if (!is_string($encodedBody)) { throw new \InvalidArgumentException( sprintf('"%s" data type is invalid. String is expected.', gettype($encodedBody)) ); } try { $decodedBody = urldecode($encodedBody); $this->parameters->fromString($decodedBody); return $this->parameters->toArray(); } catch (\InvalidArgumentException $e) { if ($this->_appState->getMode() !== State::MODE_DEVELOPER) { throw new \Magento\Framework\Webapi\Exception(new Phrase('Decoding error.')); } else { throw new \Magento\Framework\Webapi\Exception( new Phrase( 'Decoding error: %1%2%3%4', [PHP_EOL, $e->getMessage(), PHP_EOL, $e->getTraceAsString()] ) ); } } } } |
І і проприсати його підключення в /app/etc/di.xml
1 2 3 4 5 6 7 8 9 10 11 |
<type name="Magento\Framework\Webapi\Rest\Request\DeserializerFactory"> <arguments> <argument name="deserializers" xsi:type="array"> … <item name="application_x_www_form_urlencoded" xsi:type="array"> <item name="type" xsi:type="string">application/x-www-form-urlencoded</item> <item name="model" xsi:type="string">Vendor\ModuleName\Webapi\Rest\Request\Deserializer\FormUrlencoded</item> </item> </argument> </arguments> </type> |
Після встановлення модулю не слід забувати про потребу перекомпілювати весь проект. А тепер можна перевірити результат:
Як бачимо, в кабінеті LiqPay запит відпрацьовує нормально.
Аналогічно у адміністративній частині сайту, замовлення змінило статус і створено invoice.
Отже, шляхом створення кастомного модуля для Magento 2 я дозволили сайту обробляти запит від LiqPay та оновлювати дані про стан оплати замовлення. Відпрацювання бізнес процесу відновлено, а значить тепер клієнти можуть спокійно користуватися інтернет-еквайрингом та займатися онлайн-шопінгом без проблем.
Висновок
Платформа Magento 2 є потужним та досконалим інструментом для розвитку eCommerce проектів. Однак неможливо передбачити усі випадки, коли можуть виникати певні помилки. Хороша новина полягає у тому, що гнучкість Magento 2 дозволяє виправляти практично будь-які проблеми завдяки кастомній розробці доповнень для платформи. Команда Авіві має значний досвід у цій роботі, тож ми з радістю допоможемо вам створити найкращий та найефективніший інтернет-магазин.
Ми зв'яжемось з Вами протягом 10 хвилин