DEV Community: Qonversion

What does restore purchase mean?

Surik Sarkisyan — Sun, 23 Oct 2022 20:20:15 +0000

When users purchase non-consumables, auto-renewable subscriptions, or non-renewing subscriptions, they expect them to be available on all their devices and indefinitely.

For the cases when a user upgrades to a new phone or reinstalls the app, you should provide them with UI functionality for restoring purchases. This allows them to regain access to any previously purchased content without paying again. But how can you create the capability and ensure it works across both iOS and Android?

In this article, we will explore what does restore purchase mean, how to configure it on iOS and Android, and the primary differences between them.

What does restore purchase mean?

The restore purchase capability is a functionality (most commonly seen as a “Restore Purchase” button) that enables app users to maintain access to subscriptions and other in-app purchases without going through the purchase process again. This mechanism allows your users to restore purchases manually.

This method is Apple’s recommended approach to restoring purchases. However, if you enable this automatically, your users will be shown a login screen that interrupts user flow – which is anything but user-friendly.

In case you have an internal authorization logic that allows you to manage access without prompt screens, you can avoid placing this “Restore Purchase” button. However, the restore button is still the most common practice. This button should trigger the specific Restore method, which will unlock the needed permissions for your users.

Cases for restoring purchase

Our recommendation is to have this button by default. Why? Having a restore purchase feature set by default could be useful for your user:

If the user has multiple devices signed in to the same account
If the user upgraded their device
If the user reset their device to factory settings
If the app was deleted and reinstalled on a device

What products could be restored?

There are 3 types of In-App Purchases that can be restored:

Non-consumables: a type that customers purchase once. They don’t expire.
Auto-renewable subscriptions: services or content that customers purchase once and renew automatically on a recurring basis until customers decide to cancel.
Non-renewing subscriptions: services or content provide access over a limited duration and don’t renew automatically. Customers can purchase them again.
Consumables purchases are not applicable for restoring as they are associated with the account. For example, if a user previously purchased “coins,” these purchases are connected to his account, and there is nothing to restore from StoreKit or Google Play Billing Library. To learn more about this process, check out our guide on how to set up consumable and non-consumable purchases.

How to configure restore purchases on iOS?

In most cases, restoring purchases on iOS only requires you to refresh the app receipt and redeliver the products listed on the receipt. The refreshed receipt contains a record of the user’s purchases in this app from any device the user’s account is logged into. To restore purchases, use native StoreKit methods. In this guide, we’ll explore the StoreKit method as the most commonly used. We are excited by the potential of StoreKit 2, so you can learn more details about it in this the following article.

Use SKPaymentQueue restoreCompletedTransactions() to restore non-consumables, non renewable, and auto-renewable subscriptions. StoreKit notifies the app’s transaction observer by calling paymentQueue(_:updatedTransactions:) with a transaction state of SKPaymentTransactionState.restored for each restored transaction. If restoring fails, see restoreCompletedTransactions() discussion for details on how to resolve it.

If you use Qonversion to manage your in-app subscription, call this method:

Qonversion.restore { (permissions, error) in
  if let error = error {
    // Handle error
  }
  if let permission: Qonversion.Permission = permissions["plus"], permission.isActive {
    // Restored and permission is active 
  }
}

How to configure restore purchases on Android?

When compared to Apple, Google doesn’t have a specific process for restoring purchases. As Google mentions, the history of purchases is available in Google’s cache, so users receive all associated permissions automatically. From our experience, it would be better to consider restoring purchase flow, as Google’s cache could consist of unactual information or could be cleaned.

To restore Google’s purchases, use this method:

public abstract void queryPurchaseHistoryAsync (QueryPurchaseHistoryParams queryPurchaseHistoryParams, 
                PurchaseHistoryResponseListener listener).

There you get the items that are purchased, and that`s it. Take note that Google returns just the last purchase from each Product.

If you use Qonversion to manage your in-app subscription, call this method:

`
Qonversion.restore { weak self in
if let error = error {
// Handle error
}

if let permission: Qonversion.Permission = permissions["plus"], permission.isActive {
// Restored and permission is active
}
}
`

Conclusion

In this article, we explored what does restore purchase mean and the flow on how to configure restore purchases on iOS and Android. By implementing this feature, you can help customers continue their paid services with ease – and keep positive user reviews coming!

Want to learn more? We know a thing or two about in-app purchases, as Qonversion provides a complete cross-platform infrastructure that allows you to create and restore purchases, validate receipts, and provide your app with an accurate subscription status without the need to build your server.

So if you’d like to learn more about it or have any questions, feel free to contact us anytime. We’d love to help you discover how to build better subscription experience with Qonversion!

How to Create Google Play Promo Codes for Android Apps

Maria Bordunova — Wed, 19 Oct 2022 12:43:53 +0000

Google Play Developer Console offers you a number of tools that help you grow your app business. Promotions are one of them. By using these, you can launch effective acquisition campaigns (and significantly increase your installs metric), partner programs or simply use these codes as incentives (as “thank you” or “sorry” gestures). But before launching such campaigns, you should be aware of how it works and consider the limitations of the Google Play promo codes. So, let’s dive into the technical side.

Prerequisites

To start with promotional codes, you should integrate the Google Play Billing Library into your app. Keep in mind that promotion redemptions can happen outside of your app or even when the app hasn’t been installed yet. It means that your app must handle purchases with promo codes correctly regardless of the app state.

Types of Google Play promo codes

There are two types of Google Play promo codes: one-time and custom codes. The main difference is that one-time codes are automatically generated unique codes that could be used only once by a single person. The custom codes could be named universally (for instance, by name of the event where you promote your app) and used multiple times by multiple users according to your predefined limit. Custom codes are available only for subscriptions.

Once you create a promotion, you can’t change the number of promo codes in that promotion or switch promo codes to a different type. But promo codes created for subscription promotions do not count towards your limit for non-subscription promotions, and vice versa. With that in mind, define your strategy wisely.

How to create Google Play promo codes for your app

1. Open the ‘Promo codes’ tab within Google Play Developer console.

Navigate to Google Play Developer Console and select the ‘All apps’ tab from the menu on the left. Then, select your app from the list. Select the ‘Monetize‘ -> ‘Promo codes‘ tab in the left menu bar.

Click the ‘Create promo code’ button.

2. Specify the details of the promotion.

Name identifies the promo code in Google Play Console. Visible only to you.
Start date must be in the future.
End date must be within one year of the start date.
Details on Google Play promo codes

3. Choose promotion type.

Paid app: Give users a paid app for free with promo code.
In-app product: For non-subscription promotion link an existing in-app product from a drop-down list.
Subscription: For subscription promotion specify an existing subscription and duration of the trial period. Note: If a customer uses a promo code for a subscription that has already a free trial, the promo code will override the original free trial length.

4. Create one-time promo code.

In the group box ‘Code type’, choose ‘One-time codes’. Enter the number of promo codes to be created.

Click on the ‘Save’ button at the right bottom of the page. It’ll open a popup window that notifies you to implement the billing library in your app. Click on ‘Create’ in the window:

After that, you’ll be able to download promo codes as a CSV file:

That’s it! Now you can share these unique numbers via emails or personal event invitations, or simply share them with your support team so they can engage with your users more effectively.

4.1 Create custom promo code.

Enter a unique (per app) custom code using numbers (0-9), lowercase (a-z) and uppercase (A-Z). Also, specify the number of code redemptions:

User redemption flow

Once we set up everything on the Google Developers Console side, let’s take a look at this process from the users’ standpoint. In the examples below, we’ll explore promotional codes for subscriptions.

In-app redemption flow

The user can redeem a promo code as part of the normal purchase flow. Instead of purchasing the product, the user enters the code and gets the product, like a usual in-app purchase.

Start the purchase flow for the product for which you created a promotion.
Specify the Google payment method as ‘Reedem code’:
Enter the promo code and select ‘Redeem’:
If the promo code was entered correctly, a window will appear with the subscription details and the trial duration. User needs to click on ‘Continue’.
The purchase window should open. User should click ‘Subscribe’ there.

Google Play promo codes redemption flow

A user can also redeem a promo code in Google Play:

Open the Google Play app.
Open the menu by clicking the three lines in the left upper corner.
Scroll down and select ‘Redeem’.
Enter the promo code and click ‘Redeem’:
If the promo code was entered correctly, a window will appear with the subscription details and the trial duration. User needs to click ‘Continue’
The purchase window should open. User should click ‘Subscribe’ there.

To save the user from having to enter a promo code, you can generate a URL with it. Share the URL that directs the user to Google Play Store.

URL has the following format: https://play.google.com/redeem?code=promo_code

Accelerate your app promotion strategy with Google Play promo codes

Google Play promo codes are a universal tool for user acquisition and engagement that allows you to launch campaigns even with a limited budget. This is a great tool to increase the number of installs, but to convert these users to subscribers, provide them with great onboarding, and give them their “Aha!” moments as soon as possible.

Google Play promo codes are also a great tool for user engagement and receiving reviews — just send your users a notification with the unique code at the right time and gift them access to the new experience. To find out how to create custom push notifications on Android, read this article.

So there are so many things you should test. To see how your campaigns affect your subscription revenue, use Qonversion analytics tools. Try even more strategies with A/B testing and Automation. And if you still have any questions — we’d be happy to hear from you!

How to send in-app subscription events to Firebase, Google Analytics, and Google Ads

Surik Sarkisyan — Sun, 16 Oct 2022 15:56:24 +0000

Google provides massive user acquisition opportunities for subscription apps. Using Google’s App Campaigns you can promote your app across Google Search, Google Play Store, YouTube, Discover on Google Search, and the Google Display Network. Besides user acquisition, Google’s Firebase and Google Analytics provide a set of tools to manage and grow your product. This includes advanced A/B testing, push notifications, and analytics.

But to be able to truly leverage Google’s ecosystem, a subscription app needs to send accurate in-app subscription data to Google, including data on subscription renewals and trial-to-paid conversions.

For example, though Google’s machine learning does most bidding and performance optimization in Google App Campaigns, it still needs correct revenue data to do so effectively.

This article covers how to set up conversion tracking for subscription apps with Firebase. The data from Firebase can be used everywhere on Google’s platform, from A/B testing in Firebase to campaign optimization on Google’s App Campaigns. Additionally, we will take a closer look at how conversion tracking affects your Google App Campaigns.

Google Analytics for Firebase SDK

Firebase Google Analytics is a free app measurement solution that provides insights on app usage, user acquisition, and engagement. Google recommends using this solution as it is most accurate, so if you’re using Google Ads SDK, please consider switching your tool to Firebase.

When SDK is in place, you’ll automatically receive a number of events that could be used as conversion events (goals) for your Google Ads campaigns.

However, there are just a few predefined events that make sense for subscription apps:

app_store_subscription_renew
app_store_subscription_convert
app_store_subscription_event_started (Android only)
app_store_refund (Android only)
in_app_purchase

As you see, the number of subscription events to track is very limited.

Firebase Integration: How to send subscription events to Firebase and Google Analytics

Qonversion enriches Firebase data with subscription revenue events, including purchases, trial conversions, subscription renewals, and even refunds. This allows you to match your users’ behaviour with their payment history in Firebase, empowering your user acquisition and product decisions. Qonversion sends events server-side, which means that renewals and cancellations are sent to Google Analytics in real-time, even if the customer doesn’t open the app. And even more importantly, implementation takes about 20 minutes.

Firebase track install, In-app purchases and subscriptions events iOS, Android.

To send subscription events to Firebase, you need:

Set up the Google Analytics for Firebase SDK
Set up Qonversion SDK
Send firebaseAppInstanceId to Qonversion using User Properties.

if let appInstanceID = Analytics.appInstanceID() { Qonversion.setProperty(.firebaseAppInstanceId, value: appInstanceID) }

Configure the Firebase Integration 4.1. Copy your Firebase App ID and Measurement Protocol API secret from the Google Analytics Console: Admin → Data Streams → Select existing or create a new stream for your App.

4.2. Navigate to the Tools → Integrations section in your Qonversion account.

4.3. Choose your platform (IOS or Android) and click the Add new + button and select Firebase.

4.4. Provide the API Secret and App ID copied in the first step to the corresponding fields.

That’s it! From now on, all subscription events will be visible in Firebase.

How to link Firebase Google Analytics to Google Ads

This step is necessary if you’d like to optimize your Google Ad campaigns based on Firebase conversion tracking events.

To successful setup, you need to perform four steps:

Firebase => Project Settings
Click Integrations tab
Link Google Ads to Firebase project
Enable events as conversions: On the Events tab, in the row for Qonversion events, turn on the switch in the Mark as conversion column. You can have a maximum of 15 conversion events per app in Firebase. Once an event has been enabled as a conversion, it is available in Attribution > Conversion Events. Attribution reporting begins for that event at the time you enable it as a conversion.

The data from Qonversion Firebase Integration unlocks new capabilities for Google App Campaign optimization for subscription apps. Let’s take a deeper look.

What Google App Campaigns are

Google App campaigns are user acquisition channels that allow you to promote your app within the Google Network – on Youtube, Discover, Search, Google Play, etc. Unlike most Google Ads campaigns, you don’t need to create individual ads for each campaign. You only need to upload the set of assets: text, images, videos, and a starting bid and budget. Google will automatically design different ad variations across different formats and networks. Google Ads will test different combinations and show better-performing ads more often, with no extra work on your part.

There are three main types of Google App Campaigns:

Google App Campaigns for installs.
Google App Campaigns for pre-registrations.
Google App Campaigns for engagement.

The insights of this article could be the most useful for Google App Campaigns for Engagement and Google App Campaigns for Installs optimization. You can check more details on Google App Campaigns here.

How to optimize Google Ad based on Firebase conversion events data

Google App Campaigns optimization by conversion event

You can set the primary conversion event for your Google App Campaign. Google Ads will automatically use this data to learn to optimize your ads, using this parameter to get you the best number of conversions and to optimize your set cost-per-action bid.

Open the settings of your Google App Campaign.
Choose which in-app actions (conversion event) you want to optimize your campaign for, and then enter a target cost per this action (target CPA).

That’s it! Now Google Ads has enough data to learn to optimize your campaign by specific metrics: trial to subscription, or subscription to renew, etc. The fill list of metrics that you could optimize your campaigns for is here.

Google App Campaigns optimization by the audience

You can create audience segments in Firebase using any combination of events and user properties (for instance, people from UK that subscribed to your app for the first time).

Then, you could apply your segments for a particular App Campaign. Segments based on mobile app data can be targeted by Search, Display, and Video campaigns.

Create a segment in Firebase.
Make sure that your Firebase account is linked to Google Ads.
Open the settings of your Google App Campaign.
Choose the Target Audience Segment.

That’s it! Now Google Ads has enough data to lern to optimize your campaign for the specific audience – whether they are new or returning users, or people from specific territory.

Conclusion

In this article, we explored how Qonversion Firebase Integration allows you to enrich Firebase data and improve the strategy of your user acquisition campaigns. In the following article, we’ll dive deeper into how this integration enables you to attribute user acquisition costs within other Ad Networks outside Google – AdColony, IronSource, Vungle, and others.

SKErrorDomain Code=0. What is it and how to fix it?

Surik Sarkisyan — Mon, 10 Oct 2022 08:30:06 +0000

Domain=SKErrorDomain Code=0 “(null)” is one of the more common errors that you may struggle with while processing in-app purchases. This error can occur in both production and sandbox environments and affects the fail to success payment ratio of your app.

Though the reason for this error is more likely to be on the App Store’s side, there still are a few things to try.

In this article, we’ll give you a brief overview of the possible reasons for the error, and what you could test to prevent it from happening.

SKErrorDomain Code=0 in the sandbox environment

When SKErrorCode=0 occurs while in the sandbox environment and not in the production environment, it could be related to issues with the sandbox on Apple’s side and could potentially affect the make payment call and the /verifyReceipt endpoint, although it won’t do this in production mode.

Things you can check:

Test your in-app purchases with a real device, not in the simulator
Check your in-app Product ID
Create a new sandbox test account on the App Store, then logout from all other accounts, and then test it with the new sandbox test account
Check whether your in-app purchases are configured correctly on App Store Connect and have the following statuses: Ready to submit or Ready for sale.
Check if your app bundle ID matches the bundle ID from App Store Connect where the purchases were created.
Add Localisation (Subscription Display Name and Description) to the product. The hypothesis is that there is no obvious way to see this from the error and therefore you may quickly miss it when you are preparing placeholders for future In-App Purchases. However, it seems that Apple should mention this in its documentation and implement an error code that gives a warning about any missing metadata.
Reboot/Reset the device
Check that you agreed with the latest versions of Apple’s policies

If you have tried everything from the list above, then it means that the issue is on the App Store’s side and you should follow the information on Apple’s status page or submit a bug report.

SKErrorDomain Code=0 during the review process

If you have difficulties during the app review process, then you will have to ask the reviewer to retry the purchase. Also, Apple’s engineers highlight that App Review should not see any issues with sandboxes as they use special accounts for the review process. So if your app was rejected then the issue mostly probably lies elsewhere.

SKErrorDomain Code=0 in production environment

If you receive Error Domain=SKErrorDomain Code=0 “Operation could not be completed. (SKErrorDomain error 0.)” in the production environment, try the following:

Make sure you have used the correct Product Identifier. If you have, then you’ll get error 0 shortly after calling [SKPaymentQueue addPayment:], and before you get the popup asking you to confirm payment.

Try to create a new test user as your current test user might have been invalidated. This can happen if you accidentally log into the App Store with your test user. When this happens, you’ll get error 0 after entering your password to confirm the payment.

Unfortunately, not much else can be done regarding this error while in the production environment. This error mostly comes directly from Apple, and is an unknown error to do with their API. If you are using Qonversion to manage in-app subscriptions, we would also recommend checking our status page for any reported outages. Unfortunately, these errors are returned randomly and directly from Apple.

Submit a bug report about SKErrorDomain Code=0

When the issue is on Apple’s side, it can affect everyone or just some users. It’s always a good idea to submit a bug report with complete information, including a sysdiagnose archive from the device. To submit the bug report, please use Apple Developer Bug Report and follow the instructions. Before you begin, make sure you are familiar with triggering the sysdiagnose log, then follow and perform each step to replicate the problem. When the failure occurs, first, trigger the sysdiagnose profile, then wait 5 minutes before syncing the device with Apple Store and then look for the sysdiagnose archive file. While reproducing the issue, you should take screenshots showing evidence of the connection failure.

We will update this article if and when more details regarding this error become available. If you are getting other Storekit errors, then check out this complete guide on how to handle storekit errors.

Apple Fiscal Calendar 2023

Yulia Kondrashova — Mon, 26 Sep 2022 20:11:52 +0000

So, it’s that time of the year again when Apple starts their fiscal year. It is essential for an owner of a mobile app that works on Apple devices to know how to track the revenue and when you’ll be paid your App Store earnings. In this article we explained the main logic behind Apple’s financial calendar and here is a quick recap of how do the fiscal year works:

In general, Apple’s fiscal year is 364 days and it’s divided into four fiscal quarters (Q1, Q2, Q3, and Q4)
Each fiscal year quarter starts with a 35-day fiscal month (5 fiscal weeks) and is then followed by two 28-day fiscal months (4 weeks each)
The first day of the fiscal year is the last Sunday of September
The first day of the week is Sunday (the same as the US calendar)
Apple will release the 2023 Apple payment calendar in September of 2022

We’ve prepared the preliminary Apple fiscal calendar 2023 for you below.

Qonversion offers you an ability to track the revenue that you expect from Apple as well as other subscription app metrics such as churn, retention, refunds, renewals of in-app subscriptions, and other crucial aspects for your business KPIs.

Click here to check Apple fiscal calendar 2023

How to Configure Subscriptions on the Web with Stripe and Grant Users Access on iOS and Android

Maria Bordunova — Thu, 11 Aug 2022 10:35:00 +0000

Implementing renewable subscriptions is a daunting task, especially if you haven’t dealt with a third-party payment processors’ APIs like StoreKit, Google Billing Library, Stripe before. And it becomes much harder when you need to support several platforms simultaneously. You’ll find that managing cross-platform subscriptions is challenging as you need to solve technical integration complexity, consider different platforms’ policies and requirements, find the right approach to manage subscription statuses (cancellations, upgrades, downgrades, etc.), and analytics.

At the same time, cross-platform subscription management provides your users with the best user experience on any device anywhere, and allows you to reduce platform fees (15-30% for app stores and 2-3% for Stripe — just feel the difference).

In our previous article, we covered granting access on the web after a purchase was made on iOS and Android platforms. Now let’s dig deeper into the web part and explore how to configure Stripe payments and grant your users premium access on iOS and Android apps.

Connecting Stripe to Qonversion

The first step is to connect Qonversion to your Stripe account. Navigate to your Qonversion project settings. Select Stripe and switch on the Stripe toggle.

This will bring you to the Stripe sign in page. Click Connect if you have an existing Stripe account or create a new one if required. If your Stripe account isn’t activated yet, you need to activate it (add business details, banking information etc).

Setup Stripe Product and Permission

Let’s assume you have already had the Qonversion Product that contains Apple and Google product stores identifiers. If you want to sell a similar product with Stripe, update the existing product in Qonversion with the Stripe product ID.

The Stripe product ID can be found in the Products tab in Stripe Dashboard. Just select the product and copy its ID shown at the top right corner of the page.

Make sure that your Qonversion product is associated with Permission that indicates premium status of a user.

If you want to sell subscriptions only on the web, you can just leave empty the Apple Store and Google Play Product ID fields in the Qonversion product details.

Sending Stripe Purchase Data to Qonversion

You can directly call API methods or use our Web SDK in your web app to send Stripe subscriptions data to Qonversion. Choose the method that is most suitable for you. If you have never worked with API endpoints before, our recommendation is to use Qonversion Web SDK to send Stripe purchases data.

1. API methods

Qonversion provides a high-performance REST API that allows you to create and identify users, send purchases data, get user entitlements, and more. This section of the article covers the methods you should use in order to get cross-platform access based on Stripe purchases.

1.1 Create User

Before you start sending Stripe purchase data, you need to create a user. A user is a cross-platform entity with User object with the following endpoint:

POST https://api.qonversion.io/v3/users/:user_id

User_id is the Qonversion User ID that will be registered for this user. Let’s use the following identifier aa47b6fa as the user_id in this example.

1.2 Identify the User

User Identity allows cross-platform user identification and access management. Identity manages user access based on payments across different platforms. You can find more info about Identity in our documentation.

Identify the user with the Identity method:

POST https://api.qonversion.io/v3/identities/:identity_id

For identity_id always use unique ID values. Otherwise, a user can get matched to another user’s premium status. You can use the user ID from your internal system as identity_id. In our example, we will use stripe_aa47b6fa as the identity_id.

1.3 Send Purchases

Here we get to the most interesting part. Now everything is ready for sending user purchases data to Qonversion. Use the purchases endpoint for this:

POST https://api.qonversion.io/v3/users/:user_id/purchases

Below is the example with the parameters you should forward with the method body:

{
"currency": "USD",
"price": "100",
"purchased": 1659428809,
"stripe_store_data": {
   "subscription_id": "sub_1LSGVgL9K6ILzohYq5GCbktn",
   "product_id": "prod_MAbVQQaljmF6gm"
 }
}

In order to grant users with valid permissions, product_idmust be the same as Stripe Product Identifier that you provided in the previous step to the Qonversion Product annual. Subscription_id is an identifier for a Stripe Subscription object. Description of the rest parameters can be found in our guide on sending Stripe purchases data to Qonversion.

If the purchase was created successfully, the response will be the following:

{
   "currency": "USD",
   "price": "100",
   "purchased": 1659008000,
   "stripe_store_data": {
       "product_id": "prod_MAbVQQaljmF6gm",
       "subscription_id": "sub_1LSGVgL9K6ILzohYq5GCbktn"
   },
   "user_id": "aa47b6fa"
}

You can now check the Customers tab in your Qonversion account looking for your customer. Search is available with Qonversion user_id(aa47b6fa) or identity_id(stripe_aa47b6fa):

And here are the details on customer level that you can quickly see in Qonversion dashboard including price and date of the purchased product:

Once you successfully send the purchase, Qonversion infrastructure handles all subscription changes like renewal, trial conversion, refund etc. This affects user permissions and is reflected in our analytics dashboards.

1.4 Get Entitlements

At this point, you should be able to receive the active permission that was configured in the previous step (Setup Stripe Product and Permission). In our example, this is a permission with a premium ID. Call the following method to check entitlements:

GET https://api.qonversion.io/v3/users/:user_id/entitlements

Below you can see the example with entitlement response:

{
   "data": [
       {
           "active": true,
           "expires": 1690965033,
           "id": "premium",
           "product": {
               "product_id": "annual",
               "subscription": {
                   "current_period_type": "normal",
                   "renew_state": "will_renew"
               }
           },
           "started": 1659429033
       }
   ]
}

2. Web SDK

Web SDK is a TypeScript browser-client SDK that interacts with Qonversion API under the hood. With Qonversion’s Web SDK, you can easily identify users, send purchases, customize user properties, check an entitlement state, but it is still required to receive an entitlement state on the backend side. You can find SDK to be a more flexible and convenient way to share data to Qonversion from your web app.

2.1 Launch Qonversion Web SDK

You can find detailed information on how to launch the SDK in the documentation here. You need to call the Qonversion.initialize method and pass QonversionConfigBuilder as a parameter:

const qonversionInstance = Qonversion.initialize(config);

2.2 Identify the user with Qonversion Web SDK

Identify the user with the identify method:

await qonversionInstance.identify('identity_id');

Always use unique ID values for identity_id. Otherwise, a user can get matched to another user’s premium status. You can use your internal user ID from your system as identity_id. In this example, we will use stripe_aa47b6fa as the identity_id.

2.3 Send purchase

Collect stripe purchase data and call the sendStripePurchase method:

сonst stripePurchaseData: PurchaseCoreData & StripeStoreData = {
  currency: 'USD',
  price: '100',
  productId: 'prod_MAbVQQaljmF6gm',
  purchased: 1659008486,
  subscriptionId: 'sub_1LSGVgL9K6ILzohYq5GCbktn'
};

const purchase = await qonversionInstance.sendStripePurchase(stripePurchaseData);

In order to grant users with valid permissions, product_id must be the same as Stripe Product Identifier from the Qonversion Product annual (see the previous step Setup Stripe Product and Permission). Subscription_id is an identifier for a Stripe Subscription object. Description of the rest parameters can be found in our guide Send Stripe purchases to Qonversion.

If the purchase is created successfully, the response is the following:


{
  currency: 'USD',
  price: '100',
  purchased: 1659008486,
  stripeStoreData: {
    subscriptionId: 'sub_1LSGVgL9K6ILzohYq5GCbktn',
    productId: 'prod_MAbVQQaljmF6gm'
  }
}

You can check the Customers tab in your Qonversion account to see the details of this user. You can use identity_id(stripe_aa47b6fa) to find the customer:

You can see the details on user level including a purchased product price and the date of the purchase:

Once you successfully send the purchase, Qonversion infrastructure handles all subscription states like renewal, trial conversion, refunds etc. It affects user permissions and shows up in analytics as well.

2.4 Get entitlements

At this point, you should get the active permission that was configured in the previous step (Setup Stripe Product and Permission). In our example, this is a permission with a premium ID. Call the getEntitlements method:

const entitlements = await qonversionInstance.getEntitlements();

Get Subscription Status and Unlock Premium Access on Mobile Apps

The last step is to get a subscription status on an iOS or Android mobile app to handle user access. Launch the app and call the identify method:

iOS

Qonversion.identify("identity_id")

Android

Qonversion.identify("identity_id")

Identity ID must be the same you used when identifying the User on the web.

Then call the checkPermissions method:

iOS

Qonversion.checkPermissions { (permissions, error) in
  if let error = error {
    // handle error
    return
  }
  if let premium: Qonversion.Permission = permissions["premium"], premium.isActive {
    // handle the permission
  }
}

Android

Qonversion.checkPermissions(object: QonversionPermissionsCallback {
    override fun onSuccess(permissions: Map<String, QPermission>) {
        val premiumPermission = permissions["premium"]
        if (premiumPermission != null && premiumPermission.isActive()) {
        // handle the permission
        }
    }
    override fun onError(error: QonversionError) {
        // handle error here
    }
})

As you can see here, a mobile apps user has the entitlements (access level) based on his stripe subscription.

Android / iOS

Conclusion

This article demonstrates how to manage users’ access on mobile apps based on their web subscriptions. The implementation is quick and straightforward.

Once you implement cross-platform subscription management, you can easily track the performance of each platform in Qonversion analytics dashboards. Moreover, Qonversion offers a set of tools to leverage your subscription data including integrations, Apple Search Ads attribution, and push notifications.

5 ways to increase app valuation and score a beautiful EXIT webinar

Yulia Kondrashova — Wed, 15 Jun 2022 13:52:56 +0000

Hello team 😊

On June 21, 2:00 p.m CEST, we will hold a webinar together with Alon Waller from Bluethrone, an app acquisition company.

Join this webinar to learn more about:

How to measure and optimize the metrics that affect investors’ decisions
Why ASA is a must-have tool for those who want to sell an app
App Quoting Engine: how do investors determine what is the real value & growth potential of each app
Investors’ insights: what will make investors want to pay more?

Hurry up to save your spot! We’re waiting for you :

https://qonversion.io/webinar-five-ways-to-increase-app-valuation

What’s new in StoreKit testing (WWDC22 updates)

Surik Sarkisyan — Mon, 13 Jun 2022 07:12:57 +0000

New day, new WWDC22 session, new overview! Today we’ll walk you through the updates in StoreKit testing.

Before we move on, I’d like to emphasize that previous significant updates for StoreKit testing were introduced during WWDC20, which we’ve also covered here.

Now, it’s time to move on to the brand new updates!

What we will cover today:

StoreKit updates in Xcode 14
Advanced subscription cases
Sandbox updates

StoreKit updates in Xcode 14

During WWDC20, the StoreKit.configuration file was announced. This unlocked the capability to test in-app purchases without needing to set up the Products in App Store Connect.

This allowed you to set up in-app products directly in StoreKit.configuration file, and this local file would be the only place that contains these products and purchases.

The latest WWDC22 updates require you to create the app and products in App Store Connect. You still have an option to test your in-app purchases through StoreKit.configuration directly in Xcode without having an app in App Store Connect. The only limitation of this commonly used approach is that you will not have the chance to use a part of a new features.

You may wonder: what are the features of this and are they worth all this hassle with app creation in App Store? My answer is: absolutely!

By having an app with the products in App Store Connect, you can create a new configuration file in Xcode that will synchronise these products with those that were created in App Store Connect. Any changes that you make within App Store Connect – whether changing the title of the product or doing something else – can be synced with this Xcode Configuration file.

Additionally, you can convert this new file into the local version that won’t be synced with App Store Connect, but will give you an option to edit your products directly in Xcode. Be accurate and careful here, because this is a one-way operation. You will not have a chance to convert the local file back to the synced version. So, in order to proceed with further syncs you’ll need to create a new file. A great option is to have several StoreKit.configuration files; for instance, you could have both synchronized and local ones.

To create the new StoreKit.configuration file you should go to Xcode Menu => File => New (or lock Command + N). Then, type storekit in the search, select StoreKit.configuration file, and push the “Next” button.

Here’s a screenshot to clarify this process:

In Xcode 14 while creating this file you’ll see the checkbox that enables the syncing of in-app products with App Store Connect. To turn this option on, you need to choose the Team and App.

It will be pretty clear to you that to create the local file you should just fill the name of the file and leave the checkbox unchecked.

Once you create a configuration file, all the information about your Products begins to sync with App Store Connect. In the lower right corner, you’ll notice the indicator showing you that data downloading is in progress. Even though this job is in progress, you can still continue to work in Xcode.

Those who used to work with the local version of StoreKit.configuration will notice that the newly created file differs from the files that they used to see. The reason for this is that this local version of StoreKit.configuration is read-only. All the changes in products should be made with App Store Connect.

As we highlighted before, all the changes in products that were made in App Store Connect can be synced in StoreKit.configuration file just with one button below. Once the sync is complete, you can see the changes reflected in Xcode.

As I mentioned, this is a read-only file.

You still can easily copy the Product from this file and move it to the local StoreKit.configuration file in Xcode. To do so, right click to the Product that you’d like to copy and click “Copy”. Then choose the local file and open Xcode Menu => File => Paste (or hold command + V).

Alternatively, you can convert this synced file to the local one. You can’t undo this operation, but if necessary you can create a new synced StoreKit.configuration file. Xcode Menu => Editor => Convert to Local StoreKit Configuration.

Let’s move on to the testing.
To start this process you should choose the StoreKit.configuration file in Xcode that should be used for building the app. This is a commonly used method.

Then open Scheme Editor:

Choose the “Run” action, then “Options”, and then choose the right file in the StoreKit Configuration:

Congrats on the successful set up of your testing environment! Now you can configure your app.

One more great update for those who use SwiftUI: starting with Xcode 14, all the Products from StoreKit.configuration files will be uploaded to SwiftUI previews.

Let’s move on to the testing. As you might remember, WWDC20 introduced the Transaction Manager. You can open it by clicking on the “Purchases” icon in the debug bar.

Xcode 14 Transaction manager includes Transaction Inspector (on the right side) that displays under-the-hood details about a transaction. This is a super convenient way to check subscription statuses. For instance, here you could see the information about expired subscriptions or subscription renewals.

Also, by clicking these buttons you can move to the specific Product in StoreKit.configuration file in Xcode.

Moreover, at the bottom part of the inspector, there is a field to filter transactions. For instance, you can filter by the day of creation of the transaction or by Product ID. This significantly simplifies the way you navigate all your transactions (it is quite a daunting task, as you have all subscription renewals that may confuse your detection of which transaction entitles the feature).

Advanced subscription cases

The new version of Xcode allowed the chance to test things in a more convenient way, and to test something that was previously impossible to test. This is really exciting!

What was added:

Refund requests
Offer codes
Price increases
Billing retry and a grace period

Refund requests

As you might guess, the option to cancel the subscription directly in the app was released. It means that you can test this functionality for your app.

To show the corresponding screen you need to call just one function: refundRequestSheet(for:isPresented:onDismiss:)

The refund request sheet will appear above the view. It will include the list of refund reasons, and this list corresponds to revocationReason property in the App Store Server API.

It looks like this:

If we are speaking about the Product in App Store, you should remember that refunds can take some time to process; however, when testing with Xcode or Sandbox, a refund request will immediately refund the transaction. You could see this refunded transaction in the Transaction Inspector. You’ll see both the refund reason and the refund date there.

Moreover, you can test the refund directly in the Transaction Manager by clicking the “Refund purchases”.

We’ve described how to test refunds, but how does it look from the code perspective?

The Transaction object that is received from StoreKit consists of revocationDate and revocationReason properties. This will help you detect the refunded transactions.

For iOS and iPadOS the testing through Xcode iIs available starting version 15.2, through Sandbox – starting 15.0. MasOS in Xcode – 12.1, Sandbox – 12.0.

Offer codes

In the following example, let’s test offer codes redeem flow with the local configuration file. If you already have offer codes in App Store Connect, and you use synced StoreKit.configuration file, you’ll see these codes automatically in Xcode.

For our case: go to the local file, click the “plus” in “Offer Codes”, configure Offer Code, and click Save.

Once configured, it should be tested. The code implementation is simple in the case of refund requests. You just need to call the function: offerCodeRedemption(isPresented:onCompletion:)

Now you should see the redeem offer code sheet above your app. Only the users of your production app should enter offer code in this field. While testing with Xcode, you won’t need to enter offer code in this info, but rather only to choose the offer code from the list (as all this data is kept in StoreKit.configuration file).

It’s incredibly easy: choose the offer code, confirm the operation – and profit!

Once the offer code is successfully processed, you’ll see this transaction in Transaction Manager; all the details will be available in the new Transaction Inspector.

Let me skip the part where I explain the logic of managing this transaction, as it is quite straightforward. The only difference from managing the ordinary transaction is that you should check a few additional properties.

While managing transactions you can check the offerType property to see if there is an offer applied to the current transaction. While handling renewalInfo, use its property offerType to see what kind of offer will be present in the next renewal.

Offer codes are an incredibly valuable tool for working with users in your app. There are so many things you can achieve, from user acquisition to winning churning customers and support/loyalty programs. So it’s incredibly valuable that we now have a ability to test it.

Just to remind you, this option didn’t previously exist, even in the Sandbox!

Everything described above is available starting Xcode 13.3 and higher and iOS/iPadOS 15.4 and higher.

Price increases

As you might know from our previous overview of WWDC22, StoreKit Messages are aimed to be used to display messages from the App Store API to users. One example of such messages is a change in the app’s price. Let’s take a closer look at how we can test this scenario.

First, change the price of the Product in the StoreKit.configuration file in Xcode. Alternatively, you can choose the needed transaction in the Transaction manager and click the “Request Price Increase Consent”.

You can skip the flow of how to display the StoreKit Messages, but in this case the message will appear automatically over your app. If you’d like to avoid interrupting your user’s flow and do not want to affect user experience, you should implement the StoreKit Messages sequence the same way that you handle the transactions in StoreKit. Find these details here.

What is important is that this price-changing screen might be shown to your users several times until they consent to the new terms. In Xcode, you can manually call this screen only the needed number of times (read above). It is important to remember that the users might consent outside of the app – for instance, via email.

In Xcode, you can test this consent screen display scenario just by clicking the corresponding buttons in Transaction Manager.

Let’s take a look at the code side. As you work with the purchases in your app, you probably are already implemented Statuses.updates sequence. The only thing that you should do now is to check renewalInfo => priceIncreaseStatus property to receive the needed state. Check the expirationReason property to detect if the customer canceled the subscription after the price changed.

All this is unlocked by starting the following versions of OS:

Please consider that StoreKit Message testing on price changing is available just for iOS/iPadOS 15.4 version and higher.

Billing retry and grace period

Billing retry is where an error occurred while trying to renew a subscription, such as if a credit card is expired.

In this case, App Store will attempt to fix the billing issue to renew the subscription.

You can enable a grace period that gives your customer the ability to use your subscription for a limited period of time at the beginning of the billing retry state. In other words, this is a period for the user to solve billing retry issues, pay for the subscription, and continue to experience the app.

Let’s take a look at how to test this case in Xcode.

Choose your StoreKit.configuration file, then Editor Menu => Enable Billing Retry on Renewal. If you’d like to test the grace period, you can refer to the next point in the same menu.

For further convenience, you can speed up the subscription renewal rate from the same menu.

The next steps are straightforward. Let’s subscribe to the app then wait for the renewal period time (that you choose in the Subscription Renewal Rate menu). At the moment of renewal, you’ll see the new transaction with Billing Retry in the Transaction Manager. The Transaction Inspector will show that the transaction is in the grace period. Once the grace period expires, the transaction appears in the standard billing retry state. You can resolve the billing issue by clicking the corresponding button in Transaction Manager.

Handling billing retries and grace periods is key to retaining subscribers by reducing involuntary churn.

Now it’s time to explore how you can handle this in the code.

As the billing retry and grace period states change, the Status.updates sequence will emit a new value.

All that you should do is check, using the renewalInfo.GracePeriodExpirationDate property, whether your user is in the grace period. If so, you should grant him access as if the subscription were active. To detect whether the user is in a billing retry state, check the renewalInfo.IsInBillingRetry property.

Both of these states can be checked with state property in Product.SubscriptionInfo.Status you’d like, you can redirect your user to the App Store to fix the billing issues.

If you are using any currentEntitlement API, you’ll receive the transactions for expired subscriptions while they’re in the grace period.

In which versions is this feature available? Check the following:

So these are the exciting updates with Xcode testing! These will definitely improve the developers’ experience while working with in-app purchases.

Sandbox updates

Last but not least – the updates related to Sandbox.

What we’ll explore:

Sandbox Apple ID creation
App Store Connect API
Billing failure simulation

Sandbox Apple ID creation

To unlock the ability to test in Sandbox, you have to create a testing user.

There are several pieces of good news.

The number of fields that you should fill while creating the user significantly decreased.
You can use “+” symbol in email to prevent you from creating a new email for every user. For instance, “your_super_test+sandbox@iclod.com”
Added in-line suggestions for passwords

App Store Connect API

For the last few years, Apple engineers have added a lot of features to Sandbox per developers’ requests. The changing of the Sandbox account region and clearing purchase history is one of these.

Most of these features are available in App Store Connect or directly on the device on the Sandbox Manage Subscriptions page.

Later this year, the following Sandbox features will be added to App Store Connect API:

Query for Sandbox Apple IDs
Clear in-app purchase history
Set interrupted purchase state

These features will improve the speed of subscription testing with Sandbox accounts and add possibility of automated testing in the basic scenarios.

Billing failure simulation

Since launching in 2019, Billing Grace Period allowed developers to recover 300 million days of paid service to their customers. Soon, there will be the capability to use a new Sandbox Account Settings page to:

enable billing failure simulation for your account
test foreground and background subscription failures
verify subscription status with verifyReceipt, App Store Server API and App Store Server Notifications v2 in Sandbox.

Conclusion

With these testing scenarios, Apple explores the statuses that will affect App Store Notifications V2. This is a big topic to cover, so stay tuned for other articles!

We know a thing or two about in-app purchases as Qonversion provides a complete cross-platform infrastructure that allows you to create and restore purchases, validate receipts, and provide your app with an accurate subscription status without the need to build your server. So, If you’d like to learn more about it or have any questions, feel free to ping me in the comments.

If you'd like to learn more on how to handle StoreKit errors, please follow our guide. Also, recently I've created an article on how to solve SKErrorDomain 0, feel free to check!

WWDC22 overview: how to integrate and migrate in-app purchases to App Store Server API

Surik Sarkisyan — Fri, 10 Jun 2022 10:47:11 +0000

Hey everyone, today we’re going to continue our WWDC22 blog post series on what’s new with in-app purchases. We’ve already covered some of the updates: enhancements to StoreKit 2 and App Store Server API.

Today, we’ll focus on the next updates that were announced during the session Explore in-app purchase integration and migration. The session is divided into two chapters – App Store Server API and App Store Server Notifications Version 2.

In this article, I’ll mostly refer to the first part of the video. We’ll talk about App Store Server API – powerful, secure, and with efficient server-to-server endpoints, then we’ll explain how to migrate to it.

The main idea behind this API is pretty clear: to give you the all data you need about in-app purchases.

App Store API was introduced on WWDC 2021. These are two great sessions that I highly recommend to watch; however, they won’t affect your understanding of today’s topic.

What we will cover:

How to use the App Store Server API
How to sign JSON Web Tokens
How to verify signed transactions
How to migrate from verifyReceipt So, let’s get going!

Using the App Store Server API

In this part, we’ll cover the cases of Using the App Store Server API. Additionally, I’ll cover how to use the new API with StoreKit in different scenarios: when you need to support Original StoreKit, StoreKit 2, and both of it – for instance, if you decided to keep supporting StoreKit for users with previous iOS versions and add StoreKit 2 support for those who use updated versions of Apple OS.

Which endpoints are available with the new API?

GET /inApps/v1/subscriptions/{originalTransactionId} – get the statuses for all of a customer’s auto-renewable subscriptions in your app.
GET /inApps/v1/history/{originalTransactionId} – get a customer’s in-app purchase transaction history for your app.
PUT /inApps/v1/transactions/consumption/{originalTransactionId} – send consumption information about a consumable in-app purchase to the App Store after your server receives a consumption request notification.
GET /inApps/v1/refund/lookup/{originalTransactionId} – get a list of all refunded in-app purchases in your app for a customer.
PUT /inApps/v1/subscriptions/extend/{originalTransactionId} – extend the renewal date of a customer’s active subscription using the original transaction identifier.
GET /inApps/v1/lookup/{orderId} – get a customer’s in-app purchases from a receipt using the order ID.

The first 5 requests require originalTransactionid as an input parameter, which allows you to easily use these requests just having originalTransactionId. You can receive this parameter from receipts, signed transactions, signed auto-renewals, and notifications.

The 6th request requires orderId as an input parameter. But what is that parameter used for?

The main idea is to support and interact with your clients. When the customer makes a purchase, he receives an email with the data about the completed purchase. This email includes some details, and the orderId is one of them. This data could be received as well from a purchase history on the App Store.

Thus, when the user contacts your support team and sends a support query, he shares the orderId, and you receive the needed data through the Look Up Order ID endpoint.

It’s worth mentioning that Apple announced 3 more endpoints as well, but as we’ll explore these and other Apple notifications in future articles. For now, let’s just take a quick look and move on.

Here they are:

POST /inApps/v1/notifications/test – Ask App Store Server Notifications to send a test notification to your server.
GET /inApps/v1/notifications/test/{testNotificationToken} – Check the status of the test App Store server notification sent to your server.
GET /inApps/v1/notifications/history – Get a list of notifications that the App Store server attempted to send to your server.

How to get `originalTransactionIds` with the Original StoreKit?

When you call the endpoint verifyReceipt, you can see that in responseBody => responseBody.Receipt.In_app field you can find originalTransactionId for each user’s purchase. The same can be found in responseBody.Latest_receipt_info and responseBody.Pending_renewal_info.

Let’s take a look at what this looks like:

With knowledge of how to get the originalTransactionId from Original StoreKit transactions, let’s explore the whole flow between a customer, the App Store Server, and your server:

Obtain the app receipt on our server
Take the app receipt and call verifyReceipt with it from your server.
Get the decoded receipt in a response.
Get all of the originalTransactionIds from the decoded receipt in precisely the same ways I previously showed.
Call GET /inApps/v1/history/{originalTransactionId} with any one of the gathered originalTransactionIds.
Handle history of transactions for this user in response. These transactions include non-consumables, refunded consumables, non-renewing subscriptions, and auto-renewing subscriptions.

Then, if you want to get the latest signed transaction and signed renewal information for a specific subscription, call GET /inApps/v1/subscriptions/{originalTransactionId} with the corresponding originalTransactionId. As a result, you’ll receive the list of all signed transactions and signed renewals, which corresponds to originalTransactionId.

How to get `originalTransactionIds` with the StoreKit 2?

On the client you can get the originalTransactionIds with the following steps:

Get signed transaction from the devices that are on iOS 15 and later
Get the originalID property from this transaction

In terms of the API side – you’ll receive the originalTransactionIds on the top-level field, as described in the screenshot below. Here you’ll see an example of a signed JWS transaction, which is the data type you receive in signed transactions and in signed renewals from the App Store Server API and App Store Server Notifications.

Then, let’s proceed with the following steps:

Get the transaction on a user’s device
Send the transaction to your server
When you need to perform an operation on a subscription, such as extending the renewal date of a subscription, you can use the originalTransactionId from the signed transaction to call PUT /inApps/v1/subscriptions/extend/{originalTransactionId} endpoint and get back the data that you need. The screenshot:

How to handle `originalTransactionIds` with both versions of StoreKit?

So, we explored the ways to use the new API with the Original StoreKit and StoreKit2.

For the cases when you have to support both versions of StoreKit, the advice is quite simple: just take all the advantages of the App Store API and use them regardless of the version of StoreKit that processed the purchase.

To validate new purchases that were made with the Original StoreKit, the process is simple:

Get the receipt from a customer
Send this receipt to your server
Call verifyReceipt endpoint to receive decoded receipt
Request the status of the purchase with GET /inApps/v1/subscriptions/{originalTransactionId}
Get all signed transactions and renewals It’s essentially the same as the process described before, except that, as you might notice, the history purchase step is skipped.

That’s it for App Store API!

Signing JSON Web Tokens

JSON Web Token is needed for Apple to authenticate you when calling the App Store Server API. This token should be used as an authorization header in each of your server’s requests.
JWT consist of: header, payload, and the signature.

How to construct JSON Web Token for your app?

On the picture below you can see the structure of the JWT, header and payload.

The token itself can be divided into three parts, separated by periods:

The base64 encoded header
The base64 encoded payload
The signature, which is composed of the base64 encoded header + base64 encoded payload, signed using your signing secret.

Header

The header consists of metadata that represents the information on how to sign your data.

Pay attention to the key ID field (kid) – this is your private key ID from the App Store Connect. This key ID should correspond to the key that you use for JWT signature.

Payload

Payload keeps all the data about your application. To learn more about this field please read the official documentation from Apple.

For additional info on how to get your API key please read this article.

Once you receive all the data that you need for the JWT, you need to sign the JWT using the certificate that corresponds to the key ID.

Let’s take a closer look at an example (pseudocode). Please note that the final code will look different depending on the programming language, the chosen tools, and libraries with which you will implement it. But the logic behind remains the same.

import jwtLibrary;

var privateKey = readFile(“/path/to/private_key.key”)
var token = jwtLibrary.sign(payload, privateKey, header)
One your preferred library generates token, you can paste it into cURL that will get subscription statuses by `originalTransactionId`

This is an example:

curl -v -S -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer ${token}' \
    https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/${originalTransactionId}

Don’t forget to:

replace ${token} with the parameter that you’ve generated in example above.
replace ${originalTransactionId} – the Id, with which one you’d like to get the data.

Verifying signed transactions

Let’s discuss how to verify the transactions that you receive from Apple and that were signed by the App Store.

Signed transactions are JSON and are cryptographically signed, so if someone would try to replace it between App Store and your server, you can easily detect it.

These transactions are signed in the JWS format – Json Web Signature (do not confuse this with JWT, which was discussed above). By verifying this object you receive the data from the App Store and can ensure that it was not tampered by anyone.

How can I verify a signed transaction?

Decode base64 header
By alg claim in this base64 header you could understand which algorithm you should use. It will be used for the JWS verification.
Verify certificate chain in the x5c claim Now, once we verified this data, we are on the safe side – no one tampered our data.

You can learn more about JWS here. Also, please read the App Store Server API documentation to learn more about JWSTransaction.

What is the x5c chain?

This is a chain of certificates, the successful verification of which means that the data can be trusted and is signed by Apple.

What is important for the certificate chain is the order. At the beginning you’ll get the root certificate. The root certificate may be followed by additional certificates from the chain. Each following certificate is signed by the previous one. The last certificate in this chain is referred to as the leaf certificate. The first certificate is referred to as the root certificate, and is self-signed.

This certificate should match to the root certificate you obtain from the Apple’s Certificate Authority. If it does not, then the verification chain will be defined as failed.

The last certificate (leaf certificate) is used for JWS signing.

Let’s take a look at the JWS header:

At the beginning of the first line, in the alg field, there is the name of the algorithm that is used for the JWS signing. Next, in the x5c, there is a chain of certificates listed in order.

Let’s look a bit more closely at what x5c certificate chain generation looks like.

At the beginning, we take a root certificate from the Apple’s Certificate Authority. Next, we sign the intermediate certificate. There might be several certificates in this chain, and as we discussed above, each following certificate is signed by previous one. In the example below we consider the one intermediate certificate. Then, this intermediate certificate signs the leaf certificate.

Ok, we’ve described the way this chain generates. Now it’s time to move on to the next chapter – how you can verify it.

This part is simple – you just need to reverse the process.

First, make sure that the leaf certificate is signed by intermediate one. Then, that intermediate certificate should be signed by the root certificate. And the root certificate should match the one one of Apple’s Certificate Authorities. If all steps are successful, the chain is verified and counted as valid.

Let’s discuss a specific method of chain certificate verification.

This is the command fot x5c chain using OpenSSL verification:

openssl verify -trusted AppleRootCA-G3.pem -untrusted AppleWWDRCAG6.pem leaf.pem

The command verify initiates the process of certificate verification.

With -trusted we send the certificate that we trust and that will be used for the verification of the following certificates. This should be root certificate that was obtained from Apple’s Certificate Authority.

With -untrusted we send a certificate that wasn’t verified yet, but that we’d like to verify.

As a first parameter we use the WWDR certificate that received from the Apple’s Certificate Authority and signed by root certificate. This should match to the second certificate from the x5c chain. The last parameter is a leaf certificate that was signed by the previous certificate. In case of successful verification, you’ll receive a success code, and in case of failed verification, you’ll receive an error code. If verification is unsuccessful, the data shouldn’t be used.

More information about the verify command in openssl is here.

The information on openssl is here.

Migration from verifyReceipt to App Store Server API

In this part, we’ll explore the several corner cases.

How to check the subscription status of the particular user

Previously, you had to call verifyReceipt and define the status by checking several fields from the response. Now, with App Store Server API you can call GET /inApps/v1/subscriptions/{originalTransactionId} and receive all the needed data, such as subscription status, renewal info and other pieces of data in one response.

How to receive the latest transactions of the user

The next case described is when you’d like to get the latest transactions of the user to check what he purchased, whether the subscription is auto renewed, or whether there were changes like upgrades, downgrades, or plan switches.

As in the previous example, with the previous API version you had to call verifyReceipt and get the data from the responseBody.Receipt.In_app and responseBody.Latest_receipt_info fields.

With the new App Store Server API you can refer to the GET /inApps/v1/history/{originalTransactionId} endpoint that covers all needed data.
And last but not least – the new appAccountToken field that fetches UUID. We’ve covered this field in our previous article, but just to remind you: this field lets you add the unique ID of the users from your system just to connect your user with their purchases. In the previous API version there was an analogue of this field – applicationUsername – that fetched the string, but the official documentation recommended sending UUID into this field. And once you send the UUID format string into this field, you’ll see this parameter automatically in appAccountToken. The needed value will appear in StoreKit Transaction, App Store API, and App Store Server Notifications.

Conclusion

In this article, we explored the new capabilities of App Store Server API, how to integrate and migrate in-app subscriptions into API, and how to sign JSON Web Tokens and verify signed transactions.

If you still have any questions about the logic behind these updates, please feel free to reach out to us. Qonversion provides a complete cross-platform infrastructure that allows you to make and restore purchases, validate receipts, and provide your app with an accurate subscription status without the need to build your server.

If you'd like to learn more on how to handle StoreKit errors, please follow our guide. Also, recently I've created an article on how to solve SKDomainError 0, feel free to check!

What’s new with in-app purchases: WWDC 2022 overview

Surik Sarkisyan — Thu, 09 Jun 2022 13:31:14 +0000

This Tuesday, during WWDC 2022, Apple released the latest updates for in-app purchases. A lot of great updates are still coming, but today we’ll walk you through the improvements that have already been covered: enhancements to StoreKit 2 and App Store Server API.

So, let’s get started.

New App Transaction API is released

Apple has released the new API to verify the purchases of the app. The new API aims to mitigate (or totally prevent) fraud and add more flexibility to the ways you can monetise the app and grant users access.

The new App Transaction API presents the signed information about the purchase and the device with which the purchase was made.

What you should know about the new App Transaction API

- It’s signed using JWS signature
- It replaces the app details of the app receipt from the original StoreKit API
- StoreKit validates purchases automatically
You still can create your own receipt validation flow, but you’ll need to validate a JWS signature. As Apple highlights, the process is described in the official documentation, so you can easily handle it on your own.
- StoreKit automatically refreshes transactions, but in rare cases users can do this manually.
To provide this functionality, you need to create UI capabilities within the app so users can refresh the app transaction themselves.

Why it would be better to avoid actions from your side: it’s the same story as with the old API restore function. If the user doesn’t log in and you’re trying to refresh his transaction, he will unexpectedly see the screen that prompts him to authenticate. It might be shocking for users who didn’t take any action with the purchases.

How to handle switching business models with the new App Transaction API

The new App Transaction API also allows to change your business model easily without affecting the access of existing customers.

App Transaction API allows you to receive the necessary details about the user so you can change your business model from the paid app to free with in-app purchases or subscription monetisation. Previously, you would receive these details by processing the receipt.

Let’s take a closer look.

Previously, receipts combined all the information in one section.

Like this:

Now, the information is divided into separate components in StoreKit: Transaction History and App Transaction.

The first section includes the entire in-app purchase history: the user’s latest transactions, unfinished transactions, and current entitlements. You can receive all this information on your server as well through the App Store API.

The second component, App Transaction, contains all the data you need to understand whether your user has ever purchased your app previously.

So let’s take a look at the scenario of switching your business model from the paid app to the free app with subscriptions.

Apple has provided a great example of such an app’s timeline. Let’s assume you have two users: the first one has bought the paid app (v2.5) and the second has purchased the subscription after you switched the monetisation model (v8.2).

The change in your app’s business model means that there will also be changes in your access management logic for the app.

For instance, you have several features that were previously available for all who purchased your paid app, and now these features are available as non-consumable purchases. Additionally, you’ve added some new cool features that are available with subscriptions. In this case, you should make sure that all your existing customers (v1.0 to <8.0) have access to the premium content they paid for. But you could still suggest that your user buy the new features that become available after switching the business model. Newcomers (v8.0 and higher v8.2) could purchase everything as it is.

As we mentioned previously, in this case you should distinguish your users: distinguish the ones who bought your paid app from the newcomers.

Let’s take a look at the code that will help us with it:

On the first line of this code, we get the transaction. Then you should check whether it is verified or not.

If the transaction is not verified: you can prompt your user to refresh the app transaction and restore the access, simply give the user access to the app but with minimal functionality, or suggest purchasing a subscription.

If the transaction is verified: you should determine whether this user gets the app.

App Transaction is contained in the field originalAppVersion that displays the information about the app version that corresponds to this transaction. If this version is older than the version that you’ve released your new monetisation model, you need to grant the user the needed access. If the version is newer, you should check which access you should grant to your user.

As you could see, just a few lines of code allow you to receive the verified transaction that contains all the needed details to understand which app version was purchased and when. As I mentioned, it could be possible just by processing of your receipt (that wasn’t too easy).

New Properties in StoreKit

PriceLocale

PriceLocale is now included in product. But what has changed?

Previously, to show your user the price, you could use displayPrice. This field contained currency and price. There was a price field as well the price without the currency or locale.

But what about the cases when you’d like to show your user how much he might save if he purchases the annual subscription instead of the monthly one? (And let’s be honest, this is a quite popular mechanic.) What if you also want to show how much he should pay for the annual subscription monthly?

In this case, you can use priceLocale to help you add information about the price and currency. The previous version of StoreKit had this functionality, but it was quite unstable – you just needed to fill the SKProduct field. But with the new API you can use just priceLocale and show the price wherever you want.

Server Environment Property

Environment – server environment in which the transaction was processed. This is an extremely useful property that can be used for testing and analytics purposes. For instance, you could use it to distinguish production purchases from the sandbox purchases so you don’t consider the testing data in your analytics. Previously, this information was available in the receipt and reflected the entire receipt, which was super inconvenient.

Recent Subscription Start Date

RecentSubscriptionStartDate represents the most recent period of continuous subscription period (subscription with no more than a 60-day gap between any two subscribed periods). In other words, it represents the earliest start date of a subscription in a series of auto-renewable subscription purchases that ignores all lapses of paid service shorter than 60 days.

For instance, if a user purchased the monthly renewable subscription on 8th of June 2021, and then renewed it once in a year (8th of June 2022), and between these periods he didn’t use this app or subscription, this field will contain the first date: 8th of June.

This is important information to determine the customer cohort that continuously uses your app. By knowing the information about this cohort, you can reward your loyal customers with bonuses and discounts. The information about unsubscribers will help you to take actions to win back lapsed customers.

Sentinel values

All the new properties that we’ve described above will be available starting iOS15. It will be available if you build your app with Xcode14 (which is available in beta). And all the properties will be available in Production and Sandbox environments.

What does sentinel values mean?

If you are testing StoreKit with Xcode and refer to new fields/properties, you’ll receive placeholders values. These are fields with a zero values.

This is a great screenshot that’ll help you to remember this information.

Btw, you can solve this problem super easily: just update your testing divide to iOS 16.

One more great screenshot that’ll help you to identify these placeholders.

All these new properties are available with App Store Server API and App Store Sever Notifications as well.

SwiftUI + StoreKit updates

Offer Codes Redeem Modifier in SwiftUI

Offer codes help you to acquire new customers and reward existing ones with discounts, free access, and more. With App Store Connect you can create unique custom codes. You can set a maximum redemption limit and choose whether or not to set an expiration date.

The update is quite simple: offer code redemption sheet has its own view modifier in SwiftUI, so you can easily process redemption flow with just a few lines of code and a binding boolean value. Available with iOS 16. This is the same functionality that was available in StoreKit and UIKit, but now is available in SwiftUI as well.

Updated possibility to request an app review

The second Swift UI Update is the possibility to request an app review. This also was available in UIKit, but from now on available for SwiftUI as well.

The limitations and best practices are the same:

You can show it max 3 times within a 365 days
You can’t ask people to review the same app version several times
You shouldn’t interrupt user flow
You shouldn’t request a necessary review as a result of a user action (completing the game level or achieving the results within the app). The user should have an option to skip this step. The code example:

New API for StoreKit Messages

Apple released quite an interesting mechanism to display the messages that are related to StoreKit. The simplest example: you increased the price for the purchase and you’d like to show the price increase consent alert to your users.

So, let’s take a closer look at this flow.

Your app goes to the foreground. StoreKit checks: are there some changes with the App Store? The App Store returns the message info to StoreKit, and StoreKit asks the listener for permission to display the message or defer it (if you’d like to create your own scenarios for these messages to appear).

But if StoreKit doesn’t include any listener, it will display the message over your app.

Our advice here is to add listener to not interrupt your user’s flow and to not affect user experience, so the user won’t receive automate screen messages during the meditation app experience. You can ensure customers have a great experience by making sure that messages don’t appear at unexpected times.

The realisation is not that difficult. As Apple highlights, there will be official documentation on how to implement this functionality soon.

Application username

This is a field in which you can add the unique ID of the users from your system just to connect your user with their purchases. Those familiar with StoreKit can tell that this field was available earlier: so what’s the update?

Well.. you’re right, this field already exists and its title is applicationUsername. It was receiving any string value, but the official documentation recommended sending UUID into this field.

The update is that StoreKit2 includes the new additional field appAccountToken. The main difference is that this field is geared to receive UUID format only, not any random string value. The great thing is that all UUID strings from the previous StoreKit will be available in the new version of StoreKit as a part of appAccountToken.

With StoreKit2 this value will appear in appAccountToken. It is a kind of backward compatibility (in case you use UUID in applicationUsername). The needed value will appear in StoreKit Transaction, App Store API, and App Store Server Notifications.

Conclusion

In this article, we briefly discussed what was presented for in-app purchases during WWDC22, hope it was useful!

If you'd like to learn more on how to handle StoreKit errors, please follow our guide. Also, recently I've created an article on how to solve SKErrorDomain 0, feel free to check!

The new App Transaction API, Enhancements to StoreKit 2 and other WWDC22 updates for in-app purchases

Yulia Kondrashova — Thu, 09 Jun 2022 11:44:12 +0000

During WWDC 2022, Apple released the latest updates for in-app purchases. In this article, we’ll briefly walk you through the most significant improvements that have already been covered: enhancements to StoreKit 2 and App Store Server API. For more details you can refer to our blog post, where you can find detailed description of these updates with advices for its implementation.

1. App transaction API is the new API to verify app purchases

The app transaction represents the signed information about the purchase of your app for the device it’s running on. It is signed using JWS and it replaces the app detail portion of the app receipt from the original StoreKit API. With App transaction you can change your business model from the paid app to a free app with in-app purchases, check who out of your customers pre-order the app, and check purchase dates.

2. New properties in the StoreKit models

The first one is price locale, which now is included in StoreKit products. It allows you to format numbers derived from decimal prices. For example, your customers may see how much a yearly subscription would cost them per month or how much they would save by purchasing your yearly service over your monthly service.
The Server Environment property allows you to tell which server environment a transaction or renewal occurred in, which could be Xcode, sandbox or production. It filters out unnecessary information to prevent it from being sent up to your server
Another one is Recent Subscription Start Date property. You can use this to make informed decisions about your customers based on their subscription patterns. It represent the most recent period of continuous subscription (no more than 60-days gap between any two subscribed periods). It can help you to determine a pattern of loyalty between you and your customer.
These properties return sentinel values — placeholder values that signal that these are not the real values you should work with — in older operating system. To overcome this limitation you need to update your test device to a new operating system. You can take advantage of these new properties on devices as far back as last year’s operating system and it’s available in Xcode 14 and above

3. SwiftUI API for redeeming subscription offer codes and asking your customers to review your app

With App Store connect, you can create uniquely named custom codes that can help you to acquire retain and win back subscribers by providing subscriptions at a discount or free for a limited time. When a customer redeems an offer code for your app, the resulting transaction is sent to the transaction listener. Be sure to set up a transaction listener as soon as your app launches to receive new and updated transactions while your app is running. This offer code view modifier is available starting on iOS 16.

Moreover, you can now ask for a review from your customer through the special sheet. You can decide the right time to request the review for your app, but you need to be aware that the prompt will only be displayed to customers a maximum of three times within a 365-day period and you shouldn’t ask customers to review the same version of your app multiple times.

4. StoreKit Messages API used to display App Store messages to your customer

StoreKit Messages represents a sheet that appears over your app to display an important information to the user. Messages are vended by the App Store and each message has a reason which is included in the Message metadata. StoreKit messages are retrieved when your app goes to foreground. For example, if you’ve increased the price of the subscription and it requires user consent, the App Store will inform affected subscribers through e-mail, push notifications, and an in-app price consent sheet. This will appear when a user opens your app, if they haven’t already responded to your price increase.

How does it work?
You app goes to the foreground. StoreKit checks whether there are some changes with the App Store. The App Store returns the message info to StoreKit, and StoreKit asks the listener for permission to display the message or defer it (if you’d like to create your own scenarios for this messages to appear). But if StoreKit doesn’t include any listener, StoreKit will display the message over your app.

Once you’ve implemented in-app purchases, don’t forget to use the analytics tools to measure how much revenue each of your products brings. Qonversion provides a complete infrastructure for in-app purchases and allows you to create and restore purchases, validate receipts, and provide your app with an accurate subscription status without a need to build your own server. If you’d like to learn more on how to set up and analyze in-app purchases and subscriptions, please read our documentation or message us here.

The new subscription model and Google Play Billing Library 5.0 overview

Kamo Spertsyan — Thu, 26 May 2022 07:43:25 +0000

During the annual I/O conference, Google introduced its new major version of the Google Play Billing Library. Besides classic method deprecations and removals, there was also vast information about the new architecture of subscriptions, which aims to simplify the way you can create, manage and sell in-app purchases. In this article, I will explore the updates to Google Play Billing Library 5.0 and dig deeper into the most interesting ones.

The new subscription model

Google Play Billing System is the main tool that helps you to monetize your application with subscriptions. If you’re not familiar with this service yet, please read this article. With the latest version of its library, Google has changed the structure of how subscription products are defined, and this has led to changes in how they are sold in-app and managed on your backend.

With Google Play Billing Library 5.0. Google has introduced new subscription architecture, which adds such entities as base plans and offers. Let’s take a look.

Let’s say you have a premium subscription in your app and offer your clients weekly, monthly and annual subscriptions. Before these updates, you would have needed to create three different subscriptions - one per period. Then imagine that you wanted to offer a free trial to users who’ve left your app to persuade them to return. So, then you would also need to create one more annual subscription with a free trial.

These are just two of the most common cases, causing the creation of lots of subscriptions with the previous subscription model - there could be many more examples.

But from now on, you can handle all of these scenarios with just a single subscription. Google has divided a subscription model into three entities - subscription itself, base plans, and offers.

The new subscription entity includes:

an identifier
title
description
taxes information

The rest of the information is set up via base plans and offers.

A base plan contains:

its identifier
renewal type (auto-renewing or prepaid)
duration
grace period
prices and availability for different regions
and some less important settings

You can find the whole list of details in the official documentation.

An offer contains:

its identifier
eligibility criteria - an option determining which users can access this offer (first-time subscribers, those who upgrade from another subscription, or developer determined),
phases including free trials and single or recurring payments (phases usage is shown in the screenshot below)
and a price discount - either fixed amount or percentage or absolute discount depending on the base plan price

Each subscription can contain one or more base plans, which in turn may contain several offers (see the scheme above). So, for the example above you can create one premium subscription with three base plans - one per period, and an offer with a free trial for the annual base plan.

Purchasing new subscriptions

Speaking of code, in Google Play Billing Library 5.0, the SkuDetails class is deprecated as well as every other entity or method containing Sku in its name. Now you should consider using ProductDetails for that purpose. Product details contain information about a subscription, including its base plans and offers.

Before, you requested subscription details like those below:

val params = SkuDetailsParams.newBuilder()
    .setType(BillingClient.SkuType.SUBS)
    .setSkusList(listOf("premium"))
    .build()

billingClient.querySkuDetailsAsync(params) { 
        billingResult, skuDetailsList -> // Process the result
}

Now, you should do the following:

val productList = listOf(
    QueryProductDetailsParams.Product.newBuilder()
        .setProductType(BillingClient.SkuType.SUBS)
        .setProductId("premium")
        .build()
)

val params = QueryProductDetailsParams.newBuilder()
    .setProductList(productList)
    .build()

billingClient.queryProductDetailsAsync(params) {
    billingResult, productDetailsList -> // Process the result
}

And, for launching the purchase flow, you used the following constructions:

val billingFlowParams = BillingFlowParams.newBuilder()
    .setSkuDetails(skuDetails)
    .build()

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

Whereas now they should look like those that follow:

// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription.
val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return

val productDetailsParamsList = listOf(
    BillingFlowParams.ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setOfferToken(offerToken)
        .build()
)

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(productDetailsParamsList)

val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

You can also look at the migration examples in the Google official migration steps. Note, that there are a few typos in their examples which are fixed here.

Let’s overview the changes.

As I mentioned, you should now use ProductDetails for querying subscription details and purchasing flow. In addition, you should provide an offerToken to billing flow params as each ProductDetails may contain several offers. Note, that the offer details array (productDetails.subscriptionOfferDetails) always contains base plan details (if any base plan exists), so even if your subscription contains only a base plan without offers it will still have offerToken for purchase.

You could notice that the new purchase flow accepts multiple ProductDetails instead of one SkuDetails like in the previous version. But if you provide more than one ProductDetails, the flow will end up with an error. The official integration guide gives the wrong example of using the setProductDetails and setOfferToken methods right on the BillingFlowParams.Builder class, but there is only the setProductDetailsParamsList method available for those purposes. It seems as if Google decided to switch from single product details to multiple quite recently with a vision for the future when Billing will support multiple different subscription purchases at once.

The rest flow - namely processing the purchase - remains the same as in the Google Play Billing Library 4.0.

Subscriptions backward compatibility

Well, everything sounds good so far, but what if you don’t want to migrate right now? Google has taken care of it.

Despite Google Play Console already working only with the new subscription model, all the old subscriptions are converted to the new format automatically, saving their backward compatibility. This means that you see your subscriptions in the new format on Google Console but can still work with them as you did before on your app.

You will also notice that all the old subscriptions are made read-only after migration. Google warns you that editing will disable InAppProducts API support for that subscription.

You might be using this API in your backend for fetching some product details, so be careful - after making the subscription editable you will receive errors (as shown below) from that API if you try to fetch converted subscription info. The same will happen to all new subscriptions created after May, 11th.

HTTP code - 422
Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}

So, if you use InAppProducts API, consider upgrading it before creating new subscriptions or editing old ones.

While surfing through the new subscriptions UI in Google Play Console, you will find “Backwards compatible” tags near base plans and offers of subscriptions. This means that if you purchase those subscriptions using deprecated SkuDetails (as you do in Google Play Billing Library 4.0), you will buy exactly those compatible base plans/offers. If there is only a compatible base plan, without any compatible offer, then that base plan will be purchased. If there are both compatible base plan and offer available then if the offer is eligible to the current user, it will be purchased, else - base plan. You can choose another base plan/offer as backward compatible if you would like.

Note - this Backwards compatibility relates to Google Play Billing Library but not to InAppProducts API. As mentioned, if you begin using new features, for example, multiple base plans or offers for one subscription or just convert it from read-only to editable, that subscription can still be Backwards compatible for an app, but not for API.

The other updates

There were several minor updates in the Google Play Billing Library 5.0 which are worth briefly mentioning.

The method queryPurchases deprecated in Google Play Billing Library 4.0 was removed - no more synchronized requests, only queryPurchasesAsync.
launchPriceChangeFlow has been deprecated - the new recommended price change flow requires clients' confirmation via the Google Play subscriptions page, so you should use deep links for navigation there instead of calling the BillingClient method.
Added the setIsOfferPersonalized method to indicate a personalized price for EU clients following the Consumer Rights Directive. This option adds a line to the bottom of the Google Billing purchase screen noting that a price is personalized.

The new subscriptions model and Qonversion

While we are working on Google Play Billing Library 5.0 support, you can still use Qonversion SDK for your in-app purchases. We are now using Google Play Billing Library 4.0, which means we can manage only subscriptions with backward-compatible base plans and offers. You are still able to edit properties that were available in the previous subscriptions model like a price, grace period, trial duration, and so on as well as create new subscriptions. Just be sure that after you still have at least one backward compatible base plan and, if needed, a backward-compatible offer. And, we still require a whole subscription identifier for configuring products on our Product Center, not base plan or offer identifiers.

If you have any questions, please let us know. We will be happy to assist you.

DEV Community: Qonversion

What does restore purchase mean?

What does restore purchase mean?

Cases for restoring purchase

What products could be restored?

How to configure restore purchases on iOS?

How to configure restore purchases on Android?

Conclusion

How to Create Google Play Promo Codes for Android Apps

Prerequisites

Types of Google Play promo codes

How to create Google Play promo codes for your app

User redemption flow

In-app redemption flow

Google Play promo codes redemption flow

Accelerate your app promotion strategy with Google Play promo codes

How to send in-app subscription events to Firebase, Google Analytics, and Google Ads

Google Analytics for Firebase SDK

Firebase Integration: How to send subscription events to Firebase and Google Analytics

How to link Firebase Google Analytics to Google Ads

What Google App Campaigns are

How to optimize Google Ad based on Firebase conversion events data

Google App Campaigns optimization by conversion event

Google App Campaigns optimization by the audience

Conclusion

SKErrorDomain Code=0. What is it and how to fix it?

SKErrorDomain Code=0 in the sandbox environment

SKErrorDomain Code=0 during the review process

SKErrorDomain Code=0 in production environment

Submit a bug report about SKErrorDomain Code=0

Apple Fiscal Calendar 2023

How to Configure Subscriptions on the Web with Stripe and Grant Users Access on iOS and Android

Connecting Stripe to Qonversion

Setup Stripe Product and Permission

Sending Stripe Purchase Data to Qonversion

1. API methods

1.1 Create User

1.2 Identify the User

1.3 Send Purchases

1.4 Get Entitlements

2. Web SDK

2.1 Launch Qonversion Web SDK

2.2 Identify the user with Qonversion Web SDK

2.3 Send purchase

2.4 Get entitlements

Get Subscription Status and Unlock Premium Access on Mobile Apps

Conclusion

5 ways to increase app valuation and score a beautiful EXIT webinar

What’s new in StoreKit testing (WWDC22 updates)

StoreKit updates in Xcode 14

Advanced subscription cases

Refund requests

Offer codes

Price increases

Billing retry and grace period

Sandbox updates

Sandbox Apple ID creation

App Store Connect API

Billing failure simulation

Conclusion

WWDC22 overview: how to integrate and migrate in-app purchases to App Store Server API

Using the App Store Server API

Which endpoints are available with the new API?

How to get originalTransactionIds with the Original StoreKit?

How to get originalTransactionIds with the StoreKit 2?

How to handle originalTransactionIds with both versions of StoreKit?

Signing JSON Web Tokens

How to construct JSON Web Token for your app?

Header

Payload

Verifying signed transactions

Migration from verifyReceipt to App Store Server API

How to check the subscription status of the particular user

How to receive the latest transactions of the user

Conclusion

What’s new with in-app purchases: WWDC 2022 overview

New App Transaction API is released

How to handle switching business models with the new App Transaction API

New Properties in StoreKit

PriceLocale

How to get `originalTransactionIds` with the Original StoreKit?

How to get `originalTransactionIds` with the StoreKit 2?

How to handle `originalTransactionIds` with both versions of StoreKit?