Your software helps companies to manage their customers' subscriptions efficiently[1]especially when it comes to usage-based subscriptions, where accurate billing of usage data is important. In 2023, Zuora introduced a new feature: the Mediation Engine. This allows companies to easily assess and bill large amounts of usage data via a drag-and-drop interface[2] and simply implement the processing of usage data as a "no-code" or "low-code" variant.
At doubleSlash, usage-based pricing has so far been implemented with specially developed code. The aim is to implement and test usage-based pricing with the Zuora Mediation Engine and Zuora Workflows. Zuora workflows make it possible to define and automate business processes ranging from simple to complex procedures.
The focus of this article is on the billing of usage data in the area of e-mobility charging stations. Existing sample data containing detailed information on charging processes will be used. The aim is to explore the possibilities of the Zuora Mediation Engine and workflows and to identify possible challenges
Four application examples from e-mobility
To explore this, we modeled four different consumption-based subscription models for the e-mobility charging station scenario in the PoC:
1. billing according to kilowatt hours charged
- Billing is based exclusively on the kilowatt hours actually charged.
2. combination of basic fee and kilowatt hours
- A fixed basic fee is charged, which covers a predefined kilowatt hour quantity. Additional costs are incurred if usage exceeds this amount.
3. Additional costs for parking and blocking time
- In addition to the fixed basic fee and the kilowatt hours used, the parking and blocking times (excluding charging time) are also charged.
4. time-based billing with different remuneration
- Billing is based on the time used, whereby charging times are remunerated differently to parking times.
Technical implementation with the Zuora Mediation Engine
An exemplary Zuora Mediation Engine is used for this PoC[3] as shown in the following illustration.
Starting point of the mediation Engine
The starting point of the Mediation Engine is the "source", in this case the "Streaming API". This API generates a unique upload URL that can be used to call the mediation engine via an internal workflow callout. The usage data is transmitted via a POST HTTP request in JSON format in the body[4].
Mapping of usage data
In the first step, the usage data is transformed into a Zuora object. The expected fields from the JSON file must be known. One challenge is that the data format can vary depending on the provider.
Data processing by "processors" in the Zuora Mediation Engine
The Mediation Engine offers various "processors" for data processing, such as aggregators or deduplicators. However, only the "Filter" and "Advanced Transformer" processors were tested in the PoC, as no others were required:
- FilterEnable simple checking and filtering of the transmitted data using simple logic, e.g. to ensure that the amount charged is greater than 0 kWh.
- Advanced TransformerEnables the data to be edited or enriched using JavaScript or Python. In the PoC, the data was enhanced with measurement unit tags and the calculated pure loading time. This requires small sections of code within the "Advanced Transformer".
Storage and billing the usage data
Finally, the processed data can be entered as usage records (e.g. charged kWh, parking time and charging time) for the corresponding accounts in Zuora and later billed when invoices are created. In the PoC, the corresponding account numbers could be extracted from the usage data. Normally, this requires a mapping between the authentication number of the usage data and the Zuora account number of the customer.
Challenges and recommendations
Although the creation and billing of usage data with the mediation engine shown works in principle, it makes little sense to cover the four different subscription models with a single mediation engine. Both the times and the kilowatt hours are always saved as usage, but are not required for billing for all models. It is therefore advisable to create different mediation engines for the corresponding usage records as required.
There are also difficulties when the use of the same unit of measurement is applied to different charges, for example for parking and charging times. Here, the identification number of the charge is essential in order to correctly allocate the usage data.
Zuora Mediation Engine: Insights and learnings
In summary, it can be said that the Zuora Mediation Engine in combination with the workflows basically worked for the use cases presented. For more complex tasks, however, a more sophisticated solution is required. It became clear that some code is required in the Mediation Engine, especially for "Advanced Transformer" to process the data, which indicates that it is not a completely "no code" solution.
Open questions regarding the scope of use of the Mediation Engine, the need for separate engines for each subscription model and the handling of different data formats require further in-depth study of the Zuora Mediation Engine.
Despite these open points, the Zuora Mediation Engine and Zuora Workflows show promising potential. These tools offer possibilities that can be further explored and optimized in future studies and projects. It remains exciting to see how these technologies can be used in different scenarios and what insights can be gained from them.
Further links:
- Find out more about the collaboration between doubleSlash and Zuora.
- Subscription management for public charging
- doubleSlash services in the area of Subscription Management
Sources
- [1] https://www.zuora.com/de/products/billing-software/
- [2] https://www.zuora.com/2023/11/07/rev-up-your-consumption-strategy-with-zuora-mediation-engine/
- [3] Overview: https://knowledgecenter.zuora.com/Zuora_Central_Platform/Mediation
- [4] API Reference: https://developer.zuora.com/api-references/api/overview/
Learn more about Connected Mobility
