User Storage
User Storage is a feature of paid plans. Default storage duration is 1 year, with custom durations available on a CUSTOM plan.
Enabling User Storage is required when offering Subscriptions, otherwise optional.
Definition
A database record is created for each user logging into your app and making purchases. This entry can also be referred to as User Storage or User Inventory. User inventory contains most recent subscriptions and non-consumables with their purchase state. It is stored in the cloud and can be retrieved by calling the Get User API endpoint (manually), or by using the functionality provided in our game engine SDKs.
Iterate over the inventory to grant active products received in the response, or display messages about billing issues or expired subscriptions to the user.
Please try to minimize calls from one client to request user inventory as they could be rate limited. For more information on how to avoid excessive API usage, please see the notes in the Get User API.
Usage
User Behaviour
User Storage is enabled in the backend by selecting a User Behaviour value in the App Setup other than Disabled. Each selection offers a different level of security and affects how users are associated with transactions.
| Mode | Description |
|---|---|
Disabled | Default. Purchase history is not tracked. Use this if you only need server validation for each purchase and otherwise handle user inventory yourself. |
Alias | Minimum security. Multiple users can be associated with one purchase, for a total of 1 original user + 5 alias users. Subsequent alias requests will be blocked. |
Transfer | Normal security. A purchase is linked to the original user. The purchase can be transferred to a different user with a cooldown period of 5 days. |
Block | Highest security. A purchase can only exist on the original user. Sending the same receipt from a different user will be blocked. Your authentication system should also allow users to restore their login credentials. |
If you are using one of our game engine SDKs, we usually provide an Inventory Request Type dropdown on the IAPGUARD component. On that, choose a value other than Disabled to enable inventory requests on the client side.
With User Storage enabled, do not forget to pass a user identifier to each validation request. If you are using our game engine SDKs, assign a User ID value on the IAPGUARD component before initialization. Read more on user authentication below.
Authentication
Adding native or third-party authentication to your application allows users to log in, stop and resume on a different device where they left off, or even sharing purchases and subscriptions across any other platform. Implementing user authentification is an important aspect for uniquely identifying users within your application. This Service associates transactions with users in order to verify their uniqueness, but also to ensure they can retrieve and restore their own purchases later.
User Storage does not work without it!
Please note that, due to the many different platforms, programming languages and SDKs, IAPGUARD SDKs do not ship with an authentication system. It is your decision to use one of the authentication SDKs that meets your needs, your enterprise or custom solution and pass the returned user identifier over to the API.
If an user identifier is not provided with the call to receipt validation, the server generates and responds with a generated (v4 UUID) user identifier.
Example: 3ed5e911-5eaa-46b3-8efc-74612d2b878d
When the server responded with a newly generated user identifier, you will want to save the ID on the device locally, or persist it in the platform native key-value storage to be used in subsequent calls.
Best practices
When it comes to best practices for user authentication and security, consider the following points:
- Do not use emails or other forms of personal data as user IDs for privacy reasons
- In general, user IDs should not be guessable and include some randomization
- Do not use device identifiers such as IDFA or Ad-ID since they are not unique
- Do not hardcode user IDs into your application since all users would then be the same
It is best practice to require users to log in before making purchases and authenticating them with a native provider, such as Play Games Services, Sign in with Apple or when taking a more high-level approach, PlayFab login services. For cross-platform authentication, services like Facebook Login could be used. The login should be incentivised by explaining users the advantages of cloud-saved inventory and cross-platform support.
Restrictions
The maximum length of user identifiers is 100 characters. Additionally, an app user identifier should not contain or be equal to the following strings: (empty string), null, voided.
Expiration
Each user can access its inventory for the duration stated in the plan. The expiration date is reset when adding new transactions to the user's inventory. With no further interaction, the user record is deleted on the expiration date.
So, if the user is doing a purchase at least every few months, its record will not expire. Although consumable purchases are not stored in user inventory, they will also extend the expiration date, if the record contains at least one active product. To ensure a continuous storage in a subscription based application, the storage duration should be equal or longer than your maximum subscription cycle.
You should consider switching to a CUSTOM plan in case you are offering subscriptions with a renewal cycle longer than the default storage duration, or if you expect a multi-year usage period for non-consumable in-app purchases.
After its expiration, products can be re-added to the user inventory by invoking the native restore transactions workflow and validating receipts again.