What’s new with in-app purchase

Hello and welcome to WWDC. Hello and welcome to WWDC. I'm Tori, and I'll also be presenting with my colleague Ross who you'll hear from later today. I'm so excited to share with you what we have new for you with in-app purchases. And we have a lot to cover today.

This session will be divided into two sections. I'll focus on covering what's new on the server side. And later I'll hand it off to Ross to cover StoreKit updates.

So let's get started with our server updates. On the server side, first we'll cover refunds and how you can handle transactions that are refunded.

Next we'll cover some new ways to help you manage the subscription status for your customers and how you can use App Store server notifications to get notified and respond to various subscription billing events. We'll also cover the different scenarios where you may still need to use verify receipt to get the latest status. And finally we'll dive into Family Sharing.

We have a lot to cover so let's dive right in with arguably what brought us all here today, an in-app purchase. So this is an in-app purchase in one of my apps. I'm so excited to use this. But what happens if I change my mind, if I have an issue with the content and call Apple to request a refund, what should you as a developer do? That's why handling refunds is so important.

But keep in mind that while it's important it only affects a small percentage of transactions. However proper refund management could drive that percentage down.

So let's dive into that now by walking through a typical refund scenario.

First a customer purchases some content in an app like 100 Gems. However the purchase was an accident so they call Apple for support. After considering their case we issue a refund. Later the customer contacts you for support as they notice they still have the gems that were refunded. If you don't know that Apple has refunded the content it's difficult to determine how to respond. It would be so much better if you could easily determine if we had already refunded that purchase so you could take action appropriately.

Such as acknowledging the refund but letting the customer keep their gems or deducting their balance. That's why we're working to bring you new ways to manage refunds for your content. Having the ability to manage your refunded purchases is important for many reasons. Most importantly it gives you control to take action as you see fit. Such as messaging the customer or even taking back the content if needed. It also lets you handle any potential abuse of your content such as customers trying to keep their content after receiving a refund from Apple. And you can resolve customer issues like the previous one swiftly. This will also allow you to manage your in-game economy, making game play more fair for all players as there will be repercussions for refunds. So for all of these reasons and because we want you to be able to manage refunds for purchases in your app we're bringing you a brand new App Store server notification and our first ever notification for content types other than auto renewable subscriptions. The Refund notification.

So why did we decide on an App Store server notification for this. Well the primary reason is that you don't have to ask us for information. We'll just tell you. You're notified immediately with a JSON post upon a status change and we even retry up to three times if we don't get an HTTP OK back from you. If you're already receiving App Store server notifications for auto-renewing subscriptions then you'll get the new refund notification for your other content types with little additional work on your end. We'll also send you an updated unified receipt with your canceled transactions included so you can update your records. And this solution is also scalable as you grow your business on our platform. So our goal for all content types is to allow you to obtain information about refunded purchases through App Store server notifications. For consumables, non-consumables and non-renewing subscriptions you'll receive the brand new refund notification.

For subscriptions, you'll continue to receive the cancel notification. enabling App Store server notifications is straightforward if you've never done it before and can be done in a few steps. First set up your desired end point for your notifications and App Store Connect. Next make sure your End Point meets app transport security requirements as outlined in the developer documentation. Then you're all set to start receiving notifications.

So in App Store Connect, just navigate to your apps page and find the URL for App Store server notifications section. Enter your desired end point here so we know where to send your notifications. Know that if your end point already meets security requirements you'll immediately start receiving notifications. Now let's take a deeper look at the refund notification.

We'll send you this notification when any consumable, non-consumable or non-renewing subscription is refunded for your app, after we issue a refund to the customer for that purchase. Getting notified in this way makes it easy for you to take immediate action on your refunded content. This notification has also been implemented in a privacy friendly way as we're not giving you any information about the customer only information you'd already have about the purchase. The refund notification is live today so if you're already receiving App Store server notifications make sure you're looking for it. With that in mind when you receive this notification there are a few things I want you to look out for in the payload. You should look for the original_transaction_id to tell you which transaction we've refunded.

The cancellation date to know when we refunded it and the cancellation reason.

The reason can have values of zero or one and a value of one can indicate the customer requested a refund due to an issue within the app which you could then investigate. Also look for the bid, and the product_id to verify the app and product you've received a notification for. All these fields can be found in the unified_receipt object in the App Store server notification payload and the latest_receipt_info section. Except for the bid which is found at the top level of the payload. So what does the App Store server notification look like. Well it looks something like this.

Not all the fields are listed here but we have explanations for all possible fields in the developer documentation. Right now let's take a look at the ones we just discussed plus a few others. In addition to those transaction identifying fields, look for the password and the payload. This is a shared secret for your app which you can find an App Store Connect and it allows you to verify the payload is from Apple and is trustworthy. At the same level as the password you'll find the bundle identifier. You can verify this field to know which app you've received a refund for. Next look in the unified_receipt object specifically in the latest_receipt_info array for information about your refund transactions. This array contains the 100 latest transactions for your app and the four fields we told you to look for, the cancellation date, the cancellation reason, the original transaction ID and the product ID. So let's revisit our refund scenario from earlier and look at how the refund notification can now help you in a slightly different situation. In this situation the customer still buys 100 gems but then consumes the gems and still asks Apple for support with their purchase.

Once again we make a decision to honor or deny the refund because we don't know if the customer has consumed the gems. We may still honor the refund and if we do we'll send you a refund notification. Then if the customer reaches out to you asking for further support such as in-game compensation.

But now you'll know the purchase has been refunded and you can choose to take proactive action such as providing an in-app message in your app. A message such as this is great as it notifies the customer that you've observed a refund for their purchase. The action you've taken and what they can do to regain access to their content. In-app messaging is just one of many actions you can take upon observing a refund. Let's take a quick look at those now. So there are many actions you can take depending on the content type ranging from moderate to severe. For all content types, you can use this for refund monitoring. For in-app messaging and restricting access to the refunded purchase. Because we're sending you a server to server notification, this gives you the ability to restrict access cross-platform if needed.

In the case of consumables there are additional actions you can take like deducting the in-app currency balance. You as a developer are responsible for making decisions on what measures to take and how to implement them. So think carefully about which action you decide to take in order to promote a healthy community within your app. So now we've covered a lot about refunds and how to handle them appropriately. So now let's switch gears and jump into how we're making it easier for you to manage your subscriptions. First taking a look at some of the key events in the subscription lifecycle.

These include acquiring a subscriber for the first time, any auto-renew successful or unsuccessful, disabling or enabling auto-renew upgrades or downgrades and cancellations. So what do all these events look like for a customer and for you. So when the customer first subscribes we establish the subscription period and a fixed auto-renew period to repeat renewal after renewal. Within the first subscription period, your customer decides to turn off auto-renew thinking that they just aren't using the subscription enough, but later turns it back on after a little more time with their subscription.

After that we approach our first scheduled auto-renew. But there is an auto-renew failure due to a billing issue. At this point, we'll try to auto renew for the duration of the billing retry period. Also establishing a grace period. Luckily the subscription is recovered during our grace period so the renewal cycle remains the same. Shortly thereafter your customer decides they are enjoying their subscription so much that they want to upgrade. For an upgrade we start the customer at the higher tier immediately, shifting our upcoming renewals. Later after not using that higher tier as much as expected your customer decides to downgrade back to a more basic tier.

Downgrades take place at the end of the subscription period. So your customer will have access to the higher tier of service until their next scheduled auto-renew. So how can you keep track of all of these important events for your subscriptions. What we recommend is using App Store server notifications for status updates. This is a push approach, meaning you don't ask us for information we'll just tell you when something happens. And we do. We notify you when the status of one of your subscriptions changes providing you with a new receipt for your records at that time but only when you need it.

This solution is also more scalable as you require more subscribers. So let's dive into our App Store server notifications now to see what we offer and to learn a little bit more about them. When you start receiving App Store server notifications or if you already are. This is the payload you can expect to see. Note that this is a subset of possible fields and not all of these may be present all the time. There's a lot of information here, so I want to focus on some of the key components. When you received this payload first look for the auto_renew_product_id to see exactly which product the notification applies to and the product we plan to auto-renew next.

Then check the notification_type. This will tell you the type of event you are receiving. You should also verify the value and the password field matches your shared secret. So you know the content comes directly from Apple and is trustworthy. You should also look for the bundle identifier. This will tell you which of your apps you've received a notification for.

Then you want to look for the unified_receipt, this object mimics the response from verify receipt, so if you're already using verify receipt this should be familiar. The latest_receipt in the unified_receipt object gives you an updated accuracy for this customer for your app. The latest_receipt_info array contains the 100 latest transactions for your app. You can search here by the original transaction id to know which subscriptions are active for this customer. Finally look at the pending_renewal_info array to find the upcoming renewal info for each subscription the customer uses in your app. Now let's quickly revisit the notification type field. We'll send you notifications for several events and the notification type field