DEV Community: Vitaly Davydov

What’s new about StoreKit 2 server API

Vitaly Davydov — Mon, 12 Jul 2021 13:07:18 +0000

Apple introduced a new version of StoreKit 2 during WWDC 2021 that took place recently. This is a framework responsible for making purchases in iOS. A share of apps with in-app purchase and subscription features grows steadily, and Apple significantly simplified integration of in-app purchases into the app by releasing StoreKit 2. Today, we will consider working with StoreKit 2 on the part of the server, in other words, with the help of App Store Server API.

Request authentication

In the current API version, you need Shared Secret to send a request. This is a secret fixed string that you can get in App Store Connect. A new version of API uses JSON Web Token (JWT) standard for request authentication.

Key generation

First of all, create a private key that will be used to authorize the requests. Open App Store Connect and go to the Users and Access section, then to Keys tab. Select In-App Purchase key type. Download a new key. You will also need its ID – you can copy it on the same page as Issue ID which can be found in the App Store Connect API tab.
Creation of a private key for working with App Store Server API

Creating a token

The next step is to create a token that will be used to authorize the requests. This process is described in detail in documentation, so there’s no reason to pay too much attention to it. Here’s an example of a ready-made implementation for Python. It’s worth noting that it makes no sense to generate a new token for every new request. When creating a token, you set its lifetime at up to 60 minutes and use the same token during this period.

import time, uuid
from authlib.jose import jwt

BUNDLE_ID = 'com.adapty.sample_app'
ISSUER_ID = '4336a124-f214-4d40-883b-6db275b5e4aa'
KEY_ID = 'J65UYBDA74'
PRIVATE_KEY = '''
-----BEGIN PRIVATE KEY-----
MIGTAgMGByqGSMBHkAQQgR/fR+3Lkg4...
-----END PRIVATE KEY-----
'''

issue_time = round(time.time())
expiration_time = issue_time + 60 * 60 # 1 hour expiration


header = {
 'alg': 'ES256',
 'kid': KEY_ID,
 'typ': 'JWT'
}

payload = {
 'iss': ISSUER_ID,
 'iat': issue_time,
 'exp': expiration_time,
 'aud': 'appstoreconnect-v1',
 'nonce': str(uuid.uuid4()),
 'bid': BUNDLE_ID
}

token_encoded = jwt.encode(header, payload, PRIVATE_KEY)
token_decoded = token_encoded.decode()

authorization_header = {
 'Authorization': f'Bearer {token_decoded}'
}

Signed transactions

In a new version of API, all transactions returned in JSON Web Signature (JWS) standard. This is a string consisting of three parts divided by dots.

Base64 header.
Base64 transaction payload.
Transaction signature.

Base64(header) + "." + Base64(payload) + "." + sign(Base64(header) + "." + Base64(payload))

Transaction header

A header is needed to make sure the transaction is authentic. Alg key contains an encryption algorithm, x5c key contains a certificate chain.

{
    "kid": "AMP/DEV",
    "alg": "ES256",
    "x5c": [
        "MIIEO...",
        "MIIDK..."
    ]
}

Transaction payload

{
  "transactionId": "1000000831360853",
  "originalTransactionId": "1000000806937552",
  "webOrderLineItemId": "1000000063561721",
  "bundleId": "com.adapty.sample_app",
  "productId": "basic_subscription_1_month",
  "subscriptionGroupIdentifier": "27636320",
  "purchaseDate": 1624446341000,
  "originalPurchaseDate": 1619686337000,
  "expiresDate": 1624446641000,
  "quantity": 1,
  "type": "Auto-Renewable Subscription",
  "appAccountToken": "fd12746f-2d3a-46c8-bff8-55b75ed06aca",
  "inAppOwnershipType": "PURCHASED",
  "signedDate": 1624446484882,
  "offerType": 2,
  "offerIdentifier": "basic_subscription_1_month.pay_as_you_go.3_months"
}

Apple changed and extended the transaction format. From my point of view, now, it’s more convenient to work with them. You can learn details about a new format in documentation. Below, I will describe the most important changes.

Apple added appAccountToken field, which contains your system’s user ID. This ID must be in UUID format, it is set in the mobile app when a purchase is being initialized. If it is set, it will be returned in all transactions in this chain (renewal, billing issues, etc.), and you will easily understand which user made a purchase.
Apple also added offerType and offerIdentifier fields that contain the information about a used offer (if any). Here are values for offerType field:
1 — intro offer (available only for the users without active or expired subscriptions);
2 — promo offer (available only for current and expired subscriptions);
3 — offer code. If a promo offer or offer code was used, offerIdentifier key will contain the ID of the used offer. In the past, it was impossible to track the use of the offer on the server-side, this worsened the analytics. Now, you can use offer codes for analytics.
Apple added inAppOwnershipType field, which helps to understand whether a user bought a product or accessed it thanks to a family subscription. Possible values:
PURCHASED
FAMILY_SHARED
Another new field – type – includes transaction type. Possible values:
Auto-Renewable Subscription
Non-Consumable
Consumable
Non-Renewing Subscription
Cancellation_date and cancellation_reason fields have new names now: revocationDate and revocationReason. As a reminder, they contain a date and a reason for subscription revocation as a result of a refund, so the new name looks more logical.
All keys return in camelCase format (just like in all App Store Server API requests).
All dates are displayed in Unix timestamp format in milliseconds.

User subscription status

To check the current user’s subscription status, send a GET request to https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/{originalTransactionId}, where {originalTransactionId} is the ID of any transaction chain of the user. In return, you will get transactions with statuses for every group of subscriptions.

{
  "environment": "Sandbox",
  "bundleId": "com.adapty.sample_app",
  "data": [
    {
      "subscriptionGroupIdentifier": "39636320",
      "lastTransactions": [
        {
          "originalTransactionId": "1000000819078552",
          "status": 2,
          "signedTransactionInfo": "eyJraWQiOi...",
          "signedRenewalInfo": "eyJraWQiOi..."
        }
      ]
    }
  ]
}

The status key displays the current subscription status, based on it, you can decide if you should provide a user with access to the paid features of the app. Possible values:

1 — subscription is active, a user must be able to access paid features.
2 — subscription has expired, a user must not be able to access paid functions.

3 — the subscription’s status is Billing Retry, meaning that a user didn’t cancel it, but experiences problems with paying. Apple will try to charge the card for 60 days. A user must not be able to access paid functions.

4 — the subscription’s status is Grace Period, meaning that a user didn’t cancel it, but experiences payment issues. Grace Period is on in App Store Connect, so a user must be able to access paid features.

5 — subscription was canceled as a result of a refund, a user must not be able to access paid functions.
SignedTransactionInfo key contains the information about the last transaction in the chain. You can find the details about its format above.

Information about subscription renewal

SignedRenewalInfo key contains the information about subscription renewal.

{
  "expirationIntent": 1,
  "originalTransactionId": "1000000819078552",
  "autoRenewProductId": "basic_subscription_1_month",
  "productId": "basic_subscription_1_month",
  "autoRenewStatus": 0,
  "isInBillingRetryPeriod": false,
  "signedDate": 1624520884048
}

This information allows us to understand what will happen to the subscription during the next pay period. For example, if you see that a user canceled auto-renewal, you can offer them to switch to another subscription plan or provide them a promo offer. It’s convenient to track this kind of events with the help of server notifications, which I’ll tell you about soon.

User’s transaction history

To get the user’s transaction history, send GET request to https://api.storekit.itunes.apple.com/inApps/v1/history/{originalTransactionId}, where {originalTransactionId} is the ID of any chain of transactions of the user. In return, you will get an array of transactions sorted by time.

{
  "revision": "1625872984000_1000000212854038",
  "bundleId": "com.adapty.sample_app",
  "environment": "Sandbox",
  "hasMore": true,
  "signedTransactions": [
  "eyJraWQiOiJ...",
      "joiRVMyNeyX...",
      "5MnkvOTlOZl...",
      ...
      ]
}

A request can contain no more than 20 transactions. If a user has more, the hasMore flag’s value will be true. If you need the next transaction page, send the request again with the revision GET parameter containing. It will contain the value from the same key.

Server transaction notifications

Server notifications help to get information about new purchases, renewals, billing issues, etc. This helps to build more accurate analytics, as well as simplifies managing the subscriber’s status.

The existing server notifications (V1) can solve most of the problems, but sometimes they are inconvenient. Mostly, it’s about the situation when you get several notifications for just one action of a user. For example, now, when a user upgrades a subscription, Apple sends two notifications: DID_CHANGE_RENEWAL_STATUS and INTERACTIVE_RENEWAL. To process this case currently, you need to save the status somehow and check if the second notification was sent. In a new version of server notifications (V2), there’s only one notification for one action of a user. This is much more convenient.

The second version of server notifications features new events - OFFER_REDEEMED, EXPIRED, and GRACE_PERIOD_EXPIRED. They make managing subscriber status much easier. SUBSCRIBED and PRICE_INCREASE events are improved events from the first version.

Notification types

Notifications now have types, thus, one notification for any action of a user is enough to understand what happened.

Notification types

{
  "notificationType": "SUBSCRIBED",
  "subtype": "INITIAL_BUY",
  "version": 2,
  "data": {
    "environment": "Sandbox",
    "bundleId": "com.adapty.sample_app",
    "appAppleId": 739104078,
    "bundleVersion": 1,
    "signedTransactionInfo": "eyJraWQiOi...",
    "signedRenewalInfo": "eyJraWQiOi..."
  }
}

Server notifications contain information about a transaction and a renewal in JWS format which I described earlier.

Working with Sandbox environment

You need to use the URL of the Sandbox environment to test purchases: https://api.storekit-sandbox.itunes.apple.com.

A new version of server notifications isn’t available for testing yet. Once it’s available, it will be possible to specify different URLs for Production and Sandbox notifications. You can choose V2 for Sandbox, and V1 for Production for testing.

Also, App Store Connect now allows to:
*Clear purchase history for the Sandbox user, meaning that you don’t have to create a new account to do that anymore.

Change the store country for the Sandbox user.
Change Sandbox subscription renewal period, for example, you can make a monthly purchase that lasts 1 hour instead of 5 minutes.

Conclusion

Apple significantly improved working with in-app purchases and subscriptions on the server-side. From my point of view, here’re the most useful new features:

Full-fledged promo offer and offer code support;
Simpler and more informative server notifications;
An opportunity to learn about the current subscription’s status with a simple API call;
Clearing purchase history of the user’s Sandbox.

Switching to a new API won’t be hard, it’s enough to get originalTransactionId for every receipt. It’s likely it’s already contained in your base.

Development, analytics, attribution. Which services to use in 2021?

Vitaly Davydov — Fri, 09 Apr 2021 15:44:02 +0000

Apps don’t exist in a vacuum. While there’s certainly not a great space for things a good team can’t do, some 3rd-party services could be of real help to your apps’ growth.

In this article, we will dive into valuable services for freemium iOS apps that might help any development or marketing team.

‍Let's draw a plan first.

An overwhelming majority of mobile apps are monetized through traffic, that is, the purchase of advertisements. I assess that most apps don’t have a website or a web version, and even platform presence is usually limited to iOS. Suppose a company doesn’t have access to a reliable organic resource (SEO, blog, etc.). In that case, the App Store Optimization (ASO) and advertisements are the only things that this company can do for a controlled promotion.

We can divide services that are useful for development and promotion into six categories:

Traffic attribution. This will help answer where (from which ads) users come from and build the unit economy.
Product analytics. This will help to collect user events and profiles and calculate any metric, including sales funnels.
Sending push notifications. Optional: email.
ASO-tools. Analytics and optimization for organic growth in the App Store.
Crashlytics. Application crash analytics.

Let’s figure out what services are on the market, how much they cost, and how you should implement them. I will indicate only those services that I used myself or my friends did.

Attribution

‍

Why you need it

Attribution binds users with traffic channels, determining which traffic channel—an advertising campaign or even a specific banner—brought a particular user.

Attribution has traditionally been the main component in purchasing paid traffic. Since most of the ads for apps are purchased from Facebook, you need a service to attribute this traffic. Unfortunately, there are few such services, and they are quite expensive. The reason is simple: it’s challenging to become a Facebook Marketing Partner.

Whom to choose?

Several prominent players in the market know-how to attribute Facebook: AppsFlyer (responsible for 70% of the market), Adjust, Tenjin, and Branch.

How much?

Almost every player hides the price tags, but empirically you can find out that everyone is pretty equal to AppsFlyer, and the average price will be 6 cents for the attribution of paid traffic. That is, if the service for a specific user gives you non-organic attribution, then you have to pay for it. Usually, organic traffic doesn't contribute to the cost.

In general, this price is unholy concerning the provided utility; therefore, the service’s cost will grow more slowly with the growth of volumes. Moreover, you will be obliged to pay even if the traffic is not converted and does not pay off, so you pay for the installation itself. This cost can quickly increase your cost per install (CPI) by 10%.

The conclusion is simple: bargain if you want to save money.

It's easy to calculate approximately how much AppsFlyer will cost. Let's say you buy $10,000 worth of traffic per month at an installation cost of $2 with 5,000 attributions -> 5,000 * 0.06 = $300.

Note that if you don't receive attribution data when access to IDFA is disabled, you won't pay for attribution. I officially asked AppsFlyer about this, here's the answer:

“Yes, if the client has LAT enabled, we don’t receive IDFA/GAID, and the installation can convert to organic. But we will also try to do attribution through probabilistic modeling. And if that doesn’t work out, then it will go into organic production”.

Product analytics

Why you need it

Product analytics is the ability to study what your users are doing in an application analytically. Simply put, it answers the question "What features are more users using?". Answers may vary, including cohort analysis and segmentation.

Any analytics system consists of two parts:

Data storage. This is where raw events about user actions are stored.
BI or data visualization, building reports on top of raw data. This is what the user is working with.

Whom to choose

Unlike attribution, where there is no alternative to 3rd-party services, you can use open source solutions and create in-house solutions in product analytics.

Stack is traditionally created on a relational columnar database, for example, Clickhouse + Tableau for BI. Additionally, I recommend using Cube.js to collect data. As words for googling, I throw in: AWS Lambda, Redash, Google Big Query, Serverless.

In general, your own solution is an excellent way to go, but it is challenging to make it work, even with all its seeming simplicity. You will always want something extra. It will take development and support time while achieving good performance is also not a trivial task. The worst thing is that you can miss the error in the data and draw the wrong conclusions. In short, if you can assemble a data team, then this should be your option.

Amplitude and Mixpanel are prominent players in 3rd-party solutions. App Metrica and Firebase Analytics (Google Analytics for mobile devices) can be added here.

Usually, multiple analysts are selected to compare their accuracy, often taking free and paid ones.

The development and implementation of any analytics system starts with drawing up a map/list of events you want to track. After two weeks of hard work on the event table, you get something like this:

Which is later added to the application and tested.

How much?

It’s difficult to calculate the cost of your implementation. For the assessment, take the work of three people over a period of 4-6 months.

Let's estimate for services:

App Metrica and Firebase Analytics are free.
Amplitude: Free for up to 10M events per month.
Mixpanel: Free for up to 100K unique users per month.

I know many companies do the following: first, they track everything, and when it gets expensive, they remove unnecessary events, leaving a bare minimum.

All analytics services make money on large companies, which is why they give such large free limits.

In my experience, usually, a paid plan starts at $2,000 per month.

Sending push notifications

Why do you need it

There are two purposes for sending push notifications:

Product. For example, you received a notification that your taxi is waiting.
Marketing. When you are trying to sell something to a user.

Moreover, push notifications can be divided by:

Triggered and caused manually
Targeted and not targeted.

Most of the product pushes are triggered, that is, when a trigger occurs due to user actions, then all events in product analytics are taken from the table above in product analytics.

Marketing push notifications can be triggered—for example, a user has unsubscribed, and we immediately give him a discount. They can also be manual: for example, we will send a notification to all our London users about a discount on products in an offline store.

Whom to choose

Just like analytics, there is an option to make your own solution or use ready-to-go services. Both work through APNS (Apple Push Notifications Service).

Like many things in the Apple ecosystem for developers, working directly with APNS isn’t exactly easy and convenient. There are both technical tasks (push queue, sending speed, etc.) and purely product ones: you will have to match the user and his push token yourself.

The usual scheme is to use a provider to send push notifications and access them from your server through a convenient SDK/API. Examples of such services are AWS SNS and Firebase Cloud Messaging. FCM has a common Android system and shipping and delivery analytics, which is a nice addition.

The best system for sending push notifications allows you to build mailing campaigns, where you specify push chains, triggers, send delays, audiences, etc. These are complex and not cheap systems such as Intercom, Push Woosh, OneSignal. They support not only push notifications, but also email, in-app messages, and much more.

How much?

Firebase Cloud Messaging is free.
AWS SNS: 1M free, then $0.5 per million.
OneSignal: as many messages as you want, but 10K subscribers.

The price is growing quickly and strangely, so if you have 100K or more MAU, I’d be preparing for a price tag of $1,000 per month.

ASO

‍

Why do you need it

ASO (App Store Optimization) is an analog of SEO, only for applications. That is when a user searches for something in a search in the App Store or Google Play. With ASO you can:

Track keyword rankings
Track competitors
Upgrade ranking, including localization

And other related tasks.

There are Apple guidelines for better ranking. Overall, ASO and SEO are similar things that need to be worked on all the time. You can find other guides and recommendations, they are publicly available.

Whom to choose

I’m not an expert in ASO, but I heard good reviews about AppFollow and AsoDesk. Alternatively, you can write a self-written solution: there are many libraries on GitHub that will help with this, for example, here.

How much?

Service price tags don’t vary much, I would aim for a few hundred dollars a month for a small application.

Application crash analytics

Why do you need it

Crash analytics helps you understand the reasons behind your app crashing—that is, it stopped working and the user was thrown out of it. In fact, this is the basic functionality that almost all developers use.

Whom to choose

AppMetrica

Firebase is the de facto industry standard.

Choose whatever suits you.

How much?

Free.

Where Adapty fits in?

There is a sixth component your app would need: handling of payments and subscriptions. These things are tough to implement, especially when you want to export your data to 3rd-party attribution and analytics services.

Creating such systems on your own will take up to 6 months of work for a team of four. We don't think you need to do any of that, as Adapty will do it for you instead. Try Adapty for free with a 14-days trial.w

How to create and configure in-app subscriptions on Android

Vitaly Davydov — Thu, 28 Jan 2021 09:53:01 +0000

The subscription industry is booming. Since 2016, Google has been incentivizing subscriptions, introducing subscription-only measures like halving Google Play sales cut when the user is subscribed for a year or longer. Today, this bet seems victorious: according to a recent study by AppAnnie, apps with subscriptions account for 96% of consumer spend in top non-gaming apps.

In this article, we are going the full distance in introducing subscriptions for an Android app. Along the way, we will examine every tool Google has to offer while also coming up with caveats that official guidelines left uncovered. Let’s assume that you have already paid for your Google Play merchant account and have an app, or draft for an app, available in your Google Play Console.

Creating a subscription from scratch

To create a subscription, you will need to start with your app page in Play Console, redirecting you to "All Apps". Select your app, go to section Monetize –> Subscriptions, and click on Create subscription button on the right.
Last step: choose "Create subscription" on the right

Google will immediately ask you to provide a Product ID, which it uses to uniquely identify this particular subscription product. Every product available for purchase on Android has its Product ID. In this particular case, it will be an ID for your subscription. These IDs are not public (unlike Subscription Title), so don’t spend too much time here: we suggest you use an ID that’s easy to identify by you, and contains details about the product. However, remember that you can’t modify this and you can’t reuse a product ID inside the same app.

Product ID can contain numbers, lowercase letters, underscores, and periods. You can’t name a Product ID starting with ‘android.test’, and you can’t change as well as reuse a Product ID once the product has been created.

All the rest is to be filled in your local language. If you want to use different localizations, click on ‘Manage translations’ and fill in data for each locale. These are the following fields, all of which will be shown on the system dialog screen at the moment of purchase:

Title. Short name for an item, better to use titles up to 25 characters
Description. Item description, up to 80 characters
Default price and billing period. The latter may be weekly, every 4 weeks, monthly (yes, alongside 4 weeks option), every three months, half a year, or annually. Note that once you activated your subscription, you will not be able to change its billing period.

This policy by Google seems quite reasonable. It would be unfair if a user one day receives an email “Dear monthly subscriber, we’ve decided you will be charged annually starting next month, please be ready or cancel''.

Simultaneously, if developers want to update their pricing, existing subscribers will be notified of the price change by email and through a notification on Google Play 7 days after the price change occurs. Subscribers will then have 30 days to agree to the price change; otherwise, their subscription will be cancelled on their next renewal date.

Benefits (optional). You may provide up to four benefits, which will describe the subscription features, up to 40 characters each.
Benefits should highlight the features to give users a better idea of what your subscription offers, like “Full catalogue of TV shows and movies.”
You can’t mention free trial or promotional price since not all users are eligible for it.

We didn’t manage to find any mention by Google where the user might see these benefits, so we did our own investigation. Benefits are shown as the last resort when a user tries to cancel a subscription, on the very last system transactional page before the cancellation. Interestingly, neither benefits nor even app description is displayed when a user tries to purchase your plan – there is a title only.
Only place your users will see these benefits

Optional features of your subscription

Google offers a range of instruments to enhance and tailor your marketing. You may choose not to use them, but we advise you to, as most of them are necessary for a pleasant user experience.

Free trial

Free trial lets your users try out a subscription before buying it. Free trials run for a period of time that you set, and then they automatically convert to a full subscription using the subscription’s time period and price. By default, users can only receive one free trial across all available subscriptions on your app, but this can be changed in the Console settings.
Free trial settings are available under “Manage subscriptions settings” button

Requirements

You must let users know:

what content or services they will be able to access with a free trial,
how and when a free trial will convert to a paid subscription,
how much the paid subscription will cost,
and how to cancel if they do not want to convert to a paid subscription.

Examples of common violations, available on Play Console Help section)

You can create one free trial per subscription product. Free trials are always $0. Trial periods must be 3 days or longer; you can change the trial period at any time, but only new subscribers will use the updated trial period. Users can only get a free trial if they haven’t previously purchased the subscription it applies to. For more information and examples, see Free Trials & Introductory Offers in the Developer Policy Center.

How users start a free trial

To start a free trial, a user must complete the standard process for purchasing a subscription on Google Play. They aren’t charged at first, and they’re notified by email that the subscription includes a free trial period. Google Play records a transaction of $0.00, and the subscription is marked as purchased for the trial period or until it is cancelled.

Now comes the tricky part: Google claims that the user is charged the day after the trial period ends, which is not entirely correct. Based on our experience, the user receives a transaction notification from his bank **the day before the trial ends. **Basically, Google allows the user to cancel and get an automatic refund, with the subscription also being cancelled the next day. If the user manages to cancel during the last day of the trial, the money will return without any additional user actions.

We don’t really know whether Google charges users in advance or just pre-authorizes the necessary sum. Either way, this is usually confusing for your trial users as banks often don’t differentiate between these operations, resulting in angry letters to your customer support to get the refunds.

When the trial ends, a user’s payment method is charged for the specified subscription amount (price can be either full, discounted, or an introductory offer), which recurs using the subscription’s set time period. The payment status may display as pending for up to 24 hours, even if no grace period is set.

Introductory price

With introductory pricing, you can specify an initial price that applies to a set number of days, weeks, months, or billing periods. For example, you can offer a subscription for $1 per month for the first three months. Or, you can provide an introductory price of $1 for 10 days, followed by a regular monthly price. At the end of the introductory period, users are charged the full subscription price.

Requirements

You must clearly and accurately describe your offer’s terms, including the duration, pricing, and description of accessible content or services.
Be clear about what happens when the introductory offer ends, including how much users will be charged and how they can cancel.
The minimum introductory period is 3 days, and the maximum introductory period is 12 months.
Introductory prices must be within the accepted price range and less than the subscription's full price.
If the introductory period is a different length of time than the subscription period, the introductory price must cost less per day than the original price. For example, if a subscription costs $15 per month (or $0.50 per day), a week-long introductory price must cost less than $3.50. For these calculations, a month is always considered to be 30 days.

Also, two points to keep in mind. First, if you're offering a free trial and introductory price, your users are charged the introductory price at the end of the trial. Second, a user can only receive an introductory price for a specific subscription product (SKU) at one time.

For more information and examples, see Free Trials & Introductory Offers in the Developer Policy Center.

You have two options to add introductory price: as a single payment, or a recurring payment.

Having chosen ‘single payment’, you can set up an introductory period of n days/weeks/months (within limits specified above) for a specific price regardless of your subscription’s original billing period. ‘Recurring payment’ is tied to the original billing period. You can only choose the number of introductory periods and introductory price itself; for example, 3 months for a monthly subscription, and a monthly price for these 3 months.
Introductory pricing options in Play Console

Grace Period

Grace period allows your subscribers to update their payment method if a recurring payment is declined. This can be useful if your subscribers have an expired credit card, subscribed using a prepaid card, or cancelled a card without updating their payment information. Using grace period is usually considered more humane towards your users, and there’s no reason to turn it off.

At the start of the grace period, your subscribers will receive an email notifying them of a declined payment. They'll have time to update their payment method without interrupting their subscription. Once your subscribers update their payment method to a valid payment form, their next subscription billing date stays the same. If your subscriber's payment method is still declined by the end of the grace period, their subscription is cancelled, and they lose access to their subscription content.

Grace period could last for 3, 7, 14, 30 days, or none. If your subscription is ‘every 4 weeks’, the maximum grace period is 14 days; for ‘weekly’ subscription the maximum is 7 days.

For new subscription products, the following grace periods are set by default:

Weekly subscriptions: 3 days
Monthly and ‘every 4 weeks’ subscriptions: 7 days
Other subscription periods: 14 days

Resubscribe

Google offers the option to restore an expired subscription not through the app itself, but through the Play Market. If “Enabled for all” (which is the default value), users can resubscribe to the same SKU for up to a year after expiration by clicking Resubscribe in the Google Play subscription center, which generates a new subscription and purchase token.
Subscription section of Google Play

Pause and Free trial limit

When you click ‘Manage subscription settings’ button on the ‘Subscriptions’ page, you will see the following menu:

Pause

The default value is ‘enabled’.

You can prevent voluntary churn by enabling users to pause their subscription. When you enable the pause feature, users can choose to pause their subscription for a period of time between one week and three months, depending on the recurring period. Once enabled, the pause option surfaces both in the subscription center and in the cancellation flow.

Note that annual subscriptions cannot be paused, and pause limits of one week and three months are subject to change at any time. The subscription pause takes effect only after the current billing period ends. While the subscription is paused, the user doesn't have access to the subscription.

At the end of the pause period, the subscription resumes, and Google attempts to renew the subscription. Once the resume is successful, the subscription will become active again. If the resume fails due to a payment issue, the user enters the account hold state. Users can also choose to manually resume a subscription at any time during the pause period. When a user resumes manually, the billing date changes to the manual resume date.

Courtesy of Google’s Android Developer
Free trial limit

You have two options - ‘One per subscription’ or ‘One across all subscriptions’.

Overall, every field, except product ID and billing period, can be edited at any time. Billing period can be edited before you push the ‘Activate’ button. Once activated, the subscription product itself can’t be deleted.

To make your subscription visible to your testers, you need to activate it first. “Activate” button will become available once you fill in all the necessary fields and save changes, meaning your new clients can purchase it from your app. Testers can work with subscriptions without paying if you add them to License testing list by going to your app page –> Settings –> License testing.

Google Play rules

Subscription prices

You can choose to make certain content or services in your app available to users at a regular rate for a particular period. Users will be charged your chosen rate at your selected frequency until they decide to cancel.

For example, a user who buys a one-year subscription on Jan 1 for $10 will have access to the subscription until December 31 and will be charged $10 on the following renewal date.

Requirements

As a developer, you must be transparent about any subscription services or content you offer within your app.
You must communicate your offer clearly in any in-app promotions or splash screens.
You must be explicit about your offer terms, including the cost of your subscription, the frequency of your billing cycle, and whether a subscription is required to use the app. Users should not have to perform any additional action to review the information.
Subscription pricing must be within the accepted price range.
Your subscription title must accurately reflect your offer. For example, don’t name your subscription “Free Trial”.

Price changes

After you change the price of an existing subscription, here’s how it affects new users and existing subscribers:

New users can immediately see the subscription’s new price and subscribe to it on Google Play.
Existing subscribers receiving a price increase will be notified of the price change by email and through a notification on Google Play 7 days after the price change occurs. Subscribers will then have 30 days to agree to the price change; otherwise, their subscription will be cancelled on their next renewal date.

Of course, price increases may cause an increase in churn if subscribers do not accept the price change. We advise you to contact subscribers to inform them of the price increase in advance (Google recommends within a week) and give them a convincing justification. Customers will pay more if you give them a reason to do so

If you change the price multiple times before the user's next renewal date, the user only has to respond to the most recent price change. Existing subscribers receiving a price decrease will be notified and receive a lower price on their next renewal date.

Managing price changes

Once you change the subscription price, it can’t be reverted.
You can change a subscription’s price multiple times, but that's not what Google recommends as you may lose some subscribers each time you change a price

If you change a subscription’s price twice in a short period of time, your subscribers will need to agree to the first price change, and then agree on the second price change for your intended price to take effect.

If you want to offer one price to existing subscribers and a different price to new users, you can create a new subscription with the price you want to offer to new users. This way, your existing subscribers can continue renewing their subscriptions without having to agree to a price change.

And that's it, you've created your subscription! Next, we will be covering how to handle it.

Webflow + Ghost blog with Caddy

Vitaly Davydov — Mon, 14 Dec 2020 17:30:07 +0000

Modern SaaS applications usually run a landing page, blog, and the main app separately. For a landing page, you may want to use Tilda, Webflow, or other web-builders. For a blog, it’s common to use self-hosted CMS such as WordPress, Ghost, or others.

It’s crucially important to index the main domain your_domain.com instead of a subdomain blog.your_domain.com for SEO purposes. You want as many links to your main domain as possible. The more content on your_domain.com/blog, the more Google will index it.

Running Ghost blog on a subdomain such as blog.your_domain.com is easy, just create a new A-record in your DNS provider and point it to a machine with running Ghost instance. If you want to run your_domain.com on a Webflow and your_domain.com/blog being self-hosted Ghost you need a reverse-proxy server.

Reverse proxy server
From a devops point of view our goals are:

your_domain.com -> Webflow
your_domain.com/* -> Webflow
your_domain.com/blog -> self hosted Ghost blog
blog.your_domain.com -> your_domain.com/blog

We’re going to use Caddy for reverse-proxy. The reason is Docker-friendly config, super fast to deploy without deep knowledge of devops (hey, Nginx). Find the official Caddy image here. Caddy needs you to mount volumes for proper working.

We’ll host Ghost and Caddy on the same machine and in a single docker-compose.yml file.

version: "3.7"

services:
 caddy:
   image: caddy:2
   restart: unless-stopped
   ports:
     - "80:80"
     - "443:443"
   volumes:
     - $PWD/Caddyfile:/etc/caddy/Caddyfile
     - $PWD/site:/srv
     - caddy_data:/data
     - caddy_config:/config
 ghost:
   image: ghost:3
   environment:
     NODE_ENV: production
     url: https://adapty.io/blog
   volumes:
     - ./blog:/var/lib/ghost/content
volumes:
 caddy_data:
 caddy_config:

Now for Caddyfile:

blog.adapty.io {
   redir https://adapty.io/blog{uri} #point to subdirectory
}

adapty.io {
   redir /blog /blog/ #trailing slash
   reverse_proxy /blog/* ghost:2368 { #proxy to Ghost container
       header_up Host {host}
   }
   reverse_proxy proxy.webflow.com { #proxy to Webflow
       header_up Host {host}
   }
}

Run *docker-compose up -d *and here you go!

By default, Caddy passes thru incoming headers to the backend—including the Host header—without modifications, with two exceptions:

It adds or augments the X-Forwarded-For header field.
It sets the X-Forwarded-Proto header field.

Lastly,

Point A record for the main domain to your IP.
Change your DNS A record and point to a VM
In Webflow turn off SSL proxy as Caddy will serve it for you automatically (very cool, yeah? Without a certbot).
Turn off SSL in Webflow as Caddy will create a certificate for you
That’s it!