Purchases

Preparation

Remember, you need to configure and initialize the Magify Manager to handle purchases.

Overview

InApp purchases affect the user's in-app status and paying status. Subscriptions at the same time affect the subscription status and paying status of the user. We need this to properly segment and filter users.

Magify SDK works with 3 kind of statuses:

  • InApp status - determines whether the user has purchased any in-app product;
  • Subscription status - determines the status of the user's in-game subscription;
  • Paying status - combination of the 2 statuses above determines whether the user has spent money on the game;

InApp status

This status has only two states: free and paid. A player can only switch from free to paid status after purchasing an InApp product. There is no reverse transition.

Subscription status

Magify SDK automatically provides a special service to maintain the actual subscription status: MagifyService.Subscription. Be careful when working with it to keep the status up to date.

  • The status may be changed according to the following rules:
    • Inactive → Trial ↔ Trial expired
    • Inactive → Paid ↔ Paid expired
  • Switching back to Inactive is usually not allowed;
  • A user goes into expired status when the subscription has expired and no payment has been made to renew the subscription.

API

Magify provides a wide API for handling of purchases and subscriptions. You can explore the available methods here.

Purchases validaton

Our SDK provides simple way to validate and verify purchases and subscriptions.

You can read more about it on the Validation page.

Without validation

Overview

If you have custom/external purchases validation service, you can bypass Magify's validation and send validated purchase data directly from your client or server-to-server. In this case, the responsibility for ensuring the integrity of the transactions lies on your side.

1. Sending from client

If you have the data about a valid purchase on the client side (in the application), you can pass this data to Magify, in this case this purchase will be considered valid and can be processed to create analytics repors.

We call this type of purchase tracking "trusted purchases", which implies that you have already validated your purchases and we can trust the revenue data.

To track it you need to create a TrustedPurchaseRecord data model, that contains all the necessary information about valudated transaction. We highly recommend not to use constructors of this class, but instead use static constructor methods that cover all possible and necessary for Magify events related to trusted purchases.

Trusted purchase tracking methods

To track the purchase depending on the type of it you can use following methods:

2. Server-to-Server

If you have some external or own web service responsible for purchases validation, you can send data about failed purchases directly to the Magify server. Since the current page covers only SDK (client) side work, it will not describe how to configure Server-to-server communication (you can learn more about this by contacting Magify manager). However, you should also keep in mind that on the client side you will need to make small tweaks to make the approach work correctly.

Although the purchase validity data will be sent directly to the server, the client side has to send some necessary analytics data itself, so even in this case you need to track purchases on the client side, but with a small peculiarity: after making a purchase, when creating an instance of PurchaseInfo (see IMinimalInAppStore or IInAppStore) you must set the SkipVerification flag to True. In this case Magify SDK will not request validation using Magify services. This completes the configuration of Server-to-server validation on the client side. Once the property value is set, you can continue processing PurchaseInfo and pass it on to Magify.

Related articles

ICampaign

Adjust

BonusProduct

IProductObtainer

Obtainers

MagifyManager