Navigating Tariff and Fee Implementation in OCPP

Summary

The Open Charge Point Protocol (OCPP) 1.6 is the most widely deployed communication standard in the electric vehicle (EV) charging industry, but it contains a critical omission: the lack of a standardized, native method for communicating tariff and fee to the driver. This forces network operators and hardware manufacturers to implement custom solutions, creating a fragmented landscape with significant interoperability challenges.

Navigating Tariff and Fee Implementation in OCPP

This report provides a comparative analysis of the three primary approaches used to solve this problem:

  1. Fully Custom OCPP 1.6 Implementations: Proprietary solutions using the DataTransfer message, developed independently by vendors. This approach offers flexibility but creates a high risk of vendor lock-in and poor interoperability.
  2. Semi-Custom OCA-Standardized Implementations: A “best practice” approach for OCPP 1.6 that uses the DataTransfer message but adheres to the specifications in the Open Charge Alliance (OCA) white paper, “OCPP & California Pricing Requirements.” This method provides a vital, semi-standardized bridge to interoperability.
  3. Native OCPP 2.0.1 Implementation: The official, future-proof solution. The newer, non-backward-compatible OCPP 2.0.1 protocol includes a dedicated “Tariff and Cost” functional block, which standardizes all aspects of price communication natively.

Our central finding is that while custom solutions for OCPP 1.6 are a present necessity, their long-term viability is questionable due to interoperability risks. The OCA’s white paper offers the most robust path forward for existing 1.6 networks by creating a common, shared custom protocol. However, for new deployments, the native, feature-rich, and fully standardized capabilities of OCPP 2.0.1 represent the definitive and most strategically sound solution. This report details the technical specifications, pros, and cons of each approach, concluding with a decision framework for developers, network operators, and product managers.

▶ Part I: The Baseline – The Challenge of Pricing in OCPP 1.6

The core of the pricing problem lies in the architecture of OCPP 1.6. Released in 2015, the protocol’s standard messages like StartTransaction and StopTransaction reliably handle the metering of a charging session (e.g., energy consumed, duration) but have no fields to convey cost. Billing is a back-end process; the Central System (CSMS) calculates the cost after the session ends, a process invisible to the charger and the driver during the transaction.

This limitation makes it impossible for a standard-compliant OCPP 1.6 charger to display critical information like the price per kWh before charging, a real-time running cost, or a final itemized receipt on its screen. To bridge this gap, the industry has turned to the DataTransfer message, a mechanism within the protocol’s Core profile designed explicitly for vendor-specific extensions. This message is a blank slate, allowing vendors to send any custom data they define. While this enables functionality, it also opens the door to a fractured ecosystem where every CSMS and charger pair speaks a different proprietary “dialect” for pricing, undermining the core promise of an open standard.

▶ Part II: The Spectrum of Solutions – A Head-to-Head Comparison

Three distinct strategies have emerged to handle rate and cost communication. They exist on a spectrum from complete vendor freedom to full industry standardization, each with significant trade-offs in interoperability, complexity, and future-readiness.

Table 1: Comparative Analysis of Pricing Implementation Solutions

Navigating Tariff and Fee Implementation in OCPP Table

Solution 1: Full Customization (Proprietary DataTransfer)

This is the most basic and most fragmented approach. A hardware manufacturer and a CSMS provider agree on their own private DataTransfer message format to exchange pricing information.

How it Works:

The vendor defines a unique vendorId and one or more messageId values to identify their pricing commands. The data payload, containing the price information, is structured according to their private specification.

Pros:

Total Flexibility: The vendor has complete freedom to design a protocol that perfectly suits their specific hardware capabilities or business logic.

Cons:

  • No Interoperability: A charger using this method can only work with the specific CSMS that understands its proprietary messages. Switching CSMS providers would require a complete firmware replacement on the charger.
  • High Vendor Lock-In: This approach creates a tightly-coupled, closed ecosystem, which is the primary risk that OCPP was created to prevent.
  • High Development Overhead: Requires designing, documenting, and maintaining a unique protocol, increasing complexity and cost.

Solution 2: OCA Semi-Customization (Guided DataTransfer)

To combat the fragmentation of proprietary solutions, the Open Charge Alliance (OCA) published the “OCPP & California Pricing Requirements” white paper. This document defines a standardized way to use the DataTransfer message for pricing, creating a common, open specification that any vendor can adopt.

How it Works: 

Implementations use a specific, shared vendorId: org.openchargealliance.costmsg. This signals that the charger and CSMS are communicating using the message structures defined in the OCA white paper. The specification details the exact JSON payloads for messages like SetUserPrice, RunningCost, and FinalCost, effectively emulating the functionality of a native solution.

Pros:

  • Greatly Improved Interoperability: Any charger and CSMS that both implement the white paper specification can communicate pricing information seamlessly.
  • Reduced Vendor Lock-In: A network operator can switch between any CSMS providers that support this standard without being locked into a single vendor’s proprietary technology.
  • Clear Development Path: Provides a public, authoritative blueprint that eliminates the need for vendors to design their own protocols.

Cons:

  • Adoption Dependent: Its effectiveness relies on widespread adoption by both hardware and software vendors.
  • Still a Workaround: It remains a custom extension layered on top of OCPP 1.6, not a native feature of the protocol itself.

Solution 3: Native Implementation (OCPP 2.0.1 “Tariff and Cost”)

The definitive solution is found in OCPP 2.0.1, the latest major version of the protocol. It was designed from the ground up to address the shortcomings of 1.6 and is not backward-compatible. It introduces “Functional Blocks,” and the “Tariff and Cost” block provides a complete, standardized, and native solution for all pricing communication.

How it Works:

The “Tariff and Cost” functional block includes a set of standardized messages and data structures that are an official part of the protocol. This allows any OCPP 2.0.1-compliant charger to communicate with any compliant CSMS to display detailed tariff information before a session, show a real-time running cost, and present a final cost at the end. This functionality is built-in, requiring no custom extensions.

Pros:

  • Full Standardization: As part of the official protocol, it guarantees the highest level of interoperability and is supported by the official OCPP certification program.
  • Richest Feature Set: Offers the most comprehensive and flexible pricing capabilities, designed to meet current and future market needs, including complex dynamic tariffs.
  • Future-Proof: Aligns the charging infrastructure with the latest industry standards and regulatory trends demanding price transparency.
  • No Vendor Lock-In: This is the core benefit of a truly open and complete standard.

Cons:

  • Slower Market Adoption: As a newer and non-backward-compatible protocol, the installed base of OCPP 2.0.1 is currently smaller than that of 1.6.
  • Perceived Complexity: The full OCPP 2.0.1 specification is much larger than 1.6, which can be intimidating. However, its modular design allows for minimal implementations that are comparable in size to a 1.6 stack.

▶ Part III: Strategic Implications and Decision Framework

The choice between these three solutions has significant long-term consequences for cost, flexibility, and interoperability.

  1. For New Infrastructure Deployments: The strategic choice is to mandate OCPP 2.0.1. While the initial pool of compliant hardware may be smaller, this approach completely avoids the pricing problem, eliminates vendor lock-in, and ensures the infrastructure is ready for future requirements like advanced smart charging and Vehicle-to-Grid (V2G) integrations. It is the most capital-efficient decision in the long run.
  2. For Existing OCPP 1.6 Networks: When adding pricing functionality to an existing network, the most prudent path is to adopt the OCA’s “California Pricing Requirements” white paper as the implementation standard. This provides a bridge to interoperability and allows for mixing hardware and software from different vendors, provided they all support this common specification. When evaluating vendors, a critical question is whether their DataTransfer implementation is compatible with the org.openchargealliance.costmsg standard.
  3. Dealing with Fully Custom Solutions: A fully proprietary DataTransfer implementation should be considered a high-risk technical debt. It tightly couples the operator to a single vendor’s ecosystem and creates significant barriers to switching platforms or integrating new hardware from other manufacturers. This approach should be avoided wherever possible.

▶ Conclusion

The communication of tariff and fee remains a pivotal challenge in the EV charging ecosystem, directly impacting user transparency and operator business models. The evolution of solutions from proprietary DataTransfer messages in OCPP 1.6 to the native “Tariff and Cost” functionality in OCPP 2.0.1 reflects the industry’s maturation toward greater standardization and interoperability.

While fully custom implementations offer a quick but risky fix, the OCA’s semi-standardized white paper provides a crucial and highly recommended pathway for the vast installed base of OCPP 1.6 equipment. It balances the need for functionality with the goal of an open ecosystem. Ultimately, however, the future is clear: OCPP 2.0.1 is the definitive solution. Its native, standardized, and feature-rich approach to handling tariffs and costs eliminates the ambiguity and risk of custom workarounds, offering the most robust, interoperable, and future-proof foundation for the next generation of EV charging infrastructure.

WiseWish Technology’s WIS901 series OCPP protocol gateways can already implement OCA semi-customized rate and cost functions based on OCPP1.6 for charging point manufacturers. The OCPP2.0.1 protocol gateway is under development and is expected to be submitted to manufacturers for testing and connected to a platform that supports OCPP2.0.1 before the end of 2025.

admin