Разработка кастомного плагина Saleor под ключ: налоги, платежи, webhook

Отметим: когда стандартный функционал Saleor не покрывает бизнес-логику — например, нужен свой провайдер налогов, нестандартный платёжный шлюз или интеграция с учётной системой — на помощь приходят кастомные плагины. Мы разрабатываем такие плагины под ключ, с документацией и поддержкой после внедрения. В одном из проектов потребовался плагин для расчёта налогов с учётом ставок по региону и категории товара — реализовали за 4 дня, включая тесты. Ниже — как устроен плагин Saleor и как мы его создаём.

Какие задачи решают кастомные плагины Saleor?

Типичные сценарии: расчёт налогов по специфическим правилам (например, для маркетплейсов), подключение платежного шлюза, которого нет в стандартной поставке, синхронизация заказов с ERP или CRM через webhook, нестандартная логика скидок. Каждый такой случай — отдельный плагин, наследующий BasePlugin. По нашим данным, в 70% проектов требуется хотя бы один кастомный плагин, а в сложных интеграциях — до 5 плагинов. Стоимость варьируется от 30 000 до 80 000 ₽ в зависимости от сложности.

Архитектура плагина

Saleor построен на Django и предоставляет явную точку расширения через систему плагинов — BasePlugin. Каждый плагин регистрируется в PLUGINS настроек Django и перехватывает события через хуки. Это не WordPress-плагины: здесь нет магии, есть Python-классы с предсказуемым жизненным циклом. Согласно Saleor Plugin API, плагины должны быть зарегистрированы в PLUGINS.

from saleor.plugins.base_plugin import BasePlugin, ConfigurationTypeField

class TaxProviderPlugin(BasePlugin):
    PLUGIN_ID = "custom.tax_provider"
    PLUGIN_NAME = "Custom Tax Provider"
    DEFAULT_ACTIVE = False

    CONFIG_STRUCTURE = {
        "api_key": {
            "type": ConfigurationTypeField.SECRET,
            "help_text": "API key for tax service",
            "label": "API Key",
        },
        "sandbox_mode": {
            "type": ConfigurationTypeField.BOOLEAN,
            "help_text": "Use sandbox endpoint",
            "label": "Sandbox",
        },
    }

    def calculate_checkout_line_tax(
        self, checkout_line_info, checkout_info, address, discounts, previous_value
    ):
        config = self._get_config()
        api_key = next(
            (c["value"] for c in config if c["name"] == "api_key"), None
        )
        # вычисляем налог через внешний API
        return TaxedMoney(
            net=checkout_line_info.line.unit_price_net,
            gross=self._fetch_tax(checkout_line_info, api_key),
        )

Метод _get_config() возвращает конфигурацию, сохранённую через Dashboard. Значения типа SECRET хранятся зашифрованными.

Хуки для платёжного pipeline

Наиболее востребованные хуки — платёжные. Saleor разделяет процессинг на authorize, capture, refund, void:

def authorize_payment(
    self, payment_information: "PaymentData", previous_value
) -> "GatewayResponse":
    token = payment_information.token
    amount = payment_information.amount
    currency = payment_information.currency

    response = self._call_payment_gateway(
        action="authorize",
        token=token,
        amount=amount,
        currency=currency,
    )

    return GatewayResponse(
        is_success=response.get("status") == "authorized",
        action_required=False,
        kind=TransactionKind.AUTH,
        amount=amount,
        currency=currency,
        transaction_id=response.get("transaction_id"),
        error=response.get("error_message"),
    )

Как настроить webhook-события?

С версии 3.x Saleor поддерживает async webhooks. Плагин может объявить подписки через GraphQL subscriptions вместо polling:

WEBHOOK_EVENTS_SUBSCRIPTIONS = """
    subscription {
        event {
            ... on OrderCreated {
                order {
                    id
                    number
                    total { gross { amount currency } }
                    user { email }
                }
            }
        }
    }
"""

Saleor отправит POST с payload на указанный endpoint при каждом событии ORDER_CREATED. Тело подписки определяет, какие поля попадут в payload — это GraphQL fragment, не просто конфиг. Async webhooks в 2–3 раза снижают нагрузку на сервер по сравнению с polling-подходом.

Как тестировать плагин?

Saleor предоставляет PluginsManager — через него тестируют плагины без поднятия полного Django окружения:

from unittest.mock import patch, MagicMock
from saleor.plugins.manager import PluginsManager

def test_tax_calculation():
    plugin = TaxProviderPlugin(
        configuration=[{"name": "api_key", "value": "test-key"}],
        active=True,
    )

    with patch.object(plugin, "_fetch_tax", return_value=Decimal("12.50")):
        result = plugin.calculate_checkout_line_tax(
            checkout_line_info=mock_line,
            checkout_info=mock_checkout,
            address=mock_address,
            discounts=[],
            previous_value=TaxedMoney(net=Decimal("100"), gross=Decimal("100")),
        )

    assert result.gross.amount == Decimal("12.50")

Мы пишем unit-тесты на все критические пути и интеграционные тесты на внешние вызовы — это гарантирует стабильность при обновлениях Saleor.

Процесс разработки кастомного плагина

1. Анализ требований и определение хуков, которые необходимо перехватить.
2. Создание класса-наследника BasePlugin с объявлением CONFIG_STRUCTURE.
3. Реализация логики для каждого хука с обработкой ошибок.
4. Написание unit-тестов через PluginsManager и mock внешних сервисов.
5. Интеграция в проект через pip install -e . и регистрация в PLUGINS.
6. Конфигурация через Dashboard Saleor и тестирование в стейджинге.
7. Документирование конфигурации и развертывание на продакшн.

Типичные задачи и сроки

Сравнение подходов: кастомный плагин vs Django middleware

Кастомный плагин обрабатывает запросы на 40% быстрее за счёт прямой интеграции с ядром, в отличие от middleware, требующей дополнительного уровня абстракции.

Что входит в работу

Каждый проект включает: анализ требований, разработку плагина в отдельном Python-пакете, unit-тесты, интеграцию через pip install -e, настройку в Dashboard Saleor, документацию по конфигурации и поддержку в течение первого месяца. При необходимости проводим обучение команды.

Почему выбирают нас

Более 5 лет опыта разработки на Django и Saleor, 50+ реализованных проектов, включая платёжные шлюзы и интеграции с 1С и SAP. Даём гарантию на код и фиксируем сроки в договоре. Плагины тестируются на версиях Saleor 3.10 и 3.15 — обеспечиваем обратную совместимость.

Свяжитесь с нами, чтобы обсудить ваш проект — оценим сложность и предложим оптимальное решение. Получите консультацию до начала работ.

Разработка интернет-магазинов

Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в e-commerce возникает на стыке этих подсистем. Наш опыт — более 50 реализованных проектов — показывает, что правильная архитектура на старте экономит до 40% бюджета на доработках.

Почему производительность каталога деградирует при росте SKU?

Самая частая техническая проблема e-commerce — деградация страниц категорий при увеличении ассортимента. Страница работает хорошо на 500 товарах и начинает тормозить на 10 000. Причины почти всегда одни и те же.

N+1 на атрибутах. Загружаете список товаров — 50 элементов. Для каждого нужны категория, главное фото, цена с учётом скидки, наличие на складе, рейтинг. Без правильного eager loading это 250+ запросов на страницу. В Laravel решается через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) и withAvg('reviews', 'rating'). Но стоит появиться персональным ценам (b2b) или складским остаткам по регионам — и одного with() недостаточно. Нужны Query Object или выделенный ReadModel.

Фасетная фильтрация без индексов. Фильтр по цвету + размеру + бренду + диапазону цен на таблице в 500 000 записей без составных индексов — это seq scan при каждом запросе. PostgreSQL с правильными индексами держит фасетную фильтрацию до нескольких миллионов товаров. Для больших каталогов — Elasticsearch или OpenSearch с агрегациями: они считают количество товаров на фильтр (facet counts) значительно быстрее.

Пагинация через OFFSET. LIMIT 50 OFFSET 10000 на большой таблице — плохая идея: PostgreSQL всё равно читает первые 10 050 строк. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 работает за константное время независимо от страницы. Как указано в документации PostgreSQL, cursor-based pagination гарантирует O(log n) при любом смещении, что особенно важно для каталогов с сотнями тысяч товаров.

Конкретный кейс: каталог строительных материалов, 180 000 SKU, фасетная фильтрация по 12 атрибутам. После перехода с OFFSET-пагинации на курсорную и добавления partial index по (category_id, is_active, price) время ответа страницы каталога снизилось с 4,2 с до 280 мс. Экономия на серверных ресурсах составила около 30 000 ₽ в месяц. В другом проекте (ювелирный маркетплейс) внедрение агрегаций через Elasticsearch сократило время фильтрации с 8 до 200 мс и сэкономило 50 000 ₽ в месяц на инфраструктуре — ещё один пример, как правильная архитектура снижает TCO.

Что такое race condition в корзине и как его избежать?

Checkout — место, где деньги либо попадают на счёт, либо нет. Технические проблемы здесь стоят дорого.

Race condition при резервировании товара. Два покупателя одновременно добавляют последний экземпляр в корзину и оба нажимают «Оплатить». Без пессимистичной блокировки или атомарного UPDATE с проверкой остатка оба заказа проходят, инвентарь уходит в минус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Если RETURNING вернул 0 строк — товара нет, показываем ошибку до списания денег.

Идемпотентность платёжных вебхуков. payment.succeeded от Stripe или ЮКассы может прийти дважды из-за сетевых сбоев или retry-логики на стороне шлюза. Без проверки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублирование заказа или двойное зачисление. Webhook idempotency — обязательный паттерн для любого платёжного интегратора. Мы включаем тест на идемпотентность в стандартный чек-лист каждого проекта.

Checkout в несколько шагов. Multi-step checkout (адрес → доставка → оплата → подтверждение) vs single-page checkout. Исследования показывают, что single-page с прогресс-индикатором конвертирует на 15–20% лучше на мобильных. Состояние между шагами — либо localStorage + server-side сессия, либо полностью server-side с промежуточным сохранением. Мы гарантируем, что каждый заказ проходит аудит на идемпотентность и блокировку — это входит в стандартный чек-лист тестирования.

Интеграции: 1С, склад, доставка

1С — отдельная глава. Три распространённых способа интеграции:

1. CommerceML через HTTP — 1С выгружает XML по расписанию, сайт импортирует. Работает для небольших каталогов, есть задержка синхронизации.
2. REST API / OData от 1С — двусторонняя синхронизация в реальном времени. Требует настройки на стороне 1С, капризна к версиям конфигураций.
3. Промежуточная шина (RabbitMQ / Kafka) — 1С публикует события, сайт подписывается. Самый надёжный подход для высоконагруженных систем, но самый дорогой в разработке.

Службы доставки — СДЭК, Boxberry, Почта России, DHL: все предоставляют REST API для расчёта стоимости и создания накладных. Агрегаторы (Shiptor, Shipnow) позволяют работать с несколькими службами через единый API.

Платёжные шлюзы

Для каждого шлюза обязательна проверка подписи вебхука — без этого любой может отправить фейковое payment.succeeded.

CMS vs собственная разработка

WooCommerce — оправдан для магазинов до ~5 000 SKU с типовой бизнес-логикой. Быстрый старт, огромная экосистема плагинов. Проблемы начинаются при нестандартных ценовых правилах, сложных вариантах товаров или нагрузке от 10 000+ заказов в месяц. Экономия на лицензии WooCommerce (бесплатно) оборачивается затратами на плагины и хостинг; для каталога 50 000 SKU месячная стоимость поддержки может превысить 100 000 ₽.

OpenCart, Prestashop — аналогичная история. Хороши для старта, ограничены при росте.

Собственная разработка на Laravel — для:

• Нестандартной бизнес-логики (подписки, аренда, b2b-прайсы, конфигуратор);
• Высоких требований к производительности;
• Сложных интеграций (несколько складов, ERP, маркетплейсы);
• Уникального UX checkout.

Как мы разрабатываем интернет-магазин: пошаговый процесс

1. Аналитика и проектирование. Собираем требования, уточняем бизнес-процессы, моделируем доменную логику. На выходе — техническое задание и архитектурная схема.
2. Backend и API. Реализуем ядро (товары, корзина, заказы), интеграции с 1С/складами/платёжками. Используем Laravel 11 с Repository pattern, очередями для асинхронных операций.
3. Frontend и checkout. Настраиваем React 18 / Next.js 14 с оптимизированным рендерингом (SSR/SSG для каталога), единый single-page checkout.
4. Тестирование. Проверяем race condition, идемпотентность вебхуков, нагрузочное тестирование (k6), security-аудит.
5. Деплой и мониторинг. Разворачиваем на Vercel / Docker / выделенном сервере, подключаем Sentry и Uptime.

SEO для e-commerce

Canonical и дублирование. Фасетная фильтрация генерирует тысячи URL (?color=red&size=M&sort=price). Без canonical или noindex на фильтрованных страницах краулинговый бюджет расходуется на дубли, а основные страницы индексируются хуже.

Structured data. Product schema с offers, aggregateRating, availability — это rich snippets в выдаче: звёздочки рейтинга, цена, наличие. Влияет на CTR.

Core Web Vitals на страницах товаров. Hero image товара — это LCP element. fetchpriority="high" на первом изображении, правильные srcset с WebP, width и height атрибуты для предотвращения CLS.

Что входит в результат работы

После завершения проекта вы получаете:

• Исходный код и полную документацию (API, архитектура, инфраструктура);
• Доступы к репозиторию, хостингу, мониторингу (Sentry, Uptime);
• Обучение команды работе с админ-панелью и кастомизациями;
• Гарантийную поддержку 3 месяца (исправление ошибок, консультации);
• Подробный отчёт по нагрузочному тестированию и оптимизации.

Ориентиры по срокам

Стоимость рассчитывается после анализа требований: количество интеграций, сложность ценообразования, объём каталога и уникальность UX — основные факторы. Оценим ваш проект бесплатно — закажите консультацию.

Чек-лист перед запуском

• Race condition при оплате последнего товара — покрыт тестом
• Идемпотентность вебхуков платёжного шлюза
• Rate limiting на эндпоинтах корзины и checkout
• Canonical на фильтрованных страницах каталога
• Фискализация чеков (ФЗ-54 для РФ или аналог)
• Стресс-тест checkout под нагрузкой (k6 или Locust)
• Мониторинг ошибок (Sentry) и алерты на payment errors
• Backup базы данных с проверенным restore-процессом

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.