Similar to branding the paywall, you can also add your brand to the automated emails that are being sent to viewers when they create their accounts, make payments, change their passwords, and do other actions on the paywall.
It is always recommended to brand your emails, to make sure they are easily recognized by your audience.
To do this, just contact your account manager, or send us an email to clients@inplayer.com, letting us know how you would like your emails to look like.
As a reference, here is an example of the default, InPlayer-branded email a viewer will get when they make a payment.
If you have any questions, don’t hesitate to contact us at clients@inplayer.com.
You can choose to upload a default Thumbnail. This is going to be the default cover image for your assets, however, you can still set a custom thumbnail for every individual asset.
Here you can choose to either enable or disable the Top border and Protection label on the assets, as well as pick a background and text color for the Buy button on the assets.
The Button configuration colors under the PREVIEW CONFIGURATION tab will also be applied on the viewer account menu that appears on the page after a viewer logs into their account.
The default position of the viewer account menu is in the bottom right. You can change this to the bottom left in the Advanced embedding section of your asset’s embed code in the InPlayer Dashboard.
Here, you can choose the default preview style for your assets on which this branding theme will be applied.
Note that after you set a preview template here, you will also need to make sure to check the Use default branding preview template option within the Preview template settings of the assets themselves. You can use a different preview template for an asset, even if you’ve set one up here in the branding.
Similar to the Restriction settings, a preview template that has been set up directly in the settings on the asset itself will overwrite the one that has been set up in the Branding theme settings.
Here you can upload the logo that will be shown on the paywall. You can also set the background of the logo banner, as well as see a preview of how the logo will appear on the paywall.
If you upload a logo, but you do not wish the logo to appear on the paywall for some assets, you can disable it via the “Hide logo from branding theme” option in the Advanced embedding section of your asset’s embed code in the InPlayer Dashboard.
This is where you can insert a link to your own Terms and Conditions page that would replace the default InPlayer one on the registration screen.
This feature is not activated by default, so if you wish to use it, make sure to send us an email at clients@inplayer.com, or contact your dedicated account manager.
Using InPlayer, you can not only protect individual pieces of content embedded on your webpage, but also the entire webpage. With this setup, viewers will have to authenticate before they can access your webpage.
To learn all about protecting an entire webpage with the InPlayer paywall, have a look at the full documentation here.
If you have any questions, don’t hesitate to contact us at clients@inplayer.com.
Zoom is perhaps the most widely used online meeting tool. One of the coolest features in Zoom is the ability to livestream your meetings and conferences, thereby reaching a massive online audience.
InPlayer’s market-leading monetization platform is the perfect accompaniment to this, for everyone who wishes to monetize and get the most out of their Zoom conferences.
When creating the InPlayer asset, make sure to use the HTML asset type. If you need help with the asset creation, just follow our guides.
During the asset creation, when it’s time to fill in the Content section, go to your Livestream event, and copy the embed code for it. Check out this guide if you need help finding the embed code. Once you copy the Livestream embed code, paste it into the Content section of the asset, and click Save.
After you finish setting up the asset, make sure you’ve saved everything, and proceed with the third and final step: setting up the Zoom meeting.
With this step, you will schedule your Zoom meeting and set up the livestreaming settings for it.
First, schedule your Zoom meeting. If you need help with this, check out this guide.
Once your meeting is scheduled, go to your Meetings page and open the meeting.
Scroll all the way down to the Live Streaming section, and click on configure live stream settings.
On the new screen, you will need to add the Stream URL and Stream key from the Livestream event, as well as the Live streaming page URL, which is the page where people will watch your conference, i.e. the page on which you’ve embedded your InPlayer asset.
To get the Stream URL and Stream key, do the following:
Go to your Livestream dashboard and open the Livestream event for the Zoom conference.
In the Edit menu on the right, go to Live Tools.
Under RTMP Input, click on GET LINK.
Here, you will find the Stream Key and Stream URL.
Copy them and paste them in Zoom.
In the Live streaming page URL field, paste the URL of the webpage where you’ve embedded your InPlayer asset, i.e. the webpage where your audience will need to go to watch the conference.
Finally, click Save.
And that’s it. Your meeting is now ready for livestreaming.
If you wish, you can also monetize a pre-recorded Zoom meeting.
For that, you will just need the video of the meeting, and an OVP (Online Video Platform) account where you can upload the video. If you have the video, but don’t have an OVP account, just send us an email at clients@inplayer.com telling us about it. We’ll sort things out for you.
Once you have the video uploaded, you can just create your InPlayer asset like you normally would, put the video inside the asset, and embed the asset on your webpage.
If you have any other questions, don’t hesitate to contact us at clients@inplayer.com.
Our platform facilitates a quick and secure viewer data migration, including migration of the viewer payment details and subscriptions. This enables you to transfer your viewers over to InPlayer without interrupting their access or making them re-purchase their passes.
Specific migration flows are determined by the payment processor subscribers used to make a payment, and the ETA for the completion of a migration varies from processor to processor. (Stripe, PayPal, Apple IAP, Google IAP, Roku IAP, Amazon IAP, etc).
We highly recommend discussing the migration strategy beforehand with your dedicated account manager, who will be in charge of the migration process. This is so that you can understand what is possible with respect to the various platforms on the market.
The migration process also includes support from our engineering team, and alignment with our development cycles.
This article provides a general breakdown of the usual migration process. To discuss any details, make sure to contact your InPlayer account manager, or send us an email at clients@inplayer.com.
This migration consists of importing and creating viewer accounts from the previous provider in the InPlayer platform.
The processing time will depend on the proximity of the first upcoming development cycle.
When migrating user accounts, the following viewer information is required.
Your InPlayer account ID. You can find this in the Account details section of your InPlayer dashboard.
Viewer data.
(only when providing viewer account passwords) The type of encryption. The supported encryption types are included below.
The viewer data should be delivered in a CSV file. The CSV file should contain the following columns, arranged in the following order:
email
full_name Note that if your report has two separate columns for the first and last name, you should merge them and fill in the full name in the full_name column.
password (leave empty for no password) The following encryptions are supported
bcrypt
unsalted md5
unsalted shal InPlayer uses bcrypt encryption, so this is a preferred encryption format.
Any other viewer metadata you want to transfer over from the previous platform provider (ex. User ID). The names for these columns could be anything but shouldn’t contain any empty spaces between words (use _ instead). Example: primary_home_address. The purpose of having this piece of information is so you have one extra method of easily matching the InPlayer viewers with their subscription data in the old platform, should you ever need to do so.
If you are unable to provide the viewer passwords for whatever reason, or if the password encryption of your old platform is anything other than bcrypt, unsalted md5, or unsalted sha1, we can still migrate the accounts, but they would need to set up new passwords when logging in for the first time, by using the “Forgot password” button. Note that we do not support salted password encryptions.
This migration consists of granting access to viewer accounts that have already been created either as part of the viewer account migration or in some other way.
The processing time will depend on the proximity of the first upcoming development cycle.
For this migration, the following viewer information is required. The viewer data should be delivered in a CSV format.
List of viewer accounts (InPlayer viewer account ID or email) that need to be granted access,
The assets or packages to which access should be granted,
Access expiration date for each viewer. If you are unable to provide the individual access information for whatever reason, we can simply grant all viewers the same access that will be set to expire on a certain date.
The CSV file should contain the following columns:
This migration is the most complete one since it provides a seamless transition of your viewers’ subscriptions from your old platform to InPlayer.
This enables you to keep charging your viewers without interruption and without asking them to provide their payment details again.
Before we start, we need to know:
Which card provider did you use thus far?
What kind of PayPal integration did you have thus far?
Are you able to determine which payment details belong to which viewer?
There are two scenarios for this migration, depending on the payment processor that was used on your old platform. They are Web migrations and In-App migrations and are described below.
With this migration the following points should be kept in mind:
Only viewer payment details can be migrated between payment processors and not the actual subscription records with their historical data. Once the payment details are migrated, InPlayer creates new subscription records for the viewers with a free-trial period until the next rebill date.
You shouldn’t cancel any subscriptions on the old payment processors until the migration is complete on InPlayer’s end.
When the migrated subscriptions are being created in the InPlayer platform, the free trial and subscription creation emails viewers would normally get will be disabled so viewers will not get notified about the creation of their new account and subscription. This is to make the transition as seamless as possible. But this could be changed upon your request.
Below is a breakdown of the migration process depending on the payment processor that was used on your old platform.
Stripe is the credit card payment processor used by InPlayer. If you have your own Stripe account, subscriptions will remain there and the InPlayer platform will be connected with your Stripe account via the Connect feature.
If you use another credit card payment processor (ex. Adyen), it is strongly recommended that you first create your own Stripe account and schedule a migration between the two payment processors, as outlined here, and then proceed with the InPlayer migration.
Regardless of the payment processor used, before you work on the CSV migration file, it is important to confirm that your Stripe customers (i.e. InPlayer viewers) have default payment details (default payment source/card details) set on Stripe).
If not, please make sure to have them set up.
Note that in the below points the term “customer” signifies InPlayer “viewer”. “Customer” is used only for clarity’s sake since that is the terminology used in Stripe.
If the previous platform provider does offer that option, have it set for all customers.
Ask your developers to update the customer and update the default payment method, using these instructions:
Make sure that the message encoding is set to UTF-8, so special characters, such as ä, æ, å will not be encoded as odd symbols ($±@). Guidelines on how you can update those settings are presented here.
Make sure that the existing subscriptions are subscription payments, as the recurring payments are not supported by the InPlayer system.
This information can be found in one of the messages from the Instant Payment Notification (IPN) history.
When you open the Instant Payment Notification (IPN) details from a single transaction you will locate the IPN Message. Search for the txn_type value. If the txn_type is subscr_payment, we can proceed with the migration. But if the txn_type is recurring_payment, the migration cannot be done.
The CSV file should contain the following columns:
account_id – Viewer Account ID
access_fee_id – Price ID from the InPlayer system
transaction_id – last transaction ID from PayPal.
billing_agreement_id – the subscription ID from PayPal
next_rebill_date – Next billing date
Date format – YYYY/MM/DD HH:MM:SS
buyer_email – PayPal email the viewer subscribed with
Migration of subscriptions started via mobile apps is a process of validating the transactions made through the In-App payment processors. Before planning the In-App migration, it is necessary to first complete the integration with the respective In-App platform in the InPlayer platform.
When you have the migration files ready, they should be shared with your InPlayer account manager in a secure way. The easiest way to transfer the data is to use either:
Google/One Drive.
Should you decide to go that route, set the field as encrypted and invite your account manager to the drive folder.
Use of a data exchange system (i.e. www.box.com), or
a secure transfer method (SFTP)
Once the CSV files are received, your migration will be scheduled depending on dev resources availability and the proximity of the first upcoming development cycle.
After the migration is complete, remove any subscription records from the previous platform to prevent it from continuing to charge viewers. This will ensure viewers are not charged twice as they will now be charged via InPlayer.
To discuss further details of the migration process, make sure to contact your InPlayer account manager, or send us an email at clients@inplayer.com.
Our platform supports in-app payments for Amazon which means you can integrate the paywall in your Amazon apps and sell your content there.
Enabling Amazon payments
If you wish to enable Amazon payments on your InPlayer account, just send us an email at clients@inplayer.com or contact your InPlayer account manager.
The viewer experience of purchasing an InPlayer asset via your app is exactly the same as the experience of making a regular In-app payment.
There are no extra steps to follow. The viewer just follows your app’s regular payment flow.
Note that the viewers always need to log into the app where they watch the content with the same account as the one they used to purchase the content originally.
If you have any questions, don’t hesitate to contact us at clients@inplayer.com.
Our platform supports in-app payments for Android which means you can integrate the paywall in your Android apps and sell your content there.
Enabling Android payments
If you wish to enable Android payments on your InPlayer account, just send us an email at clients@inplayer.com or contact your InPlayer account manager.
The viewer experience of purchasing an InPlayer asset via your app is exactly the same as the experience of making a regular in-app payment.
There are no extra steps to follow. The viewer just follows your app’s regular payment flow.
Note that the viewers always need to log into the app where they watch the content with the same account as the one they used to purchase the content originally.
If you have any questions, don’t hesitate to contact us at clients@inplayer.com.
iDEAL is an online payment method used in the Netherlands that enables consumers to pay online through their bank, which makes iDEAL somewhat similar to Direct Debit. Payments are made via bank app or online banking
iDEAL is the most popular method for online payments in the Netherlands, well beyond credit card use, and constitutes over half of all Dutch online payments.
iDEAL only supports payments made in the Euro currency.
Direct Debit (SEPA) is a payment option where the viewer can make a purchase by transferring funds straight from their bank account, without the need of a credit card.
This can be very useful if a significant part of your viewer base are people who are not likely to have credit cards or are simply not in the habit of using them.
Our system uses SEPA Direct Debit via Stripe to process all Direct Debit transactions. This system has two limitations. These are:
Direct Debit can only be used by viewers in countries that belong to the SEPA zone.
Direct Debit can only be used for transactions in the Euro currency. This means that the asset price set up in the InPlayer Dashboard will need to be in Euros, and also, the viewer’s bank account will have to be Euro-denominated, i.e. support transactions made in Euros.
When using Direct Debit, a very important thing to keep in mind is that due to the nature of this type of banking transaction, the first charge on the viewer’s account will not be transferred over immediately like in the case of credit card or PayPal transactions.
Instead, it will take a period of up to 14 business days for the charge to be approved and funds from the viewer’s bank account to be transferred over to the merchant. This is the mandate creation period. More on this below.
However, note that the viewer will still be granted access at the moment of purchase, just like in the case of credit card or PayPal payments. They will not have to wait for the system to complete the drawing of funds from their account.
This means that the following scenario is possible:
The viewer purchases a pass using Direct Debit.
The system verifies the bank account.
The viewer is granted access to the content.
The viewer watches the content.
After 14 business days or less, the system gets a notification from the bank that the viewer did not have enough funds for the purchase, or the viewer decides to cancel the charge.
The system revokes access to the content. We are left with a situation where a viewer has had access to the content for a time, potentially watched what they wanted to watch, but they have ultimately ended up not paying for it.
For this reason, Direct Debit is more suitable for subscriptions i.e. auto-recurring payments, than it is for Pay-Per-View, i.e. one-time payments that grant access to content for a certain amount of time.
However, our system does not restrict your use of Direct Debit in any way, and you are free to use it for any payment type you wish.
Note also that once a viewer approves the mandate on the first charge, all subsequent charges (in cases of a subscription for example) will happen in real-time and without delay.
The payment records for Direct Debit purchases will be created on the date the system has successfully drawn funds from the viewer’s bank account. Until then, the records will be shown as pending.
This means that a Direct Debit purchase that was done at the end of the month can potentially be recorded as a purchase in the next month.
You can learn more about payment statuses in this article.
For every direct Debit transaction, the viewer will get both a notification email from InPlayer (which can, of course, be white-labeled), and a bank statement from their bank.
The notification email will contain the details of the content the viewer has purchased, including the title of the purchased asset.
However, the bank statement will only contain the name of the company to which the payment has been sent.
This company name will always be A&L Goodbody. A&L Goodbody is a law firm that regulates the SEPA Instant Credit Transfer Scheme.
This too will be clearly stated in the purchase confirmation email the viewers will receive so there is no confusion.
Direct Debit (SEPA) payments can be disputed for up to 8 weeks from payment, including after a payment has been refunded. If a refunded payment is later disputed, the funds will be returned to the viewer twice, resulting in a loss, and cannot be recovered without their cooperation.
Due to this, we do not process refunds for Direct Debit payments, nor do we suggest that you process them via your own Stripe dashboard. Instead, it is best that viewers are advised to submit a chargeback request to their bank.
Note that Direct Debit is only supported after you’ve connected your own Stripe account to your InPlayer account via Stripe Connect. More on this here. It cannot be used while your InPlayer account is connected to the default InPlayer Stripe account.
If you wish to enable Direct Debit payments on your InPlayer account, just contact your InPlayer account manager, or send us an email at clients@inplayer.com.
As usual, the transaction fees and revenue share for Direct Debit viewer transactions are determined by the agreement signed between you and InPlayer.
This is the flow of a Direct Debit viewer payment:
Viewer clicks the BUY button on an asset on your website.
Viewer selects the price option.
Viewer selects the Direct Debit payment method.
Viewer enters their bank information (Full Name and IBAN number). With this step, the viewer is granting InPlayer permission to draw funds from their account. This is called creating a mandate. No funds are drawn at this stage. Once a viewer successfully creates a mandate once, they will not have to do it again for any future Direct Debit payments made with the same account. Instead, they will be automatically forwarded to the final payment screen. Also, all future payments will be drawn from the viewer’s account immediately, without the need for the 14 days waiting period. This period is only for the approval of the mandate during the initial purchase.
The system immediately checks the validity of the viewer’s IBAN.
If the IBAN check is successful:
Viewer can confirm the creation of the mandate.
Viewer is presented with the final payment screen, where they can confirm the purchase.
Viewer confirms the purchase.
The paywall disappears, the viewer is granted access to the content, and the content is displayed.
Viewer receives a confirmation email informing them that their purchase was successful, but that the funds are yet to be withdrawn within 14 business days, i.e. as soon as the mandate creation is confirmed. For subscriptions, the viewer will always get a notification email before each recurrent charge, informing them that a Direct Debit transaction will be done on their account in the following days. This is a legal requirement.
If the IBAN check is unsuccessful:
Viewer gets an error informing them that the check was unsuccessful. They can try again, or choose another payment method.
Provided the viewer has completed the purchase successfully, the system has up to 14 business days to confirm the mandate creation and draw the funds from the viewer’s bank account.
If the mandate creation is successful and if the viewer’s bank account has enough funds at this time:
The funds are drawn and the viewer keeps their access.
Viewer receives an email informing them that a charge has been done on their bank account. With this, the transaction is concluded.
If the mandate creation is unsuccessful and/or if the viewer’s bank account doesn’t have enough funds at this time:
Nothing is drawn and the viewer’s access is revoked.
Viewer receives an email informing them that a charge could not be done on their bank account and that their access is revoked as a result. In the case of a subscription, the subscription will be canceled as well.
This is the experience a viewer will have when making a Direct Debit purchase.
Once they go to your webpage, they click the BUY button on the asset.
They log into their account (or sign up for a new one).
They choose the pass they wish to purchase and click NEXT.
They are forwarded to the final payment screen where they select Direct Debit as their payment method.
If they have a voucher, they will be able to enter it at this point.
They enter their name and IBAN number and click CREATE MANDATE.
They get a message confirming the successful mandate creation.
The paywall disappears, and they are presented with the content.
They receive an email informing them that their purchase was successful, but that the funds are yet to be withdrawn within 14 business days.
As soon as our system confirms the drawing of the funds with the bank, the viewer will get another email informing them that the charge has been successfully done on their account.
If the drawing of the funds fails, the viewer will get an email informing them that the charge has been unsuccessful and that their access has been revoked as a result.
For subscriptions, the viewer will always get a notification email before each recurrent charge, informing them that a Direct Debit transaction will be done on their account in the upcoming days.
Once a viewer connects (mandates) one bank account, they will not be able to change it. The only way to do this would be for them to register a different account on the paywall.
This concludes our guide.
If you have any questions, don’t hesitate to contact us at clients@inplayer.com.
If you wish to enable PayPal payments on your InPlayer account, just send us an email at clients@inplayer.com or contact your InPlayer account manager.
Once a viewer purchases a subscription using one PayPal account, they will not be able to change it. The only way to do this would be for them to cancel their ongoing subscription and purchase it again using the new account.
This concludes our guide.
If you have any questions, don’t hesitate to contact us at clients@inplayer.com.
