Платёжная система — один из самых важных элементов любого приложения. От неё зависит не только удобство пользователей, но и стабильность выручки. Когда мы запускали RuStore, быстро поняли: платежи должны работать безупречно, иначе страдают и пользователи, и разработчики.
На старте мы использовали внешнее решение, чтобы быстро запустить процесс монетизации. Но со временем, когда стор вырос и количество интеграций увеличилось, стало очевидно: для гибкости, скорости и контроля нам нужно собственное решение. Так в RuStore появилась идея создать Pay SDK — платёжное решение, которое мы спроектировали с нуля под реальные задачи российских разработчиков и наших пользователей.
Меня зовут Алексей Мольков, я менеджер продукта в RuStore. В этой статье расскажу, как мы пришли к решению написать свой SDK, какие вызовы прошли по пути и какие преимущества уже видят команды, которые его используют.
Как мы пришли к собственному SDK
Когда в 2022 году российские разработчики столкнулись с ограничениями в зарубежных магазинах приложений, стало очевидно: индустрии нужен собственный стор. Так появился RuStore. Однако просто запустить площадку было недостаточно — важно было сразу дать разработчикам инструменты для монетизации.
Чтобы быстро запуститься в условиях ограниченных ресурсов, мы выбрали готовое платёжное решение с базовой функциональностью, каталогом продуктов и системой выплат, а сверху добавили своё — обёртку над SDK, web-консоль для удобного управления платежами и продуктами, а также публичное API. Всё это позволило оперативно включить приём платежей и сосредоточиться на развитии стора.
Поначалу схема работала, но с ростом числа интеграций стала проявляться обратная сторона стороннего решения:
Ограниченная гибкость и кастомизация. Любые изменения или доработки требовали долгих согласований, сроки сдвигались, а часть задач становилась попросту невыполнимой;
Сложности с техподдержкой. Любой вопрос приходилось решать через внешнюю команду — ждать ответа, уточнять детали, терять время.
В итоге стало очевидно: если мы хотим двигаться со скоростью рынка, нужно управлять процессом монетизации самостоятельно. Так и родилась идея написать собственный SDK, адаптированный под российские реалии и потребности наших пользователей.
Переход к собственному SDK: вызовы и решения
Мы стремились сделать систему, которая будет надёжной, понятной и реально полезной для разработчиков. К этому моменту у нас уже был большой массив фидбэка от паблишеров — он и помог решить, какие функции оставить, а какие переработать.
Каждая задача на этом пути требовала отдельного подхода и внимательного отношения к деталям.
1. Бесшовный переход
Смена платёжного решения — всегда риск: чем сложнее процесс, тем выше шанс сбоев. Поэтому постарались сделать переход для разработчиков максимально простым и прозрачным.
Что сделали:
сохранили привычную структуру API, убрав лишние параметры и сделав её компактнее;
подготовили подробные гайды по переходу со старого SDK;
перенесли историю платежей и каталог продуктов из инфраструктуры вендора в VK.
В итоге миграция оказалась почти незаметной: приложения продолжили работать без сбоев, а интеграция заняла минимум усилий.
2. Платёжное ядро и инфраструктура с нуля
Создание собственного SDK означало, что всю внутреннюю логику платежей нужно строить с нуля. Мы спроектировали надёжное платёжное ядро, способное корректно обрабатывать стандартные покупки, возвраты, отмены, повторные попытки оплаты, работу с подписками и сложные крайние случаи (например, двойные списания или незавершённые транзакции).
Параллельно требовалось создать инфраструктуру для хранения и управления каталогом товаров и подписок, а также интегрировать всё с внутренними сервисами RuStore.
Отдельной задачей стало обновление логики двухстадийных платежей. В старом решении все потребляемые товары проходили в два шага, а непотребляемые — в один. Такой подход мешал строить прозрачную и предсказуемую обработку покупок.
Чтобы всё это собрать воедино, подключили экспертизу специалистов по ИБ, архитекторов, техлидов Backend- и Android-разработки. В результате получили систему, которая отвечает требованиям безопасности и надёжности, выдерживает продакшен-нагрузку и при этом остаётся гибкой для доработок.
Что получилось:
Собственная инфраструктура и сервисы. Теперь у нас полностью независимая и надёжная система, логику которой мы контролируем и можем при необходимости быстро дорабатывать;
Гибкая работа с платежами. Мы обновили подход к двухстадийным покупкам: теперь любой продукт можно оплатить как по одно-, так и по двухстадийной схеме — разработчик сам выбирает удобный вариант.
3. Поддержка привычных способов оплаты
Для российских пользователей важно, чтобы оплата происходила привычно и без лишних шагов. Поэтому мы сразу заложили поддержку ключевых платёжных методов и сделали процесс максимально простым.
Что сделали:
с самого старта SDK поддерживает основные способы оплаты РФ, а архитектура позволяет быстро добавлять новые;
добавили функцию запоминания последнего метода оплаты — повторные покупки проходят быстрее, что напрямую повышает конверсию.
4. Простота интеграции и качественная поддержка
Разработчики ожидают от SDK двух вещей: чтобы он подключался без боли и чтобы на вопросы быстро отвечали.
Что сделали:
сократили число зависимостей в SDK, чтобы минимизировать конфликты и ускорить интеграцию;
отправляем чеки в налоговую, избавляя разработчиков от необходимости самим налаживать процесс фискализации;
подготовили подробную документацию и примеры кода;
обучили команду поддержки, которая помогает на всех этапах интеграции.
5. MVP и масштабирование
Мы пошли по пути MVP — запустили минимально жизнеспособный продукт, чтобы как можно быстрее проверить его в реальных условиях. Сразу закрыть все сценарии и охватить весь рынок нереалистично, поэтому сделали ставку на постепенное масштабирование и тесную работу с командами.
Так, на старте SDK тестировали несколько компаний в закрытой бете (об этом уже рассказывали на Хабре). Мы наблюдали за интеграцией, собирали обратную связь, оперативно правили ошибки. Такой цикл «проверка — фиксы — снова тест» помог быстро стабилизировать продукт.
К моменту публичного запуска Pay SDK прошёл несколько итераций доработок, успешно выдержал нагрузочное тестирование и показал стабильность. Благодаря этому релиз прошёл спокойно: разработчики сразу получили рабочий инструмент для монетизации.
Результаты и преимущества нового решения
Переход на собственный SDK снял ограничения внешнего решения и сделал работу с платежами гибче и удобнее для разработчиков.
В мае 2025 года мы запустили RuStore Pay SDK. Ниже рассказываем, какие возможности он открыл и как изменился опыт паблишеров после релиза.
1. Сохранение ключевых сценариев работы с платежами
В новом SDK мы сохранили всё, к чему привыкли разработчики в повседневной работе:
режим песочницы для тестирования интеграции без реальных списаний;
серверные уведомления (callback) о статусах платежей;
публичное API для интеграции с бэкендом;
поддержку популярных движков для Android-разработки.
Всё это помогло сделать миграцию безболезненной.
2. Новые инструменты и удобный UI
В Pay SDK появились функции, которых не хватало в старом решении:
callback-уведомления по тестовым платежам — теперь отладка интеграции стала удобнее;
работа с developer payload в API и Консоли — можно гибко передавать и обрабатывать дополнительные данные о заказе;
обновлённый UI для пользователей — интерфейс стал интуитивнее и быстрее;
расширенные инструменты для работы с подписками прямо в Консоли разработчика;
нативная поддержка промо-активностей — выпуск купонов на скидку без костылей.
3. Гибкость под задачи российского рынка
Pay SDK изначально создавался под RuStore и российскую аудиторию, что дало главное преимущество — гибкость:
можно быстро внедрять новые функции;
оперативно подключать востребованные способы оплаты;
реагировать на фидбэк разработчиков без долгих согласований.
4. Поддержка без посредников
Теперь все вопросы паблишеров решает наша команда напрямую. Это значит — быстрые ответы, оперативные фиксы, понятная и прозрачная коммуникация.
5. Локальные способы оплаты
С самого старта SDK поддерживает ключевые инструменты, к которым привыкли наши пользователи: карты российских банков, СБП и SberPay. Архитектура позволяет быстро подключать новые методы — их интеграция занимает минимальное время.
6. Стабильность и отказоустойчивость
SDK работает на инфраструктуре VK, а все ключевые процессы мы держим под собственным контролем. Это позволяет выдерживать пиковые нагрузки и гарантировать стабильность сервиса без просадок в критичные моменты. Основные сценарии поставлены на мониторинг 24/7, поэтому если всё же что-то пойдет не так, реакция и починка будет быстрой.
7. Рост метрик и новые механики монетизации
Оптимизация пользовательского пути и новые сценарии оплаты сделали покупки проще и прозрачнее. В итоге пользователи стали чаще завершать оплату, а конверсия выросла примерно на 20%. Pay SDK стал не просто техническим решением, а инструментом, который напрямую влияет на рост доходов разработчиков в RuStore.
Заключение
Опыт показал: чтобы развиваться, важно брать контроль в свои руки. Создание своего SDK потребовало много сил, но дало главное — гибкость, скорость и предсказуемость.
Сегодня Pay SDK стабильно работает в сотнях приложений, помогает разработчикам зарабатывать и даёт пользователям удобный и понятный сценарий оплаты. Мы не останавливаемся: впереди новые методы оплаты, дополнительные инструменты монетизации и улучшения по запросам сообщества.
А чтобы продукт развивался в правильном направлении, мы продолжаем собирать фидбэк в RuStore Dev Chat — чем больше честной обратной связи, тем быстрее SDK станет ещё удобнее для всех.