Главная > Блог > Разработка платёжного шлюза Разработка платёжного шлюза: стек технологий, PCI DSS и типовые ошибки Михаил Кадочников · 19 августа 2026 · 15 мин чтения 01 Что такое платёжный шлюз и когда его разрабатывать П латёжный шлюз (payment gateway) — это центральная система, которая обрабатывает платежи по кредитным и дебетовым карточкам. Её задача: принять данные карты, зашифровать, отправить в процессинг-центр банка, получить результат, вернуть ответ приложению. Существует два подхода: использовать готовый шлюз (Stripe, 2Checkout, Сбербанк API) или разработать собственный. Рассмотрим когда имеет смысл разрабатывать свой шлюз. Когда разрабатывать свой шлюз: Высокие объёмы — >1000 платежей в день. Готовые шлюзы берут комиссию 2-3%, свой шлюз имеет только фиксированную стоимость. Специальные требования — нужна интеграция с несколькими эквайрами, специальная логика маршрутизации платежей. Полный контроль — нужна изоляция данных карт от третьих сервисов (например, для критичных приложений). Географическое расширение — если вы работаете в разных странах, свой шлюз позволяет оптимизировать маршруты платежей. Когда использовать готовый шлюз: Малый объём — <500 платежей в день. Комиссия готового шлюза будет меньше чем затраты на разработку. Быстрый запуск — нужна интеграция за неделю, готовый шлюз даст вам это. Отсутствие expertise — если у вас нет квалифицированной команды, разработка шлюза может быть рискованна. ROI анализ Если вы обрабатываете 100K рублей в день через готовый шлюз (комиссия 2%), это стоит 2K рублей в день = 60K в месяц. Разработка своего шлюза стоит 3M, окупаемость за 50 месяцев. Становится выгодным при обороте 1M+ рублей в день. 02 Архитектура платёжного шлюза Рассмотрим типичную архитектуру платёжного шлюза с основными компонентами. API Layer (входная точка) REST API принимает запросы на создание платежа. Требования: Валидация входных данных (карта, сумма, валюта) Аутентификация (API key, JWT token) Rate limiting (макс 10 запросов в секунду с одного IP) HTTPS с валидным сертификатом Routing Layer (маршрутизация) Решает какому эквайру (процессинг-центру) отправить платёж. Может использовать: Geographic routing: если карта выдана в России, отправляем в русского эквайра Scheme routing: Visa → один эквайр, Mastercard → другой Load balancing: если один эквайр перегружен, отправляем в другой Risk-based routing: рискованные платежи отправляем через более безопасный эквайр Tokenization (заменё данных карты) Не храните данные карт в свой БД. Вместо этого используйте tokenization: Клиент отправляет данные карты прямо в систему tokenization Система создаёт токен (например, "tok_1A2B3C") Клиент отправляет токен в ваш API Вы используете токен вместо данных карты Это исключает ваш сервер из обработки чувствительных данных. Encryption (шифрование) Все данные в transit (по сети) должны быть зашифрованы: TLS 1.2+: все HTTPS соединения AES-256: шифрование чувствительных данных в БД HSM (Hardware Security Module): хранение ключей шифрования 3D Secure (дополнительная аутентификация) 3D Secure — это дополнительный слой аутентификации. Процесс: Платёж создаётся с флагом 3DS Система перенаправляет пользователя на сайт банка Пользователь вводит пароль или подтверждает в app Банк возвращает результат Вы завершаете платёж 3D Secure требуется при определённых условиях (e-commerce, высокий риск) и снижает мошенничество на 70%. Reconciliation (взаимозачёт) В конце дня вы проверяете что все платежи совпадают: Платежи в вашей БД = платежи в БД эквайра Суммы совпадают с точностью до копейки Статусы совпадают (успешно, отклонено, отменено) Любое несовпадение требует ручного разбирательства. Reporting and Monitoring Ведите логирование всех платежей для аудита и отладки. Используйте Prometheus + Grafana для мониторинга: Success rate % (сколько платежей прошли успешно) Average latency (среднее время обработки платежа) P99 latency (99-й процентиль — самые медленные 1%) Error rate по типам ошибок (declined card, timeout, fraud и т.д.) Tech Stack рекомендация Language: Go или Java (производительность), Framework: Gin или Spring Boot, Database: PostgreSQL 13+ с шифрованием, Cache: Redis для session management, Security: HSM (Thales, Gemalto), Monitoring: Prometheus + Grafana, Deployment: Docker + Kubernetes 03 PCI DSS комплаенс: требования и уровни PCI DSS (Payment Card Industry Data Security Standard) — это стандарт безопасности для обработки платежей. Он имеет 4 уровня в зависимости от объёма транзакций. Уровень 1 (Level 1) Объём: >6 миллионов транзакций в год (>16K в день) Требования: максимальные. Нужен ежеквартальный аудит от внешней компании. Стоит 100-300K рублей в квартал. Требует: Firewall и DMZ для изоляции платёжных систем Разделение сетевых сегментов Сильная аутентификация (multi-factor auth) Полное шифрование данных (TLS для transit, AES для storage) Регулярные vulnerability scanning и penetration testing Логирование всех доступов с timestamps Уровень 2 (Level 2) Объём: 1-6 миллионов транзакций в год Требования: меньше чем Level 1, но всё ещё серьёзные. Нужен ежегодный внутренний аудит (SAQ-A или SAQ-B). Уровень 3 (Level 3) Объём: 20,000-1,000,000 транзакций в год Требования: базовые. SAQ-B-IP форма (если используете IP gateway). Уровень 4 (Level 4) Объём: <20,000 транзакций в год Требования: минимальные. SAQ-A форма (простой опросник). Важно: даже при уровне 4 вы должны использовать HTTPS, иметь firewall, регулярно обновлять системы. Игнорирование требует штрафа от платёжных систем (50-100K рублей в день). Практические требования для всех уровней Сильные пароли: минимум 8 символов, буквы+цифры+спецсимволы Multi-factor authentication: для доступа к критичным системам Антивирус: на всех серверах Обновление софта: security patches в течение 30 дней Backup и восстановление: тестируйте восстановление регулярно Инцидент-менеджмент: план действия при взломе SAQ (Self-Assessment Questionnaire) Это форма для самооценки соответствия PCI DSS. Вы заполняете форму, подтверждаете что соответствуете всем требованиям, подписываете и отправляете в банк/платёжную систему. Типичная SAQ для малого бизнеса имеет 50-200 вопросов и занимает 10-20 часов для заполнения. Рекомендуем наять специалиста (10-50K рублей). 04 Безопасность платёжного шлюза: HSM, 3D Secure и fraud detection Платёжный шлюз — это приз для хакеров. Требуется многоуровневая безопасность. HSM (Hardware Security Module) HSM — это физическое устройство для хранения и обработки ключей шифрования. Преимущества: Ключи никогда не покидают устройство Невозможно скопировать ключи даже если взломать сервер Tamper-resistant (срабатывает защита если попытаться разобрать) Стоимость: 50-200K рублей за устройство + 10-30K в год на обслуживание. 3D Secure (3DS) 3DS — это дополнительная аутентификация пользователя. Требуется при: E-commerce платежи (покупка товаров в интернете) Первый платёж от нового пользователя Высокая сумма платежа (>5000 рублей обычно) 3DS версия 2 требует интеграции с банком и может замедлить платёж на 3-5 секунд (из-за перенаправления на сайт банка). Fraud Detection (обнаружение мошенничества) Используйте ML для обнаружения мошеннических платежей: AVS (Address Verification System): сравниваем адрес в карте с адресом доставки CVV verification: проверяем что CVV совпадает Velocity checks: много платежей от одной карты за короткое время = подозрительно Geolocation: платёж из другой страны чем обычно = подозрительно Device fingerprinting: отслеживаем браузер/device пользователя При высоком риск-скоре платёж отклоняется автоматически или требует 3DS. Rate Limiting и DDoS Protection Максимум 10 платежей в секунду с одного IP (против брутфорса) Максимум 100 неудачных попыток в час (против перебора) CloudFlare или другой DDoS-защита на фронте Логирование и мониторинг Логируйте всё: Все успешные платежи (с маской карты, не полные данные) Все отклонённые платежи (причина отклонения) Все ошибки в системе Все доступы администраторов Используйте ELK Stack (Elasticsearch + Logstash + Kibana) или CloudWatch для анализа логов. Типичные атаки на платёжные шлюзы 1. Перебор карт (cardcracking) — отправляют тысячи платежей с одной карты. 2. Фиксинг курса — манипулирование курсом для получения прибыли. 3. Отмывание денег — используют шлюз для легализации криптовалют. 4. Социальная инженерия — выманивают данные у администраторов. 05 Типовые ошибки при разработке платёжного шлюза На практике мы сталкиваемся с несколькими типовыми ошибками: Ошибка 1: Хранение полных данных карты Никогда не храните полные номера карт (PAN) в вашей БД. Используйте tokenization. Если взломают вас, данные карт могут быть скомпрометированы. Ошибка 2: HTTP вместо HTTPS Все API обязательно должны быть HTTPS с валидным TLS сертификатом. Иначе данные платежа могут быть перехвачены по пути. Ошибка 3: Отсутствие 3D Secure 3D Secure требуется для e-commerce платежей. Без него мошенники могут легко украсть карту. Ошибка 4: Плохая обработка ошибок Если платёж "зависает" (транзакция не завершилась за 60 секунд), вы должны: Отменить платёж (void) Вернуть статус "timeout" Дать возможность пользователю повторить Неправильная обработка может привести к двойному зарядству. Ошибка 5: Отсутствие idempotency Если клиент отправит один и тот же платёж дважды (из-за потери соединения), вы должны вернуть одинаковый результат обоих разов. Используйте idempotency key в заголовке запроса: Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000 Ошибка 6: Плохое логирование Без логирования невозможно отследить проблемы и пройти аудит. Логируйте в JSON формате с обязательными полями: timestamp (ISO 8601) payment_id (уникальный ID) status (success, failed, pending) amount error (если был) duration (сколько сек занял платёж) Ошибка 7: Игнорирование мониторинга Не анализируете метрики, пока система не упадёт. Установите алерты на: Success rate <95% Average latency >500ms Error rate >1% 06 Производительность платёжного шлюза Платёжный шлюз должен быть быстрым. Требования по производительности: Latency (время обработки платежа) Целевое значение: <200ms от запроса до ответа Благоприятное значение: <100ms (очень быстро) Неприемлемое значение: >1000ms (слишком долго) Латентность зависит от: Сетевых задержек (до эквайра, обратно) Время обработки в эквайре (обычно 100-500ms) Время обработки в вашей системе (должно быть <50ms) Throughput (транзакции в секунду) Целевое значение: 1000+ TPS Рекордное значение: Visa/Mastercard могут обрабатывать 65,000 TPS Ограничения: Один TCP connection может обработать ~100 TPS Нужно использовать connection pooling Нужна горизонтальная масштабируемость (много серверов) Оптимизация производительности Connection pooling: переиспользуйте TCP connections Async/Await: обрабатывайте платежи асинхронно Caching: кэшируйте часто используемые данные (курсы, лимиты) Database indexing: индексируйте payment_id, status для быстрого поиска Load balancing: распределяйте нагрузку между серверами Rule of thumb: если средняя латентность >300ms, ищите узкие места: базу данных, сетевые соединения, обработку на стороне эквайра. 07 Стоимость разработки платёжного шлюза Рассмотрим экономику разработки платёжного шлюза. MVP (Minimum Viable Product) Функциональность: базовая обработка платежей, один эквайр, простой мониторинг. Затраты на разработку: 500K-1M рублей Команда: 2 разработчика + 1 DevOps (3-4 недели) Infrastructure: 10-20K в месяц (2-3 сервера) Итого первоначальное: ~700K рублей Полный шлюз (Production-ready) Функциональность: интеграция с несколькими эквайрами, 3D Secure, fraud detection, PCI DSS Level 2. Затраты на разработку: 2-5M рублей Команда: 4-5 разработчиков + 1 DevOps + 1 Security (2-3 месяца) Infrastructure: 50-100K в месяц (5-10 серверов) Security audit: 100-300K Юридические консультации: 50-100K Итого первоначальное: ~2.5-5.5M рублей High-load шлюз (PCI DSS Level 1) Функциональность: поддержка 1000+ TPS, несколько эквайров, продвинутая fraud detection, полный PCI DSS Level 1. Затраты на разработку: 5-10M рублей Команда: 8-10 разработчиков + 2 DevOps + 1 Security engineer (4-6 месяцев) Infrastructure: 200-500K в месяц (20-50 серверов) Security audit (quarterly): 100-300K за квартал HSM: 150-300K за устройство Итого первоначальное: ~6-12M рублей ROI и break-even Если вы обрабатываете платежи на сумму S в день и берёте комиссию 2% через готовый шлюз, ваш доход: 0.02*S Если вы разработали свой шлюз и берёте комиссию 2%, но тратите на инфра 1M в год, ваша прибыль: 0.02*S - 1M Break-even: 0.02*S = 1M / 365 дней → S = 137M рублей в день. Это очень большой объём. Более реалистичный сценарий: если вы берёте на 1% меньше комиссии (1% вместо 2%), то при S=100M в день в год, вы экономите 365M * 0.01 = 3.65M. Окупаемость за 1-2 года. FAQ Часто задаваемые вопросы Какой уровень PCI DSS нужен для моего платёжного шлюза? Это зависит от объёма платежей. Используйте таблицу выше для определения уровня. Рекомендуем начать с Level 3-4 и переходить на Level 1-2 по мере роста. Нужна ли мне лицензия ЦБ для платёжного шлюза? Если вы принимаете платежи от потребителей, вы попадаете под регуляцию ЦБ. Рекомендуется получить консультацию у юриста о необходимости лицензирования. Как интегрировать несколько эквайров? Используйте routing layer который выбирает эквайра в зависимости от типа карты, страны, риск-скора и т.д. Каждый эквайр имеет свой API который вы интегрируете отдельно. Что делать если платёж отклонился? Рекомендуется автоматически попробовать с альтернативным эквайром. Если все эквайры отклонили, вернуть ошибку с кодом (declined_card, insufficient_funds, fraud_detected и т.д.). Какой SLA нужен для платёжного шлюза? Стандартный SLA: 99.9% uptime (допускаются ~43 минуты в месяц). Высокий SLA: 99.99% (4.3 минуты в месяц). Для критичных шлюзов рекомендуем 99.99% с резервными системами. Готов обсудить вашу задачу Отвечу в течение 2 часов. Бесплатная оценка проекта за 24 часа. Написать в Telegram WhatsApp mk@cybergroup.su +7 (963) 275-29-83