Pull to refresh

Comments 20

Между покупкой в приложении и фактическим подтверждением платежа от стора – есть окно, примерно от часа до суток.

Это где такое? Вроде как в Google Play и App Store приходит всё сразу. Или речь о чём-то другом?

С помощью специализированных программ можно подменить данные, которые приложение отправляет на сервер. В том числе, можно изобразить покупку.

Для этого все вендоры очень настоятельно рекомендуют делать проверку на стороне сервера, а не на стороне приложения.
Хм, это я со слов нашего разработчика записал — расспрашивал его как нас взломали и как мы это решили в результате. Уточню у него и отпишусь.
Да, уточнил — так и есть: мы делаем проверку на стороне сервера и как раз за счет этого и возникает задержка.

Порядок такой:

  1. Пользователь нажимает «Оплатить».
  2. Стор снимает с него деньги и сразу присылает нам данные об оплате (в приложение).
  3. Мы эти данные из приложения отправляем на наш сервер.
  4. Сервер обращается к стору, чтобы проверить, что оплата действительно была.
    И вот на этом этапе бывает задержка.
    Тут три варианта развития событий:
    • стор сразу говорит, что все ок, оплата прошла;
    • стор говорит «я ещё думаю» и тогда нужно будет повторить запрос позже;
    • стор говорит «не было такой оплаты» и мы понимаем, что это мошенник.

Интересно. Никогда не замечал задержки с таким ответом. У Google Play есть потенциальная задержка при тестировании оплаты «slow credit card», но вроде как на серверной проверке оба вендора сразу говорят есть такая транзакция или это подделка (наверно, просто подпись проверяют или типа того) даже если деньги ещё идут. Тут не надо ждать.
Если потом оплата отвалилась, то можно подписаться на уведомления, делать polling, но это уже другая задача. По-крайне мере, была реальная попытка оплатить и я таким пользователям доверяю. По моей статистике они почти всегда пытаются заплатить ещё раз и тогда транзакция проходит.

P.S.: Если хочется подшутить немного над разработчиком, то достаточно задать вопрос о том, что он знает про «com.zeptolab.ctrbonus.superpower1».
Один из самых популярных iap взломщиков для iOS прикидывается именно под эту покупку, которая совершенна валидная, так как была реально сделана когда-то в июле 2012 года. И, конечно, которая по этой причине проходит все проверки на стороне Apple кроме «product-id» и «bid»).
Всё так, только не раскрыли тему удалений приложений роботами гугла. За плохи слова, например корона или рут. И отсутствие человеческой поддержки в Гугл плей.
Да, помню у меня были сложности с приложением, так я так и не достучался до поддержки Google. Предлагают читать справку и задавать вопросы сообществу, насколько помню.
Очень хорошая статья, однозначно в закладки. От себя добавлю ещё один момент о котором не задумывается типичный человек пока приложение не выходит в релиз.

Маловероятные ошибки на проде!

Например у нас есть ошибка, срабатывающая у каждого 1000-нго игрока, совершающего покупку. У нас была ошибка округления float на разных платформах. (Сразу оговорюсь, я её не делал, я её исправлял). Казалось бы, да хрень какая-то. Но когда у вас DAU 200000 это превращается в 30 ошибок в день! Не исправлять её нельзя, потому что это деньги и претензии, которые необходимо отработать корректно и все до единой. Может ли QA воспроизвести её или хотя бы проверить ваш фикс? А вот хрен то там, даже если всем отделом будет сидеть и покупать круглыми сутками.

Если задать типичному разработчику вопрос как он такую ситуацию воспроизводить исправлять и тестировать, он обычно только разведёт руками, потому что когда продумывали архитектуру клиент-серверного взаимодействия об этом забыли подумать.

Я для себя решение нашёл, оно описано в моей статье: habr.com/ru/post/435704
Но вам оно скорее всего не подойдёт, поэтому просто задайте себе вопрос, а что я буду делать оказавшись в такой ситуации.
Спасибо за интересный комментарий!
Когда работал в геймдеве — тоже сталкивался с большими числами.
Например, однажды, мы поставили небольшую вероятность выпадения премиум-предметов во время новогоднего ивента. Но это мы думали, что она «небольшая».
А количество игроков и их усердие привели к тому, что выпало слишком много таких предметов и продажи просели на целый месяц. Но, правда, игроки были счастливы)
Назовите меня старпёром, но что-то не так с индустрией «смарт»фонов. Ну не может быть чтобы разработка фонарика с миганием в качестве платной премиум функции вызывала столько бюрократических затруднений.

Старпёр) Бюрократия не со стороны разработчика, а со стороны магазинов, независимо от типа приложения. Причем нередко "бюрократические затруднения" происходят в автоматическом режиме, когда приложение ревьювит бот. Каждая публикация в стор становится похожей на лотерею — приложение могут зареджектить за фичу, которая до этого пару лет спокойно присутствовала в приложении.

Отлично показали подводную часть айсберга!!! И спасибо за ссылки.

Отличная статья, я опубликовал за последние 10 лет всего две простенькие многопользовательские игры — но сталкивался со всеми пунктами.

Отличная статья, однозначно в закладки!

Почему во всех статьях про мобильные приложения и вообще про мир "приложений" все забывают что ещё существует такая штука как backend. И если вы ошиблись при проектировании архитектуры данных (если вообще это делали) вашего приложения, то как ни старайся — сова (новая фича) не натянится на глобус. Или если вы при пуше в релиз своей "революционной" идеи мобильного приложения оставили на беке один несчастный скрипт, который парсит при каждом пользовательском запросе бедную гугл-таблицу и достает оттуда километровые тексты вашего "революшина".
Реальный кейс реального приложения, к сожалению.

А ещё все забывают про "режимы для людей с ограниченными возможностями". Всяческие увеличители шрифтов и укрупнители элементов интерфейса. Включение их в настройках ломает 90% приложений, даже самых "именитых".

Да, тоже с этим сталкивался.
Причем это касается не только людей с ограниченными возможностями — у меня на телефоне установлен шрифт на один размер больше стандартного (не потому что я плохо вижу, а просто мне так удобнее). И это иногда ломает верстку.
Я бы сказал, что это обычные задачи для мобильного разработчика. Лично для меня такая специфика добавляет интереса в работе.
Ну да, в самих задачах ничего плохого нет.
Хотя, мне кажется, всё же интереснее делать какую-то новую полезную фичу для пользователей, чем обновлять библиотеку.

Но тут больше речь о том, чтобы люди, которые планируют разработку (например, проектные менеджеры) — трезво оценивали сроки, объем работ, риски и т.д.
Менеджерам полезно, да.
Хотел было написать, что не все из перечисленного обязательно к выполнению тем более со старта, но автор не забыл про это. Хорошая статья.
Sign up to leave a comment.

Articles