WooCommerce-плагин не решает всю архитектуру
Плагин может дать платежную кнопку, но бизнесу все равно нужны статусы, возвраты, логи и сверка.
Для WooCommerce в Армении есть готовые решения под ArCa/банковский vPOS. Например, WordPress.org содержит PlanetStudio Payment Gateway с поддержкой армянских банков, payment links, test/production modes и callback logs. Это значит, что для простого магазина ответ не "искать с нуля", а начать с совместимости выбранного банка, плагина, версии WooCommerce и требований к checkout.
Но plugin не решает всю архитектуру. Перед установкой важно понять, как он создает платеж, какие статусы пишет в заказ, как обрабатывает callback и можно ли безопасно повторить попытку оплаты. Если сайт связан с CRM, складом или фискализацией, gateway должен передавать проверенное событие дальше, иначе часть заказов может остаться в неверном состоянии.
- pending payment не должен считаться paid;
- failed и canceled статусы должны быть различимы;
- callback должен проверять сумму и order id;
- повторная оплата не должна создавать дубль заказа;
- обновления WordPress/WooCommerce/plugin должны проходить через staging.
Какие поля важно хранить в заказе
WooCommerce order должен хранить связь с внешним payment id и технической попыткой оплаты.
В WooCommerce удобно хранить payment metadata в order meta. Это помогает поддержке быстро понять, какой внешний платеж относится к заказу, была ли повторная попытка и какой webhook обновил статус.
Минимальный набор для production: external payment id, provider/bank code, attempt number, verified status, сумма, валюта, время финального статуса и correlation id. Если подключена CRM или ERP, эти поля лучше нормализовать на backend-слое и передавать наружу только business-safe данные, без сырого ответа провайдера и лишних персональных данных.
- external payment id;
- payment attempt number;
- provider или bank code;
- verified status and timestamp;
- correlation id для поддержки.
Когда нужен кастомный интеграционный слой
Если магазин растет, платежную логику лучше вынести из WordPress-плагина в отдельный backend contract.
Кастомный слой нужен, если магазин использует несколько способов оплаты, CRM-счета, B2B-клиентов, фискализацию или сложную доставку. В этом случае WordPress не должен быть единственным источником платежной истины.
Практическое правило: если после оплаты нужно обновить не только WooCommerce order, но и CRM deal, склад, чек, delivery flow или бухгалтерский отчет, платежный lifecycle лучше вынести в отдельный слой. WooCommerce остается storefront, а VPOS.am нормализует webhooks, retries, audit и интеграцию с CRM/ERP.
- меньше риска при обновлении plugin/theme;
- проще подключить второй банк;
- единая логика для сайта и CRM;
- лучше контроль логов и возвратов.
FAQ
Можно ли подключить ArCa/Visa/Mastercard к WooCommerce?
Да, через банк, платежный gateway или интеграционный слой. Важно проверить, как конкретное решение обрабатывает callbacks, статусы и возвраты.
Достаточно ли установить WordPress-плагин?
Для простого магазина иногда достаточно. Для CRM, ERP, фискализации, сложной доставки и B2B лучше проектировать backend contract.
Где хранить payment id?
Минимум в WooCommerce order meta, но для надежной поддержки и сверки лучше хранить его и в backend-журнале платежных событий.
Источники
- WordPress.org - PlanetStudio Payment GatewayОписание WordPress gateway для армянских банков, payment links, test/production modes и callback logs.
- WooCommerce - Managing ordersОфициальная документация WooCommerce по заказам и статусам.
- Evocabank - V-POS TerminalОфициальное описание vPOS для приема оплат на сайте и в мобильном приложении.
