Email branding

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.

Paywall branding

The look of the paywall can be easily modified to better fit your brand.

This is done via branding themes created in the Branding section of the InPlayer Dashboard.

Creating a new branding theme

To create a new branding theme, login to your InPlayer Dashboard, and go to Settings.

Go to the Branding tab.

Click on New theme.

You can now start customizing your theme.

Name

First, name your theme at the top.
A name would usually be your company’s brand name or your current project’s name.

Upload a thumbnail

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.

Elements and Button configuration

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.


Preview templates

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.

Logo

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.

Paywall and Button configuration

Here you can set the paywall’s primary color, as well as the color for the buttons.

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.

Enable dark mode

This feature lets you activate a dark theme for the paywall.

Once you are done setting everything up, click Save at the top right.

Editing a theme

To edit an already existing theme, just go to the Branding tab, and click on the theme you wish to edit.

This will open the theme and you will be able to modify it to your liking.

Setting a theme as default

To set a theme as the default theme, just go to the Branding tab, and tick the Make default box on the theme you wish to use as default.

Choosing a theme per asset

In addition to having one default theme, you can also create multiple branding themes, and choose which one to use for which individual asset.

To do this, just select the branding theme you wish to use while you are getting the embed code for the asset.

If you’ve decided to use the default theme, just select none in the dropdown menu.

This concludes our guide.

If you have any questions, don’t hesitate to contact us at clients@inplayer.com.

Webpage protection

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.

InPlayer + Zoom

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.

Before you start

Before you begin, make sure you have the following:

Setting up the Livestream event

First, you need to create your Livestream event.

If you don’t have a Livestream account, just send us an email at clients@inplayer.com. We got you covered.

If you do have a Livestream account, proceed to create your event. If you need help with this, just follow this guide.

Once you’ve created and published your Livestream event, it’s time to create your InPlayer asset.

Setting up the InPlayer asset

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.

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.

Starting the livestream

Start the Zoom meeting.

Click on More and then on Live on Custom Live Streaming Service.

Once the livestreaming starts, you will see a message in the top left corner of the Zoom window, informing you that you are now LIVE.

When you wish to stop the livestream, click on More again, and on Stop Live Stream.

That’s it!

Using a pre-recorded Zoom meeting

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.

Migrations

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.

Viewer account migration

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.

Content entitlement (Access) migration

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:

  • user_id – Viewer Account ID
  • item_id – Asset/Package ID
  • starts_at – Access Start Date
    • Data format – YYYY-MM-DD HH:MM:SS
  • expires_at – Access End Date
    • Data format – YYYY-MM-DD HH:MM:SS

Subscription migration

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.

Web migrations

Stripe (Card, iDeal, Direct Debit)

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.

Important considerations

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:

The CSV file should contain the following columns:

  • account_id – Viewer Account ID
  • account_email – Viewer Account Email address
  • account_uuid – Viewer Account UUID
  • stripe_customer_id – ID from Stripe (cus_xxxx)
  • trial_days – Number of remaining days between the migration date and the next billing date
  • access_fee_id – Price ID from the InPlayer system
  • payment_method – The method used for starting the subscription
    • card, ideal, SEPA
  • referrer – Website where paywall will be embedded/hosted
    • Information needed for handling SCA (Strong Customer Authentication) 
  • return_url – Website where paywall will be embedded/hosted
    • Information needed for handling SCA (Strong Customer Authentication) 

The processing time will depend on the proximity of the first upcoming development cycle.

PayPal

If you have your own PayPal account, subscriptions will remain there and the InPlayer platform will be connected with them.

Important considerations

  • 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
  • branding_id – InPlayer branding theme ID

In-App migrations

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.

Android (Google Pay)

The CSV file should contain the following columns:

  • account_id – Viewer Account ID
  • product_name – the product ID from the Google play store
  • receipt – subscription receipt from the Google play store
  • next_rebill_date – The next billing date
  • Package_name – The name of the application in the Google Play Console (for example, ‘com.some.thing’)

iOS (Apple Pay)

  • account_id – Viewer Account ID
  • access_fee_id – Price ID from the InPlayer system
  • product_name – the product ID from the Apple store
  • receipt – subscription receipt from the Apple store
  • payment_providerApple InApp Acc (fixed value) 

Roku

  • account_id – Viewer Account ID
  • receipt – subscription receipt from the Roku store
  • item_id – Asset/Package ID
  • access_fee_id – Price ID from the InPlayer system

Amazon

  • account_id – Viewer Account ID
  • receipt – subscription receipt from the Amazon store
  • amazon_user_id – User ID from Amazon
  • item_id – Asset/Package ID
  • access_fee_id – Price ID from the InPlayer System

Data flow (delivery)

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.

Post-migration

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.

Amazon

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.

Setting up Amazon payments

You can find a full guide on setting up the Amazon payment flow here.

For payment and subscription management details check out this article.

Viewer experience

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.

If you have any questions, don’t hesitate to contact us at clients@inplayer.com.

Roku

Our platform supports in-app payments for Roku which means you can integrate the paywall in your Roku apps and sell your content there.

Enabling Roku payments

If you wish to enable Roku payments on your InPlayer account, just send us an email at clients@inplayer.com or contact your InPlayer account manager.

Setting up Roku payments

You can find a full guide on setting up the Roku payment flow here.

For payment and subscription management details check out this article.

Viewer experience

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.

If you have any questions, don’t hesitate to contact us at clients@inplayer.com.

iOS

Our platform supports In-app payments for iOS which means you can integrate the paywall in your iOS apps and sell your content there.

Enabling iOS payments

If you wish to enable iOS payments on your InPlayer account, just send us an email at clients@inplayer.com or contact your InPlayer account manager.

Setting up iOS payments

You can find a full guide on setting up the iOS payment flow here.

For payment and subscription management details check out this article.

Viewer experience

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.

Android

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.

Setting up Android payments

You can find a full guide on setting up the Android payment flow here.

For payment and subscription management details check out this article.

Viewer experience

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.

PayPal

Enabling PayPal

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.

Viewer experience

This is the experience a viewer will have when making a PayPal 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 PayPal as their payment method.

If they have a voucher, they will be able to enter it at this point.

They click PAY.

They are forwarded to the PayPal login screen and prompted to log into their account and confirm their payment.

Once the payment is completed, PayPal redirects them back to the content page.

The paywall on the page disappears, and they are presented with the content.

They receive an email with the payment confirmation.

PayPal account management

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.

Credit Card

Supported cards

Our payment processor is UK-based, which means that the following major credit and debit card brands are supported:

  • Visa
  • Master Card
  • American Express
  • Discover
  • Diners Club
  • UnionPay
  • Cartes Bancaires

The following credit and debit card brands are not supported:

  • JCB

Enabling credit card payments

If you wish to enable credit card payments on your new InPlayer account, just send us an email at clients@inplayer.com or contact your InPlayer account manager.

Stripe Connect

Our platform supports Stripe Connect, which means you can connect your own Stripe account to your InPlayer dashboard and have the funds for all viewer payments be transferred over to you in real-time.

Read this article to learn more about Stripe Connect.

Strong Customer Authentication (SCA)

Strong Customer Authentication is a new EU payment regulative ensuring additional security for electronic payments by requiring additional authentication during the payment process.

As per the SCA regulation, EU viewers paying via our platform might, in some cases, be required to further confirm their initiated payment by using something they know (password), something they own (phone), or something that is a part of who they are (fingerprint). The authentication process happens outside of our paywall, in a third-party website or application provided by the viewer’s bank.

Note that the SCA will not be used for all payments, but instead, will depend on the policy of the viewer’s bank or card issuer.

SCA payment flow

This is the flow of a payment for which the SCA has been triggered:

  1. Viewer clicks the BUY button on an asset on your website.
  2. Viewer selects the price option.
  3. Viewer selects the Credit Card payment method.
  4. Viewer enters their card information.
  5. Viewer concludes the payment by clicking the PAY button.
  6. The SCA authentication page is shown, where the viewer need to complete the SCA authentication.
    • An email is also sent to the viewer informing them that they need to complete the SCA authentication, with a link to the SCA authentication page.
  7. Viewer completes the SCA authentication. They have 24 hours to do so.
  8. Viewer is automatically returned to the content page, and the content is presented.

In case the viewer doesn’t complete step 7 right after purchase, they can always go to the email that was sent to them in step 6, and complete the SCA authentication from there. The flow for this is the following:

1. Viewer opens the email with the SCA authentication info.
2. Viewer clicks on the button or link asking them to complete the SCA.
3. Viewer is taken to the content page. If they are not logged in, they are asked to log in.
3. The SCA authentication page is shown.
4. Viewer completes the SCA authentication.
5. Viewer is automatically returned to the content page, and the content is presented.

For SCA-affected auto-renewal payments of ongoing subscriptions, an email will be sent to the viewer informing them that they need to complete the SCA authentication. Until they do so, their access to the content will be stopped.
If the viewer does not complete the SCA authentication within 30 days, the subscription will be canceled. Note that the 30 days is only for re-bills. For the primary payment (as well as for one-time payments), the period is 24 hours, as stated above in the SCA flow steps.
Until the viewer completes the SCA authentication, they will be asked to pay again each time they click on the asset they are trying to purchase. The payment on which they complete the SCA authentication will be the one for which they will be charged.

For subscriptions where a free trial is available, the first SCA authentication will be triggered after the free trial period has concluded and it is time for the first subscription payment to be drawn. Just like in the above-mentioned case, an email will be sent to the viewer informing them that they need to complete the SCA authentication. Until they do so, their access to the content will be stopped. Until the viewer completes the SCA authentication, they will be asked to pay again each time they click on the asset they are trying to purchase. The payment on which they complete the SCA authentication will be the one for which they will be charged as the first payment of their subscription. However, they will not receive a second free trial once they have used up the free trial on their original payment.

Viewer experience

This is the experience a viewer will have when making a credit card 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. If they have a voucher, they will be able to enter it at this point.

They enter their card information and complete the purchase by clicking on PAY.

The paywall disappears, and they are presented with the content.

They receive an email with the payment confirmation.

Credit card management

Viewers that have active subscriptions are able to change the credit card on which they are being charged.

To do this, they can go to the viewer account details menu in the bottom right corner and click on Card details.

Note that if you’ve created a custom My Account button on your page, the viewers would need to go there to access their details.

In the Card details, they can update their card info.

The viewers’ credit cards are saved on their account per-currency. This means that if you are selling content using multiple currencies, the viewers will have a separate credit card record for each currency in which they have made a purchase, even if they’ve used the same credit card.

This concludes our guide.

If you have any questions, don’t hesitate to contact us at clients@inplayer.com.

Payment setup

Default payment and outpayment setup

By default, each new InPlayer customer account is connected to our own payment processor.

This means that all viewer payments will be collected by us.

At the end of each month, our finance team will begin the outpayment process to transfer all the collected funds, minus our fees, to your bank or PayPal account.
This usually takes about 30 days.
For example, the funds from January will start getting processed at the beginning of February and will be transferred over to you at the end of February.

Note that Direct Debit and iDeal are only supported after you’ve connected your own Stripe account to your InPlayer account via Stripe Connect. More on this below. They cannot be used while your InPlayer account is connected to the default InPlayer Stripe account.

Using Stripe Connect

If you have your own Stripe account where you can receive credit card and direct debit payments, you can choose to have it connected to your InPlayer account. In this way, all Credit card, Direct Debit, and Google/Apple Pay for Web payments will go directly to your Stripe account, eliminating the need for the default outpayment process described above.
This is a great alternative because you will be receiving all your earnings in real-time.

To learn more about how to set up Stripe Connect, make sure to read this article.

Note that real-time transfer of funds to your bank account is only possible for Credit card, Direct Debit, and Google/Apple Pay for Web payments. For doing this with PayPal payments, contact us at clients@inplayer.com.


VAT

As stated here, the VAT on digital content is calculated from the end-user country of residence when selling in the EU (e.g. If the user lives in Sweden, Swedish VAT should be applied). For services provided to end-users outside the EU, VAT is not being charged.

For the UK, you can use the VAT MOSS to report the sales you made in each country quarterly and pay VAT through the system. The government then distributes the VAT to each EU country.

This concludes our guide.

If you have any questions, don’t hesitate to contact us at clients@inplayer.com.