Overview

Seamless payments on mobile and TV apps (in-app purchases) enrich your portfolio with yet another payment method for your services. Customers can purchase access to your content directly from inside your native applications. It ensures a frictionless checkout experience without being redirected to the web. It also provides added value to you.

When you enable in-app purchases you gain:

• multi-access for your users - they can use your services on many devices

• enhanced reporting for you - all-in-one-place reporting that can support your subscriber retention analytics and strategy building.

Note: ChurnIQ Dashboard relies on in-apps receipts for reporting.

It’s important to note that when you make a purchase through in-apps, Cleeng does not handle your payment. Cleeng acts as an observer and tracks in-app purchase lifecycle events to gather data to make it available for analysis.

The table below shows which in-app purchases Cleeng supports. Choose the one you are interested in and follow to the integration guide.

In-App Default Flows

The section below outlines the recommended process for integrating in-app purchases with Cleeng, including default app and user flows:

• App flow
• User flow

App Flow

See below for the default app flow.

Here is the description of the app flow above:

Depending on how you integrate with Cleeng, you will use different API:

• Core API authorized with publisherToken will be used for backend integrations (through middleware)
• MediaStore API (authorized with JWT) - for direct integrations.

1. When launched, the application checks if the user is signed in to Cleeng. A signed user will have a pair of tokens stored (JWT and refresh token). In order to validate if the user is signed in, refresh token should be used with the Refresh token API to obtain fresh JWT.
2. If the user doesn't have an account, sign-up is required. It is recommended that the application uses the Register method to register the customer (for more information, see Registration). For backend integrations Core API Register customer will be used.
3. If the user already has an account, the Login endpoint shall be used to sign in (for more information, see Login.
4. Once the user is logged in, the entitlements check follows. It is recommended that the application uses Fetch customer's subscriptions or List entitlements endpoint to check if/which content should already be available to the user.
5. Once the user selects content, it is recommended that the application uses the MediaStore API Get entitlements or Core API Get entitlements endpoint to check entitlements to the specific offer. If the user has access rights (entitlements) to the selected content, the content is displayed.
6. If the user does not have access rights (entitlements) to the selected content, it is recommended that the application uses the Fetch offers or List offers endpoint to list offers. Only offers that are available for purchase in the appstore (have the respective store productId configured) should be displayed to the user. Additionally, the offers that the users already have purchased also should be hidden.
7. The user selects an offer, and completes the purchase in the app store.
8. Once the purchase is completed in the store a synchronization request should be submitted to Cleeng via a respective store /purchases endpoint. Optionally, in order to ensure a good experience to the end user, a temporary entitlement can be granted to the user until the sync process is finished. The synchronization result will be provided via webhook or via a respective store /purchases/synchronizations/{synchronizationId} endpoint. If the purchase is synchronized successfully in Cleeng, the content is displayed. (Once the process is completed the temporary entitlement should be extended or revoked according to the result).

User Flow

See below for the default user flow.