Разработка / ROBLOX
ProcessReceipt в Roblox: план проверки выдачи Developer Product
Отделите показ окна покупки от выдачи, новую покупку от повторной обработки и выполнение функции от её результата. Составьте проверяемые условия для обработчика до запуска платного товара.
Определите результат покупки #
Начните с точного обещания: условный набор добавляет тренировочные жетоны к сохранённому профилю игрока. Укажите размер набора, область использования и то, что должно остаться после нового входа. Слова «начислено» недостаточно, если речь только о временной надписи на экране.
В статье нет рабочего магазина, реальных ID, покупок или готового обработчика. Мы составляем план проверки для автора игры. Учебные обозначения A и B — разные операции, не настоящие чеки игроков. Не подставляйте этот план вместо проверенной реализации продажи.
Разделите окно и серверную выдачу #
Показ окна означает лишь начало пользовательского сценария. Документация отдельно предупреждает: PromptProductPurchaseFinished нельзя использовать для обработки выдачи Developer Product; срабатывание события само по себе не доказывает успешную покупку. Обработку receipt нужно рассматривать отдельно от реакции кнопки.
В своём плане заведите разные наблюдения: окно показано, receipt получен, эффект подтверждён, обработка подтверждена платформе. Не объединяйте их в одно событие «успех». Если видна только анимация кнопки, состояние сохранённого профиля остаётся неизвестным.
Различайте товар и конкретную операцию #
ProductId отвечает на вопрос, какой товар обрабатывается. PurchaseId позволяет различать конкретные покупки. Два receipt с одним ProductId могут относиться к двум самостоятельным покупкам; повтор того же PurchaseId — другая ситуация, требующая проверки уже выполненной операции.
Наша первая пара случаев: A обработан впервые, затем A поступил повторно. Вторая: A обработан, затем появился новый B для того же товара. В первом случае ожидается отсутствие повторного эффекта A, во втором — отдельный результат B. Блокировка всего товара после первой покупки смешивает эти задачи.
Открыть изображение крупнее ↗Не путайте отсутствие ошибки и результат #
Защищённый вызов может завершиться без исключения, а внутренняя функция вернуть отказ или не выдать предмет. Поэтому в предлагаемой карточке есть два поля: выполнен ли вызов и подтверждён ли нужный эффект. Это разные утверждения, которые нельзя заменять одним флагом.
Запланируйте случай «обработчик вернул false без ошибки». Ожидаемая реакция должна соответствовать отсутствию выдачи, а не только успешному выполнению функции. Отдельно рассмотрите исключение и отсутствие нужного состояния игрока. В статье нет кода, который выдаёт эти результаты автоматически.
Рассматривайте эффект и запись вместе #
Для сохраняемых жетонов нужны согласованные сведения: фактический результат в профиле и запись о обработанной покупке. Если изменить временный баланс, а запись о завершении не сохранить, повтор может встретить неполное состояние. Если записать завершение раньше эффекта, можно ошибочно считать невыполненную выдачу законченной.
Нарисуйте точки отказа между этапами и опишите восстановление для каждой. Обычный удачный запуск не проверяет эти промежутки. Хранение только одного флага рядом с несохраняемым значением не является доказательством надёжной выдачи. Архитектуру сохранения и повторов нужно отдельно проверить до продажи.
Зафиксируйте контракт выбранного API #
ProcessReceipt возвращает значение Enum.ProductPurchaseDecision. В документации MarketplaceService также есть BindReceiptHandler с отдельными типами receipt и Enum.ReceiptDecision. Не смешивайте значения возврата и способы регистрации из двух контрактов в одном примере.
Наш материал рассматривает план для ProcessReceipt, а не объявляет обязательную миграцию между API. Запишите, какой контракт использует будущая реализация, где находится серверный обработчик и кто отвечает за регистрацию. Для ProcessReceipt документация описывает одну установку callback серверным скриптом; случайное переопределение другим скриптом требует исследования.
Включите неполные условия выдачи #
Запланируйте receipt для отсутствующего игрока, неизвестного товара и ещё не готового профиля. Для каждого заранее определите, какие сведения нужны, чтобы подтвердить выдачу. Отсутствие этих сведений нельзя превращать в уверенное сообщение «всё получено».
Также включите ошибку сохранения и повторный вход. Сохраняйте минимальный технический контекст и исходное наблюдение, не публикуйте персональные данные или реальные чеки на сайте. Не обещайте конкретную задержку повторной обработки: здесь проверяется логика решения, а не расписание платформы.
Отдельно проверьте повторы и несколько серверов #
Тест «A два раза подряд в одной сессии» полезен, но не охватывает конкурирующую обработку и сбой между изменением эффекта и сохранением. В API-примере ProcessReceipt прямо указано ограничение относительно межсерверных сбоев данных. Копирование примера не снимает этот вопрос.
В плане выделите параллельные попытки, повтор после неизвестного результата записи и повторяемые преобразования состояния. Не добавляйте внешние необратимые эффекты внутрь повторяемой операции без отдельного протокола. Это инженерные вопросы для реализации, а не доказательство, что наш учебный магазин уже защищён.
Составьте матрицу ожидаемых результатов #
Для каждого случая запишите исходное состояние, идентификатор операции, ожидаемое изменение и условие подтверждения. Начните с A, повторного A и нового B. Затем добавьте неготовый профиль и неудачную запись. Таблица ниже — вопросы проверки, не результаты оплаченных тестов.
Ожидаемый результат должен относиться к конкретной операции и сохраняемому эффекту. «Ошибок в Output нет» не отвечает на вопрос о двойном начислении. После изменения обработчика повторите не только обычный путь, но и случай, из-за которого менялась логика.
| Случай | Что проверить |
|---|---|
| Первое A | Подтверждён ли один эффект? |
| Повтор A | Отсутствует ли второй эффект A? |
| Новое B | Есть ли отдельный эффект B? |
| Запись не удалась | Как восстановить неизвестный результат? |
Передайте доказательства и нерешённые вопросы #
Карточка передачи содержит тип товара, выбранный API, модель профиля, сценарий повтора, фактическое наблюдение и оставшиеся ограничения. Укажите, была ли проверка мысленной, имитационной или выполненной в отдельной тестовой игре. Эти уровни не подтверждают друг друга автоматически.
До запуска нужна проверенная реализация, которая связывает эффект и подтверждение покупки при сбоях. Этот гайд помогает сформулировать такую задачу, но не подтверждает готовность продаж ваших игр. Не делайте реальную покупку ради демонстрации текста статьи и не объявляйте гипотезу проверенным результатом.
Открыть изображение крупнее ↗| Поле | Что записать |
|---|---|
| Контракт | Выбранный API и возврат |
| Операция | Товар и конкретная покупка |
| Эффект | Сохраняемый результат и повторы |
| Доказательство | Вид проверки, наблюдение, пределы |
Первоисточники
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — MarketplaceService API
