В общем, есть в нашей конторе кроссплатформенный продукт, в котором мы реализовали возможность для юзера купить подписку на доступ к сервису. В этом проекте я в основном занимаюсь серверной частью - апи для сервиса, валидация и обработка покупок от мобильных клиентов. Клиенты есть под iOs, Android, OsX и под винду (десктопную и мобильную).
Сервис существует уже достаточно давно, изначально покупки были обычного типа, постепенно по мере обновления сторов переходим на тип подписки "subscription" (это когда денюжка с юзера снимается автоматически стором, с выбранной периодичностью ). К сожалению, каждый стор видит эту механику по-своему. Например AppStore все транзакции сохраняет в ресипте. Вообще все. И каждое автоматическое списание добавляет ещё одну транзакцию. Это здоровый список.. А PlayStore и практически повторяющий его магазин от Самсунга - они хранят одну транзакцию, и при автоматическом списании денег просто увеличивают expiration_date в ресипте. В Амазоне своя реализация, в PaymentWall пока нет нужного нам функционала, и до недавнего времени я считал, что худшая реализация - это у PayPal. Но я ошибался
В феврале 2018 микрософт выкатило функционал подписок для своего магазина в тестовом режиме, а с лета этого года эта возможность стала доступна всем разработчикам.
Поскольку функционал новый и честно говоря, маловостребованный, в сети пока мало отзывов и примеров. Но в принципе документация более-менее адекватная и позволяет написать валидацию и обработку подписок. Но вот чего там не описано - это очень интересную механику работы MS Store с украинскими банками (пока пишу украинскими, т.к. я столкнулся с этими проблемами при тестировании, а у нас нет других карт). В общем в чём суть - оказывается, когда юзер покупает подписку, микрософт не списывает денег с карты юзера сразу. Сначала проходит операция блокировки нужной суммы. А само физическое списание может случиться, а может и не случиться - сильно позже. Наш рекорд - 5 дней. И это может быть критичной проблемой.
Опишу на примере:
1. юзер хочет купить подписку - клиентское приложение запрашивает у АПИ AzureID ключ, который идентифицирует приложение в сторе. Затем клиент с этим ключом получает в сторе в свою очередь другой ключ - MS Store Key, который теперь однозначно связывает клиента и приложение.
2. юзер купил подписку - клиент присылает на сервер сигнал об успешной покупке и передаёт MS Store Key в параметрах. АПИ лезет в винстор с этим ключом и получает в ответ json со всеми покупками юзера для этого приложения.
3. дальше парсим полученный ресипт, отделяем каждую транзакцию, проверяем ее на уникальность по нашей базе, и если надо - обрабатываем - добавляем юзеру дни, прописываем новую expiration_date
а дальше начинается магия. Так как винстор никак нас не уведомляет, что у юзера расширилась автоматически подписка - мы должны самостоятельно, когда у юзера заканчивается дата подписки - опросить стор на предмет, не расширилась ли подписка, не списались ли с юзера денюжки.
4. допустим, подписка закончилась 1 сентября. Ровно первого сентября мы должны пойти в винстор, скормить ему полученный ранее MS Store Key, получить новый ресипт и снова его распарсить. Однако, как выяснилось, винстор блочит деньги на первом этапе, и мы получили ресипт, в котором expiration_date осталась прежней, всё осталось прежним, и только modification_date стала равной 1 сентября.
5. на протяжении 5-ти дней мы получали такой ресипт. При этом владелец карты получил письмо об успешном списании средств. И только 6-го сентября пришёл новый ресипт, в котором expiration_date указывала уже на 1 октября, при этом modification_date стала показывать на 6-е сентября.
Возможно кому-то эта информацию будет полезна. Я потратил вагон времени на выяснение что же происходит, почему не работает - и спросить было не у кого =) В реальности из-за такого поведения магазина нам пришлось добавить двух недельный grace период для сервиса. Мало ли, вдруг деньги заблокированы и будут списаны позже, а юзеры не любят разбираться, дошли их деньги до разработчика или нет. С их точки зрения - они заплатили и хотят получить непрерывный сервис - и они правы.
Windows это хороший заработок. Борьба с геморром будет всегда, M не даст умереть разработчикам.
Судьба даёт нам меньше, чем мы хотим, поэтому если просить мало, можно не получить вообще ничего.
Invision Power Board
© Invision Power Services