Anatomy of Pay-Per-View Application Development

"Only a life lived for others is a life worthwhile." – Albert Einstein

Anatomy of Pay-Per-View Application Development

What is Pay-Per-View?


Pay-per-view is a video monetization technique widely popular in television and web broadcasts, be it private or public. For private broadcasts, pay-per-view can be a crucial way to capture revenue from their content. Pay-per-view schemes are applicable to both live as well as recorded content.

The Pay-Per-View Business Model


PPV systems are mainly built with revenue collection in mind. As we know, publically free content is usually laden with ads that generate revenue to cover various types of costs associated with the broadcast. The PPV system Is usually applied to private broadcasts or add-less broadcasts so that the cost of the content is directly compensated for.

There are many businesses that leverage pay-per-view for revenue generation such as LiveJasmin, Uscreen, etc.

A lot of the PPV systems on the web earn revenues from taking a cut of the performer/broadcaster’s earnings as commission. These systems earn their commission in two primary ways:


  • Revenue from each stream
  • Payment collection/credit card processing

Pay-per-view systems are applicable to both live and recorded content. However in this article we will be only discuss PPV in ther context of bi directional live streaming.


Popular types of Pay-Per-View Applications

  • Adult one-on-one chat
  • Online astrology services
  • Online medical consultations
  • OTT Web series
  • Education classes

How does Pay-Per-View work


On the tech side of things, pay-per-view systems need to track the usage of consumers to be able to bill them appropriately. To elaborate, each user needs to hold an account with the PPV platform. Account holders might be required to have a certain amount of real/virtual currency in their account depending on platform policy.


Whenever the user subscribes to content, the server tracks the session start time. In most PPV systems the session is measured in real-time (every minute or every second). when the user stops viewing the content/exits the content, the session is marked as closed. The session information is persisted in the system’s data store for billing & analysis purposes. The real-time measurement ensures that consumers do not exceed their credit limit while watching the stream. This means the credit value is not only calculated/updated at the end of the session but also in real-time (during the ongoing session).


If the account credits are exhausted during an ongoing consumption session, the customer will immediately be notified and disconnected from the session. The customer is then allowed back into the system only after they have added/renewed their account credits.

The data persisted in the data store ensures that the business and the consumer have a detailed overview of their billing & usage.

Building a Pay-Per-View system


Let us take a look at a practical use case of a PPV system built on top of the Wowza Streaming Engine. This will help us better understand some of the concepts of a PPV system.

LOVE-CHAT APPLICATION USE CASE

OVERVIEW


The love-chat is a theoretical cam chat portal (as an example) that provides a medium for female models to entertain their customers over audio/video & text chat through a web portal interface. Customers are required to buy virtual currency using their credit cards. The virtual currency is stored against their account on the web portal. Customers can pay for the show using virtual currency & they can also buy gifts for the performers using the same virtual currency from a store that is a part of the web portal.

WEB PORTAL LAYOUT


The web portal consists of three parts – The standard website, the Payment processing/handling & the live streaming system.

STANDARD WEB PORTAL


The standard website is built using a combination of PHP on server side and HTML/CSS/JS on the client side. Some of the features & functionalities of the portal are :

  • Model Registration
  • Customer Registration
  • Login System
  • E-Shop
  • Model listing with online status indicator
  • Model Public stream page
  • Model Private stream page
  • Customer accounts page
    • Purchasing virtual currency using a credit card through a payment gateway
LIVE STREAMING


Live streaming technology is going to be the heart and soul of this PPV system. There will be two pages where the live streaming technology will be applied – the model’s public stream page & the model-customer private stream page. Both implementations will implement different streaming paradigms.


  • Model’s Public Stream uses one-to-many streaming
  • Model-Customer private stream uses one-to-one streaming

Some systems engage their customers through a web portal alone whereas some prefer to use a desktop/mobile application instead for a better & more controlled experience.

PAYMENT PROCESSING


The portal will implement multiple options for processing financial transactions. Common options should include credit cards, debit cards, wire transfers, PayPal, etc. This can be done directly through a bank’s payment processing gateway or through third-party processing services.

THE FLOW OF SYSTEM USAGE


  • Model registers on the portal, updates personal info, and uploads images
  • Business ops will verify the model information and activate the account
  • The customer registers on the portal, fills in mandatory profile info, and verifies the account through credit card or otherwise to activate the account.
  • The model will information about upcoming events/sessions (when he/she will be online and offline)
  • The system lists out all models along with their current stream status in the portal with a random image of the aspirant. Customers can click on the image to see profile information of the model and information about upcoming events/performances.
  • When the time arrives the model will use their live streaming UI to go live on the portal. The site UI will then show the model as “online“.
  • Customers can then click on the model’s image and watch the public stream.
  • If a customer wants a private session they can request the model for the same. At this point, the customer should have sufficient virtual currency in their account to be able to request a private session. The model can accept or reject the request from their UI.
  • Once accepted the customer and the model gets engaged in a new one-on-one chat session. the public stream goes offline and the public-facing view will state that the model is now in a private session.
  • The session involves audio, video, and text interactions. In between sessions the customer can also buy a gift from the e-shop and send it to the model.
  • The system deducts virtual currency from the customer’s account by the minute for the model’s performance. The session ends either when the model/customer terminates it or when the customer runs out of currency.

THE MEDIA SERVER ASPECT


Now let’s try to take a close look at the server’s aspect in all this. Which media server technology is used for building the backbone of a PPV system depends on the technology it offers. For A/V chats two-way communication is a must and that too with ultra-low latency. Whereas for simple one-to-many broadcasts, low latency HLS will be sufficient. If your consumers use mobile/tablets for the consumption of streams then RTSP protocol would be the technology of choice. A lot of PPV systems can do well with just LL-HLS.

If your server supports WebRTC, then you are already well on your way since you can then support desktop and mobile clients using the same application & technology.

The media server’s role in this context is simply to allow the publishing and subscription of streams. Which sounds quite simple on its own. However, things get interesting when you understand you are playing with money…and therefore accurate recording/management of session duration is also very important. Therefore, needless to say, these things need to be tracked on the server side and not the client side.

FLOW OF LOGIC


To better describe this let us follow up with a logic flow on the media server side.

  • The client connects to the media server & tries to subscribe to a stream
  • The media server loads the client’s account information from the remote application server.
  • The server determines if the client is a valid customer or not and if yes do they have sufficient credits (value currency) to access the stream.
  • If the client verification succeeds, the server reads the current currency balance into memory and initializes a local timer to track the usage in real-time. Within the timer, a logic evaluates time elapsed & remaining currency balance in real-time.
  • If the currency worth of the customer gets exhausted during the session, the server will disconnect the client from the live session & the UI on the web page will notify the cause of the disconnect.
  • The timer will periodically keep appraising the application server of session duration in real-time.
  • When the session ends normally either due to termination on the model’s side or closure on the customer’s side the media server notifies the application server of the total time consumed, which in turn will evaluate & update the database to reflect the remaining virtual currency.

Final Thoughts


After 2020, the year of the pandemic, live streaming is growing at an exponential rate. However, it is important to know that the only thing that fuels growth is revenue generation – via ads, subscription models, or direct payments (pay-per-view). Some techniques are more viable to live streams while some are more geared toward video on demand.

Whether you are a business owner or a developer, your aim should always be to discover and implement innovative revenue-generation techniques for your streaming application.