Comments 20
Между покупкой в приложении и фактическим подтверждением платежа от стора – есть окно, примерно от часа до суток.
Это где такое? Вроде как в Google Play и App Store приходит всё сразу. Или речь о чём-то другом?
С помощью специализированных программ можно подменить данные, которые приложение отправляет на сервер. В том числе, можно изобразить покупку.
Для этого все вендоры очень настоятельно рекомендуют делать проверку на стороне сервера, а не на стороне приложения.
Порядок такой:
- Пользователь нажимает «Оплатить».
- Стор снимает с него деньги и сразу присылает нам данные об оплате (в приложение).
- Мы эти данные из приложения отправляем на наш сервер.
- Сервер обращается к стору, чтобы проверить, что оплата действительно была.
И вот на этом этапе бывает задержка.
Тут три варианта развития событий:
- стор сразу говорит, что все ок, оплата прошла;
- стор говорит «я ещё думаю» и тогда нужно будет повторить запрос позже;
- стор говорит «не было такой оплаты» и мы понимаем, что это мошенник.
Если потом оплата отвалилась, то можно подписаться на уведомления, делать polling, но это уже другая задача. По-крайне мере, была реальная попытка оплатить и я таким пользователям доверяю. По моей статистике они почти всегда пытаются заплатить ещё раз и тогда транзакция проходит.
P.S.: Если хочется подшутить немного над разработчиком, то достаточно задать вопрос о том, что он знает про «com.zeptolab.ctrbonus.superpower1».
Один из самых популярных iap взломщиков для iOS прикидывается именно под эту покупку, которая совершенна валидная, так как была реально сделана когда-то в июле 2012 года. И, конечно, которая по этой причине проходит все проверки на стороне Apple кроме «product-id» и «bid»).
Маловероятные ошибки на проде!
Например у нас есть ошибка, срабатывающая у каждого 1000-нго игрока, совершающего покупку. У нас была ошибка округления float на разных платформах. (Сразу оговорюсь, я её не делал, я её исправлял). Казалось бы, да хрень какая-то. Но когда у вас DAU 200000 это превращается в 30 ошибок в день! Не исправлять её нельзя, потому что это деньги и претензии, которые необходимо отработать корректно и все до единой. Может ли QA воспроизвести её или хотя бы проверить ваш фикс? А вот хрен то там, даже если всем отделом будет сидеть и покупать круглыми сутками.
Если задать типичному разработчику вопрос как он такую ситуацию воспроизводить исправлять и тестировать, он обычно только разведёт руками, потому что когда продумывали архитектуру клиент-серверного взаимодействия об этом забыли подумать.
Я для себя решение нашёл, оно описано в моей статье: habr.com/ru/post/435704
Но вам оно скорее всего не подойдёт, поэтому просто задайте себе вопрос, а что я буду делать оказавшись в такой ситуации.
Когда работал в геймдеве — тоже сталкивался с большими числами.
Например, однажды, мы поставили небольшую вероятность выпадения премиум-предметов во время новогоднего ивента. Но это мы думали, что она «небольшая».
А количество игроков и их усердие привели к тому, что выпало слишком много таких предметов и продажи просели на целый месяц. Но, правда, игроки были счастливы)
Старпёр) Бюрократия не со стороны разработчика, а со стороны магазинов, независимо от типа приложения. Причем нередко "бюрократические затруднения" происходят в автоматическом режиме, когда приложение ревьювит бот. Каждая публикация в стор становится похожей на лотерею — приложение могут зареджектить за фичу, которая до этого пару лет спокойно присутствовала в приложении.
Отличная статья, я опубликовал за последние 10 лет всего две простенькие многопользовательские игры — но сталкивался со всеми пунктами.
Почему во всех статьях про мобильные приложения и вообще про мир "приложений" все забывают что ещё существует такая штука как backend. И если вы ошиблись при проектировании архитектуры данных (если вообще это делали) вашего приложения, то как ни старайся — сова (новая фича) не натянится на глобус. Или если вы при пуше в релиз своей "революционной" идеи мобильного приложения оставили на беке один несчастный скрипт, который парсит при каждом пользовательском запросе бедную гугл-таблицу и достает оттуда километровые тексты вашего "революшина".
Реальный кейс реального приложения, к сожалению.
А ещё все забывают про "режимы для людей с ограниченными возможностями". Всяческие увеличители шрифтов и укрупнители элементов интерфейса. Включение их в настройках ломает 90% приложений, даже самых "именитых".
Хотя, мне кажется, всё же интереснее делать какую-то новую полезную фичу для пользователей, чем обновлять библиотеку.
Но тут больше речь о том, чтобы люди, которые планируют разработку (например, проектные менеджеры) — трезво оценивали сроки, объем работ, риски и т.д.
Хорошая статья.
13 подвохов мобильного приложения, о которых лучше знать до старта разработки