Ниже — практическая инструкция и чек‑лист, который поможет выбрать платёжный шлюз для сайта/сервиса с учётом комиссий, API и рекуррентных платежей. В конце — типичные ошибки при интеграции и что с ними делать. Если хотите — могу оценить finexpay.ru по этим же пунктам, если скинете ссылки на их документы/тарифы или позволите мне посмотреть публичную документацию.
1) Общая структура принятия решения — приоритеты
- Безопасность и соответствие (PCI DSS, 3DS, шифрование) — критично.
- Надёжность API / uptime / поддержка и SLA.
- Поддержка нужных бизнес‑функций: рекурренты, холды/авторизации, частичные возвраты, split payments/marketplace.
- Стоимость: комиссия за транзакцию, фикс. плата, chargeback fee, комиссии за возврат и конвертацию, возможность резервов.
- Сроки и удобство подключения (KYC, документы, время модерации).
- Удобство интеграции (SDK, плагины для CMS, тестовая среда, примеры на нужном языке).
2) Что именно смотреть в структуре комиссий
- Процент + фиксированная часть (например 2.5% + 15 руб).
- Раздельные тарифы для карт и электронных кошельков / разных схем (MIR, Visa/Mastercard, международные).
- Комиссии за возврат/чарджбек (часто фиксированная плата за обратную операцию).
- Комиссия за конвертацию валюты и кросс‑бордерные операции.
- Ежемесячная абонплата, плата за эквайринг, за обслуживание терминала/канала.
- Минимальная ежемесячная выручка или обязательства (иногда — «минимум месячных операций»).
- Резервы/сейв‑пул: возможность удержания части средств и сроки разблокировки.
- Скрытые комиссии: плата за тест/подключение, за смену реквизитов, за смену тарифа, за интеграцию.
Совет: просите работоспособный расчёт для вашей средней корзины (пример: 1000 руб*100 транзакций) со всеми возможными комиссиями и ожидаемыми чарджбеками.
3) Оценка API и документации
- Наличие понятной и актуальной документации (endpoint‑ы, примеры, коды ошибок).
- SDK и примеры на нужных языках (PHP, JS, Python, Java, Ruby).
- Тестовая среда / sandbox с тестовыми картами и инструментами отладки.
- Поддержка вебхуков: подписываются ли события, есть ли контроль подписи, где / как хранить секреты.
- Idempotency (возможность повторить запрос без двойной оплаты).
- Логи, ответы API, коды ошибок, хорошие описания ошибок.
- Ограничения по rate limit и политика восстановления (backoff).
- Версионирование API и политика обновлений.
Проверка: прогоните документацию — если в ней мало примеров, нет сценариев «decline/chargeback/recurring failure», это сигнал риска.
4) Рекуррентные (подписочные) платежи — что важно
- Тип рекуррентности: токенизация карт (card‑on‑file) или хранение реквизитов у шлюза.
- Удобный flow для подписки: создание подписки, изменение суммы/плана, отмена, прерывания.
- Поддержка 3DS для рекуррентных списаний (SCA/3DS2). Уточните, как шлюз обрабатывает 3DS при первом списании и для последующих.
- Механики retry/dunning: автоматические повторные попытки, правило попыток, уведомления пользователю.
- Вебхуки о неуспешных списаниях и chargeback’ах.
- Хранение CVV: обычно запрещено — провайдер должен токенизировать карту.
- Отчётность по подпискам и статистика по просроченным/удачным платежам.
- Поддержка офлайн‑платежей/авторизаций (hold) для пробного периода.
Практический критерий: протестировать сценарии — успешный первый платёж (с 3DS), последующие удачные списания, отказ по нехватке средств, смена карты, отмена подписки.
5) Возвраты, удержания (hold) и webhooks
- Возможность авторизации (hold) без немедленного списания и последующего capture. Важна длительность hold (например 7 дней).
- Partial refunds и full refunds — сколько времени и берётся ли комиссия.
- Механика чарджбэков и как провайдер помогает в спорных ситуациях (поддержка документами, chargeback management).
- Подпись/верификация webhook’ов (HMAC, сертификаты), повторные попытки и политика хранения событий.
- Возможность получать различные события: payment_succeeded, payment_failed, refund_issued, chargeback, subscription_failed.
Тест: имитируйте задержки и network failures, проверьте idempotency и восстановление состояния при повторных уведомлениях.
6) Интеграция с CMS и с самописными решениями
- Наличие готовых плагинов/модулей для WooCommerce, Magento, PrestaShop, Bitrix, OpenCart и др.
- Наличие платежной формы hosted (минимизирует PCI‑scope) vs inline API (собираете карточные данные у себя). Hosted проще и быстрее в подключении; inline даёт больше контролем, но увеличивает требования по безопасности.
- Раздражающие моменты: плагины часто устаревают и плохо поддерживаются — важна активная поддержка и репозиторий.
- Для самописных проектов — наличие SDK, понятных REST‑endpoint’ов, тестовой среды и webhook’ов.
Совет: если у вас нет опыта PCI, выбирайте провайдера с hosted checkout или готовыми JS‑виджетами.
7) Безопасность и требования по модерации/подключению
- Тип аккаунта: агрегатор (не нужен отдельный эквайринг) или собственный эквайринг через банк (договор с банком). Агрегаторы проще и быстрее подключаются, но могут иметь лимиты и хранить средства дольше.
- Что обычно требуют: регистрация ИП/ООО (в РФ), паспорт/ИНН, выписка из ЕГРЮЛ/ЕГРИП, реквизиты, URL сайта и описание бизнеса, договоры, иногда тест‑платежи.
- Требования по сайту: HTTPS, публичная информация о компании, политика возвратов/оферта, контакты поддержки.
- PCI DSS: если используете hosted — PCI‑SAQ A; если собираете карты сами — более жёсткие SAQ A‑EP или D.
- 3DS и Fraud‑сервисы: проверьте, есть ли встроенные антифрод‑правила (IP‑блок, velocity limits, blacklist/whitelist).
- Юридические и регуляторные ограничения: бизнес‑ниши, требующие особых разрешений (игры, фарма, финансовые услуги) часто сложнее подключать.
Перед подключением уточните у провайдера перечень документов и примерные сроки модерации.
8) Практические критерии эксплуатации (важнее, чем кажется)
- Уровень поддержки: SLA, канал: чат/телефон/почта, русский язык, рабочие часы.
- Dashboard и отчётность: экспорт транзакций, фильтры, reconciliation tools.
- Метрики надежности: uptime, среднее время ответа API, частота инцидентов.
- Chargeback protection и компенсации: страхование/поддержка в спорах.
- Планы на масштабирование: увеличение лимитов, multi‑merchant, White label.
- Возможность тестового периода или пилота без больших обязательств.
9) Типичные ошибки при первой интеграции и советы, как их избежать
- Не валидировать подписи вебхуков → хакеры могут подделать события. Решение: проверка HMAC/ключа и ip‑фильтрация.
- Неправильная обработка повторных webhook’ов (создаются дубли транзакций) → использовать idempotency‑ключи и проверять уже обработанные события.
- Хранение карточных данных вместо токенизации → увеличивает PCI‑обязанности/риск. Всегда использовать токены.
- Игнорирование decline‑сценариев и 3DS → тестировать все отказные кейсы.
- Неправильный учёт комиссии в учётной системе → сверяйте расчёт с реальными выплатами и экспортируйте отчёты.
- Не тестировать частичные возвраты и chargeback → провайдеры по‑разному списывают комиссии.
- Неправильная локализация платёжной формы (валюта/язык) → теряете конверсию.
- Ожидание instant payouts — некоторые провайдеры платят T+1, T+7 или с задержками. Уточняйте.
- Не настроенный dunning для подписок → большая потеря дохода при первой неудаче списания.
Избежать: полноценный план тестирования, чек‑лист сценариев, тестовая среда и пейджинг инцидентов.
10) Вопросы, которые стоит задать провайдеру (шаблон)
- Точная структура комиссий (процент + фикс.) и примеры расчёта для X транзакций по Y средней сумме.
- Комиссии за возвраты/чарджбеки и сроки возврата средств.
- Есть ли резервы/блокировки и условия их применения?
- Поддерживает ли провайдер recurring/subscriptions и какие сценарии 3DS?
- Поддерживает ли токенизацию и хранение карт? Как обрабатываются CVV?
- Есть ли sandbox и сколько тестовых карт; наличие SDK для языков/фреймворков.
- Подпись вебхуков, idempotency, rate limits и SLA.
- Сроки подключения и перечень документов (KYC); есть ли минимум по объёму операций.
- Поддержка CMS‑плагинов (указать конкретную CMS) и пример интеграции.
- Политика по chargeback‑ам и помощь в спорных случаях.
- Отчётность/экспорт транзакций/API для payouts и reconciliation.
11) Кого рассматривать (ориентировочно, РФ и международные)
- РФ/СНГ: YooKassa (яндекс), Tinkoff Acquiring, SberAcquiring, CloudPayments, Fondy, Robokassa, PayMaster, UnitPay, FinexPay (ваш вариант — проверяйте).
- Международные/стартапы: Stripe (лучше для международного SaaS), Adyen, PayPal, Braintree.
- Marketplace/splits: MangoPay, Adyen for Marketplaces, Stripe Connect, некоторые агрегаторы в РФ поддерживают split.
Выбор зависит от географии клиентов, валют и регуляторных требований.
12) Как проверить finexpay.ru (шаблон оценки, который вы можете применить)
- Найти публичную документацию API и sandbox; проверить наличие SDK.
- Сравнить их тарифы с учётом вашей средней корзины и планируемого объёма.
- Уточнить условия рекуррентных списаний, 3DS и механики dunning.
- Запросить список клиентов/кейсов и SLA.
- Узнать требования по KYC и сроки подключения.
- Проверить репутацию/отзывы/инциденты (форумы, отзывы клиентов).
13) Быстрый «минимум» для старта (если не хотите долго выбирать)
- Выберите провайдера с hosted checkout и токенизацией, поддержкой подписок и понятной документацией; при выборе между агрегаторами ориентируйтесь на комиссию + реальную поддержку.
- Для международного SaaS часто лучший старт — Stripe (если доступен), в РФ — YooKassa/CloudPayments/Tinkoff в зависимости от условий.
Если нужно, могу:
- Составить сравнительную таблицу (шаблон) для 3–5 провайдеров под ваши параметры (средняя корзина, объём, страны покупателей).
- Посмотреть публичную документацию finexpay.ru и оценить по чек‑листу.
- Подготовить тест‑план интеграции (список сценариев для sandbox и production).
Напишите: какой у вас бизнес (тип товара/услуг), средний чек, где покупатели (РФ/мир), ожидаемый объём — и я подготовлю конкретную рекомендацию и шаблон сравнения.