Переход RuStore с BillingClient SDK на Pay SDK
Переход RuStore с BillingClient SDK на Pay SDK сохраняет оплату внутри Android-приложения после завершения поддержки прежней библиотеки. В официальной документации RuStore указана дата 1 августа 2026 года: после неё BillingClient SDK прекращает обработку покупок, включая подписки.
Pay SDK использует другую зависимость, другой способ инициализации и обновлённые интерфейсы для товаров, покупок, статусов и ошибок. Поэтому замена названия пакета в Gradle оставляет часть приложения в старой модели. Мы прослеживаем весь платёжный маршрут: карточка товара, нажатие кнопки, открытие формы, возврат в приложение, выдача доступа, серверная проверка и восстановление покупки.
В Pay SDK consoleApplicationId переносится в AndroidManifest.xml, работа с каталогом идёт через ProductInteractor, а покупки — через PurchaseInteractor. Для серверной валидации разовой покупки используется invoiceId, данные подписки проверяются по идентификатору покупки и актуальным методам RuStore API.
Действующие подписчики требуют отдельного переходного маршрута между двумя SDK, тогда как разовые покупки доступны после перехода. Мы строим эту логику по официальной рекомендации, проверяем её на реальных типах продукта и выпускаем приложение с понятным журналом. Пользователь видит привычный продукт и корректный статус доступа, а команда поддержки может связать покупку, счёт, аккаунт приложения и ответ сервера.
Когда стоит обратиться
Обычно к нам обращаются в таких ситуациях:
- В проекте подключена зависимость ru.rustore.sdk:billingclient или создаётся RuStoreBillingClient через фабрику.
- Приложение продаёт разовые товары, подписку или цифровой доступ и зависит от платежей RuStore.
- После пробной замены SDK перестали совпадать статусы, модели Product и Purchase либо серверная проверка.
- У приложения есть действующие подписчики, для которых требуется сохранить оплаченный период и корректный доступ.
Что именно мы сделаем
Находим все вызовы BillingClient SDK, серверные проверки, товары, подписки и места выдачи доступа.
Сопоставляем старые методы и модели с ProductInteractor, PurchaseInteractor и статусами Pay SDK.
Обновляем зависимость, AndroidManifest.xml, deeplink, платёжный экран, ошибки и серверную валидацию.
Настраиваем переходный сценарий для действующих подписок и новые покупки через Pay SDK.
Проводим тестовые операции, готовим релиз и передаём карту изменений с инструкцией контроля.
Что входит в стоимость
79 900 ₽ за всю работу
Разбираем текущую реализацию BillingClient SDK и серверную часть платежей, составляем карту товаров, подписок и статусов, затем переводим приложение на актуальные интерфейсы Pay SDK. Настраиваем consoleApplicationId, deeplink, продуктовый каталог, покупку, подтверждение, восстановление доступа и серверную валидацию. Выпускаем тестовую сборку, проводим контрольные платежи и готовим рабочий релиз с журналом и инструкцией поддержки.
Что будет готово
Передадим вам
- Рабочая сборка приложения с RuStore Pay SDK и актуальными платёжными интерфейсами.
- Обновлённая серверная валидация разовых покупок и подписок с журналом состояний.
- Переходный сценарий для действующих подписчиков и карта соответствий BillingClient и Pay SDK.
- Протокол контрольных платежей, инструкция выпуска и порядок диагностики обращения пользователя.
Перед сдачей проверим
- Приложение получает выбранный каталог товаров через Pay SDK и показывает актуальные цены и типы продуктов.
- Контрольная разовая покупка проходит форму, серверную проверку и выдаёт доступ одному пользователю один раз.
- Новая и действующая подписка дают ожидаемый статус и срок доступа по утверждённому переходному сценарию.
- Отмена, временная ошибка и повтор запуска отражаются в интерфейсе и журнале с понятным итогом операции.
Как это выглядит на практике
Покупка приложения проходит через Pay SDK и подтверждается сервером
- 01
Приложение получает продукт через ProductInteractor и показывает пользователю цену из RuStore.
- 02
PurchaseInteractor открывает форму оплаты, а результат связывается с аккаунтом приложения и invoiceId.
- 03
Сервер проверяет операцию через RuStore API, сохраняет статус и включает оплаченный доступ.
- 04
После повторного входа приложение читает состояние покупки и показывает пользователю активный продукт.
Что понадобится для работы
От вас
- Исходный код Android-приложения, Gradle-конфигурация и описание процесса сборки и выпуска.
- Доступ разработчика к приложению RuStore, перечень продуктов и настройки тестовых платежей.
- Код и журнал платёжного сервера, схема таблиц покупок, подписок и пользовательского доступа.
- Контрольные аккаунты и сценарии разового товара, подписки, отмены и восстановления покупки.
Если у вас немного другая ситуация
Небольшие уточнения, которые помогают довести согласованный результат до рабочего состояния, уже учитываем в цене. Если по ходу работы появится отдельный крупный блок или понадобится платная лицензия, сначала обсудим варианты и стоимость. Расскажите о своей ситуации — подстроим план под неё.
- 3 000 ₽после подписания договора через Диадок
- 76 900 ₽после выполнения, демонстрации и приёмки результата
Предоплата входит в общую стоимость. Оставшуюся сумму оплачиваете после демонстрации и приёмки готовой работы.
Часто спрашивают
Об этой услуге
Когда RuStore прекращает поддержку BillingClient SDK?
Официальная документация называет 1 августа 2026 года. После этой даты покупки через BillingClient SDK, включая подписки, перестают обрабатываться, поэтому рабочий релиз Pay SDK стоит подготовить заранее.
Достаточно заменить зависимость billingclient на pay?
Переход затрагивает инициализацию, AndroidManifest.xml, deeplink, получение продуктов и покупок, модели статусов, обработку ошибок и серверную проверку. Мы обновляем весь платёжный маршрут и проверяем его контрольными операциями.
Что произойдёт с разовыми покупками после перехода?
RuStore указывает, что товары, купленные через BillingClient SDK, доступны в Pay SDK. Мы дополнительно проверяем восстановление покупки и связь с внутренним аккаунтом приложения.
Как обрабатываются действующие подписки?
Для действующих подписок требуется отдельный миграционный маршрут. Новые оформления идут через Pay SDK, а ранее оплаченный доступ учитывается по данным старой подписки и серверному реестру.
Можно сохранить текущий дизайн платёжного экрана?
Да. Сохраняем логику каталога и кнопок приложения, а технический слой переводим на Pay SDK. Состояния оплаты и ошибок уточняются там, где новый интерфейс возвращает другую модель результата.
Какие способы оплаты проверяются?
Проверяем доступные для приложения способы Pay SDK и выбранный одностадийный либо двухстадийный сценарий. Конкретный набор зависит от настроек RuStore, продукта и версии SDK на дату выпуска.
Нужны ли изменения на сервере приложения?
Да, когда сервер подтверждает оплату или управляет доступом. Обновляем идентификаторы проверки, модели статусов, защиту от повторов и связь покупки с пользователем и продуктом.
Как принимается переход на RuStore Pay SDK?
Проходим каталог, разовую покупку, подписку, отмену, повтор, восстановление и серверную проверку. Результат подтверждается экраном приложения, данными RuStore и техническим журналом.
Цена и изменения по ходу работы
Цена на странице окончательная?
Да. Перед началом мы сверяем исходные данные и фиксируем результат в договоре. Указанная на странице сумма покрывает согласованную работу целиком, даже если её техническая реализация потребует больше времени, чем ожидалось при оценке.
Что означает резерв незапланированных работ?
Это уже включённый в цену запас времени на небольшие связанные уточнения заказчика, которые появляются после старта: например, добавить поле, изменить формат уведомления или учесть ещё одно условие обработки.
Резерв рассчитывается по формуле: стоимость услуги × 30% ÷ 1 500 ₽. Для услуги за 30 000 ₽ это 6 часов. Эти часы относятся только к дополнительным, заранее незапланированным уточнениям. Они не являются сроком проекта и не ограничивают время на основную работу: согласованный результат мы выполняем полностью.
Можно уточнять детали уже во время работы?
Да. Небольшие связанные изменения обычно помещаются во включённый резерв и не требуют доплаты. Если новая идея заметно меняет результат или превращается в самостоятельную задачу, сначала обсудим подход и стоимость. Любое решение согласуем до выполнения.
Начало работы и оплата
Как оформляются договор и оплата?
Подписываем договор через Диадок. Предоплата составляет 3 000 ₽ и входит в общую стоимость услуги. Остаток оплачивается после демонстрации и приёмки готового результата.
Когда начинается срок выполнения?
Срок отсчитывается после согласования задачи, получения необходимых доступов и материалов, подписания договора и поступления предоплаты. Конкретную дату старта и плановый день готовности подтверждаем перед началом.
Как учитываются платные лицензии и внешние сервисы?
До старта проверяем, нужны ли тарифы, лицензии, сертификаты или дополнительные ресурсы внешних систем. Если они потребуются, заранее покажем варианты и стоимость. По возможности аккаунты и лицензии оформляются сразу на заказчика.
Проверка результата и гарантия
Как принимается готовая работа?
Вместе проверяем согласованные сценарии на контрольных данных или тестовой копии, а затем демонстрируем результат. Для интеграций сверяем передачу данных и обработку ошибок, для сайта — работу нужных страниц и действий пользователя, для отчёта — расчёты и обновление данных.
Какая гарантия действует после сдачи?
На выполненные изменения действует гарантия 3 месяца. Если в изменённой нами части обнаружится ошибка нашей реализации, проверим и исправим её без дополнительной оплаты. Переданные материалы, настройки и код остаются у заказчика.
Связанные шаги
- 01Регулярные платежи и подписки через СБП
Настроить регулярные платежи и подписки
- 02Переход RuStore с BillingClient SDK на Pay SDK
Перевести приложение RuStore на Pay SDK
- 03Восстановление и повторные платежи подписки ЮKassa
Настроить восстановление платежей подписки