Find valid purchase date apple

Correct the purchase date or expiration date for your AppleCare agreement

If you want to update information in our records about your purchase or agreement, we’re here to help.

What’s covered?

Is my device covered?

Learn more about the information provided

Understanding the limitations of Apple’s service coverage system («System») can help avoid problems. The information contained in the System is designed to help customers determine if service for their products is covered under the terms of Apple’s limited warranty or an Apple extended service contract, such as the AppleCare Protection Plan and AppleCare+.

For customers whose products are covered by consumer protection laws or regulations in their country, region, or state of purchase, the service coverage described in the System may not reflect all rights and remedies conveyed by such consumer protection laws and regulations. This may include the right of customers in California and other jurisdictions to have the warranty period extended for the number of whole days that the product has been out of the customer’s hands for warranty repairs. In order to calculate the number of days that the warranty period is extended, Apple may require customers to submit the original sales receipt of your product and repair service documentation. Please also note that the information in the System does not reflect any other additional programs that may extend Apple’s coverage, like those described on the Exchange and Repair Extension Programs page.

The service coverage information described in the System is based on the date of purchase information available to Apple. Depending on when or whether you registered your product, if you purchased it from an Apple authorized reseller or Apple Store, the estimated purchase date may be incorrect. If you believe that the information is inaccurate, please update the information by contacting Apple using the appropriate link on this page. Recently submitted information and repair service warranty coverage may not be reflected in the System records. Customers may not use the System for any purpose that is unlawful or prohibited, or to solicit the performance of any illegal activity or other activity that infringes the rights of Apple or others.

Consumer law

Apple 1 year limited warranty 1 , AppleCare Protection Plan, and AppleCare+ benefits are in addition to rights provided by consumer law. For details click here.

If you think you have a valid consumer law claim, please contact us.

Keep your sales receipt and proof of coverage in a safe place

Please put your product’s sales receipt, and if applicable, AppleCare Proof of Coverage document in a safe place. You may be asked to provide a copy of these if there is any question as to your product’s eligibility for service coverage under the warranty or AppleCare service contract. When seeking service, Apple may request that you submit the original sales receipt of your product to verify eligibility for warranty service, even if you have already registered your product. Your warranty is the same whether or not you register.

Learn more about updating Apple records

If your coverage expiration date is incorrect

If the estimated expiration date of your Telephone Technical Support, Limited Warranty, or AppleCare agreement for your serial number is incorrect, please contact us. You will need to send the original sales receipt of your product to Apple so that we can update your purchase date. A sales receipt with the receipt number, product description, original date of purchase, price, and reseller details constitutes a valid proof of purchase.

If your AppleCare agreement is missing

If you purchased an AppleCare agreement, such as the AppleCare Protection Plan, and it does not appear in your results, you may need to register your AppleCare agreement.

Learn more about Apple’s coverage for your product

• Learn more about hardware warranties.
• Learn more about AppleCare service contracts.
• Learn more about complimentary technical support (select your country or region for support).

Not all AppleCare plans are available in all countries or regions.

Learn more about your service options

Apple provides different options when products need service, including carry-in, mail-in, and do-it-yourself parts service. Availability depends on the product and the country or region in which service is requested.

• You can go directly to our Check Coverage page. Enter your serial number to see the available service options.
• Find manuals, downloads, troubleshooting advice, and more at Apple Support.

1. In Turkey, your device is covered by Apple’s limited warranty for two years.

Источник

See your purchase history for the App Store, iTunes Store, and more

To see which apps, music, and other content you bought, look at your purchase history.

See a list of your purchases from the App Store, iTunes Store, Apple Books, and the Apple TV app.

How to see recent purchases on the web

1. Go to reportaproblem.apple.com.
2. Sign in with your Apple ID and password.
3. A list of your recent purchases appears. If you’re not sure what you were charged for but you know the exact amount, search for the amount. If there’s a problem with an item that you purchased, use this website to report the problem to Apple.

See your purchase history on your iPhone, iPad, or iPod touch

1. Open the Settings app.
2. Tap your name, then tap Media & Purchases. You might be asked to sign in.
3. Tap Purchase History.
   
4. Your purchase history appears. If you want to see purchases that you made more than 90 days prior, tap Last 90 Days, then select a different date range.

See your purchase history on your computer

1. Open the Music app or iTunes. From the menu bar at the top of the screen, choose Account, then click View My Account.
2. On the Account Information page, scroll down to Purchase History. Next to Most Recent Purchase, click See All.
   
3. Find the item. It might take a moment for your Purchase History to appear. If you want to see purchases that you made more than 90 days prior, click Last 90 Days, then select a date range.

If you can’t find an item in your purchase history

If you can’t find the item you’re looking for, try these things before you contact Apple.

Find out if a family member purchased the item

If you use Family Sharing, your purchase history shows purchases that you made using your Apple ID, but you won’t see what other family members bought. To see what other family members bought, sign in with their Apple ID.

If family members have access to your device, you might want to require a password for every purchase.

To control what kids buy on their own devices, turn on Ask to Buy.

Check if you purchased the item with a different Apple ID

If you don’t see an item in your purchase history, you might have been signed in with a different Apple ID when you made the purchase. Sign in with that Apple ID to check if your purchases were billed to that account.

If you see purchases that you don’t recognize or unexpected charges

• If you see items in your purchase history that you don’t remember buying, check if someone else who uses your device, such as a family member, bought the item. If someone else is using your Apple ID and password, change your Apple ID password.
• Learn what to do if you don’t recognize a charge on your statement from your bank or financial institution.
• Learn how to request a refund.

Learn more

• If you see an in-app purchase in your purchase history but you don’t see it in the app, restore in-app purchases.
• Cancel a subscription.
• Learn about how App Store and iTunes Store purchases are billed.
• If you received a suspicious email notification about a purchase, the email might not be from Apple or reflect actual charges to your account. Learn how to identify legitimate App Store or iTunes Store emails.

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.

Источник

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 для работы с другими платформами.

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

Источник