We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Revenue Sharing & Settlement System - FIWARE Forge Wiki

Revenue Sharing & Settlement System

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Target usage

In the Future Internet there is a need to manage in a common way how to distribute the revenues produced by a user‘s charges for the application and services consumed. When a customer buys an application or service, he pays for it. But this charge can be distributed and split among different actors involved (for instance marketplace owner earns money and mash-ups have to split the money).

User roles

  • Managers will setup available business models and parts of them are the revenue share model.
  • Service provider will setup revenue share model associated to Applications and services, and they have to be loaded in the Revenue Settlement & Sharing System.
  • Developers have to know about the revenues of their applications and services.
  • Involved service/applications providers have to know about the revenues of their applications and services.

GE description

In the services oriented environments, there will be a common pattern for services delivery: it does not matter the type of service, each time there will be more composite services based on the aggregation of multiple atomic services. Beyond the complexities of the management of composite services (design, provision, etc.), there is a complex issue to solve when dealing with the business aspects. Both the composite and the atomic services must be accounted, rated and charged according to their business model, and each of the service providers must receive their corresponding payment. The service composition process will end up in a value network of services (an oriented tree) in which the price model of each service and its share of participation in the overall services is represented. On the other hand, depending on its business model, the business framework may play different roles in relation to the service providers. These realities will lead to different scenarios in which the revenues generated by the services must be settled between the service providers:

  • If the business framework charges the user for the composite service, a settlement process must be executed in order to redistribute the incomes as in a clearing house.
  • If the business framework charges for all the services in the value network, then besides the settlement function, there could be a revenue sharing process by which a service provider might decide to share a part of its incomes with the service provider that is generating the income.

Figure 49 Payments, Settlement and Revenue Sharing in a Services Value Network In this context, a service must be understood in a broad sense, that is, not only as a remote decoupled execution of some functionality, but also considering other types of services: the business framework itself, content services, advertisement services, etc. Nowadays, there are some examples in which revenue distribution is needed. The best known example is Apple Application Store21, which pays a percentage of the incomes form an application download to its developer. Another example is Telco API usage. There are two sides like Telefónica‘s BlueVia22 or Orange‘s Partner23, in which the application developers receive revenue share for the usage of Telco APIs by the final users. There are also examples of this in the cloud computing services, like dbFlex24 and Rollbase25 The Figure 50 shows a conceptual architecture of a system for settling and sharing revenues. There are a number of different sources of revenues for a given service that will be integrated and processed according to the business model of each service and the revenue sharing policies specified for each partner. The final revenues balance will be transferred to a payment broker to deliver the payments to each provider/developer.

Functionality

  • Receive or interact with other external system for loading business models models regarding sharing and settlement.
  • Define and store the different revenue sharing models to be applied taking into account Application and Services Ecosystems business models.
  • To receive, store and load call data records or charging logs about the different sources of charges of the application and services ecosystem to the customers.
  • Creation of aggregated information and data to be used to distribute the revenues.
  • The information of developers or users to be paid has to be stored.
  • Daily revenue share execution and generation.
  • Payment file generation and sending to the payment broker.

Critical product attributes

  • Revenue sharing models must be customizable.
  • There must be available simulations of RS models in real time.
  • High scalability and high volume of CDRs
  • There must be possible to process different revenue sources.
  • Report generation API to extract information.

Existing products

There exist various application stores and service ecosystem from different domains. There are well known examples like AppStores (Apple, Google, and Amazon) and BlueVia and Orange Partner initiatives from the Telco world. Inside his commercial products exists similar systems that provides this functionality.


Personal tools
Create a book