Iap apple что это

Buy additional app features with in-app purchases and subscriptions

Learn how subscriptions and in-app purchases work.

What are in-app purchases?

In-app purchases are extra content or subscriptions that you buy inside an app. Not all apps offer in-app purchases. To check if an app offers in-app purchases before you buy or download it, find it in the App Store. Then look for «In-App Purchases» near the app’s price or Get button.

What is a subscription?

With a subscription, you pay to access content from an app or service for a period of time. For example, you might subscribe to Apple Music on a monthly basis. Subscriptions include services that you sign up for in an app, such as Hulu, Spotify, Pandora, or HBO NOW.

Most subscriptions renew automatically unless you cancel them. With some apps and services, you can choose how often the subscription renews. For example, you might be offered weekly, monthly, quarterly, or yearly subscriptions.

What is a non-consumable in-app purchase?

Here are examples of non-consumable in-app purchases:

• Remove ads
• Full game unlock
• Upgrade to pro edition
• Bonus game levels

You buy these items one time, and you can transfer them to other devices that are associated with your Apple ID. If you lose a non-consumable purchase, you might be able to download it again for free.

What is a consumable in-app purchase?

Here are examples of consumable in-app purchases:

• Game currency, such as coins or gems
• Extra health points in a game
• A package of exports to a new file format

You need to buy these items every time you want them, and you can’t download them again for free. If you remove and reinstall an app or install an app on a new device, you might lose your consumable purchases. For example, if you install a game on your iPod touch that you started playing on your iPhone, the game levels sync, but extra health that you bought on your iPhone doesn’t sync.

About sharing in-app purchases

If you use Family Sharing, you might be able to share some subscriptions with family members. Find out how to share a subscription with family. Consumable in-app purchases can’t be shared.

Learn more

• To prevent unintentional in-app purchases or prevent a child from making in-app purchases, set up Screen Time.
• If you tried to make an in-app purchase and you aren’t sure the purchase was successful, check your purchase history. If you see it in your purchase history but you don’t see it in the app, contact the app developer.
• For any other issues with in-app purchases, you can request a refund or report a problem.

For more information about subscriptions and in-app purchases, see the Apple Media Services Terms and Conditions.

Store availability and features might vary by country or region. Learn what’s available in your country or region.

Information about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. Contact the vendor for additional information.

Источник

iTunes In-App Purchases со стороны сервера

Платежи через iTunes фактические лидеры по монетизации контента, предоставляемого мобильными приложениями. В одном из известных мне приложений доход от них в 3 раза превышает доход от Google Play пользователей при том, что посещаемость последних в 1.5 раза выше. Таким образом, с одного пользователя iTunes можно получить вплоть до 5 раз больше денег, чем с одного пользователя Google Play. Данный аргумент достаточен для интеграции платежей iTunes в мобильные приложения.

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

В соответствии с руководством разработчика предлагается две схемы верификации платежных транзакций: простая, при которой подтверждение транзакции происходит в результате взаимодействия мобильного приложения и App Store, и сложная. Во втором случае вводится дополнительный этап подтверждения с собственного сервера посредством обращения к сервису iTunes Connect. Факт успешного подтверждения платежной транзакции через iTunes Connect считается достаточным для верификации платежа.
К минусам простой верификации можно отнести подорванное доверие. К плюсам сложной относятся удобство работы с подписками, возможность начисления мирских благ и хранения перечня продуктов на стороне сервера. Последние два пункта особенно актуальны, когда приходится ждать обновления приложения в App Store неделю. А может и несколько недель, если вдруг решите порадовать пользователей соблазнительным продуктом в предверии иноверного рождества. О безопасности я даже не говорю — всё достаточно наглядно на следующем графике:

Так в системе мониторинга платежных запросов абстрактного приложения могут выглядеть вполне рядовые сутки. Синим цветом представлено общее количество запросов на верификацию платежа. Зеленым — запросы, которые реально прошли через App Store. А красным — вредоносные запросы. Страшно представить, какую упущенную выгоду может получить приложение, если будет игнорировать серверное подтверждение платежа. Процентое отношение данных из графика представлено в следующей таблице:

Особенность запроса
Неподтверждаемые. Фальшивые платежи, состоящие из данных, похожих на корректные, но, возможно, в них поле какое отсутствует, число строкой представлено или присутсвует ещё какая-нибудь отличительная особенность, никак не позволяющая верифицировать платеж	0.7%
Повторы. Запросы со стороны клиента с верифицированным платежем, но присланные повторно через какое-то время	1%
Платежи крекеров (типа, iAP Cracker и т.п.). Посылают на верификацию платежи, сформулированные для подтверждения ими же самими	9.3%
Поддельные. Верифицируемые через iTunes платежи других приложений	79%
Подтвержденные. Реально честные покупки. Их цифры сходятся с цифрами покупок через аккаунт	10%

На самом деле, большинство вредоносных запросов можно определить собственными силами без траты траффика на обращение к сервису верификации. Платеж iTunes предсталвляется т.н. рецепт. Рецепт — это кодированный в base64 JSON-объект данных платежной транзакции. Для верификации платежа или подписки через сервис App Store нужно передать их рецепт, который сообщает клиентское приложение. В ответ получите статус рецепта и некоторые данные платежа.

Рассмотрим корректный рецепт (здесь и далее данные корректных рецептов слегка изменены):

Рецепт состоит из данных покупки, подписи и пары служебных полей. Подпись бинарна и закодирована base64. Данные покупки также закодированы и представляют собой JSON-объект с множеством полей. Наиболее интересными считаю два поля: product-id — идентификатор приобретаемого продукта и bid — идентификатор приложения.

Лидеры выборки вредоносных запросов — поддельные запросы — выглядят примерно так:

Вполне приличный рецепт. Только не от нашего приложения. Если выполнить обращение к iTunes Connect, получим подтверждение данного платежа:

В принципе, могли бы не проверять. Можно съэкономить 80% траффика к iTunes путем сравнения product-id и bid с допустимыми в нашем приложении ещё на стадии получения рецепта от клиентского приложения.

Рецепты, создаваемые крекерами довольно-таки примитивны: Y29tLnVydXMuaWFwLjk2NjU3Mjkw . Дешифруем, получаем com.urus.iap.96657290 . Очевидно, что здесь ни о какой структуре рецепта даже речи не идет — ни подписи, ни данных покупки. Подобные рецепты можно смело отвергать. iTunes на такой рецепт вернет ошибку 21002.

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

Cамое малое зло из выборки — неподтверждаемые рецепты. Ниже представлен пример одного:

По сравнению с корректным рецептом, в данном случае замента экономия на пробелах, но это не повод отвергать рецепт — ведь его составляет и кодирует клиентское приложение. А так рецепт выглядит корректно: есть правильные идентификаторы продукта и приложения, правдоподобные данные платежа, подпись. Нужно посылать запрос в iTunes (хорошо, что таких запросов всего 0.7% от общего числа и 7% от числа полезных запросов). iTunes ответит кодом 21002.

На картинке ниже представлен алгоритм верификации рецептов, полученных от клиентского приложения, на стороне собственного сервера:

Непосредственно для верификации через iTunes предлагаю для использования небольшую и удобную библиотеку. Данная библиотека позволяет верифицировать в том числе и обновляемые подписки. Запросить информацию по подписке можно тем же запросом верификации, указав при инициализации клиента секретный пароль.

iTunes вернет нам данные ответа в следующем виде

В отличие от подписок Google Play, iTunes создает новый рецепт подписки на каждый период оплаты. Примерно за сутки до начала следующего платежного периода, iTunes пытается снять деньги со счета пользователя, хотя я видел жалобу, что деньги за продление подписки были списаны за 48 часов до начала нового платежного периода. Если попытка ещё не проводилась и пока не прошла успешно данные, представленные в latest_receipt совпадают с данными исходного рецепта, как в примере выше. В случае успешного продления подписки, данные автоматической покупки будут представлены в поле latest_receipt_info, закодированный рецепт в поле latest_receipt

В случае, если продлить подписку не представилось возможным, возвращается статус ответа 21006

Предлагаю следующую схему обработки подписок iTunes на стороне сервера:

• buy — покупка подписки на стороне клиента
• verify — верификация данных подписки на стороне сервера по алгоритму, предложенному выше
• queue — очередь данных верифицированных подписок
• periodical verification — периодическая проверка подписок. Если подписка была продлена, записываем обновленный рецепт обратно в очередь для последующих проверок

60% подписок iTunes продлевается. Для подписок Google Play эта величина составляет

40%. А подавляющим большинством случаев невозможности продления подписки являются случаи отсутсвия денежных средств на счетах пользователей

Источник

iOS in-app purchases, часть 3: серверная валидация покупок

Всем привет, я Кирилл, СТО Adapty. Я делал систему серверной валидации для наших SDK.

Сегодня как раз и расскажу про серверную верификацию покупок на iOS. Это третья статья из серии о внедрении внутренних покупок на iOS, советую познакомиться с остальными:

iOS in-app purchases часть 3: серверная валидация покупки. — Вы тут

Серверная валидация (server-side receipt validation) — это способ проверить подлинность покупки. В отличие от проверки покупки на устройстве, серверная валидация происходит, внимание, на сервере. Валидация означает, что устройство или сервер обращаются к серверам Apple и спрашивают, действительно ли была покупка и валидная ли она.

Зачем валидировать покупки

Стоит отметить, что серверная валидация не обязательна, встроенные покупки и подписки будут работать и без неё. Но она даёт ряд преимуществ:

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

Проверка подлинности покупки, то есть вы будете уверены, что это не фродовая транзакция, а значит, пользователь заплатил деньги за ваш продукт.

Кроссплатформенные подписки. Зная в живом режиме статус подписки пользователя, можно синхронизировать его с другими платформами. Например, пользователь, оформивший подписку на iOS, сможет пользоваться сервисом на Android, Web и других платформах.

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

По нашему опыту, один первый пункт — достаточная причина делать обработку покупок на сервере.

Валидация платежей

В целом процесс валидации платежей на iOS можно описать схемой:

Получение shared secret

Чтобы отправить запрос на валидацию платежа, необходимо предоставить shared secret, с помощью которого авторизуется запрос. Получить его можно в App Store Connect.

Shared secret может быть создан для конкретного приложения (app-specific) или же для всех приложений в аккаунте (primary).

Чтобы получить secret для конкретного приложения, необходимо открыть страницу данного приложения в App Store Connect, перейти в раздел In-App Purchases → Manage и кликнуть на ссылку App-Specific Shared Secret. В открывшемся окне можно будет создать новый или скопировать существующий токен.

Чтобы получить secret для всех приложений в аккаунте, необходимо открыть страницу Users and Access и перейти на вкладку Shared Secret.

Запрос на валидацию платежа

После получения shared secret вы можете отправлять квитанцию (receipt) для валидации на сервер Apple. Это делается с помощью запроса verifyReceipt. Нужно отправить POST-запрос на https://buy.itunes.apple.com/verifyReceipt. В JSON теле запроса нужно отправить shared secret в поле password и receipt в поле receipt-data . Также есть опциональный параметр exclude-old-transactions . Если его значение true, то для каждой авто-возобновляемой подписки вернётся только последняя транзакция, вместо всей истории продлений.

Пейлоад запроса на валидацию платежа

Если вы работаете в Sandbox режиме, то есть тестируете покупки, запросы на валидацию надо отправлять на https://sandbox.itunes.apple.com/verifyReceipt. Shared secret, формат пейлоада и ответа остаются без изменений.

Важно отметить, что receipt, созданный в Sandbox, нельзя будет провалидировать на Production сервере, и наоборот.

Поэтому в реальных системах рекомендуется всегда первый запрос отправлять на Production сервер, и, если в ответ в ключе status пришла ошибка с кодом 21007 , повторить запрос на Sandbox сервер. Такое поведение обязательно нужно включать на период ревью приложения, чтобы сотрудники Apple могли тестировать покупки, и в это же время их могут делать реальные пользователи вашего приложения.

Среди других ошибок, на которые нужно обращать внимание, — 21004 , которая говорит о том, что мы используем неправильный secret. Её важно мониторить, потому что она влияет и на пользовательский опыт, и на точность аналитики. В худшем случае, приложение могут удалить из App Store, если пользователю после покупки не даётся доступ к платным возможностям.

В случае успешной валидации ( status=0 ), в ответ приходит информация о транзакциях пользователя.

Ответ на запрос о валидации платежа

Ответ громоздкий, и в новой версии App Store Server API его упростили, но и с текущей реализацией нетрудно разобраться.

Получение статуса подписки и истории транзакций

Чтобы понимать, есть ли у пользователя доступ к платным функциям приложения, вам нужно уметь определять статус подписки. В данной версии API нет отдельного запроса на получение статуса подписки, поэтому вам в любом случае будет нужно работать с историей транзакций.

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

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

Для получения текущего статуса подписки достаточно взять хронологически последнюю транзакцию в цепочке и посмотреть на дату истечения подписки ( expires_date ). Исключением будет grace period, о нём мы поговорим чуть позже.

Для аналитических целей я рекомендую сохранять следующие поля:

product_id — текстовый идентификатор продукта, который был куплен.

transaction_id — числовой уникальный идентификатор транзакции. У каждой покупки/продления будет свой идентификатор, его можно использовать, чтобы понимать, была ли ранее обработана данная транзакция.

original_transaction_id — числовой уникальный идентификатор цепочки транзакций. При активации подписки/триала он будет совпадать с transaction_id, но при последующих продлениях transaction_id будет меняться, а original_transaction_id будет одинаковым. Это удобно для того, чтобы отслеживать количество продлений.

purchase_date и original_purchase_date — дата транзакции и дата оригинальной транзакции по аналогии с предыдущем пунктом.

expires_date — дата истечения подписки

cancellation_date — дата рефанда, а не отмены подписки, как может показаться из названия. Если в ответе есть это поле, значит, вы можете отозвать доступ пользователя к приложению, а также учесть в аналитике, что деньги за эту транзакцию не будут выплачены.

is_in_intro_offer_period — флаг, показывающий, был ли использован интро оффер при активации подписки.

is_trial_period — флаг, показывающий, был ли использован триал при активации подписки.

offer_code_ref_name — оффер код, который был использован при активации подписки.

promotional_offer_id — текстовый идентификатор промо оффера, который был использован при переходе на текущий период подписки.

in_app_ownership_type — тип владения подпиской, отвечает на вопрос, купил ли пользователь продукт сам или получил его в рамках семейной подписки. Возможные значения:

PURCHASED — пользователь сам купил продукт.

FAMILY_SHARED — пользователь получил продукт в рамках семейной подписки.

На WWDC 2021 Apple сообщили, что позже в транзакцию добавят поле appAccountToken , которое содержит идентификатор пользователя в вашей системе. Этот идентификатор должен быть в формате UUID и задаётся на стороне мобильного приложения в момент инициализации покупки. Если задан, то он будет возвращаться во всех транзакциях в этой цепочке (продления, проблемы с биллингом и тд.), а значит вы легко сможете понять, какой пользователь сделал покупку.

Также стоит следить за параметром subscription_group_identifier . Если у пользователя ранее была транзакция с активным триалом или интро оффером, то в рамках данной группы подписок, пользователю больше недоступны триал и интро оффер, и это нужно отслеживать со стороны сервера.

Информация о продлении подписки, grace period и billing issue

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

Информация о продлении подписки

product_id — текстовый идентификатор продукта, который был куплен.

auto_renew_product_id — текстовый идентификатор продукта, который активируется в следующем периоде. Если он отличается от текущего ( product_id ), значит пользователь сменил тип подписки.

auto_renew_status — флаг, показывающий будет ли продлена подписка на следующий период.

expiration_intent — причина истечения подписки. Возможные значения:

1 — пользователь сам отменил подписку.

2 — подписка отменилась из-за проблем с оплатой.

3 — пользователь не согласился на повышение цены

4 — продукт подписки не был доступен для продления, например, если его удалили из App Store Connect.

5 — неизвестная причина.

grace_period_expires_date — дата истечения grace period, если он включен для вашего приложения. В этом случае пользователю должны быть доступны платные функции приложения до даты, указанной здесь, а не до той, которая указана в самой транзакции. Если есть этот ключ, вы можете сообщить пользователю о том, что ему нужно обновить данные карты для оплаты или пополнить баланс.

is_in_billing_retry_period — флаг, показывающий находится ли подписка в статусе billing retry. Это значит, что подписка не была отменена, но при этом Apple не смог списать деньги за продление и будет пытаться делать это в течение 60 дней.

offer_code_ref_name — оффер код, который будет использован в следующем периоде подписки.

promotional_offer_id — текстовый идентификатор промо оффера, который будет использован в следующем периоде подписки.

price_consent_status — флаг, показывающий, согласился ли пользователь с грядущим повышением цены на подписку. Если его значение 0, то вам стоит предложить пользователю другой продукт или промо оффер, чтобы он не прекратил подписку.

Consumable, non-consumable и невозобновляемые подписки

Если у пользователя нет авто-возобновляемых продуктов, то ключи latest_receipt_info и pending_renewal_info не возвращаются. В таком случае, транзакции стоит искать в receipt → in_app. Формат транзакций похож на авто-возобновляемые транзакции, но в нём нет полей истечения, продления, офферов и других эксклюзивных для авто-возобновляемых транзакций параметров.

Стоит отметить, что receipt → in_app приходит и для авто-возобновляемых транзакций, но лучше использовать latest_receipt_info , потому что в нём будет наиболее актуальная информация по подписке.

Серверные уведомления о транзакциях

Некоторое время назад требовалось написать сложную систему, чтобы отслеживать изменения в состоянии подписок. Например, чтобы понять, продлилась подписка или нет, нужно было за сутки до её истечения раз в час отправлять запрос на сервер Apple, чтобы узнать её статус. Apple постепенно добавлял серверные уведомления, и в настоящее время практически все важные события, связанные с подписками, покрыты серверными уведомлениями. Это очень удобно: как только со стороны Apple произошло какое-то изменение, вы можете получить информацию об этом на своём сервере. То есть вы будете получать информацию о новых покупках, продлениях, проблемах с платежами и так далее. Это позволяет собирать более точную аналитику, а также упрощает менеджмент состояния подписчика.

Настроить получение серверных уведомлений можно в App Store Connect. Необходимо открыть страницу приложения, перейти в раздел General → App Information, указать желаемую ссылку в поле URL for App Store Server Notifications и сохранить изменения.

Серверное уведомление

Формат серверных уведомлений похож на ответ валидации платежа. Информация о транзакциях лежит в unified_receipt → latest_receipt_info . В ключе password лежит shared secret для вашего приложения, таким образом вы можете убедиться в подлинности запроса. В ключе notification_type указан тип события. На мой взгляд, самые полезные:

DID_CHANGE_RENEWAL_STATUS — пользователь выключил или (намного реже) включил автопродление подписки. Если автопродление выключили, надо пытаться вернуть пользователя в число активных подписчиков.

DID_FAIL_TO_RENEW — подписку не получилось продлить из-за проблем с оплатой. Стоит сообщить пользователю об этом, чтобы у него не отменилась подписка автоматически.

DID_RENEW — подписка успешно продлилась.

REFUND — пользователю вернули деньги за покупку. Нужно закрыть ему доступ к функциям, которые давала эта покупка и отразить рефанд (потерю денег) в аналитике.

Заключение

Серверная валидация значительно улучшает качество аналитики, которую вы можете собирать со своего приложения. Она также усложняет несанкционированный доступ к платному контенту и позволяет делать мультиплатформенные подписки. При этом реализация валидации может занять довольно много времени, особенно если нужна высокая точность данных, а значит надо учитывать много сайд-кейсов: upgrade подписки, cross grade подписки, trial период, promo/introductory offers, grace period, возвраты, семейные подписки и тд. Плюс нужно знать и учитывать различные нюансы, например, что для подписок, которые продлеваются больше года, Apple снижает комиссию с 30% до 15%.

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

Встроенная аналитика позволяет быстро понять основные метрики приложения.

А/Б тесты увеличивают выручку приложения.

Интеграции с внешними системами позволяют отправлять транзакции в сервисы атрибуции и продуктовой аналитики.

Промо кампании уменьшают отток аудитории.

Open source SDK позволяет интегрировать подписки в приложение за несколько часов.

Серверная валидация и API для работы с другими платформами.

Познакомьтесь подробнее с этими возможностями, чтобы быстрее внедрить подписки в своё приложение и улучшить конверсии.

Источник