Android In-App Purchases

The InPlayer Platform facilitates the payment process by providing in-app purchases (IAPs) as a valid payment method i.e. by supporting payments carried out inside native Android or TV applications. In-app purchasing allows you, as a merchant, to supply your customers with special offers (extra features or premium content behind a Paywall) within an application, as a way of providing a cross-platform monetization flow, directly on their TV or on their Android device.

Below, you can find described all the steps our Platform undertakes, in order to enable Android in-app purchases.

Proceed here to take a look at our fully equipped Android SDK.

Integration#

The InPlayer system integrates with native apps (the Android app in this case) on the end-users’ mobile devices, as a way to support the in-app payment process. For that purpose, in our merchant panel you will be provided a UI for specifying the required parameters for integrating the Android ecosystem.

You can find the dedicated integration page here.

For a more detailed and visual representation of the integration set-up, click here.

Once the integration is set up and you have your merchant offers created, you can then proceed with the implementation of the in-app payment process.

Application Development Steps#

As an InPlayer Merchant, you should use our native SDKs for the purposes of the application development. The SDKs provide methods for given functionalities and enable the communication between the application and our system. These specific functionalities include authentication, in-app payment, and subscription.

Authentication#

Our native SDKs also provide you with the register and login methods for Android, necessary for authenticating users to our system.

To learn more of the methods in play, please refer to the following guide:

In-app Authentication

In-app Payment#

The in-app payment is a separate functionality and should be implemented independently, by your app developers.

To begin with, the value of your offers (= payment options) is vital in making the payment process work. An offer ID should be created both in our platform and in the native app ecosystems, whereas for the Android implementation, each offer is called a 'product' which equals to an 'access fee' (= price) in the InPlayer system. When you create products in the native ecosystem, make sure to have the product IDs constructed in the following format:

<asset id>_<access fee id>

According to this product/access fee correlation, by purchasing one product from a native ecosystem, the end-users are in fact purchasing one price from our system. As a merchant, you need to make sure that you have entered the accurate value as a product ID and then forward this information using the validate method of our native SDKs (illustrated below). This is crucial for having both the payment and access records entered in our system correctly, as well as for ensuring that your end-users will enjoy a cross-platform access on different devices for the purchased content.

The validate method for Android:

public void validate(
    java.lang.String receipt,
    java.lang.String productIdentifier,
    InPlayerCallback<java.lang.String,com.sdk.inplayer.model.error.InPlayerException> callback
)

To enable in-app payment, the application should communicate the payment information with the InPlayer system via the native SDK libraries. More specifically, the in-app payment process ends with a receipt generated by the native Android system. Thus, via the validate method in our SDK libraries, this payment receipt is to be forwarded to the InPlayer system.

Once our system receives this payment information, as a protection measure, it engages into validating that the receipt is both existing and valid in the native ecosystem (the communication with the native ecosystem is done via the parameters entered during the initial integration process). After the validity of the receipt is confirmed, our system will create and store all the relevant information regarding the in-app payment. More precisely information for:

one-time payments - for which our system will store transaction records;
subscription payments - where for initial payments, our system will create a subscription record and store a transaction record concerning that subscription;
access records - regardless of the type of payment, the final step in the process is granting and writing access records in our system (these access records determine the duration period of an access entitlement for the purchased premium content to the paying customer).

Once the purchase is done, the InPlayer system confirms the payment and returns an object containing all the data the native app needs to display the premium content to the entitled end-user. This success notification is sent via socket. The sole purpose of the socket is enabling communication between the native application and the InPlayer system. The creation of the socket is enabled by the subscribe method that our native SDKs provide. We can view this socket as an open pipe between the app and our backend system. After successful payment, our backend sends the success notification via this ‘pipe’.

The subscribe method for success notification:

public void subscribe(InPlayerNotificationCallback callback)

Subscription Recurring Charges#

When subscription is created via in-app purchase, our backend communicates with the native ecosystem to check and confirm whether a rebill has been successfully issued and paid. This is done independently from the native application and all the rebill transaction and access records related to them will be automatically created by our system.

Reporting and Management Functionalities#

In addition to the support for implementing payments, the InPlayer system features additional reporting and management functionalities related to the payment actions that our system offers.

Reporting#

Our system provides payment reports, subscription reports and asset access reports that you can generate as a merchant. Each report renders details for each record. During the in-app payments, these records are being stored in our system, therefore, you have the reports available for usage.

Regarding the type of records that concern you, proceed to the following link(s):

Payments - https://dashboard.inplayer.com/transactions/payments
Subscriptions - https://dashboard.inplayer.com/transactions/subscription
Access records - https://dashboard.inplayer.com/access

Management#

In the case of in-app payments, the actions to be taken depend on the ecosystems themselves and the extent to which they allow external control over payments and subscriptions created in their systems. At the moment, there is a supporting functionality for subscription, more specifically for subscription cancellation which enables you to cancel subscription for some of your Android users.

As part of the management section of the platform, our system supports a specific type of voucher called in-app voucher. To learn more of the in-app voucher, please refer to the following guide:

In-app Voucher