The InPlayer system integrates with native apps (the iOS 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 iOS 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.
Our native SDKs also provide you with the register and login methods for iOS, necessary for authenticating users to our system.
To learn more of the methods in play, please refer to the following guide:
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 Apple 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 iOS:
public static func validate( receiptString: String, productIdentifier: String, success: @escaping ()-> Void, failure: @escaping (_ error: InPlayerError) -> Void )
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 Apple 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 whole purchase process is completed, the InPlayer system responds with a confirmation and an object returning the premium content which can be used by the native app to display it 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 static func subscribe( onStatusChanged: @escaping ( _status: InPlayerNotificationStatus) -> Void, onMessageReceived: @escaping (_ notification: InPlayerNotification) -> Void, onError: @escaping (_ error: InPlayerError) -> Void )
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.
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
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: