Google Play integration types

The goal of this article is to describe the two types of Google Play integration and their requirements and limitations. Each integration type has its own advantages and disadvantages so it’s best to understand them before deciding which one is right for you.

Importing and setup instructions

ChartMogul has two integration types:
The first option imports the data you have from your Google Play estimated sales report into ChartMogul. Unlike the second option, this doesn’t require any development work and will import your data automatically after setup. As for the second option, Google Play does not directly notify ChartMogul of new purchases, nor does it list all past purchases. For this reason, we rely on you, the mobile app developer, to import in-app purchases into ChartMogul. Learn how in our developer tutorial.
Depending on what integration type you choose, there are a few fields that you need to fill out to complete the setup. Check out this article to know more about the setup instructions and how to get the required fields from your Google Play console.

Process flow

Importing and updating data via the daily sales report


For this integration type, we use your Google Play credentials to download the daily sales report from your Google Play Cloud storage. Once we have downloaded all the reports that you have, then we will start mapping those into ChartMogul.

With regard to updating your data, the process is the same except that this time, we just need to download the most recent report.

Importing and updating data via the payloads URL


As for importing via the payloads URL, the process is a bit more complex:

  1. User enters his Google Play credentials to ChartMogul and once the credentials have been verified, a payloads URL will be generated.
  2. User then has to create a script that will send any new purchase tokens to the payloads URL. 
  3. ChartMogul will then add it to the list of purchase tokens to be processed for the day.
  4. A job will be scheduled that will retrieve all subscription related data from Google Play to ChartMogul for processing. 

Differences between integration types

Below are the major differences between the two types of our Google Play integration.

Google Play Developer API utilization

With option 1 (import using Google Play’s daily estimated sales report), this integration type doesn’t require a lot of API requests to import your data. The only time we use the API is to get the product details so we can import them as plans in ChartMogul. This is beneficial for users who utilize Google Play’s developer API for other business needs other than ChartMogul. However, for option 2 (payloads URL), we will do API requests when:

  • Validating the purchase tokens we receive from your end
  • Retrieve product details to import the plans in ChartMogul
  • Check for any updates on the purchase tokens (daily)

Google Play Developer API has a rate limit of 200k reqs/day. This means that if you have more than 200k active purchase tokens, you might need to request higher quotas on the Google APIs console to ensure that all updates are reported in ChartMogul.

Google fee handling

Both integration types handle Google Fee calculations and can be included/excluded from your MRR and cash flow metrics calculations. However, with option 1, since the tax and fees are provided in the estimated daily sales report, we are properly able to break them down in the customer page’s transactions table:

Data imported via daily estimated sales report


Data imported via payloads URLimage_2.png

Report on refunds

Since refund transactions are available in the daily estimated sales reports, option 1 will allow you to report on refunds into ChartMogul. Unfortunately for option 2, since Google Play does not expose any refund amounts via the API, your refunds cash flow report will not include any refunds from your Google Play datasource.

Refund transactions imported via daily estimated sales report


Import historical data

For option 1 (import using Google Play’s daily estimated sales report), Google Play allows us to import all your daily subscriber reports up till February 1, 2012. This means that any transactions up till this date will be imported into ChartMogul. However, if you choose option 2, you will need to send all historical data to ChartMogul via your payloads URL.

Also if you choose option 2, in-app Subscriptions that have remained expired for longer than 60 days are not retrievable from Google Developer APIs. This means that ChartMogul cannot automatically report on any such subscriptions. If you have historical data of such subscriptions and want to import it, please write to us.

Importing customers and transactions

When importing data using payloads URL, if there are no successful transactions for a purchase token, then the respective customer will be reported as a Lead in ChartMogul.

As for importing data using the daily sales report, we will only import the customer if there is a successful transaction.

ChartMogul will not import any failed transactions for both integration types.

Time of cancellation

When importing via the daily sales report, cancellations will always be recognized at the end of the billing period. 

When importing via payloads URL, some subscription cancellations may appear in ChartMogul before the subscriber's eligibility for the service runs out. This is because subscribers can cancel anytime during their paid subscription period and they will continue to receive the benefits until the paid period runs out. Meanwhile, the integration will register the time that the user cancelled their subscription as the cancellation time, instead of the end of the billing period.

Handling upgrades/downgrades/reactivations

The daily sales report doesn't provide any information about related transactions. Because of this, it's impossible to report on subscription upgrades, downgrades and reactivations. Instead, when a customer upgrades their subscription, we will cancel the old one and we will create a new customer with the new subscription. Below is an example of how reactivations are handled when you import your data via the daily sales report: 

This customer purchased a monthly subscription on July 4th, 2018 but decided to cancel their subscription on December 4th, 2019.



On Dec 5th 2019, the same customer actually decided to reactivate their subscription. In this case, Google Play will create a new order number and a new purchase token. Unfortunately, since the daily sales report doesn't give any information about which transactions are related, ChartMogul has no choice but to create a new customer with a new subscription for this transaction.


On the other hand, if you are importing your data via payloads URL, since we can track which transactions are related using the purchase tokens you send to us, this is handled properly in ChartMogul.

This is a screenshot of a customer with a cancellation and reactivation.


As you can see from the MRR movements table, this is reported correctly. 


Since purchase tokens allow us to identify which transactions are related, this gives us the ability to group all related transactions together and associate them to a single ChartMogul customer. 


What you need to know

Here are some additional information you should know about our Google Play integration:

  • [Both integration types] ChartMogul currently reports revenue only for Google Play in-app subscriptions.
  • [Both integration types] ChartMogul does not support consumable purchases. Non-subscription users (in-app consumables) are counted as subscription users.
  • [Both integration types] Google Play does not expose personally identifiable information of subscribers like name and email. However, with the payloads URL integration type, you can include that information while submitting purchase tokens to ChartMogul.
  • [Both integration types] Our integration checks and updates subscriptions every 24 hours. This means that any updates to subscriptions already imported and reported in ChartMogul will come through once in 24 hours.
  • [Both integration types] Google Play does not expose any date when the order transaction happened. Because of this, we will be using the start date of the subscription period as the transaction date. Unfortunately, this is a limitation at Google's end that we cannot overcome.
  • [Both integration types] Google Play does not expose introductory prices via the API. If you use this feature, subscribers who buy at the introductory price will be reported with MRR based on the list price. Unfortunately, this is a limitation at Google's end that we cannot overcome.
  • [Both integration types] ChartMogul ignores purchases by test users during data import.
  • [Payloads URL integration type] Google Play does not expose any prorated prices that are charged. If you allow for prorated changes in your in-app subscription offerings, the charge amount will always show as the list price. Unfortunately, this is a limitation at Google's end that we cannot overcome.
  • [Payloads URL integration type] If you have configured grace periods in your Google Play in-app subscriptions, be sure to account for them while setting up delinquent subscription handling in ChartMogul.
  • [Payloads URL integration type] Taxes in Google Play may be inclusive or exclusive depending on the country that the charge is taking place in. In some countries, prices shown to buyers on search and detail pages must equal the amount paid at time of payment, for example, the United Kingdom. Google doesn't expose any information about tax amounts that are charged however meaning that the MRR reported by ChartMogul will, therefore, include tax.
  • [Payloads URL integration type] ChartMogul tries to calculate Google's transaction fees and deduct them from MRR calculation. However, historical grace periods and account hold periods are not exposed by Google APIs and therefore, for subscriptions that have had them, the calculated transaction fees might not be fully accurate. This also applies to transactions from countries where taxes are included in the price where the calculated transaction fees may also not be completely accurate.