Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Step 1 to getting your code to live in Firebase and be ready for you to use is to prepare your environment. Watch this short video and follow the steps to prepare your Google Cloud environment to accept and host the required code
In order to complete the following actions you need to have a few HTTPS callable functions that live in the cloud. These actions will come in handy when you need to validate that a user should or should not have access to certain areas or content within your app. You'll need this to complete the following in-app processes
To be clear: once a purchase has been made, the only way to get an updated status on that purchase is to set up a backend that listens and waits for incoming data from the to the stores OR to directly ping the store and request the information manually. Our current process covers the later, though in the future documentation will be setup such that developers will bee able to ping their own backend Firebase server for subscription/purchase info which is much faster.
These steps are necessary when restoring purchases. Per app store polices, all apps that include IAP must also include a way for the user to restore those in app purchases should they ever need to delete/reinstall an app for any reason.
Acknowledge Android Subscriptions
if you don't do this step, subscriptions revert within 3 days of the original purchase
Verify Android Subscriptions
useful to ensure that a subscription is still valid.
Verify Android Purchases
useful to ensure users did not request refunds/charge backs after they made the original purchase
Verify iOS Purchases
Verify iOS Subscriptions
useful to ensure that a subscription is still valid.
Please be mindful. This page is almost identical to the previous with exceptions in the function name and code.
These codes will allow you to acknowledge and verify purchases or subscriptions. There is 1 call for each type of transaction.
androidPurchaseHandler should be the name you use here
the name used here should match the name used in Step 3 above
This allows any device with your endpoint URL the ability to verify purchases made via your app
Select the function you want to make public. (the function you just created)
Click the Permissions tab.
Click Add Principle
In the Add members field, type allUsers
Select the Cloud Function Invoker role from the Select a role drop-down menu.
Click Add.
These should be created and deployed like the previous 3 functions
serverLog should be the name you use here
the name used here should match the name used in Step 3 above
This allows any device with your endpoint URL the ability to verify purchases made via your app
Select the function you want to make public. (the function you just created)
Click the Permissions tab.
Click Add Principle
In the Add members field, type allUsers
Select the Cloud Function Invoker role from the Select a role drop-down menu.
Click Add.
These codes will allow you to acknowledge and verify purchases or subscriptions. There is 1 call for each type of transaction.
androidSubscriptionHandler should be the name you use here
the name used here should match the name used in Step 3 above
This allows any device with your endpoint URL the ability to verify purchases made via your app
Select the function you want to make public. (the function you just created)
Click the Permissions tab.
Click Add Principle
In the Add members field, type allUsers
Select the Cloud Function Invoker role from the Select a role drop-down menu.
Click Add.
This block will allow you to list the items that you have included in the app for sale. In order to use this block properly, your apps IAP component should always have an up-to-date IAP list of items and subscriptions.
You must be able to restore your users purchases at the click of a button. This is an iOS App Store policy.
A quick note on the blocks above. users have asked where the individualPurchaes variable comes from.
First show the hider to block user interaction, then call Get Purchase History
List of Purchase info
will output a list of objects that are formatted like this:
Assign a temporary variable as an empty list.
If there's not an error, pass the List of Purchase Info
to the Restore Previous Purchases
function, else handle the error.
Handling restoration will look different for each app, however in general it should follow this general format.
Notice the _listOfPurchases variable. you can create that by clicking the cog wheel, dragging an input name
block into the inputs
receiver, and giving it a meaningful name
Loop through the list of purchases. You can access this variable by right clicking on the function body and selecting create _listOfPurchases
Notice that the 'for each item' variable name is 'individualPurchase'. See how to change those variable names below.
in the loop, you will first check if that purchases product_id matches one of your known products, and then the purchaseState to ensure the product's purchase is still valid.
There should be one of these for each item you have in your app using an if/else if/else allowing for 1 check per product.
if the item passed the checks in step 6, check if purchasedItems
list contains that purchase and if not, add it to the list.
The final step is to save the state of the purchase locally so that you do not need to verify purchases every day. It is recommended to regularly check that subscriptions are still valid.
In this example, we store a T/F value for the purchase as well as the transactionReceipt. This allows the app to permit/block access to the purchased item and allows the app to check if the purchase is still valid again in the future.
In our example, we display an alert to the user to display the restored purchases. This is not required, though highly recommended as your users will appreciate that information. The main purpose of a workflow like this would be to be able to restore purchases if the user has to reinstall the app or changes phone
In-App Purchases (IAPs) are a great way to monetize your app. These allow you to offer access to specific in-app sections. This allows you to offer some content to the general user, but also offer ‘premium’ content/features of your app for a price.To begin, you'll need to take care of a few details for either platform you plan to incorporate IAP with. Follow the links below to get the groundwork laid to begin using IAP in your app!
Now, these combos will vary from app to app, but the basic setup is the same. Complete a purchase, parse the response, store the relevant data.
Developers should plan to store purchase information in the app for quick retrieval. Purchases are associated with transaction ID's which are associated with the Apple ID of the phone. These Transaction ID's are used like a receipt to verify purchases or to validate subscription status's.
We recommend you setup Stored Variables to hold this information locally for now if you are unfamiliar with NodeJS or Javascript programming.
The following is an example of saving information related to a Subscription and 1-Time purchase. The expiry time or T/F value is saved along with the corresponding transaction ID.
Please be mindful. This page is almost very similar but different than the last page. Differences in service account, code, package.json.
These codes will allow you to acknowledge and verify purchases or subscriptions. There is 1 call for each type of transaction.
verifyiOSPurchase should be the name you use here
the name used here should match the name used in Step 3 above
This allows any device with your endpoint URL the ability to verify purchases made via your app
Select the function you want to make public. (the function you just created)
Click the Permissions tab.
Click Add Principle
In the Add members field, type allUsers
Select the Cloud Function Invoker role from the Select a role drop-down menu.
Click Add.
Before you can create your In-App Purchases, you are required by Apple to request and fill out their Paid Applications contract.
To do so, log into your App Store Connect account, and go to the Agreements, Tax, and Banking section. In this section, you will see the ability to request the Paid Applications contract towards the top of the page.
After this is complete, you will now be able to add your In-App Purchases.
Consumable - a one-off purchase which can be repeated and keeps no history
Non-Consumable - a product that can only be purchased once and keeps history in your apple account. If you try and buy a second time, it reports you have already purchased and offers a free download
Auto-Renewable Subscription
Non-Renewing Subscription
Required role: You must have the Account Holder, Admin, App Manager, Developer, or Marketing role to add and edit in-app purchases. See Role permissions.
From My Apps, select your app.
In the sidebar under In-App Purchases, click Manage.
To add an in-app purchase, go to In-App Purchases and click the Add button (+).
Select Consumable, Non-Consumable, or Non-Renewing Subscriptions and click Create. For auto-renewable subscriptions, see Create an auto-renewable subscription.
Add the reference name, product ID, and a localized display name.
Click Save, or Submit for Review.
You can enter all your metadata when you create your in-app purchases, or enter your in-app purchase information later.
All in-app purchase metadata can be edited, except the Product ID and in-app purchase type. If your in-app purchase has never been submitted to Apple for review, you can make changes to your metadata. If your in-app purchase has already been submitted, some changes require approval by App Review.
To offer auto-renewable subscriptions within your app, you must first create auto-renewable subscription products in App Store Connect. When you create your first subscription product, the App Store Connect flow will guide you to create your first subscription group. When you create additional subscription products, you'll be able to add these products to the subscriptions groups you've already created, or create a new group. Before creating subscriptions, ensure that you understand the right subscription setup for your business model. See Overview of auto-renewable subscription group setup.
To learn more about the subscription business model for your app, read Offering Subscriptions.
Required role: Account Holder, Admin, App Manager, Developer, or Marketing. See Role permissions.
From My Apps, select your app.
In the sidebar under In-App Purchases, click Manage.
Scroll to the In-App Purchases section and click the Add button (+).
Select auto-renewable subscription, then click create.
Note: If you'd like your subscription to be accessible from more than one app, create an equivalent subscription product for each app. For more information, see Offering Subscription Products Across Multiple Apps.
Add your in-app purchase reference name and product ID, then click Next.
If this is the first auto-renewable subscription product you are creating, you'll need to also create a subscription group (you'll be able to add details to it later), by selecting Choose New Subscription Group. If you've already created subscription products and groups before, add your subscription product to an existing group or create a new subscription group. Then click Create.
Important: How you set up your subscription group or groups will determine how customers can subscribe to your content or services, how they move between subscriptions, when they are billed, and your proceeds. See [<Overview of setting up auto-renewable subscriptions>] and ensure that you understand the right subscription setup for your business model. Keep in mind that a subscription cannot belong to more than one group and cannot switch groups after it’s been created.
The Subscription Group page will open.
Once you've created your subscription product, you'll be taken to its information page to add more details. Under Subscription Duration, choose a duration from the pop-up menu.
Under Subscription Prices, set a price for your auto-renewable subscription.
Under Localizations, click on the Add button (+) to add a language for your localized display name.
Enter your localized information.
Under App Store Promotion, optionally add a promotional image. Learn more about Promoting In-App Purchases.
Under Review Information, provide any additional information that may help the App Review team review your in-app purchase.
Click Save.
You can test your app and in-app purchases without creating financial transactions by using sandbox, a test environment that uses the infrastructure of the App Store but doesn’t process actual payments. Instead, it returns transactions as if payments were processed successfully.
From Users and Access, click Testers under Sandbox.
Click the Add icon (+).
Enter the tester information, then click Invite.
Account information cannot be edited once a Sandbox Apple ID is created.
You can clear the purchase history for a tester so that you can continue to use the same sandbox Apple ID for ongoing testing. Clearing purchase history will delete all past auto-renewable subscriptions and non-consumables purchased by the selected testers in the sandbox environment. In-app purchases made by customers on the App Store are not affected.
To clear tester purchase history:
From Users and Access, under Sandbox, click Testers.
Click Edit.
Select the checkbox for each tester you want to modify and click Clear Purchase History.
Click Clear Purchase History in the dialog that appears.
Sandbox Apple IDs with a high number of purchases may take longer to clear. This action cannot be reversed.
You can choose a subscription renewal rate for each tester to speed up or slow down how often subscriptions renew. Subscriptions are automatically canceled after 12 renewals.
By default, a one month renewal lasts 5 minutes. If you wish to speed up the renewal period, you can choose 3 minutes. If you wish to slow down the renewal period, you can choose 15 minutes, 30 minutes, or an hour.
The columns in the chart below represent each of the accelerated renewal rates you can select for a tester in App Store Connect. The corresponding test durations are listed underneath the accelerated rates for each product duration.
You can test interrupted purchase scenarios on a device running iOS 14 or later by enabling interrupted purchases in App Store Connect for a specific tester Sandbox Apple ID. If this option is selected, on-device purchase attempts by that Sandbox Apple ID will be interrupted in the sandbox environment and continue to be interrupted until the option is deselected or the tester agrees to terms and conditions on their iOS device. This allows you to test your app’s handling of an interruption to ensure a seamless customer experience.
In general, an interrupted purchase is experienced anytime a customer needs to address an issue with their Apple ID. Some example scenarios include:
The user needs to agree to updated terms and conditions.
The user needs to update an expired payment method.
When interrupted purchase is enabled for a sandbox tester, all purchases will be interrupted for that Sandbox Apple ID, preventing the transaction from completing until resolved. In sandbox, the tester will need to agree to terms and conditions in order to complete the purchase. Purchases will continue to be interrupted on the Sandbox Apple ID until you disable the option in App Store Connect or the tester agrees to terms and conditions on their iOS device.
Follow the steps outlined in Testing In-App Purchases with Sandbox to understand what to test and how to use your device in a testing environment.
You can change the account region for a tester to any of the 175 different regions for the App Store. This allows you to continue testing on different storefronts using the same Sandbox Apple ID, without having to create new testers.
You will need to sign in again with your Sandbox Apple ID on your device to complete this change.
Navigate to Appleid.apple.com from your web browser and sign in with your Apple ID and Password.
Verify your identity with two-factor authentication.
Under the Security section, select Generate Passwords.
If you don't see the option to generate app-specific passwords, you'll need to enable two-factor authentication, which is different than two-step verification.
Enter a label for the password. Be sure the name relates to the app for which you are generating the password, like "Outlook" or "Thunderbird."
Select Create.
Copy the app-specific password you generated and save it in a file on your local system such that you may reference it as needed while building your app.
Please follow all of the included steps to setup and test your In App Purchases via the Android Play Store.
we cover this below
Click Create payments profile. Make sure to have your business information available to set up your payments profile.
Under "Payments profile," click the down arrow and select Create payments profile.
Name and address:
Enter the legal name of your business as you want it to appear on your payments profile. This information will be shown to your customers and also on your receipts.
Primary contact: Enter the name of an authorized representative for your company who Google can contact if we have questions about your payments profile. Provide an email address and a phone number (optional).
Enter the following public business information, or choose to match your public merchant profile and payments profile information:
Enter your business website.
Select the category of products that you sell.
Your customer support email.
The business/product name that'll appear on your customers' credit card statements.
Note: To help customers remember what they purchased and keep chargebacks to a minimum for you, use an appropriate credit card statement name.
After you create a payments profile it is automatically linked to your Play Console. Note: If you have set up a payments profile or merchant center account previously, it is already linked to your Play Console.
Before creating a product, make sure to plan your product IDs carefully. Product IDs need to be unique for your app, and they can’t be changed or reused after they’ve been created.
Product IDs must start with a number or lowercase letter, and can contain numbers (0-9), lowercase letters (a-z), underscores (_), and periods (.).
You can’t change or reuse a product ID after the product has been created.
Note: The product ID android.test
is unavailable for use, along with all product IDs that start with android.test
.
To create an in-app product:
Click Create product.
Enter your product details.
Product ID: A unique ID for your in-app product.
Title: A short name of the item (up to 55 characters, but we recommend limiting titles to 25 characters to display properly in all contexts), like "Sleeping potion."
Description: A long description of the item (up to 200 characters), like “Instantly puts creatures to sleep."
Icon: A unique and accurate image for your product. Don't include text, promotions, or branding. Your product icon is shown on your store listing and during the purchase flow.
32-bit PNG
512 px by 512 px
Up to 1 MB
Multi-quantity: Allow multi-quantity checkout for this product. Users will be able to purchase in multiple quantities within the threshold of their country/region. Note the following information:
Multi-quantity checkout is not available in some countries/regions.
In most countries/regions where Multi-quantity checkout is available, the SKU price threshold is around US$100. To allow multi-quantity checkout, you will need to adjust the price (before tax) to below the threshold in each country/region.
Play Points exclusive: Make your product available only in Google Play Points.
Save your changes and click Activate to make your in-app product available to users..
To be available for purchase, a product needs to be active, and its app needs to be published.
Before creating a subscription, make sure to plan your product IDs carefully. Product IDs need to be unique for your app, and they can’t be changed or reused after they’ve been created.
Product IDs need to start with a lowercase letter or a number and must be composed of only lowercase letters (a-z), numbers (0-9), underscores (_), and periods (.)
Note: The product ID android.test
is unavailable for use, along with all product IDs that start with android.test
.
To add a subscription:
Click Create subscription.
Enter your subscription details.
Name: A short name of the item (up to 55 characters, but we recommend limiting titles to 25 characters to display properly in all contexts) such as "Sleeping potion."
Description: A long description of the item (up to 80 characters) such as "Instantly puts creatures to sleep."
Benefits: Provide up to 4 benefits, which each describes a feature of the subscription (up to 40 characters each)
Benefits should highlight the features to give users a better idea of what your subscription offers, like “Full catalog of TV shows and movies.”
Since not all users will be eligible for a promotional price or free trial, the benefit should not mention free trial or price, for example “Try 7 days free” is not allowed.
Enter pricing details in the “Price” section:
Billing period: Choose the time interval between billing statements.
Default price: Enter a default price or import from an existing pricing template; this is used to generate local prices in other countries. Local prices use today’s exchange rate and country-specific pricing patterns. Countries without local currency support use your default price.
Choose and define additional options in the “Subscription settings” section:
Click Save.
Click Activate to make the subscription you created active.
To be available for purchase, a product needs to be active, and its app needs to be published.
With application licensing, you can set up a list of Gmail accounts to test your in-app billing and subscription integration. Your own publishing account is always considered a licensed tester.
You're able to purchase your own app, in-app item, or subscription as a test purchase. Once you've set up application licensing, authorized users can also purchase in-app products and subscriptions without charging the users’ accounts.
When making a purchase from a license test user, you will see two choices for payment method:
“Test card, always approves”
“Test card, always declines"
Before they can be tested, your in-app products and subscriptions need to be published.
When testing consumable products, we recommend testing a variety of situations, including the following:
A successful purchase where the user receives an item. With a license tester, you can use the Test instrument, always approves payment method.
A purchase where the payment method failed to be charged, and the user should not receive the item. With a license tester you can use the Test instrument, always declines payment method.
Ensure items can be purchased multiple times.
Non-consumables should be tested the same as consumables, but you should verify an item cannot be purchased again within your app. Be sure to verify purchase acknowledgement for both non-consumables and consumables (when applicable) since the logic to process each the two types of purchases vary.
The purchase flows for one-time products and subscriptions are similar, but subscriptions have additional scenarios, such as successful or declined subscription renewals. To test renewals, you can use the Test instrument, always approves and Test instrument, always declines payment methods that are available for license testers, as shown in figure 1. Use these payment instruments to test scenarios beyond the successful subscription scenario.
Test subscriptions renew more quickly than actual subscriptions, and test subscriptions can renew a maximum of six times.
The following table lists the testing renewal times for subscriptions of various durations. These times are approximate. You may see small variations in the precise time of an event. To compensate for variation, call the API to view the current status after every subscription expiration date.
Time-based subscription features such as free-trials are also shortened for testing. The following table identifies the testing time periods associated with time-based subscription features:
This next step is vital for subscriptions. If you don't complete this step, you wont be able to 'acknowledge' subscriptions. For android IAP, 'acknowledging' is how you complete the transaction and if not completed the transaction will revert and you as the developer will not make money on that purchase plus your users will likely have an unpleasant experience (i.e. they loose access to the thing they wanted to buy).
To do this process you need to make API calls. Before you can start making API calls, you need to set up API access to your Google Play Developer Account. This involves changes in both the Google Play Console and Google Cloud Console. The following instructions explain the four steps needed to start using the Google Play Developer API.
Link your developer account to a new or existing Google Cloud Project.
Enable the Google Play Developer API for your linked Google Cloud Project.
Authorize an API key for the Google Play Developer API in your linked Google Cloud Project.
Set up a service account with appropriate Google Play Console permissions to access the Google Play Developer API.
Before you can access the Google Play Developer API, you must link your Google Play Developer Account to a Google Cloud Project. In most cases, we recommend that you create a new Google Cloud Project dedicated to your Google Play Developer Account, but you can link an existing project. Keep in mind that each Google Play Developer Account can only be linked to a single Google Cloud Project. If you have multiple apps in the same Google Play Developer Account, they all must share the same Google Cloud Project.
Click Create new project.
The Google Cloud Project is automatically created and linked to your Google Play Developer Account.
If you are already a user of the Google Cloud Console, you can link to your existing Google Cloud Project by following these steps:
Choose the project you’d like to link. If your project isn't listed, verify that your user account is designated as Owner in the Google Cloud Project you want to link.
Click Link existing project.
Once you have set up the linked Google Cloud Project, you need to enable the Google Play Developer API for this project. To do this, you need to be an owner of the Google Cloud Project.
Under APIs, find the Google Play Developer API and click Turn on.
This directly updates the Google Cloud Project and the change takes effect immediately.
To use the API, you need an API key in your linked Google Cloud Project that is authorized to use the Google Play Developer API. Set this up in the Google Play Console.
You need to configure access to the Google Play Developer API with an OAuth client or a service account. In most cases, you should use a service account to access the API.
Service accounts must be used in a secure environment, such as your server. The service account credentials need to be securely managed so they are not revealed to anyone that is not authorized to use the API.
The OAuth Client ID should be used if you need to access the API on behalf of an individual user. For example, if your website needs to access the Google Play Developer API from the web client on behalf of the user, you can use the Client ID. The user will be authenticated with their Google account instead of the service account. This allows you to make API calls on behalf of a user without compromising service account credentials.
Service account: A secure software service will access the API (most common)
OAuth clients: A user will access the API
Under Service accounts, click Create new service account.
Follow the instructions to create your service account.
During the process of account creation you need to grant your service account access to the Google Cloud Project in order for it to appear in the Google Play Console.
Click Grant Access to provide the service account the necessary rights to perform actions.
To use the Google Play Billing APIs, you must grant the following permissions:
View financial data, orders, and cancellation survey responses
Manage orders and subscriptions
3. Find and click on the service account in the list in the Google Cloud Platform
4. Click the Keys tab
5. Click "Add key" then "Create new Key"
6. Select JSON as the key type and click Create. The file will automatically download to your default download folder.
Using , you can offer in-app products that charge users on a one-time basis, known as in-app products. In-app products can include items like virtual goods (for example, game levels or potions) and premium services within your app on Google Play.
You can also , which charges users on a recurring basis.
Important: Google Play and apply to all in-app products, including both one-time products and subscriptions
Create a payments profile in payments center to manage and track your app sales from Play Console. Review the list of .
Sign in to .
Go to the page (Settings > Developer Account > Payment settings).
Provide your legal business address as it appears on official documents. It’s important that we have a valid physical address on file for your business. We don't allow you to use a PO box address. Later, you'll need to make sure that your bank account is registered in the same country listed in your payments profile. Learn more .
When you're finished, click Submit. Note: You cannot change your business location country but you can later.
Open Play Console and go to the page (Monetize > Products > In-app products).
Price: Enter a price in your local currency or .
To configure multi-quantity checkout in Play Console, your app needs . Visit the to learn how to integrate the Google Play Billing Library into your app
If you’re using a test account, active items are available in unpublished apps. To learn more, go to the .
In-app products use the same default language as their app. To add translations in specific languages, select an in-app product, and then click Manage translations and apply the languages you want. .
Review Google's updated in the Developer Policy Center to ensure your app is compliant with the latest changes.
Using , you can offer in-app products that charge users for content or services on a recurring basis, known as subscriptions. Subscriptions can include items like a collection of apps, games, or other content for a recurring fee within your app on Google Play.
You can offer multiple subscriptions within the same app. Subscriptions must be priced within the . Subscriptions can't be unpublished.
You can also , which charges users on a one-time basis.
Important: Google Play and apply to in-app products and subscriptions.
If you’re in a supported location and want to start using Google Play's billing system features in your apps, and .
Note: Weekly subscriptions can now be charged using Direct Carrier Billing (DCB). For more information, review the .
Read more about Google in-app subscriptions .
Adding a subscription is similar to , except the price is set for a period of time.
Before adding a subscription, review our .
Open Play Console and go to page (Monetize > Products > Subscriptions).
Free trial: You can let users try your subscription before they pay. If you select Enabled, choose how many days you want to make it available for free. Learn more .
Introductory price: You can offer new subscribers a discounted price for a specific duration. If you do, this must be within the accepted price range and cost less per day than the original price. Learn more .
Grace period: You can give users time to resolve payment issues while keeping their subscription active. Grace periods can be 3 days, 7 days, or 14 days. Learn more .
Resubscribe: Enabling resubscribe allows users to resubscribe from the Play Store after cancellation. Learn more .
If you’re using a test account, active items are available in unpublished apps. To learn more, go to Google's site.
To set up , start by adding your list of testers' Gmail addresses in Play Console.
Open .
Your app has been published to the open, closed, internal test, or production track. We recommend publishing your app to the internal test track. Make sure that your testers are also eligible to receive your release by following the instructions for or using .
You've .
Learn more about and using .
You should also verify that purchases are properly acknowledged as described in . For purchases from license testers, a purchase will be refunded after 3 minutes if your app does not acknowledge the purchase and you will receive an email about the cancellation. You can also check the Orders tab in the Google Play Console to see if an order was refunded after 3 minutes.
Similar to one-time products, you should also verify that purchases are properly acknowledged as described in . For purchases from license testers, a purchase will be refunded after 3 minutes if your app does not acknowledge the purchase and you will receive an email about the cancellation. You can also check the Orders tab in Google Play Console to see if an order was refunded after 3 minutes.
Go to the page on the Google Play Console.
Go to the page on the Google Play Console.
Go to the page on the Google Play Console.
You can create a from the Google Play Console.
Go to the page on the Google Play Console.
Once you’ve created the service account on the Google Play Console, click Done. The Service Accounts section of the page automatically refreshes, and your service account is listed.
At this point, you should be able to access the Google Play Developer API through the service account. For more information, see .
Go to your in the Android Developer Console
Find the service account you created in and click "View in Google Cloud Platform"
Actual Duration
Monthly renewal every 3 minutes
Monthly renewal every 5 minutes (default)
Monthly renewal every 15 minutes
Monthly renewal every 30 minutes
Monthly renewal every hour
1 week
3 minutes
3 minutes
5 minutes
10 minutes
15 minutes
1 month
3 minutes
5 minutes
15 minutes
30 minutes
1 hour
2 months
6 minutes
10 minutes
30 minutes
1 hour
2 hours
3 months
9 minutes
15 minutes
45 minutes
1 hour 30 minutes
3 hours
6 months
18 minutes
30 minutes
1 hour 30 minutes
3 hours
6 hours
1 year
36 minutes
1 hour
3 hours
6 hours
12 hours
Production subscription period | Test subscription renewal |
1 week | 5 minutes |
1 month | 5 minutes |
3 months | 10 minutes |
6 months | 15 minutes |
1 year | 30 minutes |
Feature | Test period |
Purchase acknowledgement | 5 minutes |
Free trial | 3 minutes |
Introductory price period | Same as subscription test period |
Grace period (both 3- and 7-day) | 5 minutes |
Account hold | 10 minutes |
Pause (1 month) | 5 minutes |
Pause (2 months) | 10 minutes |
Pause (3 months) | 15 minutes |
When you complete a purchase, a transaction ID is returned in the green blocks. This value should be kept in a stored or cloud variable so that you can quickly verify specific purchases or that subscriptions are still valid at the device or user level. This helps ensure users are not able to trick your app into believing a purchase has been made when it has not. These values are also used to verify ongoing subscriptions for users and when restoring purchases to verify that all purchases returned by the server are valid still.
If you followed the directions for iOS Code you will have a trigger URL.
Find the trigger URL by going to your function list and selecting the iOS Verify function.
Then click the trigger Tab and notice the included URL.
you will copy this url then go back into your Thunkable projects to the blocks page and create a new web api
Copy in the URL and add a header as shown in the image below
Note: in the above example, there are several references to "server logs." this is nothing more than saving data to firebase in order to see logs in a different manner. Error logging should occur during testing to allow for easier debugging.
For Android, when a user initiates a transaction, it must be completed by first verifying then acknowledging the purchase. Once you've verified the purchase, your app is ready to grant the purchased item or subscription to the user. After granting entitlement, your app must then acknowledge the purchase. This acknowledgement communicates to Google Play that you have granted entitlement for the purchase and completes the transaction. If you fail to complete this acknowledgement step your subscriptions will revert in a period of 3 days from the time of purchase. The verification process can also be used to confirm that a users subscription status or purchase is still valid.
This is not the most efficient method and we want to acknowledge this. We will be continuing to update the docs as we produce more concrete examples. We also wanted to get something solid into your hands now. Look for updates soon! The ideal way to maintain purchase status's will be completed using server side actions and maintaining a list of purchases and their status in a database that your users can access vs calling out to the verification endpoint for each subscription/purchase to be verified. i.e. You can keep things up to date in real time without making a bunch of API calls to the Google Play Store
For this reason, we have simplified the process by creating 2 separate endpoints for Android. See how to find those below
Notice that the blocks are almost similar for these two. Thats because the response is handled the same way. We broke up the API calls in the code into "Subscription" and "One-Time Purchase" as they technically call different API's.
If you followed the directions for Android Subscriptions Code or Android Purchases Codes you will have a trigger URL.
Find the trigger URL by going to your function list and selecting the purchase or subscription function
Then click the trigger Tab and notice the included URL.
you will copy this url then go back into your Thunkable projects to the blocks page and create a new web api
Copy in the URL and add a header as shown in the image below
Note: in the above example, there are several references to "server logs." this is nothing more than saving data to firebase in order to see logs in a different manner. Error logging should occur during testing to allow for easier debugging.
the green purchase block should be handled as a list/array. The purchase object is always item # 1 in the list
Please note that the one-time items and subscription blocks are handled in a similiar manner.
a 'hider' is shown. We recommend you use a 'waiting' modal to indicate to users they should not interac
This could be a Group with a spinning 'loading' icon in an image component.
If an error does occur, the error is passed on to the Server Log
If the transaction is successful and the property purchaseState from object #1 in the (single item list) of purchase objects,
else, send a server log
Hide the hider/waiting modal after verification
Learn more about the data these blocks returnAfter you created your IAP's, you're ready to start selling them to your users!Using the corresponding productID
created above, choose the appropriate block (either Purchase Subscription
or Purchase One-Time Item
) and connect it to a user action. Purchases should be very straight forward within your app. Make it clear for your users how much they are paying and provide a brief description of the item. You can include more details in your app store item setup.Once you check there wasn't an error, you should verify the purchase
(the green block). If your users are purchasing a subscription on android, you MUST complete the step of verification and acknowledgement in order to complete the transaction.